概要
- Cloudflare の2025年6月12日の事後報告書は、サードパーティのクラウドプロバイダーの障害に関連して、Workers KV および依存する製品に影響を与えたサービス停止があったと述べている。影響を受けた製品リストと依存関係の説明は、Cloudflare 自身の事後報告書に帰属する必要がある。
- 上流プロバイダーのステータス記録は重要だが、Cloudflare の内部依存設計、顧客とのコミュニケーション、劣化運用、および計画された依存関係削減作業が完了したという証拠に対する説明責任を排除するものではない。
- 説明責任の問題は、隠れた障害ドメインの再結合である。顧客は別のプロバイダーからの多様化を目的として Cloudflare を選択することがあるが、Cloudflare の製品がサードパーティのクラウドコンポーネントに依存する可能性は、依存関係が開示され、分離され、またはグレースフルデグラデーションのために設計されていない限り残る。
- Workers KV は開発者向けのストレージプリミティブである。それが損なわれると、ダウンストリームのアプリケーション、アクセスワークフロー、セキュリティツール、中小企業のサービスが、顧客が計画していなかった方法で失敗する可能性がある。
- 信頼できる修復記録には、依存関係マッピング、影響を受ける製品の明確化、顧客通知の質、フェイルオーバーの再設計、劣化モードの動作、復旧の順序、復元力テスト、および事後報告書で行われたコミットメントが完了したという後の証拠が含まれるべきである。
隠れた依存関係が障害ドメインを再結合する
Cloudflare 自身の事後報告書、Cloudflare service outage on June 12, 2025は、影響を受けた Cloudflare サービス、Workers KV の依存関係の説明、および修復のコミットメントの主要な情報源である。Cloudflare のステータスページおよびステータス履歴は、公開インシデントステータスのコンテキストを提供する。公開の教訓は、単にサービスが停止したことではない。それは、顧客が独立した復元力層として扱う可能性のあるプロバイダー自体が、障害ドメインを再結合する方法で別のプロバイダーに依存する可能性があるということである。
その再結合が説明責任の問題である。顧客はパフォーマンス、セキュリティ、エッジコンピューティング、アクセス制御、開発者サービスのために Cloudflare を使用する可能性がある。また、顧客は別の場所でハイパースケールクラウドプロバイダーを使用する可能性がある。Cloudflare の製品が内部的に同じプロバイダーに依存している場合、顧客のアーキテクチャは顧客が考えているほど多様化されていない可能性がある。顧客は2つのベンダーを見ているかもしれないが、障害パスには1つの共有依存関係が含まれている可能性がある。
これは、サードパーティの依存関係がデフォルトで無責任であることを意味するものではない。現代のクラウドサービスは、多くのコンポーネント、サプライヤー、リージョン、API、ストレージシステム、アイデンティティサービス、運用ツールから構築されている。問題は、依存関係が理解され、分離され、伝達され、安全に失敗するように設計されているかどうかである。コアな顧客ワークフローを損なう可能性のある隠れた依存関係は、より強力な公開証拠記録に値する。
したがって、Cloudflare の事後報告書はダウンストリームプロバイダーの証拠として読まれるべきである。Cloudflare 自身のシステムを Cloudflare の視点から説明している。Google Cloud のステータス更新およびGoogle Cloud インシデントレポートは、上流のコンテキストを提供する。上流の記録は、より広範なイベントを理解するのに役立つが、すべての Cloudflare 顧客の質問に答えるものではない。Cloudflare は依然として自社の製品依存設計と顧客コミュニケーションを管理している。
この分離は重要である。上流プロバイダーが全体像として扱われる場合、Cloudflare 自身の継続性の義務は消える。Cloudflare があたかも上流インシデントを引き起こしたかのように非難される場合、依存構造は誤解される。説明責任の問題はこれらの極端な中間にある：Cloudflare は何に依存していたのか、その依存が失敗したときに何が失敗したのか、顧客は何を知っていたのか、その後何が変わったのか。
Workers KV はストレージプリミティブであり、背景の詳細ではない
Cloudflare のWorkers KV ドキュメントは、開発者が使用するキーバリューストレージサービスを説明している。Cloudflare Workers ドキュメントおよびWorkers KV ランタイム API ドキュメントは、エッジで構築されたアプリケーションにとってこのサービスが重要である理由を示している。KV は、設定、セッション関連の状態、機能フラグ、アプリケーションデータ、アクセスルール、キャッシュされたメタデータ、および開発者が高可用性として扱う可能性のあるその他の値を保持できる。
ストレージプリミティブが損なわれると、障害は多くのダウンストリームの方法で現れる可能性がある。ウェブサイトは読み込まれてもパーソナライゼーションを失う可能性がある。アクセスツールはポリシー状態の取得に失敗する可能性がある。セキュリティ製品は設定データを欠く可能性がある。中小企業のアプリケーションは顧客状態を提供できなくなる可能性がある。SaaS オペレーターは KV に依存するワーカーでエラーを目にする可能性がある。ユーザーは KV が関与していることを知らないかもしれない。彼らはアプリケーションの失敗しか見えない。
これが、影響を受ける製品の明確さが重要である理由である。Cloudflare の事後報告書は、影響を受けるサービスの公開リストを管理している。責任ある記事は、Cloudflare が特定していない製品の障害を推測すべきではない。また、すべての Cloudflare 製品が同等に影響を受けたかのように扱うべきでもない。顧客は、自分のアーキテクチャが露出していたかどうかを判断できるように、特定の製品と依存関係のカテゴリを必要としている。
開発者向けサービスは特別な通知負担を負う。開発者は、Cloudflare の文書化されたサービス特性を前提としてアプリケーションを設計している可能性がある。停止によって隠れた依存関係が明らかになった場合、開発者はアーキテクチャ、フォールバック動作、エラーハンドリング、顧客コミュニケーションを調整する必要があるかもしれない。プロバイダーの事後報告書は、新しいリスクを生み出すセンシティブな内部実装を公開せずに、その設計レビューに十分な詳細を提供する必要がある。
Workers KV は、プロバイダーの抽象化が状態の集中を隠すことができる理由も示している。シンプルなキーバリューAPI は、サーバーレスで分散されているように感じられるかもしれない。基礎となる実装は、特定の制御システム、メタデータサービス、ストレージ階層、サードパーティプロバイダー、またはレプリケーションの決定に依然として依存する可能性がある。顧客はすべての実装の秘密を必要としているわけではないが、どのサービス保証がプロバイダー障害条件下で意味があるのかを知る必要がある。
上流の障害はダウンストリームの設計義務を消し去らない
Google Cloud の信頼性ガイダンス、Architecture Framework: Reliabilityは、障害に耐えるシステムを設計するための一般的なコンテキストを提供する。AWS のWell-Architected Reliability Pillarおよび Microsoft のAzure Well-Architected reliability guidanceは、同じクロスクラウドのポイントを指している：回復力のある設計には、依存関係、障害モード、復旧目標、トレードオフの理解が必要である。
これらの一般的なフレームワークは、Cloudflare に関するインシデントの調査結果ではない。それらは、設計上の質問を定義するので有用である。プロバイダーが多くの顧客にインフラストラクチャとして扱われるサービスを提供する場合、プロバイダーはどの依存関係が許容可能か、どれが分離を必要とするか、どれがフェイルオーバーを必要とするか、どれが劣化可能かを決定しなければならない。サードパーティの障害はこれらの選択をテストする。
ダウンストリームプロバイダーの義務には、依存関係マッピング、分離、フォールバック設計、ステータスコミュニケーション、復旧の順序付けが含まれる。サードパーティのサービスが失敗した場合、ダウンストリームプロバイダーは、どの内部製品がそれに依存しているか、どのような顧客症状が現れるか、読み取り専用または劣化モードが可能かどうか、フェイルオーバーが存在するかどうか、そしてどのような影響があるかを顧客に伝える方法を知っているべきである。これらの義務は、上流プロバイダーが最初の混乱を引き起こした場合でも存在する。
これは、すべてのダウンストリーム製品がすべてのサードパーティ依存から独立しなければならないという意味ではない。それは非現実的だろう。いくつかの依存関係は意図的であり、経済的に合理的である。説明責任の基準は比例性である。依存関係が顧客が継続性のために使用するサービスを損なう可能性がある場合、プロバイダーはグレースフルデグラデーションのために設計するか、制限について明示する必要がある。サービスが重要であればあるほど、顧客はより多くの証拠に値する。
Cloudflare の公開事後報告書は、依存関係と修復のコミットメントを認めている点で貴重である。フォローアップの説明責任の質問は完了である。依存関係削減のステップは完了したか？フェイルオーバーパスはテストされたか？影響を受けた製品はより安全に劣化するように再設計されたか？顧客にはアーキテクチャガイダンスが提供されたか？事後報告書は修復記録を開始する。それは完了させるものではない。
タイポグラフィに関する注意
劣化モードは顧客への約束である
信頼性設計はしばしば完全な復旧に焦点を当てる。顧客は劣化モードも必要としている。データを書き込めないサービスでも読み取りを提供できるかもしれない。更新できないポリシーストアでも、最後に確認された良好な設定を強制できるかもしれない。依存関係に到達できない開発者プラットフォームは、タイムアウトではなく明示的なエラーを返すかもしれない。ステータスシステムは影響を受ける API を迅速に特定するかもしれない。劣化モードは、完全な混乱と制御された制限の違いである。
Google SRE Book のハンドリングオーバーロードの章は、過負荷と依存関係のストレスがシステムに負荷を捨て、優先作業を保持し、予測可能に失敗することを要求するため関連性がある。重要な状態の管理の章は、状態の依存関係が移動、キャッシュ、回復が困難であるため関連性がある。Workers KV は状態サービスであり、障害設計は状態が常に即座に再計算できるとは限らないという事実を考慮しなければならない。
顧客にとって、劣化モードは製品の期待の一部であるべきである。KV が利用不可または損なわれている場合、アプリケーションは何をすべきか？最後に知られている値をキャッシュできるか？古い設定を提供すべきか？セキュリティポリシーに対してフェイルクローズすべきか？コンテンツ表示に対してフェイルオープンすべきか？開発者はセカンダリストアを構築すべきか？Cloudflare は、顧客がこれらの決定を下すのに役立つドキュメントとインシデントレッスンを提供できる。
プロバイダーの内部劣化モードと顧客のアプリケーション劣化モードは相互作用する。Cloudflare は KV が特定の方法で劣化するように設計するかもしれない。開発者はその動作を処理する場合としない場合がある。プロバイダーの事後報告書が障害モードを明確に説明すれば、開発者は自身の設計を改善できる。事後報告書が曖昧であれば、各顧客は何を変更すべきかを推測しなければならない。
したがって、説明責任の基準は「より速く復旧する」だけではない。「失敗を読み取り可能にする」ことである。読み取り可能な失敗は、既知の症状、ステータスメッセージ、エラー動作、顧客ガイダンス、復旧の期待を持っている。隠れた依存関係の失敗は、事後報告書が説明するまで読み取り不可能であるために有害である。
中小企業はプロバイダーのアーキテクチャを継承するが、それを見ることはない
中小企業は、自分たちでグローバルな信頼性を構築できないため、しばしばクラウドインフラを利用する。彼らは複雑さを管理するためにプロバイダーに依存している。これにより、隠れた依存関係のリスクが特に重要になる。大企業はベンダーリスクチーム、アーキテクチャレビュー、マルチプロバイダー設計を持っているかもしれない。小規模な開発者は製品ドキュメントを読み、プロバイダーを信頼し、構築する。
Workers KV の停止が中小企業のアプリケーションに影響を与えた場合、企業はセカンダリストレージ層を準備していないかもしれない。障害が自社のコード、Cloudflare、上流プロバイダー、DNS、認証、顧客ネットワークのいずれにあるのかわからないかもしれない。複雑な事後報告書を解析するスタッフがいないかもしれない。プロバイダーのステータスとコミュニケーションが、企業のインシデント対応になる。
NIST SP 800-34 Revision 1、Contingency Planning Guide for Federal Information Systemsは一般的な継続性の情報源であるが、その基本的な教訓は適用される：組織はシステムの混乱に対する緊急時計画を必要とする。中小企業にとって、プロバイダーのガイダンスはその計画を実行可能にすることができる。クラウドプロバイダーは、キャッシュ戦略、マルチリージョンの考慮事項、データエクスポート、障害処理、ステータス購読、テスト方法などの実用的なパターンを提供すべきである。
NIST SP 800-160 Volume 2 Revision 1、Developing Cyber-Resilient Systemsは、回復力を予測、耐性、回復、適応の能力として位置付けている。隠れた依存関係の停止は、プロバイダーの下のプロバイダーが失敗したときにシステムが適応できるかどうかを問うため、回復力のテストである。顧客の回復力はプロバイダーの透明性に依存する。
CISA のcritical infrastructure resilienceリソースは、システム上の依存関係に対する公共セクターの枠組みを提供する。開発者サービスがすべての顧客にとってそれ自体が重要なインフラでなくても、パターンは重要である：多くの小規模サービスが同じ隠れた障害ドメインに依存する可能性がある。停止は、依存関係を共有していることを知らなかった企業に波及する可能性がある。
ステータスコミュニケーションは製品層を分離すべきである
マルチプロダクトプロバイダーにおけるステータスコミュニケーションは、階層化されなければならない。コア CDN、セキュリティ、Workers、KV、Access、Pages、またはその他のサービスを使用している顧客は、どの層が影響を受けているかを知る必要がある。ステータス言語が広すぎると、影響を受けていない顧客がパニックになる。狭すぎると、影響を受けた顧客が関連性を見逃す。上流プロバイダーだけを挙げると、顧客はどの Cloudflare 製品が損なわれているかを理解できないかもしれない。
Cloudflare のステータスページと履歴は、ステータスチャネルのコンテキストを提供する。事後報告書はより深い説明を提供する。両者は一致すべきである。ステータス更新は、影響を受けた製品、顧客の症状、進捗状況、および復旧が部分的か完全かを特定すべきである。事後報告書は、根本原因、依存関係構造、タイムライン、影響、修復のコミットメントを説明すべきである。顧客はリアルタイム版と事後版の両方を必要としている。
コア CDN/セキュリティ製品と Cloudflare が損なわれたと特定した製品の区別は重要である。Cloudflare は幅広いプラットフォームである。Workers KV の障害は、自動的にすべての Cloudflare サービスの障害として読まれるべきではない。逆に、依存する製品を使用している顧客は、一般的なプラットフォーム通知から影響を推測すべきではない。製品層の精度は信頼の管理である。
優れたステータスコミュニケーションは、顧客が独自の通知を書くのにも役立つ。Cloudflare 上に構築された SaaS オペレーターは、サービス低下を顧客に説明する必要があるかもしれない。Cloudflare が具体的な影響を受けた製品とタイムライン情報を提供すれば、より正確にそれを行うことができる。Cloudflare のステータスが曖昧であれば、ダウンストリームの通知も曖昧になる。不確実性は伝播する。
公開事後報告書は、顧客の検出にも対処すべきである。顧客はどのようなエラーを目にしたであろうか？どの API または製品が損なわれたか？顧客は影響を確認するためにどのログを使用できるか？データの耐久性や一貫性が影響を受けたか、それとも主に可用性か？公開記録がすべての質問に答えられない場合、顧客がさらに詳細を求めることができる場所を示すべきである。
依存関係マップは制御された形で顧客向けにすべきである
プロバイダーはすべての内部依存関係マップを公開することはできない。それはセキュリティと競争上のリスクを生み出す。しかし、顧客が障害ドメインを評価するのに役立つ制御された依存関係情報を公開することはできる。例えば、製品は、サードパーティのクラウドリージョンに依存するかどうか、マルチリージョンレプリケーションが存在するかどうか、顧客が計画すべき障害モード、およびサービスレベル目標が上流プロバイダーの障害を除外するかどうかを文書化できる。
これは法的な細則だけではない。アーキテクチャ情報である。回復力のために設計している顧客は、Cloudflare ともう一つのクラウドプロバイダーを選択することが特定のリスクを真に多様化するかどうかを知る必要がある。Cloudflare Workers KV が関連するパスでサードパーティプロバイダーに依存している場合、顧客は有用なレベルで設計の含意を理解すべきである。そうでなければ、顧客は誤って相関アーキテクチャを構築する可能性がある。
依存関係の透明性は階層化できる。公開ドキュメントは広範なアーキテクチャと障害モードを説明できる。エンタープライズトラスト資料は、適切な管理の下でより詳細を提供できる。ステータスページは、インシデント固有の依存関係を関連する場合に開示できる。事後報告書は、センシティブな内部を公開せずに何が変わったかを説明できる。目標は、完全な内部図ではなく、顧客の設計に十分な情報である。
2025年6月のインシデントは、依存関係を事後的に可視化した点で貴重である。修復の質問は、次の事実の前に依存関係が十分に可視化されたかどうかである。顧客は、障害モデルで2つのプロバイダーが接続されていることを知るために停止を必要とするべきではない。プロバイダーは、重要な依存関係の選択を事前に読み取り可能にするべきである。
残された未知数と説明責任の問い
公開記録にはいくつかの未知数が残されている。Workers KV の障害による顧客ごとの完全な影響は提供されていない。インシデント前の Cloudflare の内部依存設計全体は公開されていない。計画された依存関係削減のコミットメントがすべて完了したかどうかは独立に検証されていない。すべての顧客が停止前に共通の障害ドメインを評価するのに十分なアーキテクチャ情報を持っていたかどうかは証明されていない。
これらの未知数は説明責任を不可能にするものではない。それらは、顧客と観察者が次に何を探すべきかを定義する。Cloudflare は Workers KV の依存関係の設計、影響を受ける製品のコミュニケーション、劣化モードの動作、復旧シーケンス、修復のコミットメントを管理していた。Google Cloud は自社の上流障害とステータス報告を管理していた。顧客は、製品の動作と依存関係モデルが可視化されていた範囲でのみ、アプリケーションのフォールバック動作を管理していた。
説明責任の問いは、停止が将来の隠れた依存関係のリスクを減少させたかどうかである。Cloudflare は依存関係を明確にマッピングしたか？障害パスを除去または分離したか？フェイルオーバーを改善したか？顧客ドキュメントを更新したか？上流障害条件下で新しい設計をテストしたか？顧客に何を異なるべきか説明したか？後のステータス記録は改善された動作を示したか？
答えは証拠に基づくべきである。回復力が改善されたという声明は、顧客がどのカテゴリの回復力が変化したかを見ることができる場合にのみ役立つ。読み取り可用性は改善されたか？書き込み可用性は改善されたか？製品の依存関係は縮小したか？復旧時間は短縮したか？劣化モードはより安全になったか？ステータスコミュニケーションはより速くなったか？これらは測定可能な質問である。
最終的な教訓は、証明を伴う多様化である
クラウド顧客はしばしば複数のベンダーを選択することで多様化する。その戦略は、ベンダーの内部依存関係が同じ障害ドメインを静かに再結合しない場合にのみ機能する。2025年6月の Cloudflare インシデントは、多様化が証明されなければならず、想定されてはならないことを思い出させる。顧客は Cloudflare と Google Cloud を別々の選択肢として見るかもしれないが、内部依存関係が特定の製品パスでそれらを依然として結びつける可能性がある。
これは、顧客がすべての抽象化を信頼すべきでないという意味ではない。抽象化はクラウドサービスが利用可能である理由である。それは、プロバイダーが販売する抽象化の回復力特性について明確であるべきだという意味である。サービスがグローバルに分散されている場合、顧客はどの部分がグローバルに分散され、どの部分がより狭いシステムに依存しているかを理解すべきである。サービスがサードパーティのインフラを使用している場合、顧客はその依存関係が自分たちを損なう可能性があるかどうかを理解すべきである。
Cloudflare にとって、停止後の説明責任の基準は完璧ではない。それは学習の証拠である：より明確な依存関係マッピング、より安全な劣化モード、約束された場所での依存関係の削減、より強力なフェイルオーバー、より良いステータスの具体性、および開発者が回復力のあるアプリケーションを設計するのに役立つ顧客ガイダンス。顧客にとって、教訓は「どのベンダーを使うか？」だけでなく「ベンダーはどの障害ドメインを共有しているか？」と問うことである。
この停止は、リスクと説明責任シリーズに属する。なぜなら、それは微妙な現代のクラウドリスクを暴露するからである。プロバイダーは他のプロバイダーに依存しながら回復力を販売できる。それは合理的であり得るが、管理されなければならない。継続性は、稼働時間の数値だけの問題ではない。それは、どの依存関係が一緒に失敗するかを知り、次の失敗がより小さくなることを証明することの問題である。
顧客のアーキテクチャは合理的な理由で間違っている可能性がある
顧客は利用可能な情報に基づいて合理的な設計選択を行うが、それでも障害ドメインを誤解する可能性がある。開発者はアプリケーションロジックを Cloudflare Workers に配置し、Workers KV を設定や状態に使用し、他のサービスを Google Cloud にホストするかもしれない。これはリスクを分散するように見える。Workers KV がいくつかの重要な操作で Google Cloud パスに依存している場合、アーキテクチャは開発者の意図よりも相関している可能性がある。間違いは愚かさではない。それは依存関係情報の欠落である。
これがプロバイダーのドキュメントが重要である理由である。製品ページはしばしばパフォーマンス、スケール、使いやすさ、グローバル可用性を強調する。顧客は障害ドメイン情報も必要としている。どのコンポーネントがレプリケートされているか？どのコンポーネントがサードパーティの依存関係を持つか？どの依存関係が読み取りパス、書き込みパス、制御パス、復旧パスにあるか？どの製品が混乱中に古いデータを提供するように設計されているか？どの製品がプロバイダー依存関係へのライブアクセスを必要とするか？
答えはすべての内部詳細を公開する必要はない。顧客はデータベーステーブル名やプライベートネットワーク図を必要としない。彼らは設計に関連するカテゴリを必要としている。サービスが可用性を損なう可能性のあるサードパーティのクラウド依存関係を持つ場合、その事実は制御されたレベルで表現できる。インシデント後にその依存関係が削除または削減された場合、プロバイダーはどのクラスの依存関係が変わったかを述べることができる。
顧客のアーキテクチャレビューは、その後それらの事実を組み込むべきである。KV を機能フラグに使用する企業は、古い読み取りが許容可能であると判断するかもしれない。KV をポリシーに使用するセキュリティ製品は、フェイルクローズ動作がより安全であると判断するかもしれない。消費者向けアプリは、非センシティブなコンテンツを別の場所にキャッシュすることを決定するかもしれない。規制対象サービスは、セカンダリプロバイダーまたはローカル緊急モードを必要とするかもしれない。適切な依存関係情報は、異なる顧客が異なる選択をすることを可能にする。
その情報がなければ、すべての顧客は同じ驚きを継承する。それがクラウドサービスにおける障害ドメイン説明責任の問題である：プロバイダーは地図を持っているが、顧客は停止コストの一部を負担する。
サービスレベル言語は依存関係の現実と一致すべきである
サービスレベル目標とステータスページは、意図せずに依存関係の境界を隠す可能性がある。製品は可用性を宣伝するかもしれないが、顧客の本当の質問はどの障害モードの下での可用性かである。コミットメントはプロバイダー自身のインフラが健全であることを前提としているか？上流のクラウド停止を除外しているか？依存する製品を含んでいるか？読み取りと書き込みの操作を区別しているか？グローバルまたはリージョナルに適用されるか？コントロールプレーン機能とデータアクセスの両方をカバーしているか？
2025年6月の停止は、この質問を実用的にする。Workers KV を評価している顧客は、抽象的な稼働時間よりも、依存関係が失敗したときに何が起こるかを気にするかもしれない：アプリケーションは既存のキーを読み取れるか、新しい値を書き込めるか、キーをリストできるか、API 呼び出しを認証できるか、新しいワーカーをデプロイできるか、古い設定を提供できるか？単一の可用性パーセンテージはそのすべてに答えることはできない。
ステータスページはこの粒度を反映すべきである。インシデント中、「パフォーマンス低下」は、書き込みが失敗しているか、読み取りが古いか、レプリケーションが遅れているか、依存する製品が損なわれているかを知る必要がある開発者には曖昧すぎるかもしれない。プロバイダーはすべての詳細を即座に知ることはできないかもしれないが、ステータスの進行は事実が到着するにつれて不確実性を狭めるべきである。事後報告書はその後ループを閉じるべきである。
これは顧客エクスペリエンスの問題だけではない。インシデント対応を形作る。顧客が書き込みは損なわれているが読み取りは安全であると知っていれば、一時的に設定変更を凍結できる。ポリシーの読み取りが失敗する可能性があると知っていれば、フォールバックを起動できる。製品が低下していることだけを知っていれば、より広範でより混乱の大きい行動を取るかもしれない。正確なプロバイダーコミュニケーションは、ダウンストリームの過剰反応を減らす。
したがって、サービスレベル言語はインシデントに対してテストされるべきである。ステータスページは顧客が必要とするものを伝えたか？SLA または SLO の言語は障害と一致していたか？顧客はインシデントがコミットメントにカウントされるかどうかを理解したか？製品ドキュメントは障害モードに備えた設計方法を説明していたか？そうでなければ、プロバイダーの信頼性の約束は見た目よりも使い勝手が悪い。
データローカリティとプロバイダー依存関係は別の問題である
顧客はしばしばデータローカリティを、データが保存または処理される場所の観点から考える。隠れたサードパーティ依存関係は、関連するが異なる問題を提起する：どのプロバイダー関係がサービス運用に参加しているか？サービスはデータを一箇所に保存し、エッジでリクエストを処理し、それでも制御機能、ストレージバッキング、コーディネーション層、または運用コンポーネントのために別のプロバイダーに依存する可能性がある。依存関係は、顧客の正式なデータレジデンシーの態勢を変えなくても、継続性にとって重要であり得る。
この区別は顧客資料で明確にされるべきである。サービスがリージョナルデータロケーション保証を持っている場合、顧客はそれらの保証が可用性の依存関係に対処しているかどうかを知るべきである。顧客はデータローカリティ要件を遵守していても、別のプロバイダーに継続性の依存関係を持っている可能性がある。逆に、サードパーティの運用依存関係は、顧客データがそのプロバイダーに公開されたことを意味しないかもしれない。カテゴリはぼやけるべきではない。
Cloudflare インシデントにおいて、記事はソース記録を超えた顧客データの移動を推測すべきではない。説明責任の問題は継続性と依存関係の可視性であり、根拠のないデータ転送の主張ではない。しかし、データ主権の懸念を持つ顧客は、隠れた依存関係がリスク分析に影響するかどうかを依然として問うかもしれない。プロバイダーは正確な用語で答える準備をすべきである：どのデータ、どのメタデータ、どの制御信号、どのリージョン、どのプロバイダー、どの障害モード。
精度は双方を保護する。顧客が証拠が可用性の損害のみを支持する場合にデータ露出を想定することを防ぐ。また、プロバイダーが正当な依存関係の質問をプライバシーの誤解であるかのように却下することを防ぐ。継続性、プライバシー、ローカリティ、回復力は重なるが、同一ではない。
最良の顧客ドキュメントはこれらの次元を分離するだろう。データレジデンシーは顧客データが保存または処理される場所を説明する。運用依存関係はサービスが機能するためにどのシステムが機能しなければならないかを説明する。コントロールプレーン依存関係はどのサービスが設定や調整を管理するかを説明する。障害ドメイン依存関係はどの外部停止が製品を損なう可能性があるかを説明する。顧客は真剣なアーキテクチャのために4つのビューすべてを必要としている。
復旧の順序付けは公開信頼性シグナルである
事後報告書は停止がなぜ始まったかだけでなく、復旧がどのように順序付けられたかを説明すべきである。どの依存関係が最初に戻らなければならなかったか？どの製品が最初に復旧したか？顧客は書き込みの前に読み取りを提供できたか？依存する製品は Workers KV の後に復旧したか、それともいくつかは追加の修復を必要としたか？ステータスメッセージは技術的復旧と同じ順序で更新されたか？復旧の順序は、プロバイダーが自身の依存関係グラフをどのように理解しているかを顧客に伝える。
幅広いプロバイダーにとって、復旧の順序付けは優先順位も明らかにする。いくつかの製品はセキュリティ制御をサポートし、いくつかは開発者アプリケーションをサポートし、いくつかは顧客アクセスをサポートし、いくつかは内部運用をサポートする。マルチプロダクトの損害中、リーダーは何を最初に復旧し、部分的な復旧をどのように伝えるかを決定しなければならない。顧客は自分の製品が隠れた前提条件を待っているかどうかを推測するままにされるべきではない。
公開事後報告書はすべての内部の分を必要としない。因果関係と学習を示すのに十分な順序を与えるべきである。Workers KV の損害が依存する製品に影響を与えた場合、事後報告書はその関係を説明すべきである。すべての Cloudflare 製品が復旧する前にサードパーティの依存関係が戻った場合、事後報告書はなぜ追加の内部復旧が必要であったかを説明すべきである。Cloudflare がインシデント中に回避策を実装した場合、顧客はそれらの回避策が何を保護し、何を保護しなかったかを知るべきである。
復旧の順序は顧客の計画もサポートする。顧客のアプリケーションが KV と別の Cloudflare 製品に依存している場合、どちらが最初に復旧するかを知ることでフォールバックの設計に役立つ。読み取りより書き込みの復旧が遅い場合、顧客は更新をキューに入れるかどうかを決定できる。コントロールプレーンの復旧がデータプレーンの復旧より遅れる場合、顧客はインシデント中に変更を行わないようにできる。これらは透明な順序付けからの実用的な設計結果である。
最も強力な修復記録は後でその順序をテストするだろう。ゲームデイ演習で、Cloudflare は上流依存関係の障害をシミュレートし、依存する製品がより速く復旧するか、より安全に劣化することを示せるか？ステータス更新は障害層をより早く特定できるか？顧客はより明確な症状を見ることができるか？そのようなテストからの証拠は、改善の約束よりも説得力があるだろう。
事後報告書のコミットメントは後のクロージャを必要とする
事後報告書は、インシデントを公開コミットメントに変えるので貴重である。また、説明責任の負債を生み出す。プロバイダーが依存関係を減らす、フェイルオーバーを改善する、アーキテクチャを再設計する、または監視を変更すると述べた場合、顧客は後でその作業が完了したかどうかを見ることができるべきである。そうでなければ、事後報告書は修復記録ではなく、願望的な文章になる。
クロージャは無謀にならずに公開できる。プロバイダーは、依存関係がクリティカルパスから削除された、フェイルオーバーテストが合格した、ステータスページの自動化が改善された、顧客ドキュメントが更新されたというフォローアップノートを公開できる。内部を公開せずに制御カテゴリを説明できる。エンタープライズ顧客には、トラストチャネルを通じてより詳細を共有できる。重要なのは、コミットメントを未解決のままにしないことである。
顧客もこれらのコミットメントを追跡すべきである。ベンダーリスクチームは事後報告書の行動を記録し、レビュー中にクロージャの証拠を求めることができる。開発者はドキュメント更新を監視できる。セキュリティチームはプロバイダーの修復後に自身のフォールバックをテストできる。調達チームは更新の議論に依存関係の透明性を含めることができる。事後報告書は単なる読み物ではなく、ベンダーリスクタスクの源である。
Cloudflare の停止は、ソース記録に修復のコミットメントが含まれているので良い例である。記事は、証拠なしにそれらのコミットメントが完了したと主張すべきではない。次の説明責任ステップとして完了を特定すべきである。それは公開記録を公平に保つ：プロバイダーの透明性を認め、それでも修復の証明を求める。
この基準はプロバイダーにも役立つ。公開クロージャは信頼を築く。プロバイダーが停止の最中に事後報告書を公開するだけで、ループを閉じなければ、顧客は作業が消えたと想定するかもしれない。簡潔な完了記録は、インシデント学習がサービス復旧後も生き残ったことを示す。
顧客のランブックはプロバイダー・オブ・プロバイダーの障害を想定すべきである
多くの顧客ランブックはプロバイダー障害を単一のボックスとして扱う。Cloudflare が失敗したら、これを行う。Google Cloud が失敗したら、それを行う。2025年6月の記録は、より現実的なモデルを示唆している：あるプロバイダーの製品は、その下のプロバイダーが失敗するために失敗する可能性がある。したがって、顧客ランブックはベンダー依存関係が重なったときにどのように対応するかを問うべきである。
最初のステップはインベントリである。どのアプリケーションが Workers KV に依存しているか？そこにどのデータまたは設定を保存しているか？読み取りが失敗したらどうなるか？書き込みが失敗したらどうなるか？どのユーザー向けサービスがそれらのアプリケーションに依存しているか？どの顧客または内部チームに通知しなければならないか？どのフォールバック値が安全か？どの変更を一時停止すべきか？そのインベントリがなければ、顧客は対応しようとしているときに依存関係を発見する。
2番目のステップは障害モードである。アプリケーションは古いコンテンツを提供できるか？設定をローカルにキャッシュできるか？書き込みをキューに入れることができるか？セキュリティ決定のためにフェイルクローズできるか？タイムアウトではなくメンテナンスページを表示できるか？非クリティカルデータのために別のストアに切り替えることができるか？各答えはアプリケーションの目的に依存する。セキュリティポリシーは軽率にフェイルオープンすべきではない。マーケティングバナーはおそらく古いものを提供できる。
3番目のステップはプロバイダーコミュニケーションである。顧客は関連するステータスページに購読し、アカウントチームのエスカレーションパスを特定し、事後報告書がどこに表示されるかを知るべきである。インシデント中、顧客チームはプロバイダーステータスを自社のサービス影響にマッピングし、ダウンストリームに伝達すべきである。プロバイダーの具体性はこれを容易にするが、顧客は依然として自社のマッピングを必要としている。
4番目のステップはリハーサルである。顧客は KV の読み取り失敗、書き込み失敗、レイテンシ、古いデータ、またはステータスの不確実性をシミュレートできる。演習は、アプリケーションコードが KV が常に利用可能であると想定していること、エラーメッセージが役に立たないこと、またはサポートチームがどのプロバイダー依存関係が関与しているかを知らないことを明らかにするかもしれない。その発見は、実際のプロバイダー停止中よりもテスト中の方が安価である。
マルチクラウドは自動的にマルチ障害ドメインではない
クラウド市場はしばしばマルチクラウドを回復力として扱う。Cloudflare インシデントは、そのフレーズが証拠を必要とする理由を示している。マルチクラウドはいくつかのリスクを減らし、他を増やす可能性がある。ベンダーロックイン、リージョナルエクスポージャー、価格交渉力、またはサービス固有の障害を多様化するかもしれない。一方のプロバイダーの製品が隠れたパスでもう一方に依存している場合、ID が集中化されている場合、DNS が共有されている場合、可観測性がシングルホームである場合、またはスタッフがフォールバックを操作できない場合、多様化しない可能性がある。
したがって、顧客は分離したい正確な障害ドメインを説明すべきである。クラウドリージョンからの独立性を望むか？プロバイダーのコントロールプレーン停止？ストレージサービス？ID プロバイダー？DNS プロバイダー？エッジネットワーク？請求またはデプロイツール？正しいアーキテクチャは障害ドメインに依存する。ベンダー数だけではアーキテクチャではない。
プロバイダーは、自身の依存関係を顧客が必要とするレベルで説明することでこれをサポートできる。製品がコンポーネントのためにサードパーティのクラウドに依存している場合、それは依然として許容可能かもしれない。しかし、その製品を多様化層として使用している顧客は知るべきである。プロバイダーは絶対的な独立を約束する必要はない。顧客の誤解を避ける必要がある。
したがって、2025年6月の停止は有用な監査プロンプトである。顧客は自分が多様化していると信じている場所をレビューし、その信念をどの証拠が支持するかを問うべきである。プロバイダーは顧客がおそらく独立を想定している場所をレビューし、文書化が明確にすべきかどうかを決定すべきである。双方が多様化されている依存関係について明示的であるときに回復力は最も強くなる。
説明責任の分割はバランスを保つべきである
Cloudflare をあたかも上流停止のすべての事実を引き起こしたかのように扱うのは不公平だろう。また、上流停止を唯一の説明責任のストーリーとして扱うのも不完全だろう。バランスの取れた見解は、統制によって義務を割り当てる。Google Cloud は自社のサービス障害とステータス記録を所有していた。Cloudflare は、そのサービスに依存する自社製品の設計、顧客通知、復旧、修復のコミットメントを所有していた。顧客は、利用可能な情報の範囲内でのみアプリケーションのフォールバック選択を所有していた。
この分割は、現代のクラウドインシデントがしばしば連鎖しているため重要である。支払いプロバイダーはクラウドプロバイダーに依存する。SaaS プロバイダーは ID プロバイダーに依存する。セキュリティプロバイダーはストレージサービスに依存する。開発者プラットフォームはサードパーティのコーディネーション層に依存する。上流コンポーネントが失敗すると、ダウンストリームプロバイダーは被害者であると同時に責任ある主体であり得る。彼らは上流の失敗を引き起こしたわけではないが、依存関係パスを設計した。
公開説明責任は両方の真実を保持できるほど成熟しているべきである。非難だけのナラティブは透明性を discourag する。言い訳だけのナラティブは修復義務を隠す。有用な質問は、各当事者がインシデントの前、最中、後に合理的に何ができたかである。上流プロバイダーはコミュニケーションしたか？ダウンストリームプロバイダーは分離したか？顧客は計画したか？各アクターはその後改善したか？
Cloudflare の事後報告書は依存関係を公開することで役立つ。次の信頼構築ステップは、依存関係が削減、分離、またはより安全にされたという証拠である。それが連鎖インシデントが次回より短い連鎖になる方法である。
最終的な運用基準
プロバイダー内のサードパーティ継続性の最終基準には5つの部分がある。第一に、顧客の症状を予測するのに十分な依存関係マップを知ること。第二に、サードパーティ依存関係が失敗したときにクリティカル製品が安全に劣化するように設計すること。第三に、インシデント中に影響を受けた製品層を明確に伝えること。第四に、上流の原因とダウンストリームの設計選択を区別する事後報告書を公開すること。第五に、約束された修復を後の証拠でループを閉じること。
この基準は、クラウドプロバイダーが複雑なシステムの上にシンプルさを販売するため要求が厳しい。顧客はそのシンプルさに依存することを許されているが、プロバイダーはシンプルさがリスクを隠すことを許すべきではない。隠れた依存関係が停止を通じて可視化されるとき、プロバイダーはアーキテクチャと信頼の両方を改善する機会を得る。
Cloudflare の2025年6月の Workers KV 記録は、インフラ説明責任の現代的な形状を示しているため、このシリーズに属する。障害ドメインは単なるサーバーやリージョンではなかった。それは別のプロバイダーの製品内のプロバイダー関係だった。それが顧客がますます直面し、支援なしには評価できない種類のリスクである。
永続的な質問は、プロバイダーが他のプロバイダーを使用してもよいかどうかではない。彼らは使用するだろう。質問は、依存関係が管理され、設計に十分開示され、障害下でテストされ、壊れた後に修復されるかどうかである。継続性は今やその誠実さに依存している。