概要

  • 2021 年 10 月 4 日、定期メンテナンス中に発行されたコマンドが、意図せず Facebook のデータセンターをグローバルバックボーンから切り離しました。危険なコマンドを監査しブロックするためのツールにバグがあり、その保護チェックが機能しませんでした。バックボーンの喪失により、Facebook の権威 DNS サイトが BGP アドバタイズメントを撤回し、Facebook、WhatsApp、Instagram、および関連サービスが事実上、公衆インターネットから発見も到達も不能になりました。
  • DNS は増幅器であり目に見える症状でしたが、発端ではありませんでした。親ゾーンの委任は引き続き Facebook の権威ネームサーバを指しており、サーバ自体は動作していましたが、それらに到達するための経路が撤回されていました。短い DNS キャッシュ有効期間と積極的なリトライが、再帰的リゾルバと.com インフラに負荷を輸出しました。
  • 復旧が長引いたのは、同じ障害により通常のリモートアクセスや多くの内部ツールも無効になったためです。エンジニアはデータセンターに派遣され、バックボーンを復旧させる前に、意図的に厳格な物理的およびシステムセキュリティ制御を通過する必要がありました。既存の地域およびデータセンター障害訓練は制御された再起動に役立ちましたが、Facebook はグローバルバックボーン全体の喪失をシミュレーションしたことはなかったと述べています。
  • したがって説明責任は、コマンドを発行した個人よりも、1 つのメンテナンスアクションにグローバルな影響力を与えたシステム、つまり欠陥のあるガードレール、共有された制御依存性、不完全な復旧独立性、テストされていないグローバルバックボーンシナリオにあります。取締役会の監督では、ブラスト半径が制限されていること、バリデーターが独立していること、DNS がトポロジ的に到達可能であること、そして復旧が本番ネットワークなしで進行できることの証拠を要求すべきです。

プラットフォームは単にダウンしたのではなく、ネットワークが視界から消えた

2021 年 10 月 4 日月曜日、UTC 15:39 頃、Facebook のサービスへのトラフィックが世界中で崩壊しました。Facebook、WhatsApp、Instagram、Messenger などのサービスが読み込まれなくなりました。アプリを開いた人にとって、結果は普通に見えました。スピナー、エラー、送信できないメッセージ。インターネット規模では異例でした。インターネットの他の部分に Facebook の場所を伝えるネットワークの一部が、経路の広告を停止したのです。

この出来事はしばしば DNS 障害や BGP ミスと要約されますが、どちらの説明も目に見える障害の部分を捉えており、管理上の問題を隠しています。後の Facebook の技術説明によると、発端は定期バックボーンメンテナンス中に発生しました。利用可能なグローバルバックボーン容量を評価するためのコマンドが、代わりにすべてのバックボーン接続を切断しました。このコマンドは自動的にレビューされるはずでしたが、監査ツールのバグにより、その保護チェックがそれを停止できませんでした。その切断により、DNS 設備が自身を不健全と宣言し、経路広告を撤回しました。これらの撤回は数分以内に外部から観測されました。

この連鎖は重要です。なぜなら各リンクが異なる制御上の疑問を表しているからです。なぜ評価コマンドがバックボーン全体を削除できたのか?なぜコマンドバリデーターが制約するはずの同じトランザクションで失敗したのか?なぜ内部データセンター接続の喪失がすべての公開権威 DNS 経路の消失を引き起こしたのか?なぜ通常のリモートアクセスと内部インシデントツールが影響を受けたインフラを共有していたのか?なぜ訓練はサービス、データセンター、地域の喪失をカバーしていたがグローバルバックボーンの喪失はカバーしていなかったのか?

Facebook は 2 つのエンジニアリング投稿で広範な因果関係の質問に答えました。同社はコマンド、監査ツールの欠陥、分単位の内部タイムライン、完全な修復アクションのリスト、またはそれらのアクションの独立した検証は公開しませんでした。外部ネットワーク観測者は経路変更、DNS の動作、トラフィック損失、段階的な復旧について強力なビューを提供しましたが、Facebook の内部変更承認や制御コードを検査することはできませんでした。責任ある説明責任の分析では、したがって Facebook が認めたこと、外部テレメトリが独立して示したこと、依然として不明なことを区別しなければなりません。

なお、このインシデントの後すぐに企業名が変更されました。障害が発生した当時、上場企業は Facebook, Inc. でしたが、同社はその月の後半に Meta の名称を発表しました。本記事では、10 月 4 日のネットワークと当時の声明を説明する際には Facebook を、現在の企業体またはその後の提出書類について議論する際には Meta を使用します。

証拠が証明できることとできないこと

最も強力な因果関係の情報源は、Facebook の10 月 5 日の詳細なエンジニアリング説明です。これはインフラストラクチャを担当するエグゼクティブによって書かれた、当事者によるインシデント後の説明です。定期メンテナンス、容量評価コマンド、欠陥のある監査ツール、バックボーン切断、DNS 経路広告の自動撤回、通常およびアウトオブバンドアクセスの喪失、オンサイト復旧、以前の訓練の役割を明示的に特定しています。これらは重要な自認です。この説明は独立した調査ではなく、その詳細レベルは後の制御が効果的だったかどうかをテストするために必要な質問の前で止まっています。

Facebook の短い10 月 4 日の復旧更新は、当時の同社声明です。バックボーンルータの設定変更がデータセンター間の通信を中断させ、連鎖的な影響を説明し、悪意のある活動が根本原因であることを否定し、この結果としてユーザーデータが侵害された証拠はないと述べています。「証拠はない」はこのインシデントに関する同社の述べられた結論であり、セキュリティ上の影響があり得なかったことの証明や、外部機関による所見として書き換えるべきではありません。

外部テレメトリは公衆ネットワーク上の結果を裏付けています。Cloudflare の同時期の分析は、UTC 15:40 頃の Facebook のルーティング変更のピーク、DNS プレフィックスに影響する撤回、公開リゾルバからの SERVFAIL 応答、クエリ量の大幅な増加を記録しました。Kentik のトラフィックと BGP 分析は、サービストラフィックの崩壊を約 15:39 UTC とし、主要な DNS プレフィックスが約 21:00 に戻ったことを示しています。RIPE NCC の BGPlay 再構築は、Facebook の権威ネームサーバの 1 つを含むプレフィックスへの経路が 15:53:47 までに消失し、復帰時にバンプの後に安定したことを示しています。ThousandEyes の障害分析は、完全な DNS 障害の前にアプリケーションの受信エラーが始まり、DNS が応答を開始した後も持続したことを観測し、Facebook の説明であるバックボーンが先に故障し DNS がそれに続いたことを裏付けています。

これらの情報源は異なるエンドポイントを使用しています。Facebook は障害が約またはほぼ 6 時間だったと述べました。Kentik は主要な経路が UTC 21:00 頃に戻ったことを見ました。RIPE と Cloudflare はその後の経路回復と DNS 回復が続くのを見ました。ThousandEyes は後まで一部のアプリケーション信号の障害を追跡しました。これらは必ずしも矛盾ではありません。「経路がアナウンスされた」、「権威 DNS が応答した」、「公開サイトが読み込まれた」、「全てのアプリケーション機能が健全だった」は異なる復旧マイルストーンです。本記事ではそれらを誤った単一のタイムスタンプに強制しません。

公衆への影響の証拠はネットワークの証拠ほど完全ではありません。Facebook は影響を受けた人、メッセージ、トランザクション、ビジネスの監査済み数を公開しませんでした。同社の2021 年第 3 四半期決算では、9 月 30 日時点でアプリファミリー全体で月間アクティブユーザーが 35.8 億人と報告されました。この数字は依存の規模を示すものであり、障害中にサービスを利用しようとして失敗した人の数を示すものではありません。四半期広告収入や世界経済産出を 6 時間で乗じた推定はシナリオであり、測定された損失ではなく、ここでは監査済みの影響として扱われません。

メンテナンスから復旧までのシーケンス

公開記録はコンパクトな時系列を裏付けています。以下の時刻は UTC であり、完全な内部イベントログとしてではなく、観測されたマイルストーンとして読むべきです。

日時イベントと説明責任上の意義
10 月 4 日以前Facebook は定期的にグローバルバックボーンの一部をサービス停止にする可能性のあるメンテナンスを実施していました。システムはコマンドを監査し危険なアクションをブロックするように設計されていました。また、サービス、データセンター、または地域の喪失を想定した「ストーム」訓練を実施していましたが、グローバルバックボーン全体がオフラインになるシナリオはシミュレートしていませんでした。
10 月 4 日 約 15:39Kentik が Facebook のサービストラフィックの急激な低下とルート活動のバーストを観測。これは公衆インシデントの開始を示す強力な外部マーカーです。
約 15:40Cloudflare が Facebook からの BGP アップデートと撤回のピークを観測。ThousandEyes はアプリケーションが到達不能になり、権威 DNS 障害が発生し始めたのを観測。
最初の数分Facebook によると、バックボーン容量を評価するための定期メンテナンスコマンドが意図せずすべてのバックボーン接続を削除しました。コマンド監査ツールはバグを含んでいたため、それを阻止しませんでした。
バックボーン喪失直後Facebook の DNS サイトはデータセンターと通信できなくなりました。そのヘルスロジックはその状態を安全でないと解釈し、権威 DNS サービスアドレスに対する BGP アドバタイズメントを撤回しました。公開リゾルバは委任情報を取得することはできましたが、有用な Facebook 権威に到達することはできませんでした。
15:53:47 までにRIPE BGPlay は、a.ns.facebook.comのアドレスを含む 129.134.30.0/24 へのすべての経路が、選択された観測点で消失したことを示しました。異なるモニターやプレフィックスはわずかに異なる時間にこの状態に達しました。
障害中通常のリモートデータセンターアクセスと Facebook のアウトオブバンドネットワークアクセスが利用不能になり、DNS の喪失により内部調査ツールが機能しなくなりました。エンジニアは物理的にデータセンターに派遣されました。短い DNS TTL と繰り返されるユーザーとアプリケーションのリトライが、再帰的リゾルバと親 DNS インフラの負荷を増大させました。
約 21:00Kentik が主要な 129.134.30.0/23 DNS 経路の復帰を観測。他の観測者はこの後も経路変更とサービス復旧が続くのを記録しました。
約 21:30 以降ThousandEyes は、ほとんどのユーザーで DNS が約 21:30 までにほぼ復旧したと報告。アプリケーションの復旧は、Facebook が戻ってくる負荷を制御し、一部のモニターが引き続き障害を観測する中で、徐々に進みました。
10 月 4 日~5 日Facebook はシステムが復旧し、イベントの原因を悪意のある活動ではなく設定変更の誤りとし、障害により侵害が発生した証拠はないと述べました。
10 月 5 日Facebook はより完全な因果関係の連鎖を公開し、テスト、訓練、レジリエンスを強化し、グローバルバックボーン障害をシミュレーションする方法を探すことを含めると述べました。
2022 年 2 月Meta の 2021 年 Form 10-K は、このイベントをエラーとバグの組み合わせによって引き起こされた約 6 時間の障害と説明し、同社のインフラリスク開示に含めました。

このタイムラインは制御の非対称性を露呈します。破壊的な遷移は高速でした。コマンド、失敗したガード、バックボーン分断、ヘルス状態の変化、経路撤回です。復旧への遷移は、慣れ親しんだツールなしの診断、現地への移動または物理的派遣、安全な入室、ハードウェアアクセス、段階的なバックボーン復旧、戻ってくるトラフィックの慎重な管理を必要としました。優れたレジリエンスエンジニアリングはこの非対称性を前提としています。破壊的なアクションにはより強い前提条件を与え、緊急アクセスを独立に保ちます。グローバルな状態変更を元に戻すことは、ほぼ常にそれを起こすよりも遅いからです。

開始コマンドは権限の問題だった

Facebook はトリガーとなったアクションを、定期メンテナンス中にグローバルバックボーン容量の可用性を評価するために発行されたコマンドと説明しました。この表現は示唆的です。評価は観測的に聞こえますが、コマンドはすべてのデータセンターをバックボーンから切断するほど強く状態を変更しました。公開された説明では、その広がりがコマンドに固有のものだったのか、パラメータによって生じたのか、予期しない相互作用によって引き起こされたのかは述べられていません。その操作がグローバルな効果を持ったことは確立しています。

したがって、最初の説明責任の質問は「誰がタイプミスをしたのか?」ではありません。Facebook はアクションをタイプミスとして公に特徴付けておらず、エンジニアの名前を出したり、懲戒処分の結果を開示したりしていません。無名のオペレーターに非を割り当てることは、証拠のギャップを馴染みのあるストーリーで埋めることになります。関連する質問は、なぜ 1 つのメンテナンスパスが、独立して信頼できる障壁なしにグローバルな破壊的状態を表現し実行できたのか、です。

大規模環境では、特権ネットワークコマンドは本番コードです。それらは制約されたスコープ、意味的検証、現在のトポロジに対するシミュレーション、ブラスト半径に比例したピアレビュー、カナリア実行、明示的な中断条件、影響を受けるコントロールプレーンに依存しない自動ロールバックパスに値します。ツールがすべてのリージョンに到達できる場合、「定期的」は頻度を表し、リスクを表しません。操作に付随する権限は、それが引き起こし得る最大の状態変更によって評価されるべきです。

Facebook は、システムがこのようなコマンドを監査しミスを防ぐように設計されていたが、監査ツールのバグがコマンドの停止を妨げたと述べました。これは制御の不在ではありませんでした。それは、失敗が危険なアクションと一致した制御への依存でした。バリデーターは承認パスにありながら、明らかにコマンドを正しく判断できない場合にフェイルクローズドの結果を生成しませんでした。公開投稿では、ツールが誤った承認を返したのか、コマンドの解析に失敗したのか、不完全なモデルを評価したのか、または別の欠陥に遭遇したのかは説明されていません。これ以上の具体的な診断は発明になります。

それでも制御の教訓は確固としています。グローバルな変更を承認できるガードレールは、それ自体が重要インフラです。バージョン管理され、既知の危険なケースに対してテストされ、カバレッジと決定エラーが監視され、静かに劣化しないようにされなければなりません。2 つ目のチェックは、1 つの欠陥が両方の制御を一致させないように独立している必要があります。独立性は、別個のトポロジモデル、一度に削除できるバックボーン容量の割合を制限するハードポリシー、段階的実行エンジン、または例外的なグローバルスコープに対する人間の承認から得られます。同じパーサーとデータモデルに裏打ちされた 2 つのチェックは、1 つの障害モードを共有しながら冗長に見えるかもしれません。

インシデントの 5 か月足らず前、Facebook のエンジニアは、データセンター規模の BGP にはトポロジ、スイッチソフトウェア、設定、運用パイプラインとの緊密な共同設計が必要だと書いていました。大規模 BGP に関する2021 年 5 月の説明では、障害は避けられず、経路ポリシーとバックアップパスが高可用性の中心であることが強調されていました。この論文は 10 月のメンテナンスシステムを説明したものではないので、矛盾を証明することはできません。しかし、運用ツールがルーティングシステムの一部であり、管理的な付属物ではないと理解されていたことを示しています。

同様に、Facebook の以前のExpress Backbone アーキテクチャの説明では、4 つの並列物理プレーン、高度に冗長な BGP ルートインジェクター、分散障害処理、および実験とロールバックを中断を減らして行う能力が説明されていました。物理的およびコンポーネントの冗長性は実際の設計上の特徴でした。10 月 4 日は、冗長プレーンがそれらすべてを一緒に変更できる制御アクションから保護しない理由を示しています。共通のコントローラまたはコマンドスコープがすべてのドメインを選択できる場合、障害ドメインの多様性は消えます。

DNS はポリシーが指示したことを実行した

「DNS 障害」というフレーズは、壊れたネームサーバソフトウェアや破損したゾーンデータのイメージを助長します。Facebook はどちらも報告しませんでした。同社の権威ネームサーバは、広域インターネットに接続された小規模施設の既知の IP アドレスを占有していました。それらのアドレスは BGP を通じてアドバタイズされていました。DNS サイトが Facebook のデータセンターへの接続を失うと、データセンターに到達できないことを不健全なネットワーク状態と解釈したため、ヘルスロジックがアドバタイズメントを撤回しました。サーバは動作し続けましたが、インターネットにはそれらに到達する使用可能な経路がありませんでした。

このヘルスポリシーには防御可能な目的があります。正しい回答を提供するために必要な状態を取得または検証できない権威サーバは、クエリの誘引を停止する方が良い場合があります。経路撤回は、隔離されたまたは古いインスタンスにトラフィックが送られるのを防ぐことができます。エラーは、必ずしもヘルスチェックが存在したことではなく、単一のバックボーン状態がすべての権威サイトに同じ決定をさせ、一度に公開権威全体を削除させたことです。

これは古典的な共通モード障害です。分散サーバ、複数のアドレス、多くのロケーションがすべて 1 つの共有された健全性命題に依存しています。地理的多様性は、すべてのサイトが同じ上流の質問をし、同一の応答をする場合、運用上の独立性を生み出しません。公開設計には多くの物理インスタンスがありましたが、この条件下では 1 つの論理的な運命でした。

長年の DNS ガイダンスはこの区別を明示しています。セカンダリ DNS 選択に関するRFC 2182は、地理的な配置とネットワーク接続の多様性が信頼性を高めることができると述べ、トポロジ的に近接していない権威サーバを推奨しています。重要な単語はトポロジ的にです。異なる建物や国にあるサーバでも、コントロールプレーン、経路ポリシー、上流依存性、またはヘルスシグナルを共有することができます。トポロジカルな分離とは、地図上の距離ではなく、独立した経路と障害動作に関するものです。

権威ネームサーバの分散に関するRFC 3258は、共有ユニキャスト DNS メッシュについて議論し、サーバインスタンスが故障した場合に経路を撤回することに伴う運用上の複雑さについて警告しています。そのモデルは一般に、経路自体を撤回するのではなく、失敗した DNS プロセスを停止してリゾルバが他のアドレスのサーバを試せるようにすることを好みます。Facebook のアーキテクチャは独自のものであり、その情報文書の一般的なモデルよりもはるかに大規模でした。この RFC は Meta が拘束力のあるルールに違反した証拠ではありません。2021 年よりずっと前に、経路撤回のトレードオフが公開技術実務で認識されていたという証拠です。

エニーキャストは状況を複雑にします。RFC 4786は、1 つのサービスアドレスを複数の自律的な場所からアナウンスする方法を説明し、その冗長性の利点と監視および障害の落とし穴の両方を指摘しています。少数のサービスアドレスの背後にある多数の物理サーバは莫大な容量を提供できますが、すべてのアナウンスが共通のポリシーによって抑制される場合、見かけの多重化は役に立ちません。正しいレジリエンスの尺度は DNS ボックスの数ではなく、信頼できる各コントロールプレーン障害下で独立して生き残ることができる権威経路の数です。

イベント後にRFC 9199(大規模な権威 DNS オペレーターのための考慮事項)にまとめられた研究も同様に、エニーキャスト、経路最適化、集水域測定、ストレス戦略、TTL 選択を強調しています。2022 年 3 月に公開されたこの RFC は、後のエンジニアリングベンチマークとして使用されるべきであり、Facebook が無視した要件として遡及的に説明されるべきではありません。その関連性は、DNS レジリエンスが多次元的であること、つまりインスタンス、ルーティング、監視、キャッシュポリシー、および運用戦略がシステムとして機能しなければならないことです。

委任は残ったが、実用的な到達可能性は残らなかった

DNS 委任の権限は誤解しやすいものです。権限と到達可能性は別物だからです。.com の親は Facebook ドメインを Facebook のネームサーバに委任し続けました。.com インフラを運用する Verisign は、正しい委任を返し続けたと報告しました。リゾルバはどのサーバが権威を持つかを知り、それらのアドレスを知ることができました。しかし、それらのアドレスへの経路が応答する権威に通じなくなっていたため、リゾルバはそれらから回答を得ることができませんでした。

Verisign のリゾルバ動作分析は、Facebook の権威からの有用な応答はなく、Facebook の DNS TTL が約 1~5 分であることを指摘しました。キャッシュされた回答が期限切れになると、リゾルバは再度問い合わせなければなりませんでした。それらは到達不能な宛先への正しい委任をたどり、タイムアウトし、一般にユーザーに SERVFAIL を返しました。これはドメイン登録の失効でも、Facebook のドメインの削除でもありませんでした。命名階層は無傷でしたが、委任されたオペレーターがその権限を到達不能にしていました。

したがって、このインシデントは私的委任権限の一形態を示しています。グローバルに重要なドメインの制御には、その権威アーキテクチャ、ルーティング関係、キャッシュライフタイム、ヘルス基準、内部インフラへの結合を選択する能力が含まれます。これらの選択はサービスを俊敏で効率的にすることができます。また、到達可能性を撤回する能力を集中させることもできます。レジストリと再帰的リゾルバは、Facebook の権限を修復することができませんでした。彼らは現在のゾーンデータを保持しておらず、Facebook のサービスアドレスを正当にアナウンスすることもできませんでした。

外部のセカンダリ権威は単純な万能薬ではありません。第三者は同期されたゾーンデータと、Facebook のバックボーンが隔離されている間に動的なレコードに安全に回答する方法を必要とします。古い回答はユーザーをデータセンターにまだ到達できないアプリケーションエッジに導き、明確な障害を遅いまたは一貫性のない障害に変える可能性があります。権限を分割することは、セキュリティ、プライバシー、変更調整、攻撃面のコストも生み出します。教訓は「DNS をアウトソースせよ」ではありません。バックボーン隔離を生き残るべき最小限の権威機能、どの回答が安全か、どの程度古くてもよいか、どの経路制御が独立しているかについて、明示的でテストされた決定を下すことです。

最良の証拠は演習から得られます。本番を代表する環境でグローバルバックボーンを切断します。多様な外部ネットワークから少なくとも 1 つの権威経路が利用可能であるかどうかを観察します。それが障害のあるコアに相談せずに、制限されたメンテナンス応答または安全なサービスレコードを返せるかどうかを検証します。共有自動化がプロトコル固有の障害を隠す可能性があるため、IPv4 と IPv6 を別々にテストします。経路の復旧が同じ DNS 名に依存しないことを確認します。取締役会はトポロジを選択する必要はありませんが、実際に発生した障害に対してトポロジがテストされたことを経営陣が示すよう要求することはできます。

私的障害が公開 DNS に作業を課した

この障害は Facebook のネットワーク内にとどまりませんでした。人気のある名前が解決しなくなると、人々はページを更新しアプリケーションを再起動しました。ソフトウェアがリトライしました。再帰的リゾルバは再び権威を探しました。Cloudflare は、初期イベントに関連するクエリが約 30 倍に増加したと報告し、インターネットへの影響のフォローアップ分析では、Facebook および WhatsApp ドメインの SERVFAIL 率が通常の約 60 倍に達し、暗号化された DNS の SERVFAIL 応答はさらに急増したと測定しました。Cloudflare は、リゾルバがリクエストの大半を迅速に処理し続けたと述べましたが、予期しないエッジおよびシステム負荷を確認しました。

Verisign は親でさらにはっきりとした影響を観測しました。研究した 3 つのドメインに対する通常の.com および.net クエリ量は約 7,000 クエリ/秒でしたが、障害中は 900,000 クエリ/秒以上に上昇し、親の委任が変わっていなかったにもかかわらず通常の 100 倍以上になりました。一部の主要なリゾルバソースは、親へのクエリを数千倍に増やしました。正しいインフラが、既に持っている情報を再発見するよう繰り返し要求されていました。委任された権威が到達不能なままだからです。

この外部性は後にインターネット標準のケーススタディになりました。2023 年に公開された、DNS 解決失敗のネガティブキャッシングに関する RFC 9520は、リゾルバが障害をキャッシュし、失敗した権威とその祖先への繰り返しのクエリを制限しなければならない理由を説明する際に、Facebook の障害を引用しています。この標準は Facebook の根本原因ではなく、リゾルバの動作に対処しています。このインシデントが含まれていることは、1 つのオペレーターのコントロールプレーン障害がどのように共有 DNS インフラの負荷となり、より広範な運用ルールの変更を動機付けるかを示しています。

責任は分散されていますが、希釈されていません。リゾルバ開発者はリトライストームを抑制し、同一の保留中のクエリを結合し、バックオフし、解決失敗をキャッシュする必要があります。アプリケーション開発者は厳しい無制限のリトライを避ける必要があります。大規模な権威オペレーターは、障害動作を念頭に置いて TTL とヘルスポリシーを設定する必要があります。それでも、開始オペレーターは依然としてすべての権威を到達不能にした状態の所有者です。「インターネットは対処した」は、外部コストが無視できる証拠ではありません。それは他のレイヤーが障害の一部を吸収した証拠です。

これは説明責任にとって重要です。従来のインシデント指標はプロバイダ境界で止まります。Meta はアプリの可用性、バックボーン状態、失われた広告配信を測定できます。再帰オペレーター、他のプラットフォーム、ニュースサイト、企業のヘルプデスクに課せられた CPU、帯域幅、レイテンシー、サポート需要、人々の混乱を直接目にすることはないかもしれません。成熟したインシデント後評価には、これらの波及効果を含める必要があります。この規模のプラットフォームでは、ブラスト半径には、契約下の顧客でなくてもリトライしたり置き換えられた需要を受け取ったりするシステムが含まれます。

復旧アクセスは災害を共有した

メンテナンスコマンドは障害の開始を説明します。復旧アーキテクチャはその持続時間の多くを説明します。Facebook は、エンジニアが 2 つの大きな障害に直面したと述べました。ネットワークがダウンしていたため通常のデータセンターアクセスが利用不能であり、DNS の喪失が障害を調査し修復するために使用される多くの内部ツールを壊しました。さらに、プライマリとアウトオブバンドの両方のネットワークアクセスがダウンしており、エンジニアはデータセンターに移動し、安全なオンサイトアクセス手順をアクティブ化し、システムで直接作業する必要がありました。

「アウトオブバンド」は障害モデルとの関連でのみ意味があります。管理ネットワークは別個のインタフェースとデバイスを使用しても、依然として共有ファイバ、ルーティング、アイデンティティ、DNS、電源、制御サービス、または物理アクセス手順に依存する可能性があります。Facebook は、どの依存性がアウトオブバンドアクセスを破綻させたのかを開示しませんでした。このイベントは、それがこのグローバルバックボーン状態を生き残らなかったことを確立します。説明責任レビューでは、ラベルを独立性の証明として受け入れるのではなく、実際の依存チェーンをマップする必要があります。

内部コミュニケーションも同様の結合がありました。ワシントンポストの同時期の報道によると、Workplace は勤務時間の大部分で利用できず、一部の従業員は同社のサインオンメカニズムが機能しなかったためサードパーティツールを使用できませんでした。Facebook 自身の投稿は、内部ツールが機能不全に陥ったというより広い点を確認していますが、それらを列挙してはいません。Slack、文書、チケット発行、ダッシュボード、企業アイデンティティを代替手段としてリストするインシデント対応計画は、それらのツールがすべて 1 つの本番 DNS または認証パスに依存している場合、脆弱です。

答えは物理的またはシステムセキュリティを弱めることではありません。Facebook は、不正アクセスに対する強化が非悪意のある障害からの復旧を遅らせたことを明示的に観察し、そのトレードオフは価値があると判断しました。これは防御可能な立場です。緊急アクセスは、可用性エンジニアリングをセキュリティ脆弱性に変える恒久的なバイパスになってはなりません。設計上の問題は、制御されたブレークグラスパスを作成することです。強力なアイデンティティ、複数の承認者、改ざん防止ログ、狭いコマンド、時間制限、物理的保管、定期的な演習、および障害が発生した環境に依存しない認証情報またはアドレッシングです。

物理的派遣は時間と地理的リスクも導入します。適切なエンジニアが施設に到達し、入室し、正しい機器を特定し、安全に行動できなければなりません。平日のメンテナンスイベントでは人員が利用可能かもしれませんが、自然災害、交通混乱、または地域緊急事態ではそうならないかもしれません。各重要サイトには、訓練されたローカル能力またはコアから独立したテスト済みのリモートパスが必要です。演習記録は、誰かを派遣できると主張するだけでなく、派遣とアクセス時間を測定する必要があります。

公衆とのコミュニケーションも同様の独立性を必要とします。同社の主要製品と一部の内部チャネルが利用不能だったため、更新情報は他のプラットフォームとエンジニアリングサイトを通じて配信されました。レジリエントなステータスチャネルは、別個の権威 DNS、ホスティング、アイデンティティ、および公開制御を使用する必要があります。主要企業の経路が消えたときに到達可能であり、企業のシングルサインオンなしで認証された更新を許可する必要があります。そうでなければ、プロバイダはサービスだけでなく、何が起こっているかを顧客に伝える能力も失います。

再起動は 2 つ目の高リスク変更だった

エンジニアがバックボーン接続を復旧させた後も、Facebook はすぐにすべてを一斉にスイッチオンすることはできませんでした。同社のデータセンターは電力消費を数十メガワット削減していました。グローバルな需要の突然の復帰は電気システムにストレスを与え、キャッシュを過負荷にし、別のクラッシュを引き起こす可能性がありました。したがって、復旧には元のコマンドの単純な逆転ではなく、オーケストレーションが必要でした。

ここで Facebook の既存の準備が役立ちました。同社は、インフラとソフトウェアをテストするために、サービス、データセンター、またはリージョンをオフラインにする「ストーム」演習を説明しました。それらの訓練からの経験は、チームに負荷を注意深く増加させ、別のシステム全体の崩壊なしにサービスを復旧させる自信を与えました。これは記録上重要な肯定的制御です。テストされていないシナリオを露呈した同じインシデントが、より小さな深刻な障害をテストする価値も示しました。

ギャップは範囲でした。Facebook は、グローバルバックボーンがオフラインになるのをシミュレートするストーム演習を実施したことはなく、そうする方法を探すと述べました。考えられるすべての大惨事をテストすることは不可能であり、グローバルバックボーンを意図的に危険にさらす本番テストはそれ自体無責任です。しかし、まさにその本番アクションが存在し、グローバルな到達範囲を持っていました。それにより、ありそうにないと思われても、グローバル切断は信頼できる障害モードになりました。シミュレーション、デジタルツイン、隔離されたコントロールプレーンレプリカ、経路ポリシーエミュレーション、机上から物理的復旧訓練は、数十億のユーザーを意図的に切断することなくテストできます。

復旧の証拠は、バイナリのサービスアップマーカー以上のものをカバーする必要があります。経路、権威 DNS、アイデンティティ、内部ツール、公開ステータス、アプリケーションフロントドア、キャッシュ、メッセージングキュー、広告システム、およびリージョンキャパシティが戻る順序を示す必要があります。通常のテレメトリが利用できない場合の安全な負荷しきい値と使用されるテレメトリを定義する必要があります。すべて同時に再接続するクライアントと、コールドなキャッシュを考慮する必要があります。復旧計画は極度のプレッシャーの下での 2 つ目の変更計画であり、開始メンテナンスと同様に、事前計算された制限と権限が必要です。

依存は単に技術的ではなく、社会的かつ商業的だった

Meta の製品ファミリーは、既に通常インフラストラクチャに関連付けられる規模で運営されていました。同社の月間アクティブユーザー35.8 億人という指標は、35.8 億人が同時にオフラインだったことを意味しませんが、Facebook、Instagram、Messenger、WhatsApp 全体で共通の技術的命運が重要だった理由を示しています。ある企業のバックボーンにおける障害は、多くの人々が別個のサービスとして認識していた複数のチャネルを削除しました。

影響は市場とユーザーによって異なりました。一部の国では、WhatsApp は家族のコミュニケーション、ビジネス注文、カスタマーサポート、政治発表、低コスト通話のデフォルトチャネルでした。ワシントンポストは特に中東の一部での依存度の高さを報じ、当時インドで約 4 億人の WhatsApp ユーザーがいたと引用しました。これらは依存を示す指標であり、すべての通信が失敗したか、規制された通信サービスがあらゆる場所で置き換えられた証拠ではありません。

KPBS が伝えた AP 通信の記事は、ウェブサイトのトラフィックがほぼ完全に Instagram から来ており、中断を経済的フラストレーションでありプラットフォーム制御に関する警告と呼んだ中小企業を記録しました。また、再接続に必死な人々がソーシャルエンジニアリングの標的になる可能性があるという懸念も報じました。Time の中小企業への影響に関する報道は、トラフィック、顧客との会話、立ち上げ、内部音声メモの大部分を Instagram に依存している創設者を見つけました。これらの例は、グローバルな損失総額を許容せずに、実際の害のメカニズムを確立します。

広告主は別の依存に直面しました。The Indian Express が再掲載したニューヨークタイムズの報道は、イベント中に売上が急激に減少した企業と、明確な方向性なしに相当な予算を管理するメディアバイヤーを描写しました。Facebook は、広告主が障害中の広告に対して請求されないと述べました。これは 1 つの直接的な料金を防ぎますが、逃したリード、遅れた立ち上げ、失われた会話、特定の日にタイミングを合わせたキャンペーンの機会費用を回復しません。

Cloudflare の観測では、Signal、Telegram、Discord、Slack、他のソーシャルネットワーク、ニュースサイトに需要が移動しました。代替は一部の影響を和らげましたが、不均一でした。最新のメーリングリストと独立したウェブサイトを持つビジネスは顧客をリダイレクトできました。オーディエンス、ストアフロントの発見、ダイレクトメッセージ、認証のすべてが Meta のファミリー内に存在する販売者は、より少ない選択肢を持っていました。集中は、1 つのベンダーが市場シェアを持つときだけでなく、いくつかの一見異なるワークフローが 1 つのコントロールプレーンを共有するときにも存在します。

これはクラウドサービス依存の教訓です。顧客はプロバイダのバックボーンコマンドを検査したり制約したりできません。ほとんどは交渉された可用性の救済手段、アーキテクチャ開示、または専用の継続性チャネルを持っていません。彼らの実際的な制御は、どのビジネス機能が一緒に消えるかを特定し、その障害ドメインの外部に代替手段を維持することです。独立した顧客記録、独自のドメイン、合法的かつ適切な場合の電子メールや SMS 連絡先、ポータブルカタログ、代替支払いおよびサポートチャネル、リハーサルされた障害メッセージは、ソーシャルプラットフォームの拒否ではなく、それらへの依存のための継続性制御です。

政府および緊急組織はより厳格であるべきです。ソーシャルメディアは有用な公開情報チャネルになり得ますが、緊急通知の唯一の権威ある経路であってはなりません。Facebook ページや WhatsApp グループを唯一の到達可能なチャネルとして扱う公的機関は、それらのいずれも制御せずに Meta の DNS、アイデンティティ、モデレーション、デバイス、バックボーンリスクを継承します。継続性には、別途運用されるウェブサイト、電話や放送経路、購読者リスト、および権威あるソースの明確な階層が必要です。

財務上の重要性は 6 時間の広告以上のものだった

Meta の2021 年 Form 10-Kは、後にこの障害をインフラリスク要因の具体的な例として使用しました。評判とユーザーを引き付け、維持し、サービスする能力は信頼できる製品とインフラに依存し、障害は使用を減少させ広告配信を混乱させる可能性があり、エラーとバグが 10 月に約 6 時間の障害を引き起こしたと述べました。提出書類は、別途監査された障害損失額を報告しませんでした。

この取り扱いは理にかなっています。直接的な逸失広告は収益から近似できますが、平均レートは測定された反実仮想ではありません。需要は時間、国、キャンペーン、および復旧後に支出がシフトする程度によって異なります。その日の同社の株価下落も、広範なテクノロジー売りと無関係の激しい監視の中で発生しました。障害だけに帰することはできません。創業者の純資産計算は市場のスナップショットであり、営業損失ではありません。

より持続的な財務エクスポージャーは、信頼、顧客多様化、規制上の注目、エンジニアリング改善、後のイベントがより長く続くか別の危機と重なる可能性にあります。データ侵害が報告されていない 6 時間のイベントは、Meta の規模の企業によって吸収可能です。このイベントによって明らかになったアーキテクチャは、不利なタイミングの下で実質的に異なる結果を生み出す可能性があります。リスク監視は、観察されたケースの計上費用だけでなく、深刻度分布を考慮する必要があります。

依存するビジネスにとって、重要性テストは機能的でもあります。製品発売、選挙、緊急事態、またはピーク販売期間中の 6 時間は、別の時期の 1 日よりも重要かもしれません。小企業は、需要を迅速に移動するための現金、スタッフ、または顧客データを持っていないかもしれません。月間の可用性を平均化するプロバイダ報告は、この損失の集中を隠す可能性があります。顧客の継続性分析は、障害前に時間的に重要なウィンドウと共通チャネルエクスポージャーを特定する必要があります。

取締役会の説明責任はエンジニアリング指標が終わるところから始まる

取締役はルーターコマンドを承認したり、DNS TTL を選択したりすべきではありません。彼らの役割は、経営陣が潜在的に企業レベルの運用リスクを特定し、権限を割り当て、独立した制御に資金を提供し、復旧を訓練し、安心させる要約に挑戦するのに十分強力な証拠を提供したことを確認することです。10 月の障害は、そのようなレベルの注意を要求するのに十分な規模でした。1 つの内部アクションが、グローバルな製品、内部能力、復旧へのルートを一緒に削除したからです。

Meta の2022 年委任状は、フルボードが戦略的および運用リスクに対する主要な責任を負い、監査・リスク監視委員会が主要なエンタープライズおよびサイバーセキュリティエクスポージャーと、それらを監視または軽減するために経営陣が取った措置を監督したと述べました。また、取締役会の監督は経営陣と内部監査からの報告によって情報提供されたと述べました。これらは同社が説明するガバナンスの割り当てであり、取締役会がこの障害を特定の方法でレビューした証拠ではありません。委任状は、障害固有のボードパック、議事録、チャレンジ記録、または改善保証を公開していません。

有用なボードパックは、取締役を経路数で溺れさせることなく、因果関係の制御を維持するでしょう。以下を含むべきです:

  1. 変更権限:グローバルな効果が可能な操作の数とタイプ。誰がそれらを開始し承認できるか。スコープへのハード制限。試行された禁止変更からの証拠。
  2. ガードレール保証:監査およびポリシーツールのカバレッジ。危険ケースのテスト。フェイルオープン対フェイルクローズドの動作。バリデーターの独立性。欠陥履歴。ガードレール自体の所有権。
  3. 共通モードマッピング:どの製品、リージョン、DNS サイト、アイデンティティシステム、管理ネットワーク、ステータスチャネル、内部ツールがグローバルバックボーンまたはその制御サービスを共有しているか。
  4. DNS 生存性:バックボーン分割下のすべての権威アドレスの外部から測定された到達可能性。親と子の TTL 動作。安全な古い回答ポリシー。経路撤回ロジック。IPv4 と IPv6 の両方の視点からの復旧。
  5. 復旧独立性:指名された対応者が、本番 DNS、企業アイデンティティ、プライマリバックボーンなしで、通信し、認証し、機器に到達し、ステータスを公開し、狭い復旧アクションを実行できることの証明。
  6. 演習の証拠:本番を代表するグローバルバックボーン喪失シミュレーションの結果(失敗した仮定、物理的派遣時間、復旧順序、コールドキャッシュ負荷、日付と所有者付きの未解決アクションを含む)。
  7. 外部影響:サポート需要、再帰 DNS スピルオーバー、顧客および広告主の継続性への影響、影響を受けたサードパーティログインまたは埋め込み機能、実質的な地域依存性。
  8. クロージャー保証:改善が計画された改善のリストやインシデントがレビューされたという宣言ではなく、最大ブラスト半径を変更したことを示す独立したテスト。

これらはゼロ障害の要求ではありません。大規模分散システムは故障し、制御にはコストがかかります。基準は、破壊的権限が比例しているか、障害ドメインが現実的か、復旧が独立しているか、リーダーが既知の弱点が閉じられたことを証明できるかです。取締役会は簡単な反実仮想に答えられるべきです:同じ安全でないコマンドが今日試みられ、コマンド監査ツールに未知の欠陥がある場合、どの独立したメカニズムがグローバルな喪失を防ぐでしょうか?

説明責任は処罰と同じではない

公開記録は、10 月 4 日の障害に対して法的責任を割り当てる執行措置、裁判所の判決、または規制当局の所見を特定していません。影響を受けたすべてのユーザーまたは企業に支払われる契約上の損害賠償を確立していません。オペレーターの名前を挙げておらず、個人の過失を証明しておらず、ユーザーデータが侵害されたことを示していません。同時期の障害は他の Facebook の問題に対する激しい監視の期間中に発生しましたが、時間的近接性はそれらの論争をネットワーク障害の原因にしません。

それでも説明責任は具体的であり得ます。Facebook は、内部コマンドが障害を引き起こしたこと、バグが予防監査を破ったこと、DNS 撤回がイベントを悪化させたこと、通常およびアウトオブバンドアクセスが失敗したこと、内部ツールが機能不全に陥ったこと、グローバルバックボーン喪失が訓練されていなかったことを認めました。これらの自認は、法的評決を必要とせずに、システム設計と経営陣の証拠に関する質問を裏付けます。

コマンドに最も近い人物を罰することは、隠蔽を奨励し、可能にするシステムを無傷のままにする場合、逆効果になり得ます。公正な対応は、通常のヒューマンエラー、無謀な行動、欠陥のあるプロセス、既知のリスクの経営陣による受け入れを区別します。オペレーターが利用可能な手順に従ったか、その手順が安全でないグローバル権限を露出させていたか、以前のテストがコマンドとバリデーターをカバーしていたか、リーダーが復旧が共有依存性を持っていることを知っていたか、改善所有者がリソースと期限を与えられたかどうかを問います。

逆に、「非難なし」は結果のない管理を意味するべきではありません。学習レビューは、アクションが所有され、テストされ、閉じられた場合にのみ信頼できます。グローバル制御がフェイルオープンのまま、演習が観測されたシナリオを除外し続けている、またはアウトオブバンドネットワークが災害と帯域内のままである場合、上級リーダーはその残留リスクを受け入れたことに対して説明責任があります。文化は率直な報告を保護し、ガバナンスは結果として得られた証拠が変更を必要とするかどうかを決定します。

優れた改善が実証できるであろうこと

Facebook は、テスト、演習、全体的なレジリエンスを強化すると述べました。公開エンジニアリング投稿は、完了を検証するのに十分な情報を提供していません。Meta の年次提出書類はリスクを認識していますが、リスク要因の文言は制御テストではありません。したがって、改善への信頼は利用可能な証拠に制限されるべきです。

説得力のある改善パッケージは成果を実証するでしょう。シミュレートされたグローバルブラスト半径を持つコマンドは、意味監査ツールが意図的に故障している場合でも、ハードスコープ制限によって拒否されます。メンテナンス変更は 1 つの隔離されたプレーンまたはリージョンで始まり、到達可能性が逸脱すると自動的に一時停止します。クリーンなロールバックチャネルは、別途アドレス指定され認証された環境から利用可能なままです。権威 DNS は、バックボーンが分割されている場合、独立した経路ポリシーを通じて安全な応答を提供し続けるか、意図的な制限された障害がより安全である理由を文書化し、親とリゾルバの負荷が管理可能なままであることを示します。

同じパッケージは、現実的な制約の下で人間が復旧を完了することを示すでしょう。対応者はアラートを受信し、外部チャネルで通信します。彼らは二重制御下でオフライン手順と認証情報を取得します。ローカルスタッフは測定された目標内に施設に入ります。彼らは企業 DNS なしでデバイスを識別し、アプリケーショントラフィックの前に狭い管理パスを復旧します。公開ステータス更新は、別途ホストされたインフラから署名され公開されます。演習は、理想的な条件を想定するのではなく、欠けている人、古い文書、部分的なテレメトリを注入します。

独立した保証は、失敗した予防制御がそれ自体ソフトウェアだったため重要です。バリデーターを所有するチームはそれを深くテストしても、なおその仮定を共有する可能性があります。内部監査、独立した信頼性グループ、または資格のある外部レビューアは、グローバルスコープの禁止、証拠の追跡可能性、演習のリアリズム、期限超過アクションをテストする必要があります。結果は機密のトポロジを公開する必要はありません。取締役はテスト範囲、例外、失敗ケース、経営陣の対応、再テスト状況を見るべきです。

指標は活動ではなくエクスポージャーを測定する必要があります。「何千もの検証された変更」は、1 つの危険なケースについてほとんど語りません。より良い尺度には、1 つのトランザクションで削除可能なグローバルバックボーン容量の最大割合、独立した制御依存性を持つ権威 DNS 経路の割合、企業 DNS および SSO なしで使用可能な重要インシデントツールの割合、緊急アクセス確立時間、外部ステータス更新公開時間、深刻な演習からの未解決所見の経過時間が含まれます。

最終テストは、冗長性がポリシーを生き残るかどうかです。複数のデータセンター、ファイバ、ルータ、DNS インスタンス、物理プレーンは価値があります。しかし、1 つのコマンド、ヘルス状態、アイデンティティサービス、またはルートコントローラがそれらを一緒に削除できる場合、それらは別個の障害ドメインではありません。リスクレポートのすべての冗長性の主張は、すべてのコピーを同じように動作させることができるコントロールプレーンを指名する必要があります。

永続的なシグナル

2021 年 10 月 4 日は、時代遅れのプロトコルが予期せず失敗した話ではありませんでした。BGP は受け取った撤回を伝播しました。DNS 委任は指定された権威を識別し続けました。再帰的リゾルバは回答を得ようと試み、高需要下で周囲のインターネットの多くは利用可能なままでした。プロトコルは障害を可視化し、Facebook の結合がそれをグローバルにしました。

最も深いシグナルは、運用権限の集中です。ある企業が、共有グローバルバックボーン上で複数の通信、アイデンティティ、広告、ビジネスチャネルを運営していました。その企業内で、メンテナンスパスがグローバルスコープでバックボーンを変更できました。欠陥のある監査ツールがそれを阻止しませんでした。DNS ヘルスロジックは、内部の分割を公開消失に変換しました。復旧ツールとアクセスパスは、同じイベントによって機能不全に陥るのに十分な依存性を共有しました。

この連鎖は、「設定エラー」というフレーズよりも優れた説明責任の対象です。設定エラーは不可避です。独立してテストされた制限のないグローバルな権限は選択です。1 つの論理的健全性の運命を持つ DNS サイトは選択です。主要なコントロールプレーン障害を生き残らないアウトオブバンドパスは証明されていない仮定です。地域的喪失で止まる訓練は、既知のクラスのグローバルアクションをテストされないままにします。

その後の Meta の提出書類は、エラーとバグの組み合わせが障害を引き起こしたことを認めました。説明責任の次のレベルは、その組み合わせがもはや同じ到達範囲を生み出せないという証拠です。取締役、規制当局、顧客、エンジニアにとって、それは企業が別のチェックを追加したかどうかではなく、主要なものが消えたときに別のパスが残っているかどうかを問うことを意味します。