運用・監視 レッスン6
ポストモーテム
障害から学びを得て再発を防ぐための、非難のない振り返りであるポストモーテムの書き方と進め方を学ぶ
ポストモーテムとは何か
ポストモーテムとは、障害やインシデントが収束した後に行う 振り返りのプロセスと、その成果物であるドキュメントを指します。目的は個人の責任を追及することではなく、 何が起きたかを正確に記録し、同じ原因で再び障害が起きないよう組織として学ぶことです。
非難のない(Blameless)文化
「誰が間違えたか」を追及する文化では、ミスをした人が事実を隠したり報告を避けたりするようになり、 根本原因の分析に必要な情報が集まらなくなります。「なぜその判断が当時は合理的に見えたのか」 「どうすれば仕組みとして防げたか」に焦点を当てることで、正直な情報共有が促されます。
ポストモーテムに書くべき項目
形式はチームによって異なりますが、一般的に以下の項目を含めます。
# ポストモーテム: 注文APIのエラー率上昇 (2026-03-01)
## 概要
- 影響時間: 09:12 〜 09:47 (35分間)
- 影響範囲: 注文APIの約12%のリクエストが失敗
- 検知経緯: エラー率上昇アラートにより自動検知
## タイムライン
- 09:05 新バージョンのデプロイを開始
- 09:12 エラー率上昇アラートが発火
- 09:15 オンコール担当が対応を開始、トリアージ
- 09:20 直前のデプロイが原因と推測しロールバックを実施
- 09:35 エラー率が正常値まで低下
- 09:47 完全復旧を確認、インシデントを終息とみなす
## 根本原因
- 新バージョンで追加した外部APIクライアントのタイムアウト設定が
誤って極端に短い値になっていた
## 寄与要因
- ステージング環境の負荷がテスト時と本番で大きく異なっていた
- タイムアウト設定値に対する自動テストが存在しなかった
## 良かった点
- アラートにより7分で異常を検知できた
- ロールバック手順が整備されており、迅速に復旧できた
## 再発防止のアクションアイテム
- [ ] タイムアウト設定値の妥当性を検証する自動テストを追加する
- [ ] ステージング環境の負荷を本番に近づける
- [ ] デプロイ後の自動ロールバック条件(エラー率の急上昇)を設定する良い例と避けたい例
避けたい書き方
「担当者がタイムアウト設定を確認せずにデプロイしたことが原因」のように、 個人の不注意を原因として断定する書き方は、次に同じミスをしないための 仕組みの改善につながりにくく、報告する側の心理的な抵抗も生みます。
推奨する書き方
「タイムアウト設定値を検証する自動テストが存在せず、誤った値がレビューをすり抜けた」 のように、個人ではなく仕組みの不足として記述すると、具体的な改善策(自動テストの追加)につながります。
アクションアイテムのフォローアップ
ポストモーテムを書いて終わりにせず、洗い出した再発防止のアクションアイテムには 担当者と期限を設定し、通常のタスク管理と同様に追跡します。すべてのアクションアイテムを 一度に完了させる必要はなく、影響度や実現コストをもとに優先順位をつけて、 着実に消化していくことが重要です。
ポイント
- ポストモーテムの目的は個人の責任追及ではなく、組織としての再発防止
- タイムライン・根本原因・寄与要因・良かった点・アクションアイテムを記録する
- 原因は個人の不注意ではなく仕組みの不足として記述する
- アクションアイテムには担当者と期限を設定し、優先順位をつけて追跡する
確認クイズ
1 / 3ポストモーテムを「非難のない(blameless)」ものにする理由として最も適切なものはどれか？