第8章：ポストモーテム（真因/再発防止/検知・手順改善）
この章で学ぶこと
- 真因を“仕組み”として説明する
- 再発防止を“行動（期限/担当/検証）”に落とす
- 検知と手順（Runbook/運用手順書）に反映する
成果物（または判断基準）
- ポストモーテム（付録: ポストモーテム）
- フォローアップ管理（アクション一覧）
本文
ポストモーテムは責任追及や反省会ではない。再発防止を行動に落とし込み、追跡可能にすることが目的である。
最低限の構造
- 事象要約
- 真因（直接原因/背後要因）
- 再発防止（期限/担当/検証）
- 検知改善
- 手順改善（Runbook 更新）
具体例（場当たり→再現性）
悪い例（場当たり）
原因: 気をつける
対策: 注意する
フォローアップがない
良い例（再現性）
真因: 接続プール設定が負荷変動に耐えない
対策: 設定見直し + 負荷試験（期限/担当）
検知: 閾値を SLI ベースに再設計
手順: Runbook に初動とロールバックを追記
フォローアップ: アクション一覧で追跡
良いアクションアイテム例（抜粋）
「注意する」「気をつける」ではなく、誰が/いつまでに/何を/どのように検証するかを明確化する。
| # | アクション | 担当 | 期限 | 完了条件（検証） |
|---|---|---|---|---|
| 1 | 決済 API のエラー率 SLI とアラート閾値を定義し、監視に反映 | SRE | YYYY-MM-DD | 本番でアラートが発火し、Runbook に誘導されることを確認 |
| 2 | ロールバック手順を Runbook 化（前提/手順/検証/ロールバック条件） | 復旧担当 | YYYY-MM-DD | 手順を別担当が再現でき、検証項目（指標）が揃っている |
| 3 | DB 変更を伴うリリースの事前チェックリストを追加（不可逆変更の扱い） | 開発リード | YYYY-MM-DD | PR テンプレ/手順に組み込み、レビューで抜けが検出できる |
チェックリスト
- 真因が仕組みとして説明されている
- 再発防止が行動になっている
- 検知/手順に反映されている
- フォローアップが管理されている
まとめ
- 真因は個人の注意不足ではなく、仕組み（設計/運用/制約）として説明する
- 再発防止はアクション（期限/担当/検証）に落とし込み、追跡可能にする
- 検知・手順（Runbook）の改善を含めて運用に反映する
次章への接続
- 付録: テンプレ集
- 関連: 障害報告/ポストモーテムの書式と運用: engineering-documentation-book
- 関連: 秘密情報漏えい疑いの初動/証跡/隔離: security-privacy-literacy-book