月曜の朝9時30分、利用部署の窓口から内線が入った。
「社内端末から社内ポータルが開けません。外で確認した同僚は普通に開けているそうです。急ぎの参照は外部経路で進めていますが、社内側の状況を見てもらえますか」
社内ポータルは DMZ に置いてある社内向けの情報共有サイトで、portal.example.local で開ける。社内からも外部からも同じ URL で参照できる前提で運用されている。利用部署はすでに、急ぎの確認だけ外部経路へ回して凌いでいる。こちらが返すのは「外部経路で続けてください」という許可ではなく、いま社内側で何が起きていて、復旧見込みをいつ更新できるかの分け方だ。
利用部署へ最初に返す材料は、4つに絞れる。社内ポータルが社内側からだけ開けず、業務確認に影響が出ている事実。外部経路で利用部署側がすでに暫定対応を回している事実。復旧見込みはこの時点では出せず、社内側と外部側の通り方の差を裏取りした時点で更新するという扱い。次回更新の出し方。これだけを短く返した状態にしておく。
今回まとめる中心は、その裏側にある。研修担当シニアの氷室へ見せる初報補足だ。氷室は設計課のシニアだが、新人研修担当として運用1チームに常駐していて、こういう時の最初のレビュアーになる。氷室が次に誰を動かすか判断するには、利用者向けに何を返したか、いま影響と何が課題か、ここまで何を観測したか、次に何を確認するか、そして判断が必要な条件は何かが要る。
初報補足に並べる材料
隣の席で同じ画面を見ている瀬戸が、ノートを開いて声を出す。
「外部からは開けてるんですよね。だったらサーバは生きてるってことだから、社内側のネットワークがどこかでぷつっと切れてる、ですよね。社内 LAN の経路を全部見直したらいいんじゃないですか」
氷室が振り向く。
「はぁ? 外部から開けてるからサーバは生きてる、までは合ってる。でもそこから『社内 LAN がぷつっと切れてる』って、何の根拠で決めてるのよ。社内 LAN が物理的に切れてたら、社内ポータル以外の通信も全部落ちるでしょう。あんた、社内端末から社内のメールサーバや他の社内サーバが普通に使えてるかは、確認したの? 確認してないなら、それは観測じゃなくて、ただの想像」
瀬戸はペンを止め、ノートに線を引く。
「えっと、すみません。社内端末から他の社内サーバは普通に使えてます。社内ポータルだけが開けないです」
「そう。じゃあ、社内 LAN 全部が落ちてる、は消える。残るのは、社内端末からこのサーバへ向かう通信だけが落ちてる、っていう事実。これは社内 LAN が切れてるとは別の話よ」
瀬戸は手を動かして、確認した出力を読み直す。社内端末からの curl は5秒で時間切れだ。
$ curl -v --max-time 5 http://portal.example.local/
* Trying 10.1.100.10:80...
* Connection timed out after 5001 milliseconds
* Closing connection
curl: (28) Connection timed out after 5001 milliseconds
同じサーバ、同じ URL に対して、外部側で確認している同僚に頼んで打ってもらった結果はこうだ。
$ curl -sS -o /dev/null -w "%{http_code}\n" --max-time 5 http://portal.example.local/
200
「外部側からは 200 で返ってきています。社内側からは 5 秒で時間切れです」
「それは事実。で、その2つの事実から、いま何が言えて、何がまだ言えない?」
「同じサーバへの通信が、社内側からは届かなくて、外部側からは届いている、までは言えます。原因は……まだ言えないです」
「もう一歩。社内側からだけ落ちている、ってことは、社内側と外部側で通り方のどこかが違う、っていうところまでは絞れる?」
瀬戸はしばらく黙る。氷室が続ける。
「サーバそのものが落ちてたら、外部側からも 200 は返ってこないでしょう。サーバ側で確認した出力も、見たわよね」
$ systemctl is-active nginx
active
$ ss -ltn | grep ':80 '
LISTEN 0 128 *:80 *:*
「サーバ自身は動いていて、80 番でも待ち受けています」
「そう。サーバが生きてて、外部側からは 200 が返るのに、社内側からだけ届かない。これって、サーバの手前で通り方が分かれてるってことよ。社内側から来た通信と、外部側から来た通信を、サーバの手前で別の判断にかけてる場所がある」
「あ、つまり……同じサーバに対して、社内側と外部側で通り方が違う、ってことですか?」
「やっと文になったわね。原因の名前はまだ言わない。でも、社内側と外部側で通り方が違う、っていう事実までは絞れた」
「じゃあ、すぐサーバを再起動してみたらどうですか。生きてるって言っても、何か中で詰まってるかもしれないし」
氷室の声が低くなる。
「はぁ? 外部側から 200 が返ってきてる時点で、サーバの中身は応答できてるって読めるでしょう。再起動するなら、何が変わるはずだから打つ、って言えなきゃダメ。今ここで再起動して、外部側の 200 が消えたら、見えてた事実まで自分で潰すことになるの。観測を消す操作は、今やる仕事じゃない」
「あ、そうか……今ある観測を残したまま、次の確認に進むんですね」
「そう。観測を消さずに、社内側と外部側で通り方が違うっていう事実を、サーバの手前にある判断材料で裏取りする。これが次の一手」
「つまり、社内側から来た通信と外部側から来た通信を、サーバの手前で別の判断にかけている場所を、いま社内に置いてある機器の中から探して、その判断の中身を読む、ってことですか?」
「やっとまともな文になったじゃない。ただし、もう一段詰めなさい。サーバの手前って言ったけど、社内側から DMZ のサーバへ向かう通信は、社内端末を出てから、社内側と DMZ をまたぐ機器を通って、サーバに着く。外部側から来た通信は、外部を出てから、外部側と DMZ をまたぐ機器を通って、同じサーバに着く。両方の経路で、どこが共通でどこが違うのか、頭の中で並べてごらん」
瀬戸はノートを真ん中で線を引き、左に「社内側」、右に「外部側」と書き、それぞれの経路を矢印でつないでいく。
「社内側からは、社内端末→社内と DMZ をまたぐ機器→サーバ、です。外部側からは、外部の端末→外部と DMZ をまたぐ機器→サーバ、です。サーバ自身は同じです。違うのは……まただ機器のところ、ですか?」
「そう。同じサーバへの通信なのに、通り抜ける機器が違う。だから機器ごとに別の判断が掛かっている可能性がある。今、外部側からの判断は通って、社内側からの判断は通っていない。両方が同じ機器で判断されているのか、別の機器で判断されているのかは、今の手元の出力だけでは分からない。でも、社内側と外部側で判断が分かれている事実までは確かよ」
「それを、機器の名前で先に言わずに、社内側と外部側で判断が分かれている、っていう事実として残すんですね」
確認した範囲
ここまでで、手元に集まっている材料を整理する。
利用部署の窓口からの連絡で、社内ポータル portal.example.local が社内端末から開けないと分かった。外部側で確認している同僚は同じ URL を普通に開いている。社内端末からの curl は 5 秒で時間切れ、外部側からの curl は 200。サーバ側で systemctl is-active nginx を見ると active、80 番の listen も生きている。社内端末から、社内ポータル以外の社内サーバは普通に使えている。
社内側と外部側のあいだに置かれている境界機器の interface 状態だけは、変更を加えずに見ておく。
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 203.0.113.1 YES manual up up
GigabitEthernet0/1 10.1.0.1 YES manual up up
GigabitEthernet0/2 10.1.100.1 YES manual up up
外部側の interface、社内側の interface、DMZ 側の interface のいずれも、リンクも上位も up だ。物理的なつながりや、interface の状態としては落ちていない。
ここまでで言えるのは、社内側と外部側で同じサーバへの通り方が違う、というところまでだ。サーバが生きていることと、interface が up であることは確認できているが、サーバの手前で社内側からの通信だけが落ちている理由は、まだ手元では区別できていない。先週、社内側と外部側の通り方を分ける判断を整理する作業が境界機器側で入っていたという話も、運用1チーム内では出ている。これが今回の事象とつながっているかは、今の手元の出力だけでは判断できない。
瀬戸がメモを読み返す。
「curl が落ちた、を原因の名前にせずに、社内側と外部側で通り方が違うところまでで止めるんですね」
「そうよ。続報で、サーバの手前の判断材料を実際に開いて、社内側からの通信が何で落ちているかを読めば、確度を上げられる。いま無理に断定して、後で間違ってましたって言う方が、利用部署にとっても運用にとっても痛い」
LAB を開ける場合も、開けない場合も、ここまでに使った材料は同じだ。利用者の申告、社内端末からの curl、外部側からの curl、サーバ側の稼働確認、境界機器の interface 状態。これらを Show / Config として開く順番が、Stage 1 として用意されている。同じ順序で読めば、LAB がない側でも同じ場所まで来られる。
氷室への初報補足の前に整える
氷室へ見せるのは、利用者向け共有、影響と現在の課題、ここまでの観測、次に確認すること、判断が必要な条件の5つに分かれた整理だ。利用部署へ短く返した内容は、その先頭の「利用者向け共有」に短く要約して入る。原因、修正内容、恒久対処、再発防止案は、まだここに書くものがそろっていない。追加観測と復旧確認がそろってから、続報や報告書で扱う。
注意したいのは、「次に確認すること」の書き方だ。具体的なコマンド名や、社内側と外部側の判断を分けている仕組みの名前を、いまここで先取りして並べると、氷室が確認したい「どこまで観測で詰めて、どこから仮説か」が見えなくなる。同じサーバへの通信が、社内側と外部側で通り方が違う事実を、サーバの手前にある判断材料と先週の作業記録で裏取りする必要がある、というところまでに止め、何を読むかの選択は、選択式チェックで自分の言葉として選ぶ。
「影響と現在の課題」には、社内ポータルが社内側からだけ開けていないこと、外部経路の暫定対応がすでに利用部署側で回っていること、社内側だけ落ちている事実をどう絞り込むかが残っていることを入れる。「ここまでの観測」には、社内端末からの curl 失敗、外部側からの curl 成功、サーバ稼働、境界機器の interface up を、原因確定ではなく事実として並べる。
「判断が必要な条件」は、影響が社内全体や DMZ 上の他サーバへ広がる場合に部門責任者へ上げること、対象の判断材料・期待状態の根拠・戻し方・変更後の確認が揃うまで設定変更には進まないこと、申告時刻と確認した出力と利用部署へ共有した内容を記録に残すこと、と書く。氷室はここを読んで、いま動かす相手と、まだ動かさない相手を分ける。
「次に確認すること」が終わるまでは、観測だけで残りを詰める段に居る。社内側からの通信がサーバの手前で何によって落ちているのか、先週の作業記録のどの判断と関係するのか、その判別が揃って初めて、何をどう戻すか、別の手当てを当てるかが選べる側面に変わる。
瀬戸がノートを閉じながら言う。
「いま僕が氷室さんに渡せるのは、利用部署に短く返した内容と、社内側と外部側で通り方が違う事実、サーバが生きていて interface も up な観測、まだ詰められていない読みの3点ですね。原因の名前を当てに行く文じゃなくて、観測でどこまで進んだかの文として書く」
「そう。それを5つの欄に入れなさい。文の体裁が整ったら、私が見るわ」
氷室に渡すまでに残っている選択
ここから先は、あなたが整える。利用部署の窓口に短く返した条件を「利用者向け共有」へ落とし、影響と現在の課題、ここまでの観測、次に確認すること、判断が必要な条件をそれぞれの欄に分ける。次の確認の選び方は、選択式チェックで自分の言葉として固める。