概要

2026-05-01 Jeremy Hartman | 8 min read

過去約2四半期にわたり、内部コード名「Code Orange: Fail Small」として集中的なエンジニアリング施策を実施し、Cloudflare のインフラをすべてのお客様にとってより回復性が高く、安全で信頼できるものにすることに注力してきました。今月初め、Cloudflare チームはこの作業を完了しました。

回復性の向上は決して「完了する仕事」ではなく、開発ライフサイクル全体で常に最優先事項であり続けますが、今回完了した作業は、November 18, 2025 と December 5, 2025 のグローバル障害を回避できたであろう変更群を含んでいます。

本取り組みは主に次の領域に集中しました：安全な設定変更、障害の影響縮小、および“break glass”手順とインシデント管理の見直し。さらに、時間経過によるドリフトや回帰を防ぐ対策の導入、および障害発生時の顧客への通知方法の強化を行いました。以下で、私たちが導入した内容とそれが意味することを詳しく説明します。

安全な設定変更

あなたにとっての意味： 多くの場合、Cloudflare の内部設定変更は即時にネットワーク全体に反映されることはなく、代わりにリアルタイムのヘルス監視を伴う段階的なロールアウトで適用されます。これにより、観測ツールが問題を検出してトラフィックに影響が出る前に変更を戻すことが可能になります。

• 本番に到達する前に危険なデプロイを検出するため、高リスクな設定パイプラインを特定し、設定変更をより適切に管理する新しいツールを構築しました。
• 顧客トラフィックを処理し設定変更を受けるプロダクトについては、これらの変更をネットワーク全体に即時展開することをやめ、ソフトウェアをリリースする際に用いる「health-mediated deployment」方式を全ての設定デプロイにも採用しています。

中心的な新コンポーネントとして Snapstone を構築しました。Snapstone は設定変更をパッケージ化し、ヘルスメディエーションの原則に従って段階的なリリースを可能にするシステムです。以前は設定にこの方法を適用するのは可能でしたが困難で、チームごとに大きな負担があり一貫して適用されていませんでした。Snapstone はこれを解消し、段階的ロールアウト、リアルタイムのヘルス監視、自動ロールバックをデフォルトで提供します。

Snapstone の強みは柔軟性にあります。過去の特定の障害への対処に限定された修正ではなく、データファイル（November 18 の障害を引き起こしたもののような）やグローバル設定システムの制御フラグ（December 5 に関与したもののような）など、ヘルスメディエーションが必要な任意の設定単位を動的に定義できます。チームは必要に応じてこれらを作成し、Snapstone がそれらを安全に展開することを保証します。

これにより、リスクレビューや運用経験から危険な設定パターンが特定された場合の対応が簡単になります：それを Snapstone に取り込み、当該パターンは即座に安全なデプロイメントの恩恵を受けます。

障害の影響を減らす

あなたにとっての意味： ネットワーク上で問題が観測された場合、システムはより穏やかにフォールトし、影響範囲（blast radius）を大幅に縮小します。これにより、最悪のシナリオでもお客様のトラフィック配信を維持できるようにしています。

• 各プロダクトチームは、顧客トラフィック配信に重要なプロダクトについて、手動およびプログラム的に故障モードを精査しました。
• 非必須のランタイム依存を除去し、より良い故障モードを実装しました。
• 可能な限り「最後に正常だった設定」を使用する（“fail stale”）方針を採用し、それが不可能な場合は各障害ケースごとにレビューして「fail open」または「fail close」を実装しています（機能低下であってもトラフィックを提供する方が望ましいか否かに基づく判断）。

例として、2025年11月の障害は Bot Management の検出機械学習分類器のロールアウト失敗が引き金でした。新しい手順では、システムが再び読めないデータを生成した場合、更新された設定の使用を拒否して古い設定を使う動作を行います。古い設定が何らかの理由で利用できない場合は、顧客の本番トラフィックが継続して配信されるように「fail open」するようになり、ダウンタイムよりもはるかに良い結果をもたらします。

• 同じ Bot Management の変更が再度デプロイされた場合、現在ではデプロイの初期段階で失敗が検出され、影響はごく一部のトラフィックにとどまります。
• システムのさらなるセグメンテーションも開始しました。異なるコホート（顧客群）のトラフィックごとに独立したサービスのコピーを実行することで、信頼性を高めます。Cloudflare は既にトラフィック管理の手法で顧客コホートを利用しており、今回の追加的なプロセス分割により強力な信頼性機能が得られます。

例：Workers ランタイムは複数の独立サービスに分割され、異なるコホートのトラフィックを処理しています。そのうち一つは無料顧客専用です。変更は顧客コホートに基づいてこれらのセグメントにデプロイされ、無料顧客から先に開始します。

• 重要度の低いセグメントには更新をより速く頻繁に送り、最も重要なセグメントにはより遅いペースで配信します。
• その結果、Workers ランタイムに変更がデプロイされてトラフィックが壊れた場合でも、自動検出とロールバックが行われる前に影響を受けるのは無料顧客のごく一部だけになります。

例として、今月初めの7日間で、Workers のデプロイプロセスは50回以上トリガーされました。変更がエッジに伝播するにつれて各デプロイが「波」のように発生する様子が観測され、しばしば前後のリリースと並行して行われます。

今後、このデプロイパターンをさらに多くのシステムへ拡張していく予定です。

“break glass” とインシデント管理手順の見直し

あなたにとっての意味： インシデントが発生した場合、より明確に情報を伝達し、より速く解決できるツールとチームを備えています。これによりダウンタイムを最小化します。

• Cloudflare は Cloudflare 上で稼働しています。Zero Trust 製品でインフラを保護していますが、これは依存関係も生みます：ネットワーク全体の障害がこれらのツールに影響を与えると、ツール自体を修復するための経路を失います。
• Code Orange 以前は、"break glass" 経路は限られた人数にしか開かれておらず、ツールアクセスも限定的でした。障害時にこれらのツールと経路をより広く利用可能にする必要がありました。

対策として、システム可視化、デバッグ、運用変更に不可欠なツールの包括的な監査を行い、最終的に18の主要サービスに対するバックアップ認可経路を確立し、新しい緊急スクリプトとプロキシでこれをサポートする体制を整えました。

• Code Orange プログラム中には、小規模チームでの演習から始め、2026-04-07 に200名以上が参加するエンジニアリング全体のドリルを実施しました。
• 自動化によりこれらの経路は機能を保ちますが、ドリルによりエンジニアがプレッシャー下でも確実に手順を実行できる筋肉記憶を養います。

また情報の流れにも注力しました。内部可視性が損なわれるとインシデント対応は遅れ、外部への情報発信能力も低下します。これまで現場での技術的観察が必ずしもお客様向けのわかりやすい更新に変換されてこなかったため、これを埋めるために、重大イベント時にインシデント対応者と歩調を合わせて動く専任のコミュニケーションチームを設置しました。

エンジニアが "break glass" 手順を実践的に訓練したのと同様に、このチームも Code Orange を通じて顧客向け更新のリズムと明瞭性を訓練しました。可視化するツールと発信する構造の両方を整えることで、インシデントをより速く解決し、顧客への情報提供を改善します。

改善点をコード化しました

あなたにとっての意味： インシデントから得た学びを忘れず、解決策をコード化しました。ネットワークは継続的に強化されます。

• 時間の経過で Code Orange の作業にドリフトや回帰が入り込まないよう、チームは社内のすべてのガイドラインを明確なルールに固めた内部 Codex を構築しました。
• Codex は全エンジニアリングおよびプロダクトチームに対して必須となり、Cloudflare の社内手順の中心的要素になっています。
• そのルールは AI によるコードレビューで強制され、ガイドラインから逸脱する可能性のある箇所を自動的にハイライトし、追加の手動レビューを要求します。これは例外なく全コードベースに適用されます。

目標は簡単です：自己強制する組織的記憶を構築すること。November と December の障害に共通していた失敗モードは、入力が常に有効だという前提に依存し、その前提が破綻したときに優雅な劣化がなかった点です。ある Rust サービスがエラーを扱わずに .unwrap() を呼んでいた、Lua のコードが存在しないオブジェクトをインデックスしていた、といったパターンは、防止可能です。Codex はその解の一部です。

• Codex は RFC プロセスを通じてドメイン専門家が作成したエンジニアリング標準の生きたリポジトリであり、実用的なルールに蒸留されます。
• 以前は上級エンジニアの頭の中にあったベストプラクティスや、インシデント後にのみ発見された知見が、今では誰でもアクセスできる共有知識になります。
• 各ルールはシンプルな形式に従います："If you need X, use Y" といった形で、理由を説明する RFC へのリンクが付属します。

例：ある RFC は「テストと build.rs を除き .unwrap() を使わない」と明記しています。別の RFC はより広い原則を示しています：「Services MUST validate that upstream dependencies are in an expected state before processing.」もしこれらのルールが以前から強制されていれば、November と December の障害はグローバルインシデントではなく却下されたマージリクエストになっていたでしょう。

ルールは強制がなければ提案にすぎません。Codex は設計レビューからデプロイ、インシデント分析に至るソフトウェア開発ライフサイクルのあらゆる段階で AI エージェントと統合されています。これにより強制は左へ移り（shift left）、"global outage" ではなく "rejected merge request" で問題を止められます。違反の影響範囲は数百万件のリクエストから、コードが本番に届く前の単一の開発者への実用的なフィードバックへと縮小します。

Codex は生きた文書であり継続的に改善されます。ドメイン専門家が RFC を書いてベストプラクティスを定義し、インシデントがギャップを浮き彫りにして新しい RFC を生みます。承認された各 RFC は Codex のルールを生成し、それらのルールが次のマージリクエストをレビューするエージェントにフィードバックされます。専門知識は基準になり、基準は強制になり、強制は全体の底上げを生むフライホイールが回転します。

コードだけではない：コミュニケーションも重要

あなたにとっての意味： 透明性は私たちにとって重要です。何か問題が起きた場合、私たちはあなたが重要な事に集中できるよう、段階を追って最新情報を提供することをお約束します。

• グローバルな障害を受け、エンジニアリングやプロダクト開発を超えたコアプロセスや文化的アプローチの見直しを行いました。
• 幅広い Code Orange の取り組みとして、すべてのサービスに追加の SLO を導入し、グローバルなチェンジログを強制し、すべてのチームをメンテナンス調整システムにオンボードし、社内の in に関する透明性を改善しました。