incident-postmortem

インシデントの事後分析レポート作成

概要

運用上の障害を学びの機会へと変える、非難のないインシデント事後分析レポートを作成します。これらの文書では、個人を責めるのではなく、システム障害やプロセスの不備に焦点を当て、継続的な改善と再発防止を可能にします。

基本原則

1. 非難しない：人ではなくシステムに焦点を当てます。「誰が失敗したのか？」ではなく、「なぜ起きたのか？」を問いかけます。
2. 心理的安全性：チームメンバーが恐れることなく根本原因を話し合える環境が必要です。
3. データに基づく：推測ではなく、ログ、メトリクス、事実に基づいて所見をまとめます。
4. 行動につなげる：すべての所見から、実行可能な改善策につなげます。
5. 学習する文化：インシデントを失敗ではなく、価値ある学びの機会として捉えます。
6. 透明性：所見を広く共有し、同様のインシデントを防ぐための変更を伝えます。

タイムラインの再構築

イベントの詳細な時系列を作成します。

Time (UTC) | Who | What | Evidence | Context
-----------|-----|------|----------|----------
2024-02-15 14:32 | Jenkins | Deploy v2.1.3 (buggy) | Logs | Automated Friday deploy
14:35 | Customer | Website errors | CloudFront | 500 errors reported
14:37 | On-call | PagerDuty alert | Alert | Error rate exceeded threshold
14:42 | Eng team | Investigation starts | Slack #incidents | Identified deploy cause
14:55 | Lead | Rollback initiated | Logs | Reverted to v2.1.2
15:02 | On-call | Error rate normal | Metrics | Customers back to normal
15:30 | Team | Root cause meeting | Notes | Identified root cause

タイムラインのテンプレート：

• T+0（アラート）：最初に検知された時刻
• T+X（検出）：インシデントが認識された時刻
• T+Y（連絡）：関係者に通知した時刻
• T+Z（緩和）：インシデント担当者が対応を開始した時刻
• T+N（解決）：システムが正常な状態に戻った時刻
• 期間：検出から解決までの合計時間

根本原因分析（5 Whys）

明白な原因にとどまらず、システム上の問題を見つけます。

Incident: Website down for 28 minutes

Why 1: Why did website go down?
Answer: Deployment v2.1.3 contained a bug causing infinite loop in auth service

Why 2: Why did the bug reach production?
Answer: Code review missed the issue; test suite didn't catch it

Why 3: Why didn't test suite catch the infinite loop?
Answer: Load/stress tests only run occasionally; not part of standard CI pipeline

Why 4: Why aren't load tests mandatory in CI?
Answer: Historically slow; team prioritized speed over reliability

Why 5: Why does team optimize for deploy speed over testing?
Answer: Pressure to ship features fast; no documented standard for testing rigor

ROOT CAUSE: Process gap - no mandatory load testing in CI; pressure to ship

避けること：

• 早い段階で分析を打ち切ること（「オペレーターがエラーに気づかなかった」）
• ヒューマンエラーを根本原因とすること（「開発者がミスをした」）
• システム上の問題を曖昧にすること

焦点を当てる項目：

• プロセスの不備
• 監視の抜け漏れ
• コミュニケーションの断絶
• 知識の不足
• ツールの制約
• アーキテクチャの弱点

寄与要因（スイスチーズモデル）

ほとんどのインシデントは、複数の障害が重なって発生します。

Incident: Late-night 30-minute outage

Contributing Factors:
1. Code change made Friday afternoon (rush to deploy before weekend)
2. No automated rollback capability (manual process)
3. On-call engineer had weak knowledge of new code (hired 3 weeks ago)
4. No load test coverage for auth service changes (technical debt)
5. Monitoring alert threshold set too high (missed early warning)
6. Deployment not staged; went straight to production (process gap)
7. No change advisory board approval (governance gap)

Any ONE of these alone wouldn't have caused incident. Combined: 28-minute outage.

根本原因と直接原因

直接原因（直近の原因）：

• 認証コードの無限ループ
• 実施すべきではなかったデプロイ
• モニターのアラート不足

根本原因（システム上の不備）：

• 重要な変更に対するコードレビューのプロセスが不十分だった
• デプロイプロセスに段階的デプロイ／カナリアデプロイがなかった
• テスト戦略にストレステストが含まれていなかった
• オンコールチームに最近の変更に関する知識が不足していた

事後分析では、直接原因ではなく根本原因に焦点を当てます。

アクション項目（フォローアップ）

形式：[優先度] | [内容] | [理由] | [担当者] | [期限] | [ステータス]

即時対応（0～7日）

CRITICAL | Deploy hotfix for infinite loop | Prevent recurrence | Sarah | 2024-02-15 | DONE
HIGH | Document code change impact | Knowledge transfer | John | 2024-02-16 | IN PROGRESS
MEDIUM | Post-incident communication to customers | Transparency | PM | 2024-02-15 | DONE

短期対応（1～4週間）

HIGH | Implement automatic canary deployment | Catch issues pre-production | DevOps | 2024-03-01 | PENDING
HIGH | Add auth load tests to CI pipeline | Catch performance issues early | QA | 2024-03-01 | PENDING
MEDIUM | Onboard new on-call engineer on recent changes | Knowledge gap closure | Tech Lead | 2024-02-28 | IN PROGRESS

長期対応（1～3か月）

MEDIUM | Implement automated rollback capability | Faster recovery time | Arch | 2024-04-15 | PENDING
LOW | Review change advisory board process | Governance improvement | Ops | 2024-05-01 | PENDING
LOW | Schedule quarterly load testing for critical services | Proactive risk management | Perf | 2024-06-01 | PENDING

SMART アクション項目：

• S（Specific：具体的）：具体的に何をする必要がありますか？
• M（Measurable：測定可能）：完了したことをどのように確認しますか？
• A（Assignable：割り当て可能）：誰が担当しますか？
• R（Realistic：現実的）：実際に実行できますか？
• T（Time-bound：期限付き）：期限はいつですか？

予防策

予防戦略：この種のインシデントをどのように防ぎますか？

1. プロセスの変更：

   • 重要なサービスに段階的デプロイ／カナリアデプロイを導入する
   • 認証サービスの変更にコードレビューを必須とする
   • 重要なパスの変更には、ロードテストの合格を必須とする

2. 監視とアラート：

   • エラー率アラートのしきい値を下げる（早期警告）
   • 認証サービスの CPU／メモリのアラートを追加する
   • カナリアエンドポイントの外形監視を追加する

3. 自動化：

   • エラー率が 2% を超えた場合に自動でロールバックする
   • CI パイプラインにロードテストのゲートを追加する（任意ではなく必須）
   • カオスエンジニアリングテストを毎週自動実行する

4. ドキュメントとトレーニング：

   • 認証サービスのアーキテクチャを文書化する
   • 認証サービスのインシデント対応用ランブックを作成する
   • オンコールチーム向けの知識共有セッションを予定する

5. 組織面：

   • 期限によるプレッシャーをなくし、金曜の午後にはデプロイしない
   • 重要なサービスのコードレビューにオンコールエンジニアを加える
   • インシデントの SLA を定める：P0 インシデントの検出から解決までを 15 分未満にする

テンプレート構成

インシデント事後分析

インシデント ID：INC-2024-047 日付：2024-02-15 継続時間：28 分（14:35 UTC - 15:03 UTC） 影響：ウェブサイトが利用不可；0.5M 件のページリクエストが失敗 重大度：P1（重大）

インシデント概要 [何が起き、どのような影響があったかを1段落で概説]

タイムライン [時系列のイベント表]

根本原因分析 主な根本原因：[概要レベルの調査結果]

5つのなぜ分析： [「なぜ」の連鎖]

寄与要因： [体系的な問題の一覧]

影響分析

• 影響を受けた顧客：[人数または割合]
• 継続時間：[分]
• 収益への影響：[定量化できる場合]
• 評判への影響：[定性的な評価]
• データ損失：[あり／なし。「あり」の場合は詳細]

検知と対応

• 検知時間：[検知までの分数]
• 対応時間：[緩和策の開始までの分数]
• 解決時間：[完全復旧までの分数]
• 対応の質：[円滑／多少の遅延あり／混乱 — 理由]

うまくいったこと

• [良かった点1]：[成果]を実現
• [良かった点2]：[成果]を実現
• [良かった点3]：[成果]を実現

優れた取り組みを認め、良い行動を強化しましょう

改善できること

• [課題1]：その影響は[結果]でした
• [課題2]：その影響は[結果]でした
• [課題3]：その影響は[結果]でした

アクションアイテム [担当者と日付を含む、即時・短期・長期のアクション]

予防策 [今後、同種のインシデントをどのように防ぐか]

付録

• エラーログ（匿名化済み）
• 顧客への連絡
• インシデント発生中の監視グラフ
• アーキテクチャ図
• 関連するインシデント（過去の傾向）

事後分析の進行

責任追及をしない会議の原則：

1. 責任追及ではなく、状況の説明から始める：「14:30 UTC に何が起きていたか説明します……」
2. 中立的な言葉を使う：「コードが変更された」と言い、「コードが壊れていた」とは言わない
3. 好奇心を持って質問する：「画面には何が表示されていましたか？」と尋ね、「なぜログを確認しなかったのですか？」とは尋ねない
4. 経験を語るよう促す：各自の経験を話してもらい、流れのある説明を促します
5. 前提を記録する：「……だと思い込んでいました」という発言から、知識のギャップが明らかになります
6. 階層を設けない：オンコールエンジニアの所見も CTO の所見と同様に尊重します
7. 決定事項を記録する：修正ではなくロールバックを選んだのはなぜか？判断に至った考えを記録します
8. 学びを記録する：何が予想外でしたか？何を学びましたか？

参加者：

• オンコールエンジニア（インシデント対応者）
• サービスオーナー
• DevOps／インフラチーム
• プロダクト／ビジネスオーナー
• ファシリテーター（経験豊富で中立的な立場の人）

会議の所要時間：最大30～60分

開催時期：インシデント解決から48時間以内（詳細が鮮明なうちに）

共有とフォローアップ

1. 広く共有する：事後分析は学習のための社内ツールです。エンジニアリング組織全体に共有しましょう
2. エグゼクティブサマリー：リーダーシップ向けの1ページの概要
3. 顧客への連絡：何が起きたか、再発防止策は何かを透明性をもって伝えます
4. プロセスの見直し：未完了のアクションアイテムを毎月確認します
5. 傾向分析：四半期ごとに確認します — インシデントの種類を予防できていますか、それとも火消しに追われているだけですか？

同様のインシデントの予防

インシデント種別の追跡：

• 認証の失敗
• データベースのパフォーマンス低下
• メモリリーク
• 設定エラー
• 依存関係の障害
• デプロイの失敗

同じ種類のインシデントが2回発生した場合：予防策を強化します
同じインシデントが3回発生した場合：組織レベルでエスカレーションします（経営陣によるレビュー）

---

このスキルの用途：インシデントを学びの機会に変え、システムのレジリエンスを向上させ、心理的安全性の高いインシデント対応文化を築きます。