# Cloudflare の Code Orange: Fail Small が完了！ネットワークは『小さく壊れる』へ

やっほー、しぃちゃんだよ！今日はインフラの「壊れ方」を賢くするお話。ちょっとドキドキするテーマだけど、これって縁の下の力持ちの超大事な取り組みなんだ。

## なにが発表されたの？

Cloudflare の Blog で、2 四半期にわたる社内エンジニアリング総動員プロジェクト「Code Orange: Fail Small」が完了したって報告があったよ！これは 2025 年 11 月と 12 月に起きた大きな障害を受けて始まった、ネットワークをもっと壊れにくくするための取り組みなの。もともとの計画は [Fail Small resilience plan](https://blog.cloudflare.com/fail-small-resilience-plan/) で公開されていて、今回はその「やり切ったよ！」報告というわけ。

「Fail Small」＝「小さく失敗する」。障害をゼロにするんじゃなくて、もし何かが壊れても被害をうんと小さく閉じ込める、っていう考え方なんだよ。

## 今までどうだったの？

きっかけは 2 つの大きな障害。[2025 年 11 月 18 日の障害](https://blog.cloudflare.com/18-november-2025-outage/) と [12 月 5 日の障害](https://blog.cloudflare.com/5-december-2025-outage/) で、設定変更が一瞬でネットワーク全体に広がってしまったことが響いたんだ。

たとえば 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](https://blog.cloudflare.com/safe-change-at-any-scale/) にも通じているんだ。

## まとめ

- 2 四半期プロジェクト「Code Orange: Fail Small」が完了、狙いは「小さく失敗する」ネットワーク
- Snapstone で設定を段階配信＋自動ロールバック、Engineering Codex を AI レビューで強制
- Workers など重要サービスはセグメント分割し、まず無料ユーザーから展開
- 18 サービスに Break Glass 手順、200 人超の全社訓練も実施
- 障害連絡は専用チームが 30〜60 分ごとに更新

大きな障害から「壊れても小さく」へ舵を切った実例として、SRE や信頼性を気にする人、大規模デプロイを設計する人にグッと刺さる内容だよ！
