ストーリー
田
田中VPoE
ブレームレスの文化を理解した。次はその精神を具体化するドキュメント — ポストモーテムの書き方だ
あなた
テンプレートがあると統一的に書けますね
あ
田
田中VPoE
テンプレートは重要だ。だが、テンプレートを埋めるだけでは不十分だ。良いポストモーテムは「読んだ人が同じ問題に遭遇したとき、より速く・正しく対応できる」ものだ
あなた
組織の知識資産になるということですね
あ
田
田中VPoE
そうだ。1年後に新しく入ったメンバーが「過去にこういう障害があったのか」と学べる。ポストモーテムは報告書ではなく、教育資料だ
ポストモーテムの目的
3つの目的
| 目的 | 説明 |
|---|---|
| 学習 | 組織全体が障害から学び、同じ問題を繰り返さない |
| 改善 | システムとプロセスの具体的な改善につなげる |
| 透明性 | 何が起き、どう対応し、何を改善するかを組織全体に共有する |
ポストモーテムが必要な条件
| 条件 | 例 |
|---|---|
| SLO違反 | エラーバジェットの10%以上を消費 |
| ユーザー影響 | ユーザーからの報告があった |
| データ関連 | データ損失・破損が発生 |
| 長時間障害 | 復旧に1時間以上かかった |
| 繰り返し | 類似の障害が3ヶ月以内に再発 |
| ニアミス | 大事に至らなかったが、リスクの高い状況だった |
ポストモーテムテンプレート
標準テンプレート
# ポストモーテム: [インシデント名]
## 基本情報
- 日時: YYYY-MM-DD HH:MM - HH:MM (JST)
- 影響時間: XX分
- 影響範囲: [影響を受けたサービス、ユーザー数]
- 重大度: SEV1-4
- IC: [名前]
- ポストモーテム作成者: [名前]
- ポストモーテムレビュー日: YYYY-MM-DD
## サマリー（3行以内）
[何が起き、何に影響し、どう解決したかを簡潔に]
## 影響
- ユーザー影響: [具体的な数字]
- ビジネス影響: [売上影響など]
- エラーバジェット消費: [消費量]
## タイムライン
| 時刻 | イベント |
|------|---------|
| HH:MM | [検知/アクション/判断] |
## 根本原因
[直接原因と根本原因を区別して記載]
## 対応の評価
### うまくいったこと
- [具体的に]
### うまくいかなかったこと
- [具体的に]
### 幸運だったこと
- [偶然助かった要因]
## アクションアイテム
| # | アクション | 種別 | 担当 | 期限 | 優先度 |
|---|----------|------|------|------|--------|
| 1 | [具体的なアクション] | 防止/検知/緩和 | [名前] | MM/DD | P1-3 |
## 学びと教訓
[この障害から組織が学ぶべきこと]各セクションの書き方
タイムラインの書き方
| 良い例 | 悪い例 |
|---|---|
| 「14 アラート発報。ECサイトの可用性SLIが99.5%に低下」 | 「午後 アラートが鳴った」 |
| 「14 Primary on-call(鈴木)が応答。ECサイトのエラー率を確認」 | 「担当者が対応開始」 |
| 「14 直前のデプロイ(v2.3.1)が原因と推定。ロールバックを決定」 | 「原因を特定してロールバック」 |
根本原因分析: 5 Whys
事象: ECサイトで30分のダウンタイム
Why 1: なぜダウンしたか？
→ デプロイしたv2.3.1でメモリリークが発生
Why 2: なぜメモリリークがリリースされたか？
→ メモリに関する負荷テストが実施されていなかった
Why 3: なぜ負荷テストが実施されていなかったか？
→ CIパイプラインに負荷テストのステップがなかった
Why 4: なぜCIに負荷テストがなかったか？
→ 負荷テスト環境の構築が後回しにされていた
Why 5: なぜ後回しにされていたか？
→ 機能開発が優先され、テスト環境への投資が承認されていなかった
根本原因: テスト環境投資の意思決定プロセスに品質観点が欠如アクションアイテムの分類
| 種別 | 目的 | 例 |
|---|---|---|
| 防止（Prevent） | 再発を防ぐ | CIに負荷テストを追加 |
| 検知（Detect） | より早く検知する | メモリ使用率のアラート閾値を追加 |
| 緩和（Mitigate） | 影響を小さくする | カナリアリリースの導入 |
ポストモーテムレビュー会議
進め方
| フェーズ | 時間 | 内容 |
|---|---|---|
| ドキュメント共有 | 事前 | 参加者は事前にポストモーテムを読んでおく |
| タイムライン確認 | 10分 | 事実の確認、認識のズレを修正 |
| 根本原因議論 | 15分 | 5 Whysの妥当性を議論 |
| アクション決定 | 15分 | アクションアイテムの担当・期限を決定 |
| 学びの共有 | 5分 | 組織全体に共有すべき教訓を確認 |
| クロージング | 5分 | 次のステップの確認 |
レビューのルール
| ルール | 説明 |
|---|---|
| ブレームレス | 「誰が」ではなく「なぜ」に焦点 |
| 事実ベース | 推測ではなくデータとログに基づく |
| 建設的 | 批判ではなく改善提案 |
| タイムボックス | 50分以内に終了 |
| フォローアップ | アクションアイテムの進捗を追跡 |
まとめ
| ポイント | 内容 |
|---|---|
| ポストモーテムの目的 | 学習、改善、透明性の3つ |
| 根本原因分析 | 5 Whysで「人」ではなく「システム」の問題に到達する |
| アクションアイテム | 防止・検知・緩和の3分類で具体的に定義 |
チェックリスト
- ポストモーテムテンプレートの各セクションを理解した
- 5 Whysによる根本原因分析の方法を理解した
- ポストモーテムレビュー会議の進め方を理解した
次のステップへ
次は「アクションアイテムと改善サイクル」です。ポストモーテムから導かれたアクションアイテムを確実に実行し、継続的な改善につなげる仕組みを学びましょう。
推定読了時間: 30分