インシデント対応 基礎：切り分け・状況共有・復旧・ポストモーテムの型

第8章：ポストモーテム（真因/再発防止/検知・手順改善）

この章で学ぶこと

  • 真因を“仕組み”として説明する
  • 再発防止を“行動（期限/担当/検証）”に落とす
  • アクションアイテムを Issue / PR / Runbook / 監視設定に接続する
  • 検知と手順（Runbook/運用手順書）に反映する

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

  • ポストモーテム（付録: ポストモーテム）
  • フォローアップ管理（アクション一覧）

本文

ポストモーテムは責任追及や反省会ではない。再発防止を行動に落とし込み、追跡可能にすることが目的である。

最低限の構造

  • 事象要約
  • 真因（直接原因/背後要因）
  • 再発防止（期限/担当/検証）
  • 検知改善
  • 手順改善（Runbook 更新）

具体例（場当たり→再現性）

悪い例（場当たり）

原因: 気をつける
対策: 注意する
フォローアップがない

良い例（再現性）

真因: 接続プール設定が負荷変動に耐えない
対策: 設定見直し + 負荷試験（期限/担当）
検知: 閾値を SLI ベースに再設計
手順: Runbook に初動とロールバックを追記
フォローアップ: アクション一覧で追跡

ポストモーテムで分けるもの

ポストモーテムでは、原因分析、対応評価、再発防止、公開/通知判断を混ぜない。

区分 書くこと
事実 タイムライン、観測値、影響範囲、実施した操作
分析 直接原因、背後要因、検知/手順/権限/設計の不足
対応評価 うまくいったこと、遅れたこと、判断に迷ったこと
再発防止 Owner、期限、完了条件、検証方法を持つアクション
残リスク 今回残すリスク、別 Issue に分離する課題

アクションアイテムは「注意する」ではなく、完了を第三者が確認できる形にする。完了先は Issue、PR、Runbook、監視設定、訓練計画のいずれかに接続する。

良いアクションアイテム例（抜粋）

「注意する」「気をつける」ではなく、誰が/いつまでに/何を/どのように検証するかを明確化する。

# アクション 担当 期限 完了条件（検証）
1 決済 API のエラー率 SLI とアラート閾値を定義し、監視に反映 SRE YYYY-MM-DD 本番でアラートが発火し、Runbook に誘導されることを確認
2 ロールバック手順を Runbook 化（前提/手順/検証/ロールバック条件） 復旧担当 YYYY-MM-DD 手順を別担当が再現でき、検証項目（指標）が揃っている
3 DB 変更を伴うリリースの事前チェックリストを追加（不可逆変更の扱い） 開発リード YYYY-MM-DD PR テンプレ/手順に組み込み、レビューで抜けが検出できる

チェックリスト

  • 真因が仕組みとして説明されている
  • 再発防止が行動になっている
  • 検知/手順に反映されている
  • フォローアップが Issue / PR / Runbook / 監視設定に接続されている
  • 残リスクと別 Issue 化した項目が記録されている

まとめ

  • 真因は個人の注意不足ではなく、仕組み（設計/運用/制約）として説明する
  • 再発防止はアクション（期限/担当/検証）に落とし込み、Issue / PR / Runbook / 監視設定へ接続する
  • 検知・手順（Runbook）の改善を含めて運用に反映する

次章への接続

Edit this page on GitHub