この記事の趣旨
ここ1〜2年、インフラエンジニアの胃に穴を開けるような大規模障害が多発しました。「クラウドなら落ちない」「冗長化してるからヨシ」という神話が崩壊した今、各社が公開した**ポストモーテム（事後検証レポート）**を読み込み、我々が明日のデプロイで死なないための教訓をまとめました。
はじめに：もはや「落ちない」は幻想
2024年から2025年にかけての障害トレンドを一言で言うなら、**「設定ファイルが凶器になった」**です。
CrowdStrikeの件も、Azureの件も、コードのバグというよりは「Config」や「運用プロセス」の隙を突かれた形でした。ベンダーの公式発表（英語の長文PDF）を一つずつ読むのは骨が折れるので、要点だけを抽出して日本語で整理しておきます。
忙しい人のための「転ばぬ先の杖」として使ってください。
1. CrowdStrike Falcon Sensor 障害（2024年7月）
〜カーネルモードで「Nullポ」したらどうなるか〜
正直、この件は全エンジニアが震え上がったと思います。世界中のWindows端末850万台がBSOD（ブルースクリーン）で再起動ループに入ったあの事件です。
なぜ起きたのか（技術的な話）
原因は**Out-of-Bounds Read（境界外読み取り）**です。
- センサーの設定ファイル（Channel File 291）が更新された。
- 読み込む側のインタプリタは「フィールドが21個ある」と期待していた。
- 実際に来たファイルには「20個」しかなかった。
- 存在しない21番目のメモリを見に行ってクラッシュ。
これがユーザーランドのアプリなら「アプリが落ちました」で済みますが、カーネルモードで動くドライバだったため、OSごと道連れにして落ちました。
ここがヤバかった（SRE的視点）
技術的なバグは誰にでもあります。本当に怖いのはデプロイ戦略です。
- 全台一斉配信: カナリアリリース（一部だけ公開）のプロセスが形骸化しており、ほぼ同時に世界中にばら撒かれた。
- バリデーションのバグ: 配布前にチェックするはずの「Validator」自体にバグがあり、不正ファイルを「OK」と通してしまった（テストのテスト誰がやるんだ問題）。
教訓
「設定ファイルの変更」を軽視していませんか？ Configも立派なコードです。CIを通し、少しずつデプロイし、何かあったら即ロールバックできる体制がないと、設定ファイル一つで会社が傾きます。
2. AWS US-EAST-1 DynamoDB 障害（2025年10月）
〜「DNSレコードが消える」という悪夢〜
2025年10月、AWSの主要リージョンが死にました。DynamoDBが落ちたと言われていますが、厳密にはDynamoDBのエンドポイントのDNSが空になったという、聞くだけで寒気がする事象です。
なぜ起きたのか
**競合状態（Race Condition）**です。事後報告書を読むと、AWS内部のDNS管理システムで以下のコンボが決まったようです。
# 実際に起きたことのイメージ
def dns_enactor():
# サーバーA：処理が遅れて「古いプラン」を持っている
stale_plan = get_old_plan()
# サーバーB：既に「新しいプラン」でDNSを更新済み
# サーバーAの悲劇：「この古いデータはいらんな」と判断して削除実行
# → 結果、サーバーBが書いた「最新のレコード」ごと消し飛ばした
if is_stale(stale_plan):
delete_dns_record() # 全滅
結果、dynamodb.us-east-1.amazonaws.com のIPが引けなくなりました。
復旧を阻んだ「卵と鶏」
これが一番辛いところですが、AWSの復旧ツール自体がDynamoDBに依存していたため、**「DynamoDBを直すためのツールが、DynamoDBダウンのせいで動かない」**というデッドロックに陥りました。
教訓：静的安定性 (Static Stability)
コントロールプレーン（DNS更新の仕組み）が死んでも、データプレーン（名前解決）は生き残れるようにすべきです。キャッシュTTLを長くする、あるいは/etc/hosts的な静的ファイルに逃げ道を作っておくなど、「管理画面が死んでも現場は回る」設計が重要です。
3. Microsoft Azure Front Door 障害（2025年10月）
〜DDoSは内側からやってくる〜
AzureのグローバルCDN「Front Door」の設定変更ミスが引き金です。
何が起きたか
- 特定リージョン（欧州）のエッジサーバーに設定変更を適用。
- 設定にバグがあり、エッジがクラッシュ。
- Anycastの仕様で、行き場を失ったトラフィックが生き残っている他のリージョン（北米・アジア）へ殺到。
- 健全だったサーバーも過負荷でダウン。
典型的な**カスケード障害（連鎖的な倒れ方）**です。部分的な障害が、自動フェイルオーバーの仕組みによって全体障害に拡大してしまいました。良かれと思って入れた冗長化の仕組みが、逆に仇となるパターンです。
4. Cloudflare / Workers KV 障害（2025年6月）
〜その「安全策」が命取り〜
Cloudflareが依存しているバックエンドストレージが落ちた際、セキュリティ製品であるCloudflare Gatewayが**Fail Closed（安全のために遮断）**挙動をとったため、インターネット全体がブロックされました。
Fail Open か Fail Closed か
ここが設計の分かれ道です。
| 戦略 | 挙動 | メリット | デメリット |
|---|---|---|---|
| Fail Closed | 異常時は全て止める | セキュリティは安全 | 業務が全停止する |
| Fail Open | 異常時は通す | 業務は継続できる | セキュリティリスク有 |
「設定ファイルが読めない時、古いキャッシュを使ってでも動かすか（Stale Cache）、止めるか」。これはエンジニアだけで決められる話ではないので、平時にビジネスサイドと握っておく必要があります。
まとめ：明日から何をするか
各社のポストモーテムを読んで痛感するのは、**「システムは複雑になりすぎて、人間が全てを把握するのは無理」**という現実です。
だからこそ、以下の3点だけは徹底したいところです。
- 設定ファイルも「コード」として扱う
- YAML 1行の変更でもレビューし、テストし、段階的にリリースする。
- 依存関係の「円環」を断つ
- 「復旧ツールが障害対象システムに依存していないか？」を点検する。
- 「もし全部落ちたら？」を議論する
- AWSが落ちた時、せめて「ただいまメンテナンス中です」という静的ページ（S3や別サーバー）を出せるようになっているか？
障害は必ず起きます。大事なのは「起こさないこと」よりも「起きた時に致命傷にしないこと」です。
...と、偉そうに書きましたが、次の障害対応が自分の当番でないことを祈るばかりです。
参考資料
- CrowdStrike Post Incident Review
- Summary of the Amazon DynamoDB Service Event
- Microsoft Azure Status History
- Cloudflare Blog