要約

  • 2021年10月4日、グローバルなバックボーン容量の可用性を評価する意図で発行されたメンテナンス用コマンドが、Meta Platforms のバックボーン全体を運用から外した。同社の説明によれば、各拠点はその後みずからを不健全と判定しBGP広告を撤回した結果、DNSサーバーは動作したままだが到達不能になった。
  • 外部測定は、異常の起点を15:40 UTC頃、DNSプレフィックスへの経路の撤回を15:58 UTC、経路活動の再開を21:00 UTC頃・ピーク21:17 UTC、完全復旧の顕在化を21:28 UTC頃としている。撤回から復旧まで約五時間半だが、これは報告された二つの時刻の差であり、独立に測定された継続時間ではない。
  • 持続する結論は構造的なものだ。回復経路が、回復すべき経路制御と名前解決の平面を通っている運用者には、自らの障害を観測することも巻き戻すこともできない。この記録で検証されていないのは、当初の設定ミスではなく、修復の耐久性である。

Meta Platforms の2021年10月4日の世界規模の障害は、悪い一行のコマンドの物語として何度も語られてきた。その語りは正確だが、ほとんど役に立たない。単一のメンテナンス操作がバックボーン全体を運用から外し、そこから生じた障害は大きかっただけでなく、形を持っていた。それは運用者自身の依存グラフに沿って進み、封じ込めるはずだった制御ツールにまで到達し、唯一残った対処手段が「人が建物まで車で行くこと」になるまで続いた。

本稿はこの事故を偶発事象ではなく、一連の制御判断の連鎖として読む。四つの問いが記録を整理する。運用者自身はこの変更をどう説明し、効果はどこで不可逆になったのか。外部の観測点は実際に何を測定し、外部観測が決して見られないものは何か。どの破綻が工学の問題で、どれが統治の問題か。そして、そのうち何が恒久的に修復されたという証拠が存在するのか。

公開記録が答えない箇所では、本稿はもっともらしさで穴を埋めず、答えがないと明示する。二つの欠落は最初から重要である。本検証では、撤回されたプレフィックスの数も影響を受けたネットワークの数も確立できなかった。また時系列は単一の独立測定系列に依存しており、複数の測定機関の合意ではない。

運用者自身が語った変更の内容

Meta Platforms は事故の翌日、自社のエンジニアリングサイトに「More details about the October 4 outage」と題する説明を公開した（Engineering at Meta）。決定的な一節は短く、注意深く読むと順序について驚くほど率直である。

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. ... In the recent outage the entire backbone was removed from operation, making these locations declare themselves unhealthy and withdraw those BGP advertisements. The end result was that our DNS servers became unreachable even though they were still operational.

日本語にすれば、こうである。定例メンテナンス作業の一つにおいて、グローバルなバックボーン容量の可用性を評価する意図でコマンドが発行され、それが意図せずバックボーン網の全接続を停止させ、結果として同社のデータセンターを世界規模で相互に切り離した。今回の障害ではバックボーン全体が運用から外れ、そのため各拠点はみずからを不健全と判定してBGP広告を撤回した。最終的に、DNSサーバーは動作していたにもかかわらず到達不能になった、と。

この段落には三つの段階が見て取れる。それぞれ異なる制御を含意するので、分けて扱う価値がある。

第一段階はコマンドである。その目的は可用容量の評価、すなわち測定であって、本番トポロジへの変更ではなかった。ツールがその答えをどう扱ったにせよ、実際の効果はバックボーン網の全接続を停止させることだった。意図が測定で効果が全断であるコマンドは、影響範囲が「広い」のではなく「境界がない」のである。

第二段階は自動である。バックボーンが失われると、各拠点は自らの健全性を評価し、孤立していると判断し、適切に設定されたルーターがすべきことをした。すなわちBGP広告の撤回である。内部の故障をインターネットから見える事象に変えたのはこの環である。撤回は事故対応の中で下された判断ではなく、忠実に実行されたポリシーだった。この区別は再発防止を考える者にとって重要である。忠実なポリシーは、嘘をつけと命じても直らない。ヘルスチェックが失敗したとき、その拠点がなお何をなし得るかを決めることで直る。

第三段階が障害を長引かせた。運用者自身の言葉では、DNSサーバーは動作していたにもかかわらず到達不能になった。サーバーは落ちていない。ネットワークがそこへ到達できなくなり、それによって「何がどこにあるか」に答えることもできなくなったのである。

本検証のために取得した公開説明は、制御分析にとって中心的なさらに二つの要素を述べている。ただし本稿はこれらを独立に観測された事実ではなく、運用者自身の性格づけとして扱う。一つは、まさにこの種の誤りを捕捉するための監査ツール自体に不具合があったこと。もう一つは、DNSの喪失が循環依存を生み、アウトオブバンドの管理アクセスを断ち、技術者がルーターを再設定するために物理的にデータセンターへ赴く必要が生じたことである。どちらも疑ってはいない。どちらも当事者が自らの内部状態を述べたものであり、監査ツール、変更チケット、建物内での作業を観測した第三者は存在しない。

外部の観測点が測ったもの

運用者の説明は原因を語るが、時計についてははるかに弱い。時系列については、事故当日にCloudflareが公開した独立測定が有用である（Cloudflare Blog）。大手リゾルバ網が見たものに時刻を与えている。

At around 15:40 UTC we saw a peak of routing changes from Facebook. That's when the trouble began. ... At 15:58 UTC we noticed that Facebook had stopped announcing the routes to their DNS prefixes. ... At around 21:00 UTC we saw renewed BGP activity from Facebook's network which peaked at 21:17 UTC.

つまり、15:40 UTC頃にFacebookからの経路変更のピークを観測し、問題はそこで始まった。15:58 UTCには、Facebookが自社DNSプレフィックスへの経路の広告を停止したことに気づいた。21:00 UTC頃には、FacebookのネットワークからのBGP活動が再開し、21:17 UTCにピークに達したのを観測した、となる。

三つの時刻と一本の曲線。何かが15:40 UTC頃に始まった。15:58 UTCまでに、同社のDNSプレフィックスへの経路はそのネットワークから広告されなくなっていた。経路変更が可視化されてから名前解決層がグローバル経路表から消えるまでの、十八分の窓である。21:00 UTC頃に活動が再開し、21:17 UTCにピークを迎え、Cloudflareの分析がさらに報じるところでは、グローバルインターネットへの完全な再接続が21:28 UTC頃に顕在化した。

これらの端点は、情報源が読者の代わりには行わない引き算を一つ許す。15:58 UTCのDNSプレフィックス広告の撤回から、21:28 UTC頃の完全復旧までの間は約五時間半である。この数字は報告された二つの時刻の差であって、独立に測定された障害継続時間ではない。その留保とともに読むべきだが、インターネットの縁で実際に回復がどれだけかかったかについて、最も具体的な数字ではある。

外部測定が提供できないものも同じくらい重要である。影響を受けたネットワークの外にある観測点は、広告の出現と消失を見ることはできる。しかし変更の承認も、鳴ったか鳴らなかったかの警報も、監視対象と同時に暗くなった内部ダッシュボードも、運用者が自らのツールが失われたと理解した後の判断の順序も見ることはできない。Cloudflareが測ったのは表面であり、運用者が語ったのは機構である。どちらか一方の文書だけでは因果は確立しない。因果を確立するのは、運用者が語った機構がまさに観測された表面を生み出すという事実である。すなわち、名前解決サーバーが機能しなくなる前に、ネットワークがその広告をやめるという表面である。

一つの事故に二つの破綻

これを単一の原因による単一の破綻として扱いたくなる。記録は少なくとも二つを支持しており、混同すると誤った処方になる。

バックボーン全体を外すメンテナンス用コマンドは、工学の破綻である。処方は、範囲を狭めること、段階的に実行すること、事前の評価実行、そして単一の評価操作が触れてよい対象への厳格な上限である。

その規模のコマンドを止めるはずだった監査や検証の段階が、止めなかったなら、それは統治の破綻である。処方は性質を異にする。なぜ単一のガードが全負荷を負っていたのか、そのガードの実際の適用範囲は影響範囲に対してどれほどだったのか、止めるべき変更の種別に対して試験されていたのか、そしてガードが機能しなくなったことに誰が気づく責任を負っていたのかを問う。

ガードが存在して故障したのなら、最初の問いは、なぜ単一の検証点がグローバルネットワークを守っていたのかである。ガードの適用範囲が影響範囲より狭かったのなら、すなわち提出された変更を検証し、実行された変更を検証していなかったのなら、より居心地の悪い問いは、なぜその影響範囲が一度もモデル化されなかったのかである。本検証で参照した公開記録は、どちらの記述がより適切かを決しない。運用者自身が、予防しなかった予防的制御について述べているという事実だけを確立する。

さらに第三の破綻があり、運用者はほとんど通りすがりに触れているが、最も広く共有されているため一行を割く価値がある。すなわち、それを運ぶネットワークがない状況でもヘルスシグナルは信頼できるという思い込みである。仲間が見えないために自らを不健全と判定する拠点は、通常の条件下では正しく振る舞っている。この事故では、正しい振る舞いが故障を増幅した。設計上の問いは、ヘルスチェックを残すかどうかではなく、健全だが孤立したノードが何を撤回することを許されるかである。

循環依存

この記録の中で、循環依存は最も広く当てはまり、最も公開証拠の少ない部分である。

Meta Platforms の説明は、DNSアクセスの喪失がアウトオブバンド管理を断ち、そのため技術者がルーターを再設定するために物理的にデータセンターへ赴かざるを得なかったと述べている。これをアーキテクチャの記述として読むなら、共線性についての文である。ネットワークを観測するために使うシステムと、それを管理する経路の一部が、ネットワーク自身の名前解決と経路制御の平面に依存していた。その平面が落ちれば、運用者が見て動く能力も一緒に落ちた。

これは奇異な誤りではない。プラットフォームを動かす道具立てをプラットフォームの上に築くと起きることである。超大規模でこれを正しく行うのは本当に難しい。管理トラフィックには認証、認可、記録、ネットワークポリシーが必要であり、それらを最も安く提供する方法は、すでに提供しているシステムを再利用することだからだ。その便利さの代償は、まさにここで観測された遅延である。障害の継続時間は、待機していた技術者の人数ではなく、一人がラックに到達するまでの時間で決まる。

統治にとっての帰結は居心地が悪い。組織は優れたインシデント対応能力、成熟したオンコール体制、よく訓練されたエスカレーション経路を持ちながら、なお対応できないことがある。故障した平面の向こう側にある能力は、故障の間は存在しない能力だからだ。対応能力は、障害の条件下で測らねばならず、抽象的に測ってはならない。事実に照らせば、2021年10月4日の Meta Platforms の対応能力は、数時間にわたりゼロだった。技術者が失敗したからではなく、技術者への経路がほかのすべてと一緒に失敗したからである。

影響範囲は他者のものだった

企業は自社の障害を内部コストとして扱える。この事故の公開記録は別のことを示している。すなわち、その変更に対して何の投票権も持たない当事者へ分配された帰結である。

本検証のために取得したCloudflareの分析はさらに、事故の間に世界的なDNSクエリのトラフィックが増加したと報じている。アプリケーションと利用者が、到達できなくなった名前解決サーバーに対して再試行を繰り返したためである。これは故障が外へ輸出された兆候である。再試行を続ける依存アプリケーション、追加の問い合わせ負荷を吸収するリゾルバ、認可呼び出しを完了できない決済ページのすべてが、他者のメンテナンス作業を自らの障害として経験していた。

この型は一般的である。少数のネットワークが、日常的なインターネット利用の極めて大きな割合の解決と経路制御の経路に位置している。そこにはSNSと無関係な用途も含まれる。身元プロバイダ、決済の流れ、加盟店のログイン、公共サービスのポータルである。自らのインフラに正しく冗長性を築いた組織でも、見ることも試すことも監査することもできない設定変更によって倒され得る。取締役会や規制当局にとって、この事例の本当の露出はそこにある。ある企業の製品の可用性ではなく、無関係な組織が、内部の変更慣行が見えない少数の制御点に、管理されないまま依存していることである。

ネットワーク運用の実務者はすぐに気づいた。業界の論評はBGPを中心的な機構として扱い、この出来事を同社の歴史上最大かつ最悪の一つと位置づけ、ネットワーク専門家向けの教訓を明示的に引き出した（TechTarget）。この資料は測定ではなく論評である。経路データも一次的なアーキテクチャの詳細も提供しない。それでも、この事故がどう受け止められたかの証拠ではある。すなわちプラットフォームの障害としてだけでなく、経路制御の教訓として受け止められた。

証拠の境界

この事故を引用するあらゆる記述には四つの限界が伴うべきであり、本稿はそれを覆い隠さない。

第一に、規模はここでは確立されていない。本検証では、撤回されたプレフィックスの数も、影響を受けた自律システムの数も確立できなかった。経路規模の測定を目指した調査の試みは利用可能な情報源を返さず、本稿はそれを、規模が小さいとか大きいとかいう証拠ではなく、記録の欠落として扱う。読者は、その背後にある測定系列を名指さずにこうした数字を示す記述に対して、疑いを持つべきである。

第二に、時計は単一の観測点に依存している。上述の時系列は、どれほど信頼できるものであっても単一の独立測定機関に由来する。第二の測定系列は撤回と復旧の曲線を実質的に強くするはずであり、その不在は、復旧が集中的に調整されたのかネットワークごとに伝播したのかについて、責任ある形で述べることを妨げる。記録が提供するのはいくつかの時刻であり、系列ではない。

第三に、内部の機構は運用者の言葉である。監査ツールの不具合、循環依存、物理的アクセスの必要性は、いずれもそれを経験した当事者の説明である。もっともらしく、詳細で、相互に整合しているが、独立に観測されてはいない。

第四に、そしてこれを物語ではなく事例として読む者にとって最も重要なことだが、修復の記録は薄い。本検証は2026年10月17日に作成され、Meta Platforms がアウトオブバンド管理を本番の経路制御と名前解決の平面から具体的に分離したとする公表物も、そうした変更に対する独立の評価も見つけられなかった。これは参照した公開記録についての日付のある否定的所見である。そうした変更が行われなかった証拠ではない。組織は日常的に私的にこうした変更を行う。しかし、第三者はいまのところその修復を検証できないということを意味する。

検証可能な修復とはどのようなものか

修復の耐久性が未解決の問いであるなら、何がそれを閉じるのかを具体的に述べる価値がある。三つの試験が、事実から直接導かれる。

第一は回復経路の独立性である。アウトオブバンド管理は本番の経路制御と名前解決の平面に依存すべきではなく、その独立性はアーキテクチャ図で断言されるのではなく、故障条件下で示されるべきである。試験の実際の形は演習である。名前解決層を統制された形で意図的に撤回し、運用者がなお認証でき、ネットワーク状態を見て、変更できることを確認する。この演習を一度も行っていない組織は、自らの答えを知らない。

第二は境界のある影響範囲である。単一のメンテナンス用コマンドは、実行の瞬間の運用者の注意力以外の何かによって強制される最大許容効果を持つべきである。ここでの記録が描くのは、バックボーン全体に語りかける評価操作である。評価を定義された区画に限定し、その区画を検証し、残りに触れずにその区画を復旧できる制御は、世界的障害を局所的障害に変える。

第三は反証可能性である。耐久性のある修復は、外部の誰かが検査できる成果物を生む。新しい分離についての公表された記述、独立のレビュー、あるいは開示された演習結果である。参照した記録にはそのいずれも存在しない。代わりにあるのは、同規模の再発がないまま経過した時間である。弱い証拠であり、「何かが変わった」ことを示すのではなく「何も変わらなかった」ことを静かに前提とする証拠である。

五年後になぜこの事例がなお重要なのか

本検証の時点で事故から五年が経ち、その主要な教訓は古びていない。障害は工学的人材、監視、資金の不足によって起きたのではない。ネットワークを守るはずのシステムが、ネットワークを通じてしか到達できないという信頼のトポロジーによって起きた。そのトポロジーは、道具を便利にする日常の過程で、どの組織でも、どの規模でも容易に再現される。

具体的な技術的問いは答えられ、ほとんど答えが出ている。管理トラフィックを運ぶバックボーンが不健全だからといって名前解決サーバーが到達不能になるべきではないし、ヘルスチェックが、その到達性が自らの修復の前提であるサービスを撤回できるべきでもない。答えが出ていないのは制度的な問いである。Meta Platforms のディレクトリ上の記録はこちらで参照できる。その記録にまだ欠けているのは、影響を受けた顧客、取締役会、規制当局が「修復された」という主張を受け入れるのではなく照合できるようにする証拠である。

これは事後報告ではなくリスク登録簿に属する部分である。運用者は何が壊れたかについて率直でありながら、修正の耐久性を、影響を受けるすべての者の手の届かないところに置いたままにできる。