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

この章で学ぶこと

• 障害報告は「説明責任」のために整理する
• ポストモーテムは「再発防止を行動に落とす」ために書く
• テンプレと相互参照し、運用に反映する

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

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

本文

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

テンプレ

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

記入例（要点）

• タイムライン: いつ何を判断し実施したか
• 影響: 範囲と期間
• 真因: 直接原因/背後要因
• 再発防止: 期限/担当/検証
• 手順改善: Runbook/手順書の更新

よくある落とし穴

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

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

悪い例

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

良い例

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

チェックリスト

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

まとめ

• 障害報告は事象・影響・タイムラインを明確化し、説明責任を担保する
• ポストモーテムは真因と再発防止を行動（期限/担当/検証）に落とし、運用ドキュメントへ反映する

次章への接続

• 次章: 第10章