필사 모드: 有名ポストモーテム解剖 — Cloudflare・Fastly・AWS・Knight Capital・GitLab の失敗から学ぶ

プロローグ — 「失敗は最高の教師だ」

2025 年 4 月、あなたのサービスが午前 3 時にダウンした。

• 原因: 不明
• 復旧: 2 時間
• 責任者: 昨夜コミットした誰か
• 雰囲気: 「誰がやったんだ?」

これが Blame culture — 失敗から学べない環境。

反対に、世界的な企業は Postmortem を公開する。Cloudflare、Google、AWS、GitLab。「我々はこう壊し、こう学んだ」という透明性が 業界全体 を学習させる。

Season 3 Ep 1 で各社の 成功 アーキテクチャを見たなら、Ep 2 は 失敗 から学ぶ。

この記事は公開された postmortem から抽出した実戦的な教訓。同じミスを 他人のコストで 避けよう。

第 1 部 — Postmortem とは

定義

Postmortem (事後分析): 事件発生後に原因、影響、タイムライン、教訓をドキュメント化する。

Google SRE 本の 5 要素

1. Incident summary
2. Impact (誰が、どれだけ)
3. Root cause (技術的 + プロセス)
4. Timeline (分単位)
5. Action items (具体的)

Blameless Postmortem の核心

悪い例: "Alice が誤った config を push した"
良い例: "Config validation が不在だった。
        Alice の change が通過したのはシステムのギャップ。"

哲学: 人ではなく システム を直す。非難すれば次の人が隠す。

第 2 部 — Cloudflare 2022-06-21 — BGP で半分がダウン

何が起きたか

2022 年 6 月 21 日 06:27 UTC
Cloudflare の 19 のデータセンター (世界の半分のトラフィック) がダウン
1 時間 30 分にわたり顧客サービスに影響

原因

BGP 経路変更中のミス:

Cloudflare がネットワーク標準化の最中
一部データセンターで BGP configuration をロールアウト
Config 変更: 一部 prefix の広告を停止 → トラフィックの行き先がなくなる

なぜ全体が?

中央の control plane が config を伝播
複数の DC が同時に影響を受ける構造
Canary なしで高速に伝播

教訓

1. Config change もデプロイ: Canary は必須
2. 中央制御の諸刃: 速度 vs 爆発半径
3. BGP は危険: ミスがインターネット単位
4. 透明なポストモーテム: Cloudflare が数時間以内に公開

Action items (Cloudflare 発表)

• Config 変更 workflow の再設計
• より強い staging 環境
• Progressive rollout の強制
• Alert の改善

第 3 部 — Cloudflare 2019-07-02 — 正規表現が CPU 100%

何が起きたか

2019 年 7 月 2 日
Cloudflare WAF rule 更新 → 世界中で CPU 100%
27 分にわたり HTTP 50x が増加

原因 — Catastrophic Backtracking

WAF rule にあった正規表現:
(?:(?:\"|'|\]|\}|\\|\d|(?:nan|infinity|true|false|null|undefined|symbol|math)|
`|\-|\+)+[)]*;?((?:\s|-|~|!|{}|\|\||\+)*.*(?:.*=.*)))

"Catastrophic backtracking" を誘発
一部の入力で指数時間の実行
→ CPU 100% → HTTP 処理不能

教訓

1. Regex は危険: 複雑になると ReDoS 攻撃が可能
2. WAF rule は global change: ひとつの修正が世界中へ
3. CPU テストが必要: Latency + throughput も
4. Kill switch: 問題時に即座に切る

Cloudflare の対応

• Re2 (Google) のような linear-time regex エンジンの検討
• WAF change に CPU profiling
• Rolling deployment (一度に世界中は X)

第 4 部 — Fastly 2021-06-08 — 一顧客がインターネットの半分を止める

何が起きたか

2021 年 6 月 8 日 10:00 UTC
Fastly CDN が世界中でダウン (約 1 時間)
影響: Amazon、Reddit、CNN、NYT、PayPal、UK 政府ウェブサイト
「インターネットが半分止まった」と報道

原因

ある顧客が特定の config を変更
この config が Fastly 内部のソフトウェアバグを trigger
→ 世界中の edge サーバーで cache miss + システムエラー
→ 85% のトラフィックに影響

5 月からデプロイされていたバグ

5 月 12 日: ソフトウェアをデプロイ (bug が仕込まれる)
6 月 8 日: 特定顧客の config がバグを trigger
  → 潜伏していた bug が爆発

教訓

1. Multi-tenancy の危険: 一顧客が全員に影響
2. Dormant bugs: 数週間/数か月後に爆発
3. Fast recovery: Fastly は 1 時間以内に復旧 (印象的)
4. 顧客テストの限界: 実際の production mix はシミュレーション不可

第 5 部 — AWS S3 2017-02-28 — タイプミス 1 つがインターネットを止める

何が起きたか

2017 年 2 月 28 日 09:37 PST
AWS us-east-1 S3 ダウン (約 4 時間)
影響: Slack、Quora、Trello、Medium、数千のサイト
AWS の「Service Health Dashboard」も S3 を使うため更新できず

原因

エンジニアが billing システムをデバッグ中:

S3 subsystem のサーバー一部を意図的に再起動する計画
しかしタイプミスでより多くのサーバーを再起動

具体的には:
- Index subsystem + Placement subsystem の中核サーバーを削除
- この subsystem は S3 の core
- 完全な再起動が必要 → 4 時間

教訓

1. 人間のミスは不可避: ツールで防御すべき
2. Automation の空席: 破壊的コマンドの確認が X
3. Blast radius: すべての subsystem が同じ AZ
4. Dashboard dependency: Status page が同じシステムに依存

AWS の対応

• Dangerous operations に対する safeguard の追加
• Command-line tool の改善 (--confirm のような)
• Service 依存関係の再設計
• Status page の独立

第 6 部 — Knight Capital 2012-08-01 — 8 分で $440M を失う

何が起きたか

2012 年 8 月 1 日 午前 9:30 (ニューヨーク株式市場の開場)
Knight Capital (米国株式市場の主要 market maker)
8 分で $440M の損失
→ 会社はほぼ破綻、3 か月後に買収

原因 — Dead Code Resurrection

背景:
- Knight の取引システムに数年使われていない "Power Peg" 機能
- Dead code として残っていた
- 新機能のデプロイ中、8 台のサーバーのうち 1 台でデプロイミス
- このサーバーが "Power Peg" code を re-enable flag と解釈
- 市場の開場と同時に狂ったような注文生成を開始

8 分間:
- 数百万の注文を生成
- 価格に関係なく buy high, sell low
- 市場の歪み
- 合計 $440M の損失

教訓

1. Dead code の除去: 使わないコードは危険
2. デプロイの自動化: 手動で 8 台のサーバーを更新するのはエラーの温床
3. Feature flag の再利用は禁止: 同じ flag を違う意味で使えば災厄
4. Circuit breaker: 異常な注文の自動遮断が X
5. Testing gap: Pre-production で問題を捕まえるべきだった

第 7 部 — GitLab 2017-01-31 — DB wipe

何が起きたか

2017 年 1 月 31 日の夜
GitLab.com のデータベースが wipe
300GB のデータを失いかける (復旧可能: 約 6 時間分の transaction 損失)

原因 — 人的ミス + バックアップ不動作

状況: DB replication の問題をデバッグ中
  1 次 DB で replication がもつれる
  エンジニアが replica を整理しようとする
  
ミス 1: rm -rf を誤った DB に対して実行
  → Production DB の一部を削除

復旧の試み:
  バックアップ 1 (daily pg_dump): エラーでファイルが 0 bytes
  バックアップ 2 (LVM snapshot): 6 時間前
  バックアップ 3 (S3 upload): 有効化されていなかった
  バックアップ 4 (replica): 問題の原因だったそれ
  バックアップ 5 (Azure ディスク snapshot): 復旧可能

→ 結局 6 時間分の transaction を損失

革新的な対応

Live-stream postmortem: GitLab が YouTube で復旧過程をリアルタイム公開。 数万人が視聴。透明性の極致。

教訓

1. バックアップはテスト: 復旧してみていなければバックアップは X
2. 複数のバックアップ種別: ひとつ失敗しても別のもの
3. 人的ミスの防止: Destructive command は double-check
4. 透明性: GitLab の信頼はむしろ増加

第 8 部 — Facebook 2021-10-04 — またも BGP が犯人

何が起きたか

2021 年 10 月 4 日 15:40 UTC
Facebook、Instagram、WhatsApp が世界中で 6 時間ダウン
Facebook の社員も建物に入れず (badge システムも依存)

原因

BGP config 変更 → Facebook の DNS サーバーが internet から消える
社内ツールもすべて internet に依存 → エンジニアが復旧できない
物理的な入館証も影響 → データセンターに進入不可

復旧:
- データセンターに物理的に進入
- ネットワーク機器を手動でリセット
- BGP 広告を復元

教訓

1. Out-of-band access: 主ネットワークが死んでも入れる経路
2. Dependency loop: すべてを Internet に依存すると self-lockout
3. 物理的アクセス: デジタルインフラにも物理空間が必要
4. BGP の危険: 繰り返されるパターン

第 9 部 — Heroku 2021-04-13 — GitHub OAuth トークン流出

何が起きたか

2021 年 4 月
Heroku の GitHub OAuth integration トークンが流出
攻撃者が数千の Heroku アカウントの GitHub repos にアクセス
Heroku が初期にきちんと知らせず信頼を喪失

教訓

1. Secret 管理: OAuth token も secret
2. Rotation: 定期的な交換
3. 迅速な disclosure: 隠せばより大きな危機
4. Third-party risk: 統合は脆弱性の窓口

第 10 部 — Roblox 2021-10-28 — 73 時間ダウン

何が起きたか

2021 年 10 月 28 日から 73 時間ダウン
5 千万 DAU のゲームプラットフォーム
Black Friday の週末

原因

HashiCorp Consul (service discovery) クラスターのサーバー負荷
新機能が Consul に過度な書き込み負荷を発生
Consul consensus が壊れる → 全体 downtime

特別な点

HashiCorp + Roblox の共同ポストモーテム。ベンダーと顧客が一緒に分析。

教訓

1. Service discovery dependency: 中核は極端な安定性
2. Chaos testing: 負荷テストで捕まえるべきだった
3. Vendor collaboration: 責任共有モデル

第 11 部 — Atlassian 2022-04-05 — 14 日ダウン

何が起きたか

2022 年 4 月
775 の Atlassian 顧客 (Jira、Confluence など)
14 日間の復旧作業
スクリプトのエラーでデータ削除

原因

legacy 機能の deprecation スクリプト
「サイト」単位で削除すべきところを「アプリ」単位で引数を誤る
→ 顧客のサイト全体のデータを削除
復旧: バックアップから、but 顧客データのため個別に手作業

教訓

1. Destructive script は dry-run 必須
2. Backup per tenant: SaaS マルチテナンシー復旧の核心
3. Restore の速度: バックアップがあっても復旧が遅ければ意味半減
4. 顧客 communication: Atlassian は初期対応の不備で非難された

第 12 部 — 失敗パターン 10 個

すべての postmortem に見えるパターン:

1. 手作業 + ミス (Knight, AWS, GitLab)
2. Config change without staging (Cloudflare)
3. Dead code / 使っていない機能 (Knight)
4. Global rollout without canary (Cloudflare, Fastly)
5. BGP (Facebook, Cloudflare)
6. Backup が動かない (GitLab)
7. Dependency loop (Facebook, AWS S3 dashboard)
8. Multi-tenant blast radius (Fastly, Atlassian)
9. Third-party integration risk (Heroku)
10. Chaos testing gap (Roblox)

第 13 部 — Postmortem テンプレート

実戦テンプレート

# Incident: [Title]
Date: 2026-04-15
Severity: SEV1/SEV2/SEV3
Duration: 09:30-11:45 UTC (2h 15m)
Impact: X users affected, Y revenue lost

## Summary
[2-3 sentences]

## Impact
- Users: ...
- Revenue: ...
- Services: ...
- Customer communications: ...

## Timeline
- 09:30 UTC: Alert triggered
- 09:35 UTC: Engineer paged
- ...

## Root Cause
[Technical explanation]
Contributing factors:
- ...

## Detection
- How was it detected?
- Time to detect: X min
- Could it have been detected faster?

## Response
- Time to mitigate: X min
- What worked?
- What didn't?

## Recovery
[Steps taken to restore service]

## Lessons Learned
### What went well
- ...

### What went wrong
- ...

### Where we got lucky
- ...

## Action Items
| Item | Owner | Priority | Due |
|---|---|---|---|
| Add canary deployment | @alice | P0 | 2026-04-30 |
| ... | | | |

## Supporting Data
- Graphs, logs, screenshots

書き方のコツ

1. 事件後 48 時間以内 に草案
2. 複数人でレビュー (関係者すべて)
3. Action item は SMART (Specific, Measurable, ...)
4. Follow-up: 2 週間、4 週間後に status チェック
5. 公開の検討: 一部だけでも外部に共有

第 14 部 — チェックリスト 12 個

• Postmortem テンプレートをチームに導入
• Blameless 文化の明示 + 訓練
• Action item tracking (Jira/Linear)
• 2 週/4 週の follow-up ミーティング
• バックアップ復旧の 実際 のテスト (四半期に 1 回)
• Chaos Engineering の開始 (簡単なものから)
• Canary / Progressive rollout の強制
• Out-of-band access (建物/ネットワーク)
• Destructive command safeguard (--confirm)
• Dead code の定期整理
• Incident response runbook
• Company-wide Game Day (年 1 回)

第 15 部 — アンチパターン 10 個

1. 誰がやったかを探す → 非難文化
2. Postmortem を公開しない → 同じチームが同じミス
3. Action item の追跡が X → 張り子の虎
4. 1 時間のミーティングで終わり → 深さがない
5. Root cause をひとつに → 複雑な事件は複数の原因
6. 「Just human error」 → システム設計の問題を回避
7. SEV1 でなければ postmortem X → 小さなものからの学び
8. バックアップがあるからと安心 → 復旧テストをしない
9. Chaos Engineering を先送り → プロダクションが Chaos
10. Legal/PR が Postmortem を編集 → 真実の希釈

まとめ — 「失敗は高くつくが、学びはもっと高くはない」

Cloudflare、GitLab、AWS — 業界トップが公開 postmortem で 業界全体 を教えている。 彼らが失ったもの: 100M+ ドル。 我々が得るもの: ただの教訓。

次にあなたのサービスがダウンしたら:

• 誰かを責める時間に システムを直せ
• 恥ずかしがる時間に ドキュメント化しろ
• 隠す時間に チームと共有しろ

「失敗から学べる組織が競争力」。Google SRE 本が 25 年前から言っていたこと。

次の記事は Season 3 Ep 3 — スケーリング変曲点 完全ガイド。 1 → 100 → 10K → 100K → 1M → 10M ユーザー別のアーキテクチャ変化。いつ DB シャーディング? いつ Microservices? いつ CDN? 具体的な閾値。

次回予告 — 「スケーリング変曲点 完全ガイド: 100 → 10K → 1M ユーザー別アーキテクチャの進化」

Season 3 Ep 3 は:

• 100 users: 単一サーバー、SQLite
• 10K users: Rails + Postgres + Redis
• 100K users: read replica、キャッシュ、CDN
• 1M users: read/write split、シャーディング
• 10M users: Microservices の検討
• いつ言語を変えるか?
• Real な企業の変曲点

次の記事で。