要約
- Cloudflare が2020年7月17日に公開したポストモーテムによると、アトランタでのネットワーク構成変更により、27分間にわたる大規模障害が発生し、ピーク時には約半数のトラフィックが影響を受け、顧客の可用性に影響を及ぼした。
- 説明責任の問題は、ルータールールのテスト、段階的展開、経路選好、最大プレフィックス保護、バックフェイルセーフ動作、顧客ステータスメッセージング、ロールバック速度、およびインシデント後に展開安全性が改善されたことの証明を誰が管理していたかにある。
- このケースは単なるクラウド障害ではない。Cloudflare のエッジサービス、DNS、セキュリティ、アプリケーション配信、トラフィックステアリングが他組織の公共サービスや事業継続スタックの一部であるため、ネットワーク復元力のケースである。
- 本記事は Cloudflare のポストモーテムを一次的なインシデント報告として扱い、BGP、復元力、SRE、NIST、CISA、ステータス情報源を文脈として使用するが、ルーター内部の証拠としてではない。
- 永続的な教訓は、段階的なネットワーク変更は約束するだけでなく証明されなければならないという点である。プロバイダは、1つのルータールール展開がどのようにテストされ、制限され、監視され、ロールバックされ、共有顧客障害に発展しないように防止されるかを示すべきである。
このケースがリスクと説明責任ファイルに属する理由
Cloudflare は、2020年7月17日のインシデントにより、ルータールール展開をネットワーク復元力の説明責任テストに変えた。このインシデントは、現代のクラウド依存関係の基本的な特徴を明らかにした。すなわち、プロバイダの内部トラフィックエンジニアリングの決定が、変更を認識していない顧客にとって公開可用性イベントになり得るということである。Cloudflare のインシデント報告（https://blog.cloudflare.com/cloudflare-outage-on-july-17-2020/）によると、アトランタでの構成変更によりバックボーントラフィックがブラックホール化され、主要インシデントは21:12 UTC から21:39 UTC まで続き、かなりの割合のトラフィックが影響を受けた。この公開報告は、プライベートなルーターログを発明することなく説明責任の問いを立てるのに十分な事実の骨格を提供している。
問題は Cloudflare が異常に脆弱かどうかではない。問題は、Cloudflare が多くの顧客の公開可用性にとって異常に重要であることだ。Cloudflare のサービスは、ウェブサイト、API、DNS レコード、セキュリティフィルタリング、DDoS 保護、Workers アプリケーション、Zero Trust アクセス経路、パフォーマンスルーティングの前面に配置される可能性がある。そのような役割を持つネットワークプロバイダがバックボーンやルーティングイベントを経験すると、そのインシデントは多くの顧客にとって自社の障害として認識される。これにより、プロバイダの展開管理が顧客の継続計画の一部となる。
Cloudflare のステータスページ（https://www.cloudflarestatus.com/）とステータス履歴（https://www.cloudflarestatus.com/history）は、公開コミュニケーションがインシデント管理の一部となるため重要である。プロバイダ障害時、顧客は自社のオリジンが壊れているのか、DNS が関与しているのか、セキュリティ制御がトラフィックをブロックしているのか、代替経路が存在するのか、ユーザに待機するよう伝えるべきかを判断する必要がある。ステータスページは単なるコミュニケーションツールではなく、下流のトリアージを形成する運用シグナルである。
このケースがリスクと説明責任シリーズに属する理由は、トリガーが不正侵入や自然災害ではなく、計画されたまたは許可されたプロバイダ側の変更が障害モードに遭遇したことにある。これこそが説明責任が最も具体的であるべき点だ。計画された変更はテスト、段階化、制限、監視、ロールバック、訓練が可能である。プロバイダが何が失敗し、何を変更するかを説明するポストモーテムを公開できれば、一般は修復が実際の障害経路に対応しているかどうかを問うことができる。
Cloudflare のラーニングセンターの BGP 背景（https://www.cloudflare.com/learning/security/glossary/what-is-bgp/）、RFC 4271（https://www.rfc-editor.org/rfc/rfc4271.html）、NIST SP 800-189（https://csrc.nist.gov/pubs/sp/800/189/final）は、ドメイン間ルーティングと復元力のあるトラフィック交換を枠組みとして提供する。これらは2020年7月のルーターに関する調査結果ではなく、ローカルプリファレンス、経路広告、トラフィックステアリング、プロバイダバックボーンがなぜ抽象的な配管ではなく制御面であるかを読者が理解するのに役立つ。
公開説明責任の基準は実用的であるべきだ。誰がルータールールを承認したか？ 展開前にどのようにテストされたか？ 1つのロケーションに展開されたか、複数に展開されたか？ 顧客が気付く前にブラックホール化を示すテレメトリーは何か？ 過剰なトラフィックシフトを停止する自動化ガードレールは何か？ 存在したロールバック経路は？ ロールバックの決定は誰が行ったか？ 最大プレフィックス、ローカルプリファレンス、段階的ロールアウトの制御はその後どのように変更されたか？ 影響を受けた顧客はどの顧客で、プロバイダイベントと自社のインシデントをどれだけ迅速に区別できたか？ 公開ポストモーテムは、これらの質問に有用なレベルで答えるために機密デバイス詳細を開示する必要はない。
ルータールールの障害が共有インフラとしてのエッジで顧客障害になる
2020年7月のインシデントは、内部展開の境界を可視化するため有用である。Cloudflare のエンジニアにとって、ルータールールやトラフィックエンジニアリングの変更はネットワーク運用である。顧客にとっては、ウェブサイトの可用性、API の到達可能性、セキュリティ制御の継続性である。この変換がクラウド依存関係の核心である。顧客は DDoS 保護、CDN キャッシング、DNS、アクセス制御、エッジコンピュートを購入するかもしれないが、障害中は単一の可用性事実を経験する。ユーザがサービスに確実に到達できない。
Cloudflare 自身のサービスドキュメント（https://developers.cloudflare.com/fundamentals/、https://developers.cloudflare.com/dns/）は、顧客向け制御面の広さを示している。Workers ドキュメント（https://developers.cloudflare.com/workers/）とネットワーク相互接続情報（https://www.cloudflare.com/network-interconnect/）は、Cloudflare が単なるウェブサイトキャッシュではなく、エッジプラットフォーム、開発者ランタイム、相互接続参加者であることを示している。これらのページはインシデント証拠ではなく、顧客が合理的に Cloudflare の内部ネットワーク変更管理に依存する理由を説明している。
共有インフラは説明責任の計算を変える。顧客が自社のルータールールを変更してネットワークを壊した場合、顧客の変更プロセスが焦点となる。プロバイダが内部ルールを変更し、数千の顧客が可用性を失った場合、プロバイダの変更プロセスは多くの顧客のリスク記録の一部となる。顧客はすべてのルーターコマンドを必要としないかもしれないが、プロバイダの制御が顧客の重要度と互換性があるかどうかを判断するのに十分な証拠を必要とする。これは、公共部門、医療、緊急、金融、市民サービスが公開アクセスの一部としてクラウドエッジプロバイダを使用する場合に特に当てはまる。
このインシデントは、顧客側の冗長性が難しい理由も示している。顧客はマルチ CDN、セカンダリ DNS、オリジンフェイルオーバー、緊急バイパスを設計できるが、これらの制御はコストがかかり、適切に管理されなければセキュリティ体制を弱める可能性がある。多くの顧客は、プロバイダの信頼性とセキュリティが自社で構築できるものより優れているため、プロバイダ集中を受け入れる。そのトレードオフは合理的だが、証明の負担をプロバイダに移す。顧客が Cloudflare に攻撃の吸収とトラフィックのルーティングを依存する場合、Cloudflare は自社の展開経路が攻撃のようなイベントにならないことを示さなければならない。
Google の SRE 資料（https://sre.google/sre-book/handling-overload/、https://sre.google/sre-book/managing-critical-state/）は、分散システムが負荷、フィードバック、状態管理問題の下でどのように失敗するかを枠組みとして提供するため有用な文脈である。Cloudflare のインシデントはネットワーク制御イベントであり、Google SRE のケースではない。しかし、SRE の語彙は適切な質問をするのに役立つ。どのシグナルが監視されたか、どのしきい値が重要だったか、どの自動応答が存在したか、どの人間の判断が必要だったか、修復がどのように検証されたか。
Cloudflare の2020年7月の公開報告は、ルーティング構成に関する保護を含む具体的なインシデント後の改善テーマを特定した。説明責任の問いは、それらのテーマが変更作成から顧客影響までの経路をカバーしているかどうかである。ルールの構文のみをチェックする修復はトラフィック動作を見逃す可能性がある。1つのルーターのみを監視する修復はグローバルシフトを見逃す可能性がある。顧客報告を人間が気付くことのみに依存する修復は遅れる可能性がある。展開前にブラスト半径をシミュレートまたは制限できない修復は、依然として1つのコマンドを顧客障害に変える可能性がある。
段階的展開はエンジニアリングの丁寧さではなく説明責任の制御
段階的展開はしばしばエンジニアリングの慎重さとして説明されるが、インフラプロバイダにとっては説明責任の制御である。理由は単純で、段階的展開は不良な変更が検出される前に害を受ける顧客数を制限するからである。グローバルまたは高ブラスト半径の変更は運用効率的かもしれないが、局所的なミスを公開インシデントに変換する。Cloudflare の2020年7月の障害は、ルーター、トラフィックエンジニアリングシステム、バックボーン経路がアプリケーションコードと同じリリース規律で扱われるべきであり、場合によってはより厳格な規律が必要であることを示している。
段階的ネットワーク展開は、変更が広範なトラフィックに到達する前にいくつかの質問に答えるべきである。意図された効果は何か？ 効果を証明するメトリックは何か？ 害を証明するメトリックは何か？ 最初の展開セルは何か？ 拡張前にセルをどのくらい実行する必要があるか？ 拡張を停止する自動ゲートはどれか？ 既にテストされたロールバック経路はどれか？ インシデント宣言をトリガーする顧客可視シグナルはどれか？ 展開停止の権限を持つ責任エンジニアまたはインシデントコマンダーは誰か？ これらの質問は官僚的ではなく、プロバイダが顧客への害を制限する方法である。
Cloudflare のポストモーテムが重要なのは、単なる謝罪以上のものを顧客に提供したからである。障害経路とフォローアップ制御を説明した。公衆はそれらの制御が十分に具体的であったかどうかを依然として問うことができる。最大プレフィックス制限、ローカルプリファレンス制御、構成検証、段階的ロールアウトはすべて、ルータールールとトラフィックブラックホール化障害に関連するため適切に聞こえる。マッピングが強固であればあるほど、修復の信頼性が高まる。ネットワークがより復元力を持ったという一般的な声明は、悪い経路がどのようにブロックされたかを示さないため弱い。
NIST SP 800-34 Rev. 1（https://csrc.nist.gov/pubs/sp/800/34/r1/final）と NIST SP 800-160 Vol. 2 Rev. 1（https://csrc.nist.gov/pubs/sp/800/160/v2/r1/final）は、ここで有用である。これらは緊急時計画とサイバー復元力の概念を定義している。ルーターマニュアルではない。ネットワークエンジニアリングを復元力の義務に変換するのに役立つ。予想、耐性、回復、適応、検証。プロバイダのポストモーテムは、1つのインシデントからの回復だけでなく、インシデントを許容した展開システムの適応を示すべきである。
段階的展開にはコミュニケーションの対応物もある。プロバイダがリスクの高い変更をセルでロールアウトする場合、対応する検出とステータスセグメンテーションを持つべきである。影響を受ける地域の顧客は、影響を受けない経路の顧客とは異なる情報を必要とするかもしれない。グローバルステータスページは地域差を不明瞭にする可能性があり、詳細過ぎると圧倒する可能性がある。説明責任のあるバランスは、顧客の意思決定シグナルを提供することである。影響を受けたサービス、既知の影響地域、開始時間、緩和時間、現在のステータス、推奨される顧客行動または非行動。
経済的インセンティブは段階化に反する可能性がある。グローバルプロバイダは速度を重視する。ネットワーク変更は、輻輳、攻撃トラフィック、コスト、容量、信頼性に対処するため緊急である可能性がある。しかし、変更が速くなればなるほど、ガードレールはより良くなければならない。2020年7月のインシデントは、速度が敵ではなく、無制限の速度が敵であることを示している。プロバイダは、不良な変更が検出とロールバックの前にグローバルな害を生み出せないことをシステムが証明すれば、迅速に行動できる。
ロールバック速度はタイムラインが正確である場合にのみ可視化される
Cloudflare の公開インシデント報告は、時間枠を提供するため有用である。27分間の大規模インシデントは、プラットフォームに依存する公共サービスを持つ顧客にとって些細なイベントではないが、無制限の障害でもない。説明責任の問題は、タイムラインが何を証明するかである。検出、エスカレーション、緩和、回復を示すことができる。また、システムが人間の介入に依存した箇所、自動制御が作動しなかった箇所、ステータスコミュニケーションが運用現実に遅れた箇所を明らかにすることができる。
ロールバックはしばしばイエス・ノーの質問として扱われる。プロバイダはロールバックしたか、しなかったか。それは粗すぎる。有用なロールバック記録は、害がいつ始まり、内部テレメトリーがいつ害を示し、インシデントコマンドがいつ宣言され、ロールバック決定がいつ行われ、ロールバックアクションがいつ始まり、顧客トラフィックがいつ改善し、完全回復がいつ確認されたかを説明する。これらのタイムスタンプにより、顧客はプロバイダの可観測性と決定速度を判断できる。
ステータスページはその記録の一部を提供できる。Cloudflare のステータスリソースは公開コミュニケーションを示しているが、公開ステータスは内部検出より遅れることが多い。なぜならプロバイダは公開前に事実を確認しなければならないからである。その遅れが小さく説明されていれば許容できる。顧客が自社システムのデバッグに時間を費やしている間に、プロバイダがグローバルまたは地域イベントが進行中であることを既に知っている場合、説明責任の問題となる。顧客は重要なインシデント対応時間を無駄にしないよう、早期にステータスシグナルを必要とする。
ロールバック記録は、技術的回復と顧客回復を区別するべきである。Cloudflare のトラフィックがネットワーク層で回復しても、一部の顧客はキャッシュ、セッション、DNS、リトライ、キュー、ユーザサポートの余波を経験する可能性がある。短いプロバイダ障害は、より長い顧客作業を生み出す可能性がある。公開ポストモーテムはしばしばプロバイダの回復を報告するが、顧客影響にはサポートチケット、失われたトランザクション、失敗した API コール、アラート疲れ、緊急コミュニケーション、信頼損失が含まれる可能性がある。本記事は2020年7月の顧客損失の定量化された数字を主張していない。公開記録がそれをサポートしていないからである。しかし、プロバイダのタイムラインは顧客説明責任の始まりに過ぎないと言及している。
公共部門の継続性は利害を高める。CISA の重要インフラ復元力資料（https://www.cisa.gov/resources-tools/resources/critical-infrastructure-resilience）は、多くの公共および重要サービスがウェブ可用性、DNS、セキュリティフィルタリングに依存しているため有用である。プロバイダの障害は、市民情報、公共ポータル、緊急関連コミュニケーション、基本的なオンラインサービスに影響を与える可能性がある。プロバイダ自体が公的機関でなくてもそうである。これはすべての Cloudflare 顧客が重要インフラであるという意味ではない。プロバイダの制御プロセスは、重要インフラである顧客にとって十分強力であるべきであるという意味である。
ロールバック速度はしたがって証明の問題である。正確なロールバック経路、テストされたロールバックツール、自動化ガードレール、顧客可視の改善を示すことができるプロバイダは、単にサービスが復旧したと言うだけのプロバイダよりも信頼を得る。Cloudflare の詳細なポストモーテムはその証明の基礎を作る。次の説明責任の問いは、顧客がその後のインシデント、ステータス透明性、展開実践の変更において継続的な証拠を見ることができるかどうかである。
ピアリング、トランジット、バックボーン設計は顧客信頼の一部
Cloudflare の2020年7月のインシデントは、内部バックボーンエンジニアリングとより広いインターネットエコシステムの境界にある。顧客はピアリングとトランジットの詳細をめったに調査しないが、それらの詳細は到達可能性を形成する。PeeringDB（https://www.peeringdb.com/）は相互接続エコシステムの公開文脈を提供する。RIPE RIS（https://ris.ripe.net/）と RouteViews（https://www.routeviews.org/routeviews/）は、公開ルーティング観測が存在することを示している。すべてのプライベートプロバイダ決定を明らかにできなくてもである。MANRS オペレーターアクション（https://manrs.org/netops/actions/）と RFC 7908（https://www.rfc-editor.org/rfc/rfc7908.html）は、関連イベントに関連するルートリークとルーティングセキュリティの語彙を提供する。
2020年7月のインシデントは、Cloudflare が分析した2019年6月のルートリーク（https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/）と混同されるべきではない。2019年、Cloudflare は他のネットワークが関与するルートリークを説明する影響を受けたプロバイダであった。2020年、Cloudflare のポストモーテムは内部ネットワーク構成問題を説明している。その区別は、説明責任のマップが異なるため重要である。ルートリークの場合、修復にはオリジン検証、フィルタリング、トランジットプロバイダ責任、エコシステム規範が関与する可能性がある。内部ルータールール障害の場合、修復はプロバイダの変更管理、テスト、ローカルプリファレンス、最大プレフィックス保護、トラフィック制御ブラスト半径により直接焦点を当てる。
Cloudflare は RPKI とルーティングセキュリティの資料（https://blog.cloudflare.com/rpki/、https://blog.cloudflare.com/rpki-updates-data/）を公開している。これらの情報源は Cloudflare の公開提唱とルートセキュリティに関する技術的語彙を示している。2020年7月の修復を自動的に証明するわけではない。しかし、ルーティングセキュリティに深く参加するプロバイダが、公開教育と同様に検証可能なネットワーク変更規律で判断されるべき理由を読者が理解するのに役立つ。
バックボーン設計は顧客信頼の一部である。なぜなら顧客はトポロジーではなく成果を購入するからである。顧客はトラフィックがアトランタ、アッシュバーン、シカゴ、ロンドン、シンガポールを通過するかどうかを気にしないかもしれないが、ルーティング変更が地理を可視化する瞬間に気にする。その瞬間、顧客はプロバイダのトポロジーが暗黙の依存関係であることを発見する。説明責任のあるプロバイダは機密トポロジーを完全に公開する必要はない。障害モードを、顧客がインシデントが設計上局所的、地域的、システム的、またはグローバルであったかを理解できるレベルで説明すべきである。
公開ファイルは、顧客が独立して検証できることを過大評価することを避けるべきである。公開ルートコレクターは一部の BGP 可視動作を示すかもしれないが、内部トラフィックブラックホール化、ローカルルーターポリシー、プライベートバックボーン詳細、アプリケーション層影響を示さないかもしれない。顧客ログは失敗したリクエストを示すかもしれないが、根本原因を示さない。ステータスページはサービス状態を示すかもしれないが、すべてのプライベート証拠を示さない。信頼できる記事はこれらの証拠の限界を可視化し続ける。
有用な説明責任モデルは階層化されている。インターネットエコシステム制御はルートリークとドメイン間信頼に対処する。プロバイダバックボーン制御は内部経路安全性に対処する。プロダクト制御はエッジサービスがネットワークストレス下でどのように失敗または継続するかに対処する。顧客制御は冗長性、緊急バイパス、インシデントトリアージに対処する。公開コミュニケーションは階層を接続する。いずれかの階層が全体の答えとして説明されると、記録は誤解を招くものになる。
顧客の継続性はプロバイダの自信ではなくプロバイダの証明に依存する
顧客にとって、2020年7月の障害後の主な質問は、Cloudflare の従業員が自信を持っていたかどうかではなかった。それは、プロバイダが変更経路が修正されたことを示せるかどうかであった。顧客の継続性は証明に依存する。なぜなら顧客は、重要な経路でプロバイダに依存し続けるか、高価な冗長性を構築するか、アーキテクチャを変更するか、インシデントランブックを調整するか、自社の利害関係者に障害を報告するかを決定しなければならないからである。
Cloudflare の2020年 Form 10-K（https://www.sec.gov/Archives/edgar/data/1477333/000147733321000023/net-20201231.htm）は会社のビジネスリスク文脈を提供し、Cloudflare のトラストとコンプライアンス資料（https://www.cloudflare.com/trust-hub/）は現在の保証文脈を提供する。投資家提出書類とトラストページはインシデント修復証拠ではない。可用性、セキュリティ、顧客信頼がビジネスモデルにとって重要であることを示している。そのため、詳細なインシデント説明責任は倫理的に望ましいだけでなく、商業的に合理的である。
継続性のバイヤーは具体的なインシデント後の質問をするべきである。プロバイダはルータールール変更のブラスト半径を制限したか？ 展開にはネットワークポリシーのカナリアまたはセルベースのロールアウトが含まれているか？ どのメトリックがロールアウトを停止するか？ 最大プレフィックスとローカルプリファレンス制御は自動化されているか？ ロールバックはテストされているか？ ステータスメッセージは内部インシデント状態に結びついているか？ 顧客向けサービスは重要度で分類されているか？ 内部ポストモーテムアクションは完了まで追跡されているか？ エンタープライズ顧客は契約の下でより詳細なインシデント証拠を受け取ることができるか？
顧客は自社側も調査する必要がある。必要に応じて Cloudflare を安全にバイパスできるか？ バイパスはオリジンを攻撃にさらすか？ セカンダリ DNS は設定されテストされているか？ アプリケーションはエッジリトライ動作に対して復元力があるか？ 内部サポートチームはいつ Cloudflare ステータスに依存し、いつオリジンインシデントを開始するかを知っているか？ 公開サービスコミュニケーションはサードパーティエッジ障害に備えているか？ プロバイダの障害は顧客の継続性責任を消し去らないが、顧客の責任はプロバイダが有用な証拠を提供する場合にのみ公平である。
2020年7月のインシデントは、可用性パーセンテージと障害深刻度の違いを強調する。プロバイダは高い年間稼働時間を提供しながらも、その時間にユーザがアクティブだった顧客にとって深刻な27分間のインシデントを引き起こす可能性がある。集約メトリックは集中した害を隠すことができる。説明責任はフリートレベルの信頼性と顧客時間の深刻度の両方を測定するべきである。公開ポータルにとって、締切中の短い障害は、静かな期間の長い障害よりも重要である可能性がある。
したがって本記事は、Cloudflare のポストモーテムを単なる障害の認めではなく、建設的な公開記録として扱う。同社は具体的な説明と命名された修復テーマを提供した。それは漠然とした保証よりも優れている。説明責任の負担は公開後も継続する。その後の展開実践、その後のステータス透明性、その後のインシデント、顧客証拠が、ポストモーテムが耐久性のある制御になったかどうかを決定する。ポストモーテムは過去に関する報告であると同時に未来への約束である。
否定的証拠は有用なネットワークポストモーテムの一部
強力なネットワークポストモーテムは何が起こったかだけでなく、プロバイダが証明できる範囲で何が起こらなかったかも述べるべきである。否定的証拠は、顧客が自社の対応を制限する必要があるため貴重である。インシデントが DNS データ破損イベントではなくトラフィックブラックホール化イベントであった場合、顧客はゾーンファイルの整合性ではなく可用性とリトライ証拠を優先できる。プロバイダが顧客構成が変更されていないことを示せれば、顧客は自社設定の不要なロールバックを避けられる。プロバイダがイベントがトラフィック内容を露出させていないことを示せれば、顧客は機密性レビューと可用性レビューを分離できる。目的はインシデントを最小化することではなく、顧客が間違ったリスクレーンで高価な作業を行うのを防ぐことである。
2020年7月の Cloudflare 障害の場合、有用な否定的証拠には、データ整合性、顧客構成、セキュリティポリシー状態、DNS レコード状態、証明書状態、Workers コード状態、オリジンアクセスに関する境界が含まれる。公開ポストモーテムはしばしば障害の正の連鎖に焦点を当てる。顧客は除外も必要とする。ルータールールイベントがコンテンツを変更したか、プライベートデータを漏洩したか、セキュリティポリシーをバイパスしたか、DNS を変更したか、または単に到達可能性を妨げたかを知る必要がある。プロバイダが除外を証明できない場合は、そのように述べるべきである。証明できる場合は、その根拠を明記するべきである。
否定的証拠は調達および監査チームにも役立つ。ポストモーテムを読むバイヤーは、プライバシーインシデント、稼働時間例外、ベンダーリスクノート、継続性レビュー、または追加措置なしのいずれかを提出するかを決定する必要があるかもしれない。これらの決定は異なる。プライバシーインシデントはデータ範囲の質問を必要とする。稼働時間例外は可用性と顧客通知の質問を必要とする。ベンダーリスクノートはプロバイダが制御を変更したかどうかを尋ねる。継続性レビューは顧客がセカンダリサービス経路を必要とするかどうかを尋ねる。1つの障害がこれらのプロセスのいくつかをトリガーする可能性があるが、正確なポストモーテムは不要なエスカレーションを防ぐことができる。
否定的証拠を書くには規律がある。プロバイダは、「可用性を超える顧客影響なし」などの過度に広範な主張を避けるべきである。ただし、すべての顧客使用例をカバーする証拠がある場合を除く。より良いパターンは境界のある言語である。「影響を受けたシステムで顧客構成の変更は観察されていません」や「イベントはバックボーン内でトラフィックがドロップされたことによるもので、顧客ダッシュボードアクセスは関与していません」や「顧客は失敗したリクエストを見たかもしれませんが、インシデントが認証マテリアルに関与していないため、資格情報をローテーションする必要はありません」など。正確な事実はインシデントに依存する。説明責任のある実践は境界を明記することである。
公開証拠は限界がある。Cloudflare は公開されていない顧客固有データ、プライベートサポート記録、エンタープライズインシデントブリーフィング、内部テレメトリーを持つ可能性がある。公開記事はそれらの事実を発明すべきではない。しかし、説明責任の基準は依然として顧客が恩恵を受ける証拠を指名すべきである。公的否定的証拠の欠如は隠れた害の証明ではない。サービスが重要である場合、洗練された顧客がアカウントチームに、より正確なインシデント声明を求める理由である。
顧客ランブックにはプロバイダエッジ障害の決定を含めるべき
Cloudflare の2020年7月の障害は、顧客がオリジン障害だけでなくプロバイダエッジ障害のランブックを必要とすることをも示している。多くのインシデントチームは、ユーザがアクセス失敗を報告した際に自社のアプリケーション、データベース、クラウドリージョン、ファイアウォール、認証層、展開履歴を調査する訓練を受けている。エッジプロバイダがサービスの前面にある場合、ランブックはエッジプロバイダに現在のステータスインシデントがあるかどうか、代替ルーティングまたはバイパスが安全かどうか、プロバイダの背後でオリジンが健全かどうか、顧客がセキュリティを弱めずにユーザ影響を伝達できるかどうかを尋ねるべきである。
難しいのは、バイパスが危険である可能性があることである。DDoS 保護、ウェブアプリケーションファイアウォール、TLS 終端、ボット軽減、アクセス制御、オリジン非表示のために Cloudflare を使用している顧客は、攻撃や設定ミスにオリジンをさらすことなくプロバイダをバイパスできないかもしれない。低リスクの静的サイトには機能する緊急バイパスが、高リスクの API や公共部門サービスには受け入れられない可能性がある。そのため、プロバイダエッジ障害計画は障害の前に設計されなければならない。顧客はどのサービスがバイパス可能か、どのサービスが不可能か、どのサービスがセカンダリエッジプロバイダを必要とするか、どのサービスが技術的フェールオーバーではなくコミュニケーションを必要とするかを決定すべきである。
同じ論理がセカンダリ DNS とマルチ CDN 設計に適用される。冗長性は依存関係を減らすことができるが、構成の複雑さを追加し、新しい障害経路を生み出す可能性がある。セカンダリプロバイダがセキュリティルール、キャッシュ動作、TLS 構成、オリジン認証、ロギングをミラーリングしない場合、フェールオーバー経路は障害よりも安全でない可能性がある。プロバイダの説明責任と顧客の継続性は相互作用する。Cloudflare は自社の制御を強固にする必要がある。顧客はどのサービスが独立したフォールバックのコストと複雑さを正当化するかを決定する必要がある。
公共部門および重要サービス顧客は特に明確であるべきである。市のポータル、学校情報サイト、健康サービスアプリケーション、裁判所提出ページ、緊急関連コミュニケーションチャネルは、障害、バイパスリスク、公開メッセージングに対して異なる許容度を持つ可能性がある。顧客ランブックは、サードパーティプロバイダ障害を宣言できる者、ステータスメッセージングを切り替えられる者、プロバイダに連絡できる者、セキュリティリスクが可用性利益より大きいためバイパスしないことを決定できる者、既知の情報を公衆に伝えられる者を特定すべきである。プロバイダのステータスページはそのガバナンスプロセスへの入力となる。
プロバイダは、インシデント中に明確な顧客行動ガイダンスを公開することで、それらのランブックを容易にできる。時には正しい顧客行動はなしである。プロバイダの緩和を待ち、オリジン構成を変更しない。時には正しい行動は展開を一時停止するか、重複アラートを抑制することである。時には承認された代替経路を通じて重要なユーザをルーティングすることである。ステータスメッセージは、顧客が自己救済を試みながら追加の害を生み出さないよう十分に正確であるべきである。
インシデント後、顧客は自社のモニタリングが何を見たかを記録すべきである。合成チェックはプロバイダステータスと同時に失敗したか？ 特定の地域のユーザはより悪い影響を経験したか？ サポートチームはオリジン障害を誤診したか？ アラーティングは対応者を圧倒したか？ リトライ動作はオリジンへの負荷を増幅したか？ 緊急コミュニケーションは機能したか？ この顧客記録は Cloudflare のポストモーテムの代替ではなく、説明責任ファイルの下流半分である。プロバイダの証拠と顧客の証拠が一緒になって、依存関係が十分に理解されて維持すべきか、アーキテクチャを変更すべきかが示される。
エンタープライズおよび公共部門顧客は、機密ネットワーク詳細を開示せずに公開ポストモーテムを超えるプロバイダ証拠パックを要求することもできる。有用なパックはすべてのルーターを命名したり独自トポロジーを公開したりしない。影響を受けたサービスクラス、影響を受けた時間枠、観察された顧客向け症状、失敗した制御、ロールバックメカニズム、修復責任者、フォローアップアクションが完了した証拠を要約する。また、境界のある言語を使用して、インシデントが機密性、整合性、または可用性のみに関与したかどうかを述べる。そのような証拠パックにより、顧客は広範な自信ではなく事実で自社のベンダーリスクチケットを閉じることができる。
プロバイダもこの規律から利益を得る。構造化された証拠パックがなければ、重要な顧客ごとに同じ質問の異なるバージョンが寄せられ、サポートチームがポストモーテムの翻訳者になる。構造化されたパックがあれば、アカウントチーム、セキュリティチーム、法務チーム、エンジニアリングチームが同じ記録を参照できる。記録は機密詳細を保持しながら、顧客が内部的に回答しなければならない運用質問に答えることができる。これにより憶測が減り、公開ポストモーテムの有用性が高まる。
したがって、Cloudflare の2020年7月のインシデントは、プロバイダと顧客の証拠交換の設計プロンプトとして読まれるべきである。プロバイダの公開ブログはコア障害経路を説明できる。ステータスページはライブ状態を追跡できる。顧客証拠パックはガバナンスのクロージャをサポートできる。顧客テレメトリーはローカル影響を示すことができる。4つの記録すべてが必要である。なぜなら、単一の記録がすべての説明責任質問に答えるわけではないからである。プロバイダは内部制御証明を所有する。顧客はローカル継続性決定を所有する。公衆は共有インフラ障害が影響を受けたサービスの推測なしでの回復を助ける方法で説明される期待を所有する。
その交換はまた、将来のレビュアーに、次の障害を約束された制御変更と比較するためのベースラインを提供し、すべてのインシデントを孤立した歴史として扱うことを防ぐ。
同じベースラインはアーキテクチャレビューに使用できる。後の Cloudflare インシデントが異なるサービスに影響する場合、顧客は2020年7月の制御が関連していたかどうか、新しい障害クラスが出現したかどうか、プロバイダのポストモーテムスタイルが改善または弱体化したかどうかを尋ねることができる。後のインシデントが同じ迅速なブラスト半径成長パターンを繰り返す場合、顧客は以前の修復が依存関係に完全に対処しなかった証拠を持つ。後のインシデントが狭く、検出が速く、ステータスメッセージングが明確である場合、顧客は制御システムが成熟した証拠を持つ。この比較使用が、ポストモーテムが一般的な復元力言語の代わりに特定の制御主張を保存すべき理由である。
永続的な教訓はネットワーク変更の安全性を観察可能にすること
Cloudflare の2020年7月のルータールール障害からの永続的な教訓は、ネットワーク変更の安全性が展開前、展開中、展開後に観察可能でなければならないことである。展開前、プロバイダは意図されたトラフィック効果を知り、ポリシー動作をシミュレートまたは検証し、ブラスト半径を特定し、段階的経路を選択すべきである。展開中、トラフィック、エラー、ブラックホール化インジケータ、経路変更、顧客向けヘルス、拡張ゲートを監視すべきである。展開後、証拠を保存し、境界のある説明を公開し、修復を完了し、修復をテストすべきである。
これは完璧なネットワークを要求するものではない。大規模ネットワークは失敗する。説明責任の質問は、それらが境界があり、観察可能で、可逆的な方法で失敗するかどうかである。プロバイダは、1つの不良ルールが静かに過剰なトラフィックを捕捉またはドロップできないこと、カナリアセルが予期しない動作を捕捉すること、自動ゲートがロールアウトを停止すること、ロールバックが訓練されていること、ステータスコミュニケーションが顧客に自社オリジンのデバッグに時間を浪費させる前に届くことを示すことで信頼を得ることができる。
Cloudflare のより広範なルーティングと信頼性資料（https://www.cloudflare.com/learning/security/glossary/what-is-bgp/、https://blog.cloudflare.com/rpki/、https://blog.cloudflare.com/rpki-updates-data/）は、同社が公開ルーティングを説明責任の領域として理解していることを示している。2020年7月のケースは同じ基準を内部に適用する。公開ルーティングの提唱は、内部ネットワーク変更制御が同等に検証可能である場合に最も強力である。顧客はドメイン間とドメイン内の原因の区別をエンジニアほど明確に経験しない。彼らは到達可能性を経験する。
このインシデントはまた、すべてのエッジおよびクラウドプロバイダに対する一般的なバイヤーの質問を示唆する。どの種類の内部変更が顧客障害を生み出す可能性があり、その種類はどのように制限されているか？ プロバイダは DNS 変更、ルーティング変更、ファイアウォールルール変更、証明書変更、アイデンティティポリシー変更、キャッシュポリシー変更、展開ツール、データベース移行について回答できるべきである。回答には防止と回復の両方を含めるべきである。「専門家がいます」は制御ではない。「自動停止条件とテスト済みロールバックを備えた段階的展開を行っています」は制御に近い。「アクション追跡付きのポストモーテムを公開しています」はさらに近い。
公共部門の継続性はこの規律をより選択肢のないものにする。政府、学校、健康サービス、緊急関連サイト、市民組織は、セキュリティとパフォーマンスを向上させるために商業クラウドエッジプロバイダに依存することが多い。その依存は、プロバイダが内部ネットワーク変更を公衆向けリスクとして扱う場合にのみ合理的である。プロバイダ内部のルータールール変更は、プロバイダ外部の公共サービスインシデントになり得る。説明責任の連鎖はその現実を認識しなければならない。
したがって、Cloudflare の2020年7月の障害は、実用的制御の明確な例であるため、このシリーズに属する。ルータールールを展開できたオペレーターは、変更のテスト、段階化、監視、ロールバックに対して最も強い義務を持っていた。顧客は依存関係を理解し継続性を計画する義務があったが、プロバイダのバックボーンを修正することはできなかった。公開記録は、内部プロバイダ制御が顧客可用性制御になり、インシデントが修復され、修復が次のネットワーク変更を顧客が信頼できるよう十分に可視化されなければならないと正確に述べるときに最も強力である。