ポストモーテム

概要

ポストモーテム（postmortem、原義は「検死」）は、障害が収束した後に「何が起きたのか」「なぜ起きたのか」「どう対応したのか」「再発を防ぐには何をするか」を文書にまとめて振り返る実践です。インシデント対応が火を消す活動だとすれば、ポストモーテムは火事から学ぶ活動であり、両者が揃ってはじめて障害対応のサイクルが閉じます。

最大の特徴は「blameless（非難しない）」という原則です。誰がミスをしたかを追及する報告書ではなく、「善意で合理的に行動した人が、なぜその結果に至ったのか」というシステム側の要因を明らかにする文書として書きます。個人の処罰ではなく仕組みの改善に焦点を当てる — この姿勢が単なる障害報告書とポストモーテムを分ける本質です。

なぜ生まれたか

障害のたびに「担当者の不注意」で片づけて反省文を書かせる組織では、次に何が起きるでしょうか。人はミスを隠し、ヒヤリとした話を共有しなくなり、障害の一次情報が上がってこなくなります。犯人探しは再発防止に一切寄与しないばかりか、学習の材料そのものを枯らしてしまうのです。しかも「注意する」「気をつける」という対策は、同じ条件が揃えば別の誰かが同じミスをすることを防げません。人間はミスをするという前提に立ち、ミスが事故に発展しない仕組みを作るしかない — この認識は、航空業界や医療の安全工学で先に確立されていました。パイロットが処罰を恐れず報告できる制度が航空安全を飛躍的に高めた歴史は、その代表例です。

ソフトウェア運用の世界では、Google の SRE が blameless postmortem を実践の柱として体系化し、書籍『Site Reliability Engineering』を通じて業界標準になりました。障害が避けられない分散システムの運用では、個々の障害を「授業料を払い済みの学習機会」として最大限回収することが、信頼性向上のもっとも確実な道だからです。

詳細

文書に書くこと

典型的なポストモーテムには、影響の要約（何が・どれくらいの時間・どの範囲に）、時系列（検知・エスカレーション・緩和・復旧の各時刻をログやチャット履歴から正確に再構成したタイムライン）、根本原因の分析、うまくいったこと・いかなかったこと、そしてアクションアイテムを記載します。影響は「ユーザーの3%が15分間ログイン不能」「SLO のエラーバジェットを月間予算の40%消費」のように定量的に書きます。感情や責任の記述ではなく、事実と因果の記述に徹するのが作法です。

根本原因分析 — 5 Whys とその先

分析の代表的な道具が、トヨタ生産方式に由来する「5 Whys（なぜなぜ分析）」です。表面的な事象から「なぜ？」を繰り返して掘り下げ、仕組みレベルの原因に到達します。重要なのは、掘り下げの終点を「人」ではなく「システム」に置くことです。「担当者が確認を怠ったから」で止めれば対策は「注意喚起」にしかなりませんが、「確認が人間の注意力に依存する手順だったから」まで掘れば「CI/CD パイプラインで自動検証する」という再発しない対策が導けます。

現実の障害は単一の根本原因に収束しないことも多く、複数の要因が同時に揃ったときだけ事故になる、という見方（寄与要因分析）が近年は主流です。「なぜ」を機械的に5回繰り返すことよりも、「この障害を防げたはずの防壁はどこで、なぜ機能しなかったか」を多面的に洗い出すことが目的だと理解しておくと、道具に振り回されずに済みます。

アクションアイテム — 振り返りを行動に変える

ポストモーテムの価値は、最終的にアクションアイテムの実行で決まります。良いアクションアイテムは、担当者と期限が明確で、「注意する」ではなく検証可能な変更 — アラートの追加、モニタリングダッシュボードの整備、切り戻し手順の自動化、カナリアリリースの導入など — として書かれます。よくある失敗は、立派な文書を書いた満足感でアクションアイテムが放置されることです。課題管理システムに登録して通常の開発タスクと同じ優先度付けの土俵に載せ、定期的に消化状況を追跡する運用が欠かせません。書きっぱなしのポストモーテムは、書かないのとほぼ同じです。

blameless を機能させる条件

blameless は「誰も責任を取らない」という意味ではありません。個人を罰しない代わりに、組織が仕組みの改善という形で責任を引き受ける、という取り決めです。これが機能するには心理的安全性が前提になります。文書中では「Aさんがコマンドを誤った」ではなく「デプロイ担当者が、成功と失敗の表示が紛らわしい画面で誤った環境を選択した」のように、役割と状況で記述し、当時の判断がなぜ合理的に見えたのかを掬い上げます。優れた組織はさらに進んで、ポストモーテムを全社に公開して他チームの学びに変えたり、大障害から得た教訓をカオスエンジニアリングのゲームデーの題材にして対応力を鍛えたりします。障害を恥として隠す組織と、資産として共有する組織 — 長期的な信頼性の差はここから生まれます。