月曜の朝、10:04。顧客接点部門の窓口から内線が入る。

「お客様から、貴社の公開 API を呼んだら応答がない、という連絡が入っています。Web サイトのトップは普通に開けるそうです。社内の開発端末から同じ API を呼ぶと、こちらでも応答が返らないと開発側から共有がありました。状況を見てもらえますか」

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

「えっと、Firewall のログ見て、deny って出てなかったら、Firewall は関係ないってことですよね? それ先にお客様に返しちゃっていいですか」と瀬戸が言う。

氷室の動きが止まる。

「deny が出ていない」と「Firewall は関係ない」は別の話

「はぁ? なんでそうなるのよ」と氷室。「あんた、いま何を見て『関係ない』って言ったの。Firewall のログに deny が出ていない、でしょ。それと『Firewall は無関係』、別の話なんだけど」

「あ…たしかに、ログを見ただけです」と瀬戸。

「いい? deny が出ていない、は事実。Firewall は通信を一切触っていない、は仮説。勝手に混ぜない」と氷室は赤ペンの先で瀬戸のメモを指す。「『Firewall は無関係です』って書いてお客様に返したら、どうなると思う? 相手は『じゃあサーバ側ですね』って受け取って、そこから先の確認に移るの。こっちが許可ログだけしか見てないのに、相手の判断は『Firewall は調べ終わった』で動き出すのよ」

「でも、Web サイトのトップは普通に開けてるんですよね? 同じ Firewall を通ってるなら、Firewall はちゃんと通してるって言えるんじゃないですか?」と瀬戸。

「ちょっと、今の本気で言ってる?」氷室は赤ペンのキャップを音を立てて閉じる。「Web サイトトップは応答が返る、は事実。同じ装置を経由しているもう一つの通信は途中で応答が返らない、も事実。同じ装置を通っているのに片方だけ止まっている、というのは、装置が黙って通しているのか、装置が黙って何かしているのか、いまの材料からはどちらにも倒せないの。両方とも書いていいけど、欄を分けなさい。混ぜると、観測で支えてない判断が走り出す」

「つまり、『deny ログに該当の拒否が出ていない』と『Web サイトトップは開ける』は別の欄に置いて、Firewall が無関係だって判断するのは、もう一手観測を入れてから、ってことですか?」

「やっとまともな文になったじゃない」

公開 API は途中で止まり、Web サイトトップは応答が返る

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

まず社内開発端末から、応答が返らないと言われている公開 API へ curl を投げる。タイムアウトを 10 秒に切って手元の挙動を確かめると、TCP 443 への接続自体は通る。Connected to api.example.jp の行は出る。そのあと、応答を待ったまま 10 秒が経過し、何も帰ってこずに切れる。途中で何かを返してから止まるのではなく、応答そのものが返ってこない並び方だ。

続いて、同じ端末から、同じ Firewall を経由して開けている Web サイトトップへ curl を投げる。こちらは TCP 443 への接続が通り、そのまま HTTP/1.1 200 OK の行までが返って終わる。同じ Firewall、同じ TCP 443 を使っているのに、応答の返り方が分かれている。

最後に、顧客接点部門の窓口にも、いま影響しているものを改めて確認する。お客様側でも、公開 API の一部を呼ぶ通信が応答を返さない。手元の業務は、古い接続方法を残しているクライアントへ切り替えて回している。Web サイト経由の閲覧そのものは続けられている。

「えっと…同じ Firewall を通っているはずなのに、片方は応答が返って、片方は途中で止まる、ってことですか」と瀬戸が小声で言う。

氷室は無言でうなずく。「そこまでは事実。なぜ片方は応答が返って、片方は応答が返らないのかは、まだ手元の材料からは言えない。だけど、同じ装置を経由する二つの通信で結果が分かれている、は今の手元にある、いちばん効いている材料よ」

顧客接点部門の窓口へ先に短く戻す

顧客接点部門の窓口は、業務影響を聞きたがっている。氷室への初報補足を出す前に、先に窓口側へは短く返しておく。

「窓口の人に、deny ログは出てなかったって伝えた方が、ちゃんと調べてますって伝わって安心しますよね?」と瀬戸。

「ちょっと、今の本気で言ってる?」と氷室。「あんた、窓口の人が deny ログの有無を見て何を判断できると思ってるわけ?」

「えっと…窓口の人は、お客様に何て返せばいいか知りたいだけ、です」

「そう。先方が判断に使えるのは、影響、お客様側でいま業務をどう回しているか、復旧の見込みがどこまで言えて、次にいつ連絡が来るか。これだけよ。観測の細部を渡すと、相手は読む情報量に対して何を待てばいいか分からなくなる」

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

「やっとまともな文になったじゃない」

お客様側はすでに「古い接続方法を残しているクライアントへ切り替えて業務を継続している」と言っている。これはこちらが許可した暫定運用ではなく、先方の現状として扱う。窓口へ返すのは、この現状を踏まえた短い共有だ。

公開 API への一部の通信で応答が返らない事象を確認しています。お客様側では古い接続方法を残しているクライアントへ切り替えて業務を継続していただいている前提で、Web サイトトップは通常どおりご利用いただけています。復旧見込みは、経路上どこで通信が止まっているかが分かった時点で更新としてお伝えします。

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

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

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

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

1. 利用者向け共有

   顧客接点部門の窓口へ返した内容と、復旧見込みは次回更新で扱う旨。お客様側は古い接続方法を残しているクライアントへ切り替えて業務を継続している、という先方の現状もここに残す。Web サイトトップの閲覧は続けられている。

2. 影響と現在の課題

   公開 API への一部通信だけが応答を返さない。同じ Firewall を経由している Web サイトトップは通常どおり応答が返っている。社内開発端末からも同じ症状を再現できているので、お客様側の端末固有の話ではない。優先したい課題は、なぜ片方は応答が返って、片方は応答が返らないのかを言える材料を、観測で取りに行くこと。

3. ここまでの観測

   • 社内開発端末から公開 API へ curl を投げると、TCP 443 への接続自体は通るが、その先の応答が返ってこずに 10 秒で切れる。
   • 同じ端末から同じ Firewall を経由する Web サイトトップへ curl を投げると、TCP 443 への接続から HTTP/1.1 200 OK の応答までが普通に返ってくる。
   • Firewall のログには、応答が返らない通信に対する deny の記録は見えていない。許可された通信としての記録は残っている。
   • 顧客接点部門の窓口からの声は、お客様側でも公開 API の一部呼び出しは応答が返らず、Web サイト経由の閲覧は続けられている、と一致している。
   • 同じ装置を経由している二つの通信で、応答の返り方が分かれていることまでは観測が支えている。

4. 次に確認すること

   失敗する通信と成功する通信が、経路上どの装置を境にどこで切れているかを観測で出す。同じ Firewall を経由しているのに片方だけ応答が返らない、という分かれ方を作っているのは、経路のどこかで通信が止まっているか、通信が触られているか、いまの手元からはどちらにも倒せていない。失敗側と成功側を並べてから、次の判断に進む。

5. 判断が必要な条件

   • 失敗側と成功側の通信が、経路上どの装置を境に分かれているかが見えた場合、変更条件と切り戻し条件を整えてから次の検証へ進めるかを氷室と相談する。
   • 影響が公開 API 全体や他サービスへ広がる場合は、部門責任者へ上げる。
   • 復旧見込みは、経路上どこで止まっているかが見えた時点で顧客接点部門の窓口へ更新する。
   • 申告時刻、確認した curl 出力、Firewall ログの読み方、窓口へ共有した内容は記録に残す。

「『Firewall は無関係』って書いた方が、氷室さん的に切り分けが進んでて親切じゃないですか?」と瀬戸が紙を覗き込む。

「書きたくなるのは分かる」と氷室。「だけど、観測が支持していない名前を欄に入れると、その名前に合わせて後の判断が引っ張られるの。deny ログに該当の拒否が出ていない、は『ここまでの観測』に置いていい事実。ただし、それを『Firewall は無関係』として紐づけるのは、失敗側と成功側で経路がどう分かれているかを並べてから書いて」

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

紙の五つの欄を埋め終えたところで、氷室がコーヒーを一口飲んで、赤ペンの先で「ここまでの観測」の欄を指す。

「あんた、この欄に書いてないものを、いま頭の中に持ってる?」

「えっと…社内開発端末で curl を打ったときに、最後にどう切れたか、画面に残ってます。あと、Firewall のログで、許可された側の記録が、終わり方が普通と違うのが目に入っていました」

「それ、なんで欄に入れなかったの?」

「いや、まだ何を意味するか分からないし、書くと『これが原因です』って読まれそうで…」

「書け」と氷室。「『ここまでの観測』は、観測した事実を置く欄。意味が言えていなくていい。意味が言える観測しか書かないと、次に観測する人は、いま手元にある材料の半分を失ったまま動くことになる。書く場所を間違えるな、で済む話よ。『次に確認すること』に書いたら原因として読まれるけど、『ここまでの観測』の欄なら、確認した事実として並ぶ」

瀬戸はうなずきながら、観測欄に「TCP は接続するが、応答が返らずに切れる」「許可された側の記録は残っているが、終わり方の中に普段と少し違う点が目に入っている」を書き足す。

「終わり方が違う、は『次に確認すること』のヒント側に置かないんですか?」と瀬戸。

「置かない。終わり方が違うように見える、までが今の手元の事実。それが何を意味しているかは、失敗側と成功側を経路で並べてから読む話。先に意味を入れたら、次に観測する人は、その意味に合わせた出力ばかり探すようになるの。観測の幅が、勝手に狭くなる」

「つまり、観測したことは観測の欄、まだ意味を出せないものも観測の欄、意味は経路で並べてから書く、ってことですか?」

「やっとまともな文になったじゃない」

復旧見込みが書けない初報を、続報で動かす

最後に、氷室が紙の一番下の余白を指す。

「次回更新の条件、書いた?」

「えっと…経路上どこで止まっているかが分かった時点、で書きました」

「それで動く?」と氷室。「あんた、いまの五つの欄の中で、いちばん先に動く欄はどれ?」

「『次に確認すること』、ですか?」

「そう。次に確認することが動けば、ここまでの観測が増える。ここまでの観測が増えれば、影響と現在の課題の言い方が変わる。影響と現在の課題の言い方が変われば、利用者向け共有も次回更新できる。五つの欄は、上から順に書くけど、動くのは下から上に向かってよ。だから、いちばん下の『判断が必要な条件』に、次に確認することが動けば何が変わるか、までは書いておきなさい」

瀬戸は紙の五つ目の欄に、「失敗側と成功側の経路差が見えた時点で、影響範囲と利用者向け共有を更新する」「経路差が他のサービスにも当てはまる場合は部門責任者へ上げ、当てはまらない場合は対象 policy と切り戻し条件をそろえて変更検討に入る」と書き足す。

「最後にひとつ」と氷室。「あんた、いまの初報、お客様には『Firewall は無関係です』って書いた?」

「書いてないです。書きたかったけど、観測が支えてないので、書きませんでした」

「それでいい。許可ログだけを見て『うちの装置は無関係です』って言うのは、いちばん信頼を失う返し方なの。観測の不在は、装置の無関与の根拠じゃない。書いていないことを、書いていないとして残せた初報は、次の更新で信頼を取り戻せる初報よ」

氷室は赤ペンのキャップを閉めて、瀬戸ではなく、あなたの紙の五つの欄を一度だけ見る。

「やっとまともな文になったじゃない」

紙の上にあるのは、復旧時刻が書けていない初報案だ。書けていないことを書けていないと分けたまま、次の確認へ進める材料だけが、五つの欄に残っている。