「Code Orange: Fail Small」が完了しました。その結果、Cloudflareネットワークはより強力になりました

過去2四半期あまりの間に、当社は「Code Orange: Fail Small」という内部コード名で呼ばれるエンジニアリング活動を集中的に行い、Cloudflareのインフラストラクチャをすべてのお客様にとって、より安全で、耐障害性と信頼性の高いものにすることに専念してきました。

今月初めに、Cloudflareのチームはこの作業を完了しました。

耐障害性を向上させる作業には終わりはなく、開発ライフサイクル全体において常に最優先事項ですが、2025年11月18日と2025年12月5日の世界的な障害を回避できたであろう作業を完了しました。

この作業は主に、より安全な構成変更、障害による影響の軽減、「ブレークグラス」手順およびインシデント管理という重要な分野に重点を置きました。また、時間の経過とともに発生しうるドリフトやリグレッションを防ぐための対策を導入し、障害発生時にお客様とコミュニケーションを図る方法を強化しました。

ここでは、私たちが行った内容と、それがお客様にとってどのような意味を持つものかを詳しく説明します。

お客様にとっての意味：ほとんどの場合、Cloudflareの内部構成の変更は、即座にネットワークに展開されることはなく、その代わりに、リアルタイムで正常性を監視しながら段階的に展開されます。これにより、監視ツールが問題を検出し、トラフィックに影響を与える前に問題を解決することができます。

本番環境に展開される前に、潜在的に危険なデプロイメントを検出できるよう、リスクの高い構成パイプラインを特定し、構成変更をより良く管理するための新しいツールを構築しました。

お客様のトラフィックを処理し、構成変更を受け取る当社のネットワーク上で動作する製品については、これらの変更を即座にネットワーク全体に展開することはしません。その代わりに、関連チームは、すべての構成デプロイメントにおいて、ソフトウェアをリリースする際に用いるのと同じ「Health Mediated Deployment」手法を採用しました。チームには、インシデントによって直接影響を受けた製品チームが含まれますが、それらに限りません。

この手法を実現するうえで中核にあるのが、新たに構築した内部コンポーネント「Snapstone」で、これにより正常性を考慮して構成変更を展開するHealth Mediated Deploymentを実現しています。Snapstoneは、構成変更をパッケージとしてバンドルし、正常性考慮の原則に基づいて構成変更を段階的にリリースするシステムです。Snapstoneの導入前は、この手法を構成に適用することが可能ではありましたが、困難でした。チームごとにかなりの労力が必要であり、ネットワーク全体で一貫して適用されていませんでした。Snapstoneは、段階的なロールアウト、リアルタイムの正常性監視、および自動ロールバックを構成デプロイメントにデフォルトで組み込む統一的な方法を提供することで、このギャップを埋めます

Snapstoneが特に強力である理由は、その柔軟性にあります。Snapstoneは、過去の特定の障害を修正するものではなく、11月18日の障害を引き起こしたデータファイルや、12月5日の障害に関与したグローバル構成システムの制御フラグのように、正常性を考慮すべきあらゆる構成ユニットをチームが動的に定義することができるようにします。チームは必要に応じてこれらの構成ユニットを作成し、Snapstoneはそれらが使用されるすべての場所で安全に展開されるようにします。

これにより、私たちはこれまでになかったものを実現できます。リスクレビューや運用経験から危険な構成パターンが特定された場合、修正は簡単です。Snapstoneに取り込むことで、その構成パターンは直ちに安全なデプロイメントを継承します。

お客様にとっての意味：ネットワークで問題が観察された場合、システムが以前よりもスムーズに障害を処理できるようになりました。これにより、潜在的な影響範囲が大幅に縮小され、最悪の事態においてもトラフィックが確実に配信されるようになります。

製品チームは、お客様のトラフィックの配信において重要な製品の潜在的な障害モードを、手動とプログラムの両方の方法で慎重にレビューしました。チームは重要でないランタイムの依存関係を取り除き、より優れた障害モードを実装しました。可能な場合は最後に正常に動作していた構成（「フェイルステイル」）を使用し、それが不可能な場合は、各障害ケースを確認の上で、「フェイルオープン」または「フェイルクローズ」を実装しました。これは、機能が制限された状態でトラフィックを処理することが、トラフィックを処理できなくなることよりも好ましいかどうかに基づいて決定します。

この仕組みがどのように機能するか、例を見てみましょう。2025年11月の障害は、Bot Managementの検出機械学習分類子のロールアウトに失敗したことが原因で発生しました。新しい手順の下で、もしシステムが読み取れないデータが再び生成された場合、システムは更新された構成の使用を拒否し、代わりに従来の構成を使用します。古い構成が何らかの理由で利用できない場合、フェイルオープンによりお客様の本番トラフィックが継続して配信されるようにします。これはダウンタイムよりもはるかに良い結果です。

その結果、11月に発生した障害を引き起こしたのと同じBot Managementの変更がロールアウトされた場合でも、システムはデプロイメントの初期段階で障害を検知し、ごく少数のトラフィックにしか影響を及ぼさないうちに対応できることとなります。

また、トラフィックの異なるコホートごとに独立したサービスのコピーが実行されるように、システムをさらにセグメント化する作業に着手しています。Cloudflareはすでにトラフィック管理技術を用いてこれらの顧客コホートを効果的に利用し、被害範囲を抑えることに努めていますが、このプロセスのセグメント化作業を進めることにより、今後さらに強力な信頼性を確保することができます。

例えば、Workersのランタイムシステムは異なるトラフィックのコホートを処理する複数の独立したサービスに分けられており、そのうちの1つは無料のお客様のトラフィックだけを処理しています。変更は顧客コホートに基づいてこれらのセグメントにデプロイされ、無料のお客様から順次デプロイされます。最も重要でないセグメントにはより迅速かつ頻繁に更新を送信し、最も重要なセグメントにはより慎重なペースで更新を送信しています。

その結果、もしWorkersランタイムシステムへの変更がデプロイされ、それがトラフィックに影響を与えた場合、現在では無料のお客様のごく一部にしか影響を及ぼさず、すぐに自動的に検出されてロールバックされるようになっています。

Workersランタイムシステムを例に挙げると、今月初めの7日間において、デプロイメントプロセスが50回以上トリガーされました。変更がエッジに伝播する際、それぞれが「波」のように発生していきます。多くの場合、それは前後のリリースと並行して起こります。

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

お客様にとっての意味：万が一インシデントが発生した場合、私たちはツールを駆使してチームがより明確にコミュニケーションし、迅速に解決することでダウンタイムを最小限に抑えます。

Cloudflareの製品はCloudflareで動作します。Cloudflareのインフラを保護するために自社のZero Trust製品を使用していますが、これにより依存関係が生じます。つまり、ネットワーク全体の障害がこれらのツールに影響を与えた場合、それらを修正するために必要な経路を失ってしまうことになります。このCode Orangeイニシアチブ以前は、当社の「ブレークグラス」経路はごく少数の人に限定され、ツールアクセスも限られていました。そのため、これらのツールや経路を、障害時により広く利用できるようにする必要がありました。

これを解決するために、システムの可視性、デバッグ、そして本番環境の変更に不可欠なツールの包括的な監査を実施しました。最終的に、新たな緊急スクリプトとプロキシによってサポートされる、18の主要サービス向けのバックアップ認証経路を開発しました。

Code Orangeプログラムを通じて、私たちは理論を実際に機能するものとして実現したのです。小規模チームによる演習の後、2026年4月7日にエンジニアリング部門を対象にした訓練を実施し、200人以上のチームメンバーが参加しました。自動化によってこれらの経路が機能するように維持する一方で、このような訓練により、エンジニアたちはプレッシャー下でも経路を活用できるように操作を習得します。

この取り組みでは、情報の流れにも着目しました。内部の可視性が損なわれると、インシデント対応が遅れ、影響を受けている外部とのコミュニケーション能力が低下します。歴史的に見ても、状況が緊迫しているときに技術的にわかっていることが、常にお客様へ明確に伝達されてきたわけではありませんでした。

このギャップを埋めるため、大規模な事象発生時にインシデント対応者と緊密に連携する専任のコミュニケーションチームを設立しました。エンジニアたちが「ブレークグラス」手順を練習したのと同様に、このチームはCode Orangeプログラムにおいて、お客様へ最新情報を伝達する頻度と明確さを効率化する訓練を行いました。状況を確認するツールとコミュニケーションを図るための構造の両方を確保することで、インシデントをより迅速に解決し、お客様により優れた情報提供ができます。

お客様にとっての意味：私たちはインシデントから得た教訓を忘れることなく、解決策を体系化しました。私たちのネットワークはさらに耐障害性を高めていきます。

Code Orangeの一環として行われた作業が時間の経過とともにドリフトやリグレッションが生じたりすることを避けるため、チームはすべてのガイドラインを明確かつ簡潔なルールとして体系化した内部Codexを作成しました

Codexは現在、すべてのエンジニアリングおよび製品チームにとって必須であり、Cloudflareの内部手順において中心的な役割を果たすようになりました。そのルールは、ガイドラインから逸脱する可能性のあるインスタンスを自動的に強調表示するAIコードレビューを通じて施行され、追加の手動レビューが必要とされます。これは私たちのコードベース全体に例外なく適用されます。目標はシンプルです。自己強制力を持つ組織的な記憶を構築することです。

11月と12月の障害には共通の障害モードがありました。それは、入力が常に有効であることを前提としたコードであり、その前提が崩れた場合に適切なグレースフルデグラデーションが行われていなかったのです。.unwrap()という名前のRustサービスがエラーを処理する代わりに、Luaコードは存在しないオブジェクトをインデックス化しました。これらのパターンは、教訓を残し、適用すれば予防可能です。

Codexは私たちの答えの一部です。Codexとはエンジニアリング標準の生きたレポジトリであり、分野の専門家がRequest For Comments（RFC）プロセスを通じて記述し、その後に実行可能なルールに絞り込まれます。以前はシニアエンジニアの頭の中にあったり、インシデントが発生して初めて発見されたベストプラクティスが、今では誰でもアクセスできる共有知識となっています。各ルールはシンプルな形式に従っています。「Xが必要なら、Yを使う」というものです。また、その理由を説明するRFCへのリンクがあります。

たとえば、あるRFCでは次のように述べています。「テストおよびbuild.rs以外では.unwrap()を使用しないでください」。別のRFCではより広範な原則を説明しています。「サービスは処理を行う前に、上流の依存関係が期待される状態にあることを確認しなければなりません。」

もしこれらのルールがより早い段階で施行されていたならば、11月と12月の障害はグローバルなインシデントではなく、マージリクエストの拒否として処理されていたでしょう。

強制力のないルールは提案に過ぎません。Codexは、設計レビューからデプロイメント、インシデント分析までのソフトウェア開発ライフサイクルのあらゆる段階でAIを利用したエージェントと統合されています。これにより「グローバル障害」ではなく「マージリクエストの拒否」として対処できるようになります。違反による影響範囲は、何百万件ものリクエストという規模から、コードが本番環境にデプロイされる前に、一人の開発者が具体的なフィードバックを得る程度にまで縮小されます。

Codexは生きた文書であり、時間とともに継続的に改善されていきます。分野の専門家は、ベストプラクティスを成文化するためにRFCを記述します。インシデントによってギャップが明らかになり、これが新しいRFCとなります。承認されたすべてのRFCはCodexルールを生成します。これらのルールは、次のマージリクエストをレビューするエージェントにフィードされます。それは好循環を生み出します。専門知識が基準となり、基準が執行され、執行によって全員の基準が引き上げられるのです。

お客様にとっての意味：透明性は私たちにとって重要です。何か問題が発生した場合、お客様が重要なことに集中していただけるよう、常に最新情報をお届けするよう全力で取り組みます。

世界的な障害は、私たちがエンジニアリングや製品開発にとどまらず、コアプロセスや文化的アプローチを見直すきっかけとなりました。Code Orangeイニシアティブの広範な取り組みの一環として、すべてのサービスに追加のサービスレベル目標（SLO）を導入し、グローバルな変更履歴を有効にし、すべてのチームがメンテナンス調整システムを使えるようにし、会社全体でインシデントの「予防」チケットバックログに関する透明性を向上させました。

当社はまた、障害発生時にお客様へのコミュニケーションを図る方法を強化しました。お客様が問題に気づくよりも前に、Cloudflareで問題を確認した瞬間にお知らせすることを目標としています。遅延やエラーに気づく頃には、最新情報を通知できることを目指しています。

インシデントが発生している間は、たとえお伝えする内容が単に「修正をテスト中であり、新しい変更はまだありません」となる場合でも、予測可能な間隔（例：30分または60分ごと）で最新情報を提供します。これにより、お客様はステータスページを頻繁に更新するのではなく、一日の計画を立てることができます。

私たちの仕事は、状況が正常に戻ったときに終了するわけではありません。発生したインシデント、原因、および再発防止のために具体的にどのような構造的変更を行うかについて、詳しい事後レポートを提供します。

私たちはインシデントを非常に重く受け止めており、Cloudflare組織全体で責任を共有する体制を整え、すべてのチームに「もっとうまくできたことは何だったのか？」と問いかけました。これは、過去2四半期にわたって私たちが取り組んだ作業を導くものとなりました。

この作業は決して完全に終わることはありませんが、私たちは以前よりもずっと良い状態にあり、その結果Cloudflareはより強くなりました。