Meta の6時間にわたる消失：コントロールプレーンの結合、DNS の到達可能性、および説明責任

要約

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

プラットフォームが停止しただけでなく、ネットワークが視界から消えた

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

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

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

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

法人名もインシデントの直後に変更されました。障害は Facebook, Inc.の時に発生し、同社はその月の後半に Meta という名前を発表しました。この記事では、10月4日のネットワークと同時期の声明を説明する際には Facebook を使用し、現在のエンティティまたはその後の提出書類について議論する際には Meta を使用します。

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

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

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

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

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

公衆への影響の証拠は、ネットワーク証拠よりも完全ではありません。Facebook は影響を受けた人、メッセージ、取引、ビジネスの監査済み数を公開していません。四半期ごとの結果は、9月30日時点でアプリファミリー全体で35.8億人の月間アクティブユーザーを報告しました。この数字は依存関係の規模を確立するものであり、障害中にサービスの使用を試みて失敗した人の数ではありません。四半期広告収入や世界経済生産を6時間で乗じた推定値はシナリオであり、測定された損失ではなく、ここでは監査済みの影響として扱われません。

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

公的記録はコンパクトな年表を支持しています。以下の時間は UTC であり、観測されたマイルストーンとして読むべきであり、完全な内部イベントログではありません。

タイムラインは管理上の非対称性を露呈しています。破壊的遷移は迅速でした。コマンド、失敗したガード、バックボーン分割、ヘルス状態変更、経路撤退。復旧遷移は、慣れたツールなしでの診断、移動または物理的派遣、セキュアなエントリ、ハードウェアアクセス、段階的バックボーン復旧、および戻るトラフィックの慎重な管理を必要としました。優れた回復力エンジニアリングはこの非対称性を前提としています。破壊的行動にはより強力な前提条件を与え、緊急アクセスを独立させます。なぜなら、グローバル状態変更を元に戻すことは、それを行うことよりもほとんどの場合遅いからです。

引き金となったコマンドは権限の問題だった

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

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

大規模環境では、特権ネットワークコマンドはプロダクションコードです。制約されたスコープ、セマンティックバリデーション、現在のトポロジに対するシミュレーション、爆発半径に比例したピアレビュー、カナリア実行、明示的なアボート条件、および影響を受ける制御プレーンに依存しない自動ロールバックパスが必要です。ツールがすべてのリージョンに到達できる場合、「定期的」は頻度を表し、リスクを表しません。操作に付与された権限は、それが引き起こす可能性のある最大の状態変更によって評価されるべきです。

Facebook は、システムがこのようなコマンドを監査しミスを防ぐように設計されていたが、監査ツールのバグがコマンドを阻止するのを妨げたと述べました。これは管理の欠如ではありませんでした。危険な行動と整列した管理への依存でした。バリデータは承認パスにありましたが、コマンドを正しく判断できなかったときにフェイルクローズの結果を生成しなかったようです。公の投稿は、ツールが誤った承認を返したのか、コマンドを解析できなかったのか、不完全なモデルを評価したのか、別の欠陥に遭遇したのかを説明していません。これ以上の具体的な診断は創作になります。

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

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

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

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

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

そのヘルスポリシーには防御可能な目的があります。正しい答えを提供するために必要な状態を取得または検証できない権威サーバーは、クエリを引き寄せないサーバーよりも悪い可能性があります。経路撤退は、孤立したまたは古いインスタンスにトラフィックが送信されるのを防ぐことができます。誤りはヘルスチェックが存在したことではなく、1つのバックボーン状態がすべての権威サイトに同じ決定をさせ、一度にすべての公的権威を削除させたことでした。

これは古典的な共通モード障害です。分散サーバー、複数のアドレス、多くの場所すべてが1つの共有されたヘルス命題に依存しています。地理的多様性は、すべてのサイトが同じ上流の質問をし、同じように応答する場合、運用上の独立性を生み出しません。公的な設計は多数の物理インスタンスを持っていましたが、この状態の下では1つの論理的な運命を持っていました。

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

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

エニーキャストは状況を複雑にします。RFC 4786は、1つのサービスアドレスを複数の自律的な場所からアナウンスする方法を説明し、その冗長性の利点と監視および障害の落とし穴の両方に言及しています。少数のサービスアドレスの背後にある多くの物理サーバーは巨大な容量を提供できますが、すべてのアナウンスが共通のポリシーによって抑制される場合、見かけ上の多重性は役に立ちません。適切な回復力の尺度は DNS ボックスの数ではなく、信頼できる制御プレーン障害の下での独立して存続可能な権威パスの数です。

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

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

DNS 委任の力は、権威と到達可能性が別であるため誤解されやすいです。.com 親は Facebook のドメインを Facebook のネームサーバーに委任し続けました。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クエリ/秒でした。障害中は90万クエリ/秒以上に上昇し、通常の100倍以上でした。親委任が変更されていないにもかかわらず、いくつかの主要なリゾルバソースは親へのクエリを数千倍に増やしました。委任された権威が到達不能のままであったため、正しいインフラが既に持っている情報を繰り返し再発見するよう求められていました。

この外部性は後にインターネット標準のケーススタディになりました。DNS 解決失敗のネガティブキャッシングに関する RFC 9520（2023年発行）は、リゾルバが失敗をキャッシュし、失敗した権威とその祖先への繰り返しクエリを制限する理由を説明する際に、Facebook の障害を引用しています。この標準はリゾルバの動作を扱い、Facebook の根本原因ではありません。インシデントの言及は、1つのオペレーターの制御プレーン障害が共有 DNS インフラへの負荷になり、より広い運用ルールの変更を動機付ける方法を示しています。

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

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

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

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

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

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

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

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

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

再起動は二度目の高リスク変更だった

エンジニアがバックボーン接続を復旧した後も、Facebook はすべてを一度に安全にオンにすることはできませんでした。データセンターの消費電力は数十メガワット減少していました。世界的な需要の突然の復帰は、電気系統にストレスを与え、キャッシュを過負荷にし、別のクラッシュを引き起こす可能性がありました。したがって、復旧には単に元のコマンドを元に戻すだけでなく、オーケストレーションが必要でした。

ここで Facebook の既存の準備が役立ちました。同社は、サービス、データセンター、または地域をオフラインにしてインフラとソフトウェアをテストする「ストーム」訓練について説明しました。これらの訓練からの経験により、チームは負荷を慎重に増やし、システム全体の崩壊なしにサービスを復旧する自信を得ました。これは記録における重要な肯定的な管理です。テストされていないシナリオを露呈した同じインシデントが、より小規模な深刻な障害をテストする価値も示しました。

ギャップは範囲でした。Facebook は、グローバルバックボーンがオフラインになることをシミュレートしたストーム訓練を実施したことはなく、そうする方法を模索すると述べました。考えられるすべての大災害をテストすることは不可能であり、グローバルバックボーンを意図的に危険にさらすライブテストはそれ自体無責任です。しかし、正確なプロダクションアクションが存在し、グローバルな影響力を持っていました。それにより、世界的な切断はありそうになくても、信頼できる障害モードになりました。シミュレーション、デジタルツイン、分離された制御プレーンレプリカ、ルートポリシーエミュレーション、および机上から物理的な復旧訓練までが、数十億のユーザーを意図的に切断せずにテストできます。

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

依存関係は技術的だけでなく、社会的かつ商業的だった

Meta の製品ファミリーは、通常インフラに関連する規模で既に運用されていました。同社の35.8億人の月間アクティブユーザー数は、35.8億人が同時にオフラインになったことを意味するわけではありませんが、Facebook、Instagram、Messenger、WhatsApp にわたる共通の技術的命运がなぜ重要であるかを示しています。1つの会社のバックボーンでの障害が、多くの人々が別々のサービスとして認識していた複数のチャネルを削除しました。

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

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

広告主は別の依存関係に直面しました。ニューヨークタイムズの報告は、イベント中に売上が急激に低下した企業と、明確な方向性なしに多額の予算を管理するメディアバイヤーについて説明しました。Facebook は広告主が障害中の広告に対して課金されないと述べました。それは直接の請求を防ぎますが、逃したリード、遅れた立ち上げ、失われた会話、特定の日に合わせたキャンペーンの機会費用を回復しません。

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

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

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

財務的重要性は6時間の広告よりも広範だった

Meta の2021年フォーム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 の結合がそれをグローバルにしました。

最も深い信号は、運用能力の集中です。1つの会社が、複数のコミュニケーション、アイデンティティ、広告、およびビジネスチャネルを共有されたグローバルバックボーンで実行していました。その会社内で、メンテナンスパスがグローバルスコープでバックボーンを変更できました。欠陥のある監査ツールはそれを止めませんでした。DNS ヘルスロジックは、内部パーティションを公開消失に変換しました。復旧ツールとアクセスパスは、同じイベントによって障害を受けるのに十分な依存関係を共有していました。

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

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