要約

  • 世界中のデータセンターを切り離したのは、容量を測るための日常的な保守コマンドだった。その種のコマンドを止めるために作られていた監査ツールは、自らのバグによって止められなかった。
  • バックボーンが消えたとき、DNS サーバーは設計どおりに BGP 広告を取り下げた。正しく作動したこのフェイルセーフが、内部の接続断を外部からの到達不能へ変換した。
  • 主系も帯域外も失われ、復旧は施設の前に立つことから始まった。監査ツールがその後どう試験され、誰がその設計を承認したのかは、今回読めた公開記録からは分からない。

Meta は自社のエンジニアリングブログで、何が起きたかをかなり率直に書いている。「More details about the October 4 outage」 から引く。

"During one of these routine maintenance jobs, a command was issued with the intention to assess the availability of global backbone capacity, which unintentionally took down all the connections in our backbone network, effectively disconnecting Facebook data centers globally."

意図は測定であり、結果は全断だった。ここまでは事故の話でしかない。この事案が統制の話になるのは、その次の一文からだ。

"Our systems are designed to audit commands like these to prevent mistakes like this, but a bug in that audit tool prevented it from properly stopping the command."

組織が「持っている」と信じていた統制と、実際に持っていた統制は別物だった。監査ツールは、それ自体がソフトウェアである以上、それ自体の欠陥を免れない。破壊的なコマンドを止める役目を負った検査が、止められる側と同じ種類の可変物で書かれていたという一点に、この障害の性格が集約されている。コマンドが何を対象とし、どの範囲に及び、誰の権限で承認されたのかを示す内部記録は、今回読めた資料の中にはない。したがってコマンドの構文や承認者について、ここで推測はしない。

二番目の統制は、より正確に作動した。Facebook の DNS サーバーは、データセンターと通信できないとき、自らの BGP 広告を撤回するように設計されていた。Meta の説明はこうだ。

"To ensure reliable operation, our DNS servers disable those BGP advertisements if they themselves can not speak to our data centers, since this is an indication of an unhealthy network connection. In the recent outage the entire backbone was removed from operation, making these locations declare themselves unhealthy and withdraw those BGP advertisements."

これは想定外の副作用ではない。設計された動作が、設計された条件の上で実行された結果である。バックボーンが全損したために、すべての拠点が同時に「自分は不健全だ」と宣言し、一斉に手を引いた。内部の切断は、そのまま外部からの到達不能になった。守る対象と運命を共にするフェイルセーフは、正常に動くほど被害を広げる。

外から見えた時間軸は Cloudflare の観測による。「Understanding how Facebook disappeared from the Internet」 は、Cloudflare の DNS リゾルバー 1.1.1.1 上で facebook.com の名前解決がおよそ15:50 UTC に停止し、21:20 UTC に戻ったと記録している。

"It stopped being available at around 15:50 UTC and returned at 21:20 UTC."

Cloudflare は、Facebook が DNS プレフィックスの BGP 広告を停止したのがおよそ15:58 UTC、障害はおよそ5時間半から6時間続いたと報告している。これは Meta が公表した継続時間ではなく、Cloudflare が整理した枠組みである。同じ観測によれば、21:00 UTC 前後に BGP 活動が再開し、21:17 UTC にピークをつけた。

復旧は遠隔操作から始まらなかった。Meta の説明は、当時の制約をそのまま示している。

"Our primary and out-of-band network access was down, so we sent engineers onsite to the data centers to have them debug the issue and restart the systems. But this took time, because these facilities are designed with high levels of physical and system security in mind. They're hard to get into, and once you're inside, the hardware and routers are designed to be difficult to modify even when you have physical access to them."

施設の堅牢さは、平時には正しい設計判断である。ところが主系と帯域外の両方が同時に失われると、その同じ堅牢さが、復旧を分単位から時間単位へ引き延ばす要因に反転する。手順書の速さは、扉の前で必ず一度止まる。

問いは「誰が検証者を検証するのか」に尽きる。監査ツールは、それ自体の挙動が試験され、それ自体の失敗が見えるようになっているときだけ統制になる。公開記録の中に、そのどちらの試験も見えない。何が事案の分類を変えるかは具体的だ。監査ツールに専用の回帰試験があり、その試験自体が独立に確認されている記録。DNS のフェイルセーフ方針が「守る対象との共有運命」を観点として定期レビューされている記録。主系と帯域外の双方が同時に失われる前提で復旧手順が演習されている記録。この三つが読めれば、事案は「未検証の統制」から「検証済みの統制の失敗」へ移る。

今回読んだのは、Meta のエンジニアリングブログ1本と、Cloudflare の観測分析1本である。修復計画、実装状況、耐久性を示す文書、監査ツールの欠陥報告書、コマンドの承認経路は、いずれも読めていない。Cloudflare 以外の独立した経路分析も読めておらず、本稿が依拠する第三者の観測は Cloudflare である。Facebook, Inc. の企業情報はディレクトリ項目にまとめている。