Cloudflare の Code Orange: Fail Small が完了！ネットワークは『小さく壊れる』へ
やっほー、しぃちゃんだよ！今日はインフラの「壊れ方」を賢くするお話。ちょっとドキドキするテーマだけど、これって縁の下の力持ちの超大事な取り組みなんだ。
Cloudflare Blog
blog.cloudflare.com
なにが発表されたの？
Cloudflare の Blog で、2 四半期にわたる社内エンジニアリング総動員プロジェクト「Code Orange: Fail Small」が完了したって報告があったよ！これは 2025 年 11 月と 12 月に起きた大きな障害を受けて始まった、ネットワークをもっと壊れにくくするための取り組みなの。もともとの計画は Fail Small resilience plan で公開されていて、今回はその「やり切ったよ！」報告というわけ。
「Fail Small」＝「小さく失敗する」。障害をゼロにするんじゃなくて、もし何かが壊れても被害をうんと小さく閉じ込める、っていう考え方なんだよ。
今までどうだったの？
きっかけは 2 つの大きな障害。2025 年 11 月 18 日の障害 と 12 月 5 日の障害 で、設定変更が一瞬でネットワーク全体に広がってしまったことが響いたんだ。
たとえば 11 月の Bot Management の分類器の不具合。設定が即座に全体へ配られると、まずいものもそのまま本番に届いちゃう。「速い」ことが逆にリスクになっていたんだね。
これで何が変わるの？
これからは設定変更が「一気に全部」じゃなくて、健全性を見ながら少しずつ広がるようになるよ。もし異常が出たら自動でロールバック。だから同じ Bot Management の不具合が起きても、展開のごく初期・ほんの一部のトラフィックで検知されて、自動的に巻き戻る仕組みになったの。
障害のときの連絡も変わるよ。専用のコミュニケーションチームが対応担当と連携して、稼働中のインシデントでは 30〜60 分ごとに更新を出すって約束してくれたんだ。「気づく前に知らせる」がゴールなんだって。
深く潜ってみよう
具体的な仕組みがいくつも登場したよ。
- Snapstone: 設定変更を「健全性に応じて配る（health-mediated deployment）」ための新しい社内コンポーネント。リアルタイムで健全性を見張りながら段階的に配って、ダメなら自動で戻すの。
- Engineering Codex: 全チーム必須の社内ルール集。AI コードレビューで強制されて、たとえば「テストと
build.rs以外では.unwrap()を使わない」みたいなベストプラクティスを、本番じゃなくてマージリクエストの段階で捕まえるんだ。 - システムのセグメント分割: Workers ランタイムなどの重要サービスを独立したセグメントに分けて、顧客のグループごとに段階展開。まず無料ユーザーから配るのがポイント。ある 7 日間では 50 回を超えるデプロイが「波」のようにエッジのセグメントを順に伝わっていったそう。
- Break Glass（緊急時）手順: 主要な 18 のサービス向けに、非常用スクリプトやプロキシで別の認可経路を用意。2026 年 4 月 7 日には 200 人超が参加する全社訓練までやったんだって。
失敗の仕方も設計されていて、重要度に応じて「fail stale（最後に正しかった設定を使い続ける）」や「fail open / close」を選ぶようになったよ。この「どんな規模でも安全に変える」考え方は Safe change at any scale にも通じているんだ。
まとめ
- 2 四半期プロジェクト「Code Orange: Fail Small」が完了、狙いは「小さく失敗する」ネットワーク
- Snapstone で設定を段階配信＋自動ロールバック、Engineering Codex を AI レビューで強制
- Workers など重要サービスはセグメント分割し、まず無料ユーザーから展開
- 18 サービスに Break Glass 手順、200 人超の全社訓練も実施
- 障害連絡は専用チームが 30〜60 分ごとに更新
大きな障害から「壊れても小さく」へ舵を切った実例として、SRE や信頼性を気にする人、大規模デプロイを設計する人にグッと刺さる内容だよ！
