月曜の朝、09:08。社内 LAN にいる一般社員側の窓口から内線が入る。

「社内の PC から自社のサイトが開けません。自分のスマホ(4G)からは同じ URL が普通に開けるので、急ぎの確認はそちらでやっています。会社の PC で開きたいので、状況を見てもらえますか」

受話器を置くと、横で瀬戸が同じメモを覗き込んでいる。研修担当の氷室が斜め向かいの席で、湯気の立つマグを置いたところだ。

「外からは開けてるんだから、社内の DNS が壊れてるってことですよね? 名前解決を直してもらう連絡だけ、先に走らせちゃっていいんじゃないですか」と瀬戸が言う。

氷室の動きが止まる。

外から開けて中から開けない、を、名前解決の不具合、と読み替えない

「はぁ? なんでそうなるのよ」と氷室。「あんた、申告のどこに『名前が引けない』って書いてあるの。社内 PC から開けない、自分のスマホでは普通に開ける、急ぎの確認はそっちで回している。それと『社内の DNS が壊れている』、別の話なんだけど」

「あ…たしかに、利用者の人は『開けない』としか言ってないです」と瀬戸。

「いい? 社内から開けない、は事実。社内の名前解決が壊れている、は仮説。勝手に混ぜない」と氷室は赤ペンの先で瀬戸のメモを指す。「『DNS の不具合』って書いて他チームに連絡入れたら、社外網からは同じ URL が普通に開けている事実と、なぜ社内側だけ開けないのかを観測する手が、最初から消えるの。混ぜたまま利用者側に『DNS 障害です』と返したら、相手は『じゃあ DNS を直せば終わるのか』としか思えなくなる」

「でも、社外からは開けて社内からは開けないんだから、社内側の何かがおかしいですよね? それって名前解決じゃないんですか?」と瀬戸。

「ちょっと、今の本気で言ってる?」氷室は赤ペンのキャップを音を立てて閉じる。「社内側の何かに違いがある、は事実の側。それが『名前解決の不具合』だ、は一歩飛んだ解釈。同じ URL が外から開けて中から開けない、は名前解決の話に決め打ちできる並び方をしてないの。社内から名前を引いた結果がどう出ているかは、まだ手元にあるものを見ないと言えない」

「つまり、『社内から開けない』と『社外からは開ける』は別の欄に置いて、その差を『名前解決の不具合』と呼ぶのは、社内から名前を引いた結果まで見てから、ってことですか?」

「事実の欄と解釈の欄を、やっと分けられたわね」

社外で開けて、社内で開けない、を、手元の事実だけで並べ直す

あなたは紙の上にいったん、いま見えている事実だけを並べ直す。

社内 PC から自社サイトの URL に curl を投げる。5 秒のタイムアウトを設定しても、接続自体が成立せずに落ちる。同じ社内 PC から、同じドメインで名前を引いてみる。社内の名前サーバから、サイトの公開アドレスが普通に返ってくる。応答自体は出ている。続いて、社内 PC の手元情報も拾う。社内 LAN のセグメントから割り当てられたアドレスを持っており、社外向けの通信は社内 LAN の出口へ向くようになっている。社内 LAN 側から見える範囲では、通信は通常どおりに出ていく構成になっている。

社員側にもいったん、4G テザリングや自宅の回線でその URL を試してもらう。普通に開く。同じ URL に対して、社外網からのリクエストには応答が返り、社内 LAN からのリクエストでは接続自体が成立しない。応答が返らないのは、社内 LAN から投げた場合だけだ。

「えっと…社外網からは普通に開けてて、社内からだけ届かない、ってことですか」と瀬戸が小声で言う。

氷室は無言でうなずく。「そこまでは事実。なぜ同じ URL で、社外網からは開けて社内 LAN からだけ開けないのかは、まだ手元の材料からは言えない。だけど、社外網と社内 LAN で結果が分かれている、社内から名前を引いた結果は公開アドレスが返っている、社内 PC の手元設定は社内 LAN の出口へ普通に向いている、は今の手元にある、いちばん効いている材料よ」

一般社員側に先に短く戻す

社員側の窓口は、業務でその資料を見たがっている。氷室への初報補足を出す前に、先に社員側へは短く返しておく。

「利用者の人に、社外網と社内の両方を試してくれてありがとうございます、って書いた方が、ちゃんと見てますって伝わって安心しますよね?」と瀬戸。

「ちょっと、その仮説は何で支えるの?」と氷室。「あんた、社員の人が御礼の文を見て何を判断できると思ってるわけ?」

「えっと…社員の人は、会社の PC でその資料を見たいだけ、です」

「そう。先方が判断に使えるのは、影響、いまどう業務を回しているか、復旧の見込みがどこまで言えて、次にいつ連絡が来るか。これだけよ。社内の名前解決まで触ると、相手は読む情報量に対して何を待てばいいか分からなくなる」

「つまり、影響、すでに取られている暫定運用、復旧見込みの扱い、次回更新の四つだけ、ってことですか?」

「社員側に渡す範囲、ようやく四つの欄に絞れたじゃない」

社員側はすでに「急ぎの確認は 4G の方で回している」と言っている。これはこちらが許可した暫定運用ではなく、先方の現状として扱う。社員側へ返すのは、この現状を踏まえた短い共有だ。

社内 LAN から自社サイトへの接続が確立しない事象を確認しています。社外網からは同じ URL が開けることまでは確認済みで、すでにお進めいただいている 4G 経由での閲覧を継続いただきつつ、復旧見込みは確認が進んだ時点で次回更新としてお伝えします。

復旧見込みの時刻はまだ出していない。出せる根拠が手元に無いからだ。

氷室へ見せる初報補足の五つの欄

ここからが、今回まとめる主成果物だ。氷室は社員向けの文章の添削者ではなく、次に誰を動かすか、原理面で叩き返してくる相手として座っている。

紙の上で、欄を五つに分ける。

1. 利用者向け共有

   社員側窓口へ返した内容と、復旧見込みは次回更新で扱う旨。急ぎの資料閲覧は 4G 経由で回している、という先方の現状もここに残す。

2. 影響と現在の課題

   社内 LAN から自社サイトへの接続が確立せず、社外網からは同じ URL が普通に開ける。申告は複数フロアの社員から出ており、影響は社内 LAN 全体の可能性がある。社員側の現状として、社外網経由での閲覧で暫定対応している。優先したい課題は、なぜ同じ URL に対して社外網からは応答が返り、社内 LAN からだけ接続が成立しないのかを言える材料を、観測で取りに行くこと。

3. ここまでの観測

   • 社内 PC から自社サイトの URL への接続は、タイムアウトまでに確立しない。
   • 同じ社内 PC から、社内の名前サーバ越しに同じドメインを引くと、サイトの公開アドレスが普通に返る。応答自体は出ている。
   • 個人回線(4G テザリングなど)の社外網からは、同じ URL が普通に開く。サイト自体は外から到達できている。
   • 社内 PC の手元アドレスは社内 LAN のセグメントから割り当てられており、社外向けの通信は社内 LAN の出口へ普通に向いている。
   • 同じ URL に対して、社外網と社内 LAN で結果が分かれていることまでは観測が支えている。

4. 次に確認すること

   社内 LAN から、サイトの公開アドレス宛に向かう通信が、社内 LAN の出口で通常どおりの取り扱いを受けているかを確かめる。直近で出口側に手が入った経緯があるかも併せて拾う。社外網からは届いて社内 LAN からだけ届かない、という分かれ方を作っている場所は、回線そのものや名前解決の話ではなく、社内側の出口での通信の取り扱いに残っていそうだ、というところまでは観測が示している。出口側の取り扱いを並べてから、次の判断に進む。

5. 判断が必要な条件

   • 出口側の通信の取り扱いに差が見えた場合、変更条件と切り戻し条件を整えてから次の検証へ進めるかを氷室と相談する。
   • 影響が顧客接点系サービスや、広報・問い合わせ業務へ広がる場合は、部門責任者へ上げる。
   • 復旧見込みは、出口側で何が起きているかが見えた時点で社員側窓口へ更新する。

「『DNS 障害』って書いた方が、氷室さん的に親切じゃないですか?」と瀬戸が紙を覗き込む。

「書きたくなるのは分かる」と氷室。「だけど、観測が支持していない名前を欄に入れると、その名前に合わせて後の判断が引っ張られるの。社内から引いても同じ公開アドレスが返ってきている、は『ここまでの観測』に置いていい事実。ただし、それを『DNS の不具合』として紐づけるのは、出口側の取り扱いがどう違うかを並べてから書いて」

書いていないことのほうから確認する

五つの欄を、書いてあるものではなく、書いていないもののほうから見直す。氷室に渡す前のチェックだ。

書いていないこと、ひとつ。原因の名前。社外網からは普通に開けて、社内 LAN からだけ接続が成立しない状況を起こしうる仕組みは、社内側の出口での通信の取り扱いを並べてからでないと、いまの材料だけでは絞れない。

書いていないこと、ふたつ。修正の手順。どこを変えるか、戻すならどう戻すか、どこで確認するかは、出口側で社内 LAN からの通信がどう扱われているかが見えてからの話だ。順番を入れ替えると、検証材料が手元に残らない。

書いていないこと、みっつ。復旧見込みの時刻。「何時までに直します」を書いていない。出口側の取り扱いが見えていない段階で時刻を約束すると、その時刻になって何も言えなかった場合、社員側にもう一度訂正の連絡を入れることになる。

書いていないこと、よっつ。「社内 DNS が同じアドレスを返している」を「名前解決は問題ない、回線も問題ない」と一気に読み替える言い切り。社内側で名前を引いた結果が、公開アドレスをそのまま返している、は『ここまでの観測』に置いてある事実だ。だが、それを「ネットワーク全体は問題ない」のような原因方向の言い切りへ昇格させる根拠は、手元の観測にはない。同じ URL に対して社外網からは応答が返り、社内 LAN からだけ接続が成立しない、という分かれ方は、そこから先を観測しないと言葉にできない。

次の確認は、社内側の出口で通信がどう扱われているかを並べることから

ここまで来ると、初報補足の整理としてはひとまず形になる。社員側には先に短く戻し、氷室には次の動きを決める五つの欄を渡せる状態だ。

残っているのは、「社外網からは開けて、社内 LAN からだけ開けない」を、社内側の出口での通信の取り扱いとして並べるところだ。

「社内 DNS の再起動だけ、先に出口側のチームへ依頼しちゃえば、いったん名前が引けてアクセスもできるんじゃないですか? それでだめなら、出口の取り扱いを見直す、で」と瀬戸が言ってしまう。

氷室の赤ペンが机を一度叩く。「あんた、社内から引いて公開アドレスがちゃんと返っている、その紙が目の前にあるのよ。それを見ないで再起動を入れるって言ってるの? 名前解決を触っても、社外網からは開けて社内 LAN からだけ届かなかった、という分かれ方を作っていた場所が、手元から全部消えるのよ。それに、いま手元にあるいちばん効いている材料は、社内から引いたアドレスと社外網から開けたアドレスが、どちらも同じ公開アドレスだったこと。そっちを生かしたまま、社内 LAN からそのアドレス宛に通信を出した時、出口側でどう扱われているかを並べるのが先」

「えっと…先に DNS を触ると、なぜ社外網からは開けて社内 LAN からだけ届かなかったかの材料も消えちゃう、です」

「だから、まず、社内 PC から同じ公開アドレスへ向かう通信が、社内 LAN の出口でどう取り扱われているか、そこを並べるの。社外網からは届いて社内 LAN からだけ届かない、という分かれ方を作っている場所は、その並びの中で初めて見える。先に並べてから、必要なら触る」

「つまり、社内側から公開アドレスへ向かう通信の、出口側での取り扱いを並べて、そこに違和感があるかを確かめてから、変更を考える、ってことですか?」

「『先に並べてから触る』の順番、ようやく腑に落ちたわね」

机の上に並んだのは、社内 PC からの接続不成立、社内で引いた名前解決の応答、社外網からの閲覧成功、社員側の 4G 経由での暫定対応。氷室に渡す欄は五つに分かれた。社員側への返事は短く済んでいる。

通信は一部が通っている。同じ URL に対して、社外網からは応答が返り、社内 LAN からだけ接続が成立しないままだ。なぜそこで分かれているかは、社内側から公開アドレスへ向かう通信が、出口側でどう取り扱われているかを並べてからでないと、欄のどこにも書き足せない。次に取りに行くのは、その並びだ。