インシデント対応

ポストモーテムぽすともーてむ

インシデント対応障害対応振り返り再発防止SRE根本原因分析

ポストモーテムって何？システム障害のあとに書くやつ？

簡単に言うとこんな感じ！

そう、システム障害が起きたあとに「何が起きたか・なぜ起きたか・次はどう防ぐか」をチームで振り返ってまとめるドキュメントだよ。犯人捜しじゃなく「仕組みとして防ごう」って考え方がポイントなんだ！

ポストモーテムとは

ポストモーテム（Postmortem） とは、システム障害やサービス停止などのインシデント（問題事象）が発生・収束したあとに行う、体系的な振り返りとその記録文書のことです。もともとは医学用語で「死後解剖」を意味しますが、IT業界では「障害を解剖して原因と教訓を取り出す」プロセスとして広く使われています。

ポストモーテムの最大の特徴は、「非難しない（Blameless）」文化 を前提としていることです。特定の担当者を責めるのではなく、「なぜそのような状況が生まれたのか」という システム・プロセス側の問題 に着目します。Google の SRE（サイト信頼性エンジニアリング）チームが体系化・普及させた手法として有名で、現在は多くのIT企業・情報システム部門で採用されています。

発注者・管理者の立場では「障害報告書を書く」だけで終わりがちですが、ポストモーテムは 再発防止のアクション（改善策）まで明確にして追跡する 点が障害報告書と大きく異なります。

ポストモーテムの構成と書き方

一般的なポストモーテムには以下のセクションが含まれます。

セクション	内容
概要	何が起きたか・影響範囲・継続時間を一言でまとめる
タイムライン	発生から収束まで時系列で出来事を記録する
根本原因（Root Cause）	なぜ発生したかを「なぜなぜ分析」などで深掘りする
影響	影響を受けたユーザー数・売上損失・SLA違反有無など
検知と対応	どのアラートで気づき、誰がどう対応したか
再発防止策	具体的な改善アクション・担当者・期限を明記する
教訓	チーム全体が学んだこと・次に活かせること

覚え方：「なぜなぜ5回」で根本原因を掘る

根本原因分析でよく使われるのが 「5 Whys（なぜなぜ分析）」 です。「なぜ起きた？」を5回繰り返すことで、表面的な原因（DBサーバーが落ちた）から本質的な原因（監視アラートの閾値設定が甘かった）まで掘り下げられます。

なぜ1: サービスが停止した
  → DBサーバーへの接続が切れたから
なぜ2: なぜ接続が切れた？
  → DBのディスクが満杯になったから
なぜ3: なぜ満杯になった？
  → ログが自動削除されていなかったから
なぜ4: なぜ自動削除されていなかった？
  → ローテーション設定が抜けていたから
なぜ5: なぜ設定が抜けた？
  → 本番環境へのデプロイチェックリストに含まれていなかったから
  ↓
【根本原因】デプロイチェックリストの不備（仕組みの問題）

深刻度（Severity）による優先度分類

インシデントの深刻度を分類し、ポストモーテムを実施すべきか・どの深さで行うかを判断します。

レベル	名称	例	ポストモーテム
SEV-1	致命的	全サービス停止・データ損失	必須・詳細
SEV-2	重大	主要機能が一部使えない	必須
SEV-3	中程度	パフォーマンス低下・一部エラー増加	推奨
SEV-4	軽微	UI不具合・軽微な誤動作	任意

歴史と背景

1990年代以前 — 障害報告は「誰がミスしたか」を中心に記録する文化が主流。担当者への責任追及が再発防止よりも優先されがちだった
2000年代前半 — AmazonやGoogleなどの大規模ウェブサービスが急成長し、システムが複雑化。「人のせいにしても問題は再発する」という認識が広まる
2003年 — Google が SRE（Site Reliability Engineering）チームを設立。Blameless Postmortem の考え方を社内で体系化し始める
2014年 — Google の Ben Treynor Sloss らが書いた 「SRE本（Site Reliability Engineering）」 が公開・出版（2016年書籍化）。ポストモーテムの手法が業界標準として広く認知される
2016年以降 — DevOps・アジャイル開発の普及とともに、SREの考え方が大企業・スタートアップ問わず浸透。ポストモーテム文化が日本のIT現場にも広がる
2020年代 — クラウドサービスの普及により、AWSやGCPなど主要クラウドベンダーも障害発生後に公開ポストモーテムを発行するのが標準的な慣行になる

ポストモーテム vs 従来の障害報告書

似ているようで目的が大きく異なります。

観点	従来の障害報告書	ポストモーテム
主な目的	経緯の記録・報告	学習と再発防止
フォーカス	誰が何をしたか	なぜそうなったか（仕組み）
責任の考え方	担当者の責任を明確化	Blameless（非難しない）
アクション	必須ではない	具体的な改善策と期限が必須
共有範囲	上長・関係者のみ	チーム全体・場合により社外公開
更新	基本的に書き直さない	アクションの完了状況を追跡・更新

以下の図は、インシデント発生からポストモーテム完了までの流れを示しています。

規格・文書	内容
Google SRE Book – Postmortem Culture	Google が公開している SRE 本のポストモーテム文化の章（無料で全文公開）
ITIL v4 – Problem Management	ITIL（ITサービス管理のフレームワーク）における問題管理プロセスの定義