障害が復旧すると、チームはすぐ次の仕事に戻ります。数日後に「結局あれは何だったのか」と聞かれても、残っているのはチャットの断片と「操作ミスでした」の一言だけ。そして半年後、別の人が似た障害を起こします。この記事は、そうならないための振り返り文書「ポストモーテム」を、何を書き、どこまで掘り、どう終えるかの型として整理します。
この記事の結論
- ポストモーテムは、障害のあとに「何が起き、なぜ起き、次に何を変えるか」を残す振り返りの文書です。
- 目的は犯人探しではなく、仕組みの穴を見つけて塞ぐことです。
- 基本の構成は、影響の範囲・時系列・原因（寄与した要因）・対策と担当・期限の4点です。
- 原因は1つに絞らず、人の操作を許した仕組み（確認の不足、検知の遅れ）まで掘ります。
- Well-Architected の運用の柱にも、すべての運用上のイベントから学ぶという原則があります。
ポストモーテムとは何か
ポストモーテム（postmortem）は、直訳すると「死後の検証」です。IT の運用では、障害や事故が収まったあとに、起きたことと原因、これからの対策をまとめて残す文書、またはその振り返りの場を指します。
ここで大事なのは、復旧の記録とは別物だという点です。復旧の記録は「どのコマンドで元に戻したか」を残します。ポストモーテムが残すのは「なぜそうなったのか、次は何を変えるのか」です。前者は同じ障害が起きたときに早く戻すのに役立ち、後者は同じ障害を起こさないのに役立ちます。
| 観点 | 復旧の記録 | ポストモーテム |
|---|---|---|
| 主な問い | どうやって戻したか | なぜ起きたか、次に何を変えるか |
| 使う場面 | 同じ障害が再び起きたとき | 仕組みを直すとき |
| 書く時期 | 対応中から直後 | 落ち着いてから |
| 読む人 | 対応する人 | 運用・開発・管理に関わる人 |
用語は組織によって揺れます。障害報告書、事後レビュー、RCA（根本原因分析）などと呼ばれることもあり、中身が重なります。この記事では「次の改善が主題の振り返り文書」を指す言葉として使います。
なぜ書くのか
理由は3つあります。
1つ目は再発の防止です。原因が個人の記憶に残るだけでは、その人が異動すれば消えます。文書にして初めて、次の担当者が同じ穴を避けられます。
2つ目は知識の共有です。障害は、システムが実際にはどう動くかを一番よく教えてくれる機会です。対応した数人だけが知っている状態から、チーム全体が知っている状態に変えられます。
3つ目は、Well-Architected の考え方と合っていることです。AWS Well-Architected フレームワークは、運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性の6本の柱で構成されています（Well-Architected の記事も参照）。その運用上の優秀性の設計原則に「Learn from all operational events and metrics」、つまりすべての運用上のイベントと指標から学ぶ、があります。障害は避けたい出来事ですが、学ぶ材料としては最も濃いものです。
READ ALSO — 学習中向け・段2 構成
AWS Well-Architected フレームワークとは｜6つの柱・設計原則・レンズを「問いの集まり」として使う
BREAK THE LOOP障害の輪を断つ
復旧で止まると輪は回る。対策で断ち切る
ポストモーテム
次の改善が主題
- 障害
- 復旧
- 振り返り
- 対策ここで断つ
- 検知の改善
図のとおり、障害は放っておくと「障害 → 復旧 → 次の障害」を回ります。ポストモーテムは、このループを対策の段階で断ち切るための仕組みです。復旧で止まると輪は回り続けます。
何を書くのか｜影響・時系列・原因・対策の4点
書式は組織ごとに違いますが、核になるのは次の4点です。
FOUR POINTS書く4点
ポストモーテムは4点で書く
-
影響
誰に・何に・どのくらい
影響の範囲
-
時系列
起きた・気づいた・戻った
時刻の並び
-
原因
直接の原因と寄与した要因
なぜの連鎖
-
対策
何を・誰が・いつまでに
担当と期限
1. 影響
誰に、どの機能に、どのくらいの間、何が起きたかを書きます。数字を入れるときは、監視やログで確認できたものだけにします。分からないことは「不明」と書き、推測で埋めません。
2. 時系列
いつ起き、いつ気づき、いつ対応を始め、いつ戻ったかを時刻順に並べます。ここで見たいのは、起きてから気づくまでの間と、気づいてから動き出すまでの間です。検知が遅れていたなら、直すべきは監視の側かもしれません。ログの種類や集め方はAWS のログの記事で扱っています。時系列を作る材料はそこで集めます。
3. 原因
直接の原因と、それを許した要因を分けて書きます。詳しくは後の章で扱います。
4. 対策
何を、誰が、いつまでにやるかを書きます。担当と期限の無い対策は、書いた時点で実行されないことが決まっているようなものです。
復旧の手順書だけでは再発を防げないのは、この4点のうち「原因」と「対策」が抜けるからです。
CHECK 1ここまでの確認
ポストモーテムに入れる基本の4点はどれか?
答えと解説
答え: 2. 影響の範囲・時系列・原因・対策
復旧の手順を並べただけでは、同じ種類の障害を防ぐ材料になりません。「何を書くのか」の章の4点を読み直してください。
「責めない」とはどういうことか
ポストモーテムは、人を責めない形で書く（ブレームレス）のが基本とされています。これは「誰も悪くない」と言いたいのではありません。問いを人から仕組みへ向けるということです。
操作を誤った人がいたとして、その人を責めても、次に同じ場所に立った別の人が同じことをするかもしれません。誤りが起きたこと自体より、「その誤りが通ってしまった」ことのほうが重要です。
ASK THE SYSTEM問いの向きを変える
人への問いを、仕組みへの問いに置き換える
責める問い
仕組みへの問い
責める問い: 誰がミスしたのか
仕組みへの問い: なぜそのミスが通ったのか
責める問い: なぜ気づかなかったのか
仕組みへの問い: なぜ検知の仕組みがなかったのか
責める問い: もっと注意すべきだった
仕組みへの問い: 確認を仕組みに入れられないか
責めると、もう一つ副作用があります。責められると分かっている場では、人は事実を話さなくなります。時系列に空白ができ、原因が浅いまま終わります。事実が集まらなければ、仕組みの穴も見えません。
責める振り返りが残すもの
- 「操作ミスが原因」で終わり、操作を許した仕組みが手つかずのまま残る
- 事実が語られなくなり、時系列に空白ができる
- 次の障害で、別の人が同じ穴に落ちる
責めないことと、事実を曖昧にすることは違います。「誰が何をしたか」は時系列に書きます。ただしそれは、判断の背景を理解するためであって、評価のためではありません。
CHECK 2ここまでの確認
原因欄が「担当者の操作ミス」で終わる振り返りの問題は何か?
答えと解説
答え: 2. 操作を許した仕組みが残り、別の人が同じ穴で再発する
人の操作は直接の原因にすぎず、確認の不足や検知の遅れといった寄与した要因が残ります。「責めないとはどういうことか」の章を読み直してください。
原因をどこまで掘り、対策をどう決めるのか
原因をどこまで掘るのか
原因は1つに絞らないほうが、多くの場合は実態に合います。障害は、いくつかの要因が重なって起きることが多いからです。
ここでは2層に分けて考えます。
- 直接の原因: 障害の引き金になった出来事（誤った設定の投入、容量の枯渇など）
- 寄与した要因: 引き金が障害にまで育つのを許した条件（確認の不足、検知の遅れ、手順書の欠落、復旧手順が試されていなかったこと）
掘り方の基本は「なぜ」を重ねることです。たとえば「設定を誤って投入した」で止まらず、次のように進めます。
- なぜ誤った設定が投入されたのか → 投入前に内容を確認する仕組みがなかった
- なぜ気づくのが遅れたのか → 影響を示すアラームがなかった
- なぜ戻すのに時間がかかったのか → 戻す手順が文書になっていなかった
こうして出てくる答えのほうが、対策に直結します。「確認の仕組みを足す」「アラームを足す」「戻す手順を書く」は、いずれも人に注意を促すより確実です。監視の設計の細部は別の記事に譲りますが、検知の遅れが原因に挙がったときは、そこにつなげて見直します。
掘る深さに決まった回数はありません。目安は、対策として実行できる形になるところまでです。「気をつける」で終わる答えは、まだ掘り足りません。
対策をどう決めるのか
対策は、書いて終わりにしないことが最も大事です。1つずつ次の3つを付けます。
| 付けるもの | 内容 | 付けないとどうなるか |
|---|---|---|
| 担当 | 個人またはチーム | 誰も動かない |
| 期限 | 完了の目安の日付 | 優先順位が下がり続ける |
| 確認方法 | 完了をどう判断するか | 「やったつもり」で終わる |
対策は性質で分けると整理しやすくなります。再発を防ぐもの（確認の仕組みを入れる）、早く気づくもの（検知を足す）、被害を小さくするもの（切り戻しの手順を整える）の3つです。1つの障害に対して、3つのうち複数に手を打つのが現実的です。
また、すべてを一度にやる必要はありません。効果の大きさと手間を見比べて、順番をつけます。見送る対策があるなら、見送った理由も書いておくと、次の振り返りで経緯を追えます。この「何を採って何を採らなかったか」の考え方はトレードオフの考え方の記事につながります。
READ ALSO — プロフェッショナル向け・段4 設計
トレードオフの考え方｜「なぜそのサービスか」を根拠つきで説明する型と、Well-Architected の6本柱の使い方
最後に、書いたあとの運用です。対策の進み具合は定例などで追い、完了したら手順書や監視の設定に反映します。ポストモーテムは、反映されて初めて意味を持ちます。
AWS の Post-Event Summary を読む
AWS は、重大な障害のあとに Post-Event Summary（PES）を公開しています。公式ページによれば、PES には影響の範囲、寄与した要因、対策が含まれます。この章で見た4点と、骨格はよく似ています。
読むときの観点は3つです。
- 影響の範囲: どのサービスが、どのリージョンで、どの機能に影響を受けたか。自分の構成が該当していたかを照らします。
- 寄与した要因: 単一の原因ではなく、重なった条件として書かれているか。上の「直接の原因と寄与した要因」の分け方で読み直せます。
- 対策: AWS 側がどこを直したか。自分の構成に当てはめるなら、同じ種類の穴が自分の側にもないかを点検します。
ここで書き留めておきたいのは、PES は他社の障害を「自分の構成の点検材料」にできる文書だということです。自分が経験していない障害を、自分の運用に取り込む入口になります。なお個別の PES の中身や数値はここでは扱いません。読むときは必ず公式ページの原文で確認してください。
CHECK 3ここまでの確認
AWS の Post-Event Summary に含まれるとされる内容はどれか?
答えと解説
答え: 1. 影響の範囲・寄与した要因・対策
公式ページが示す内容です。個人名や処分は含まれません。最後の章を読み直してください。
まとめ
- ポストモーテムは、復旧の記録とは別の「次の改善のための文書」です。
- 影響・時系列・原因・対策の4点を、事実で書きます。
- 責めないとは、問いを人から仕組みへ向けることです。
- 原因は直接の原因と寄与した要因に分け、対策として実行できる形になるまで掘ります。
- 対策には担当・期限・確認方法を付け、運用に反映するまでを1つの仕事にします。
Cloudory 執筆者（AWS 認定 全冠）
次に障害が起きたら、復旧後に最初の1行だけでも書いてみてください。「なぜそれが通ったのか」を問いの先頭に置くだけで、振り返りの質は変わります。
参照ソース
- AWS Well-Architected フレームワーク 運用上の優秀性の設計原則 — 「すべての運用上のイベントと指標から学ぶ」という原則の根拠
- AWS Post-Event Summaries — PES が影響の範囲・寄与した要因・対策を含むことの根拠
- AWS Well-Architected フレームワーク — 6本の柱の構成の根拠（台帳
well-architected）
