第9章：障害報告・ポストモーテム（タイムライン / 真因 / 再発防止）

この章で学ぶこと

障害報告は「説明責任」のために整理する
ポストモーテムは「再発防止を行動に落とす」ために書く
テンプレと相互参照し、運用に反映する
follow-up Issue / PR と検証結果まで追跡する

この章の成果物（または判断基準）

障害報告（付録: 障害報告テンプレ）
ポストモーテム（付録: ポストモーテムテンプレ）

本文

本章は、テンプレ→記入例→落とし穴→チェックリストの順で整理する。

責務分界

障害報告とポストモーテムは、同じ障害を扱っても目的と確定時期が異なる。まず障害報告で確認済みの事実と対応状況を共有し、復旧後に証拠と関係者の認識が揃ってからポストモーテムで学習と改善行動を確定する。一方で、障害報告をポストモーテムの完成まで保留したり、ポストモーテムを障害中の状況共有に使ったりしない。

成果物	作成開始・確定時期	主な読者	必須項目	非目的	follow-up
障害報告	障害中から作成・更新し、復旧後に影響とタイムラインを確定する	影響を受けた関係者、運用、サポート、管理者	事象、影響範囲と期間、タイムライン、暫定対応と成功条件、恒久対策の担当・期限	未確認情報による断定、個人の責任追及、真因分析の完了を待つこと	訂正履歴を残し、恒久対策とポストモーテムへ事実関係を引き継ぐ
ポストモーテム	復旧後、証拠と事実関係が安定してから作成・合意する	開発、運用、関連チーム、管理者	非難しない前提、事象と影響、直接原因と背後要因、再発防止、検知・手順改善、担当・期限・検証結果	障害中のリアルタイム状況共有、顧客向け障害通知、個人への責任帰属	改善を Issue / PR にし、担当・期限・状態・検証結果を追跡する

障害報告の恒久対策欄は、復旧時点で分かる対策候補と追跡先を示す。深い原因分析と改善行動の合意はポストモーテムで行い、実装と有効性確認は follow-up Issue / PR で管理する。後続成果物で前提が変わった場合は、相互リンクと訂正履歴により差分を追跡できるようにする。

テンプレ

記入例（要点）

タイムライン: いつ何を判断し実施したか
影響: 範囲と期間
真因: 直接原因/背後要因
再発防止: 期限/担当/検証
手順改善: Runbook / 手順書の更新
フォローアップ: Issue / PR、検証結果、公開反映

よくある落とし穴

真因が整理されず、対策が「注意する」で終わる
再発防止が行動になっていない
影響範囲が曖昧
責任追及の文脈になる

具体例（悪い例→良い例）

悪い例

原因: 調査中（真因の説明なし）
対策: 注意する
影響: 影響あり（範囲/期間不明）

良い例

影響: 決済 API、10:12〜10:35、最大8%失敗
タイムライン: 検知→暫定→復旧→確認
真因: 接続プール設定が負荷に耐えない
再発防止: 設定見直し+負荷試験（期限/担当/検証）
手順改善: Runbook に初動/ロールバックを追記

チェックリスト

影響範囲と期間が明確
タイムラインがある
真因が仕組みとして説明されている
再発防止が行動（期限/担当/検証）になっている
手順/検知に反映されている
follow-up Issue / PR と検証結果が紐づいている

まとめ

障害報告は事象・影響・タイムラインを明確化し、説明責任を担保する
ポストモーテムは真因と再発防止を行動（期限/担当/検証）に落とし、運用ドキュメントへ反映する
フォローアップは Issue / PR と検証結果まで追跡し、対策が実行されたことを確認する

次章への接続

次章: 第10章