ポストモーテム（事後分析）

ポストモーテムとは

ポストモーテム（Postmortem）は、インシデントや障害が発生した後に実施する非難のない（Blameless）事後分析です。「検死」を意味する医学用語に由来しますが、SREにおいては「何が起きたのか」「なぜ起きたのか」「どうすれば再発を防げるのか」を客観的に分析し、組織の学習と改善につなげるための重要なプロセスです。

目的

ポストモーテムの主な目的は以下の通りです。

インシデントの詳細な記録: 何が起きたのかを正確に文書化する
根本原因の特定: 表面的な原因ではなく、根本的な原因を明らかにする
再発防止策の策定: 具体的で実行可能な改善アクションを定義する
組織学習の促進: 知見を共有し、チーム全体のレジリエンスを高める
システムの改善: インシデントから学び、より堅牢なシステムを構築する

ポストモーテムの重要性

Google SRE bookでは、「失敗は学習の機会である」という考え方が強調されています。ポストモーテムを通じて、組織は同じ過ちを繰り返さず、継続的に改善することができます。

非難のない文化（Blameless Culture）

ポストモーテムにおいて最も重要な原則は、**個人を責めない（Blameless）**ことです。

なぜ非難しないのか

人間は誰でもミスをします。個人を責めることは、以下の悪影響をもたらします。

隠蔽の助長: エンジニアが失敗を隠そうとするようになる
心理的安全性の低下: チームメンバーが萎縮し、リスクを取れなくなる
根本原因の見落とし: 人的ミスにフォーカスし、システム的な問題を見逃す
学習機会の喪失: 組織全体が失敗から学ぶ機会を失う

非難のない文化の実践

非難のない文化では、以下の問いを立てます。

「誰が悪いのか？」ではなく「何が悪かったのか？」
「なぜミスをしたのか？」ではなく「なぜシステムはミスを防げなかったのか？」
「誰が責任を取るのか？」ではなく「どうすれば再発を防げるのか？」

人間はシステムの一部

人間のミスは、システム設計の欠陥を示すシグナルです。適切なガードレール、自動化、チェック機構があれば、多くの人的ミスは防ぐことができます。

ポストモーテムの実施タイミング

すべてのインシデントにポストモーテムが必要なわけではありません。以下の基準に該当する場合に実施します。

実施すべきケース

ユーザーに影響を与えた障害（ダウンタイム、パフォーマンス低下など）
データの損失や破損
セキュリティインシデント
SLO違反
手動での緊急対応が必要だったインシデント
他のチームや関係者に影響を与えた問題
貴重な学習機会となるインシデント

実施が推奨されるケース

ニアミス（実際には影響がなかったが、潜在的なリスクがあった）
手順書やツールの不備が発覚したケース
複数の小規模な問題が同時に発生したケース

小さなインシデントも見逃さない

小規模なインシデントでも、パターンが繰り返される場合は、より大きな問題の兆候である可能性があります。軽微なインシデントのポストモーテムも価値があります。

ポストモーテムのプロセス

1. 実施時期

インシデント解決後、できるだけ早く（通常は24〜48時間以内）に実施します。記憶が新しいうちに詳細を記録することが重要です。

2. 参加者

以下のメンバーが参加することが推奨されます。

インシデント対応者: 実際に対応したエンジニア
サービスオーナー: 該当サービスの責任者
関連チームメンバー: 影響を受けた、または関連する他のチームメンバー
ファシリテーター: 議論を中立的に進行する役割（任意）

3. 実施ステップ

ポストモーテムテンプレート

以下は、Google SRE bookで推奨されているポストモーテムテンプレートの要素です。

基本情報

項目	内容
タイトル	インシデントの簡潔な説明
日時	インシデント発生日時と解決日時
作成者	ポストモーテム作成者
ステータス	Draft / In Review / Finalized
重要度	Critical / High / Medium / Low

セクション構成

1. エグゼクティブサマリー

インシデントの概要を2〜3文で簡潔に説明します。

## エグゼクティブサマリー

2024年12月11日 10:30 JSTから12:00 JSTまで、
決済APIのレスポンスタイムが平均500msから5秒に劣化し、
約15%のトランザクションがタイムアウトしました。
根本原因はデータベース接続プールの枯渇で、
緊急でプールサイズを拡大して復旧しました。

2. インパクト

影響を受けたサービス: どのサービスや機能に影響があったか
影響範囲: ユーザー数、リージョン、顧客セグメントなど
ビジネスインパクト: 金銭的損失、評判への影響など
ダウンタイム: 合計のダウンタイムまたは劣化時間

## インパクト

- **影響を受けたサービス**: 決済API (payment-service)
- **影響範囲**: 全リージョンのユーザー（約10万アクティブユーザー）
- **失敗したトランザクション**: 約1,500件（全体の15%）
- **ダウンタイム**: 完全停止なし、パフォーマンス劣化が90分間
- **ビジネスインパクト**: 推定売上損失 約50万円
- **SLO違反**: 月次可用性99.9%のSLOに対し、0.1%のエラーバジェットを消費

3. タイムライン

時系列でインシデントの経過を記録します。すべての時刻はタイムゾーンを明記します。

## タイムライン

| 時刻 (JST) | イベント |
| :--- | :--- |
| 10:30 | Datadogアラート: 決済APIのレスポンスタイムが閾値超過 |
| 10:32 | オンコールエンジニア（田中）が確認開始 |
| 10:35 | APMで決済サービスのDB接続待機を確認 |
| 10:40 | データベース接続プールが上限に達していることを特定 |
| 10:45 | プールサイズを50から100に緊急拡大（設定変更） |
| 10:50 | 決済サービスを順次再起動 |
| 11:00 | レスポンスタイムが正常範囲に戻り始める |
| 11:30 | すべてのインスタンスが正常動作を確認 |
| 12:00 | インシデントクローズ |

4. 根本原因

5 Whys法などを用いて、根本原因を特定します。

## 根本原因

### 5 Whys分析

1. **なぜレスポンスタイムが劣化したのか？**
   → データベース接続の待機時間が長かったため

2. **なぜ接続の待機時間が長かったのか？**
   → 接続プールが枯渇し、新しい接続を取得できなかったため

3. **なぜ接続プールが枯渇したのか？**
   → トラフィックが通常の2倍に増加し、プールサイズ（50）が不足したため

4. **なぜトラフィックが増加したのか？**
   → マーケティングキャンペーンによる予期しないトラフィック急増

5. **なぜキャンペーンのトラフィック増加を予測できなかったのか？**
   → マーケティングチームとエンジニアリングチーム間のコミュニケーション不足

### 根本原因まとめ

**直接的原因**: データベース接続プールのサイズ不足

**システム的原因**: 
- トラフィック急増時の自動スケーリング機構の欠如
- キャンペーン実施前の負荷テスト未実施
- 部門間コミュニケーションプロセスの不備

5. 解決策と対応

インシデント対応中に実施した緊急措置を記録します。

## 解決策と対応

### 緊急対応

1. **接続プールサイズの拡大** (10:45)
   - 設定変更: `max_pool_size: 50 → 100`
   - 決済サービスの順次再起動

2. **不要なバッチ処理の一時停止** (10:50)
   - DB負荷軽減のため、レポート生成処理を一時停止

3. **モニタリング強化** (11:00)
   - 接続プール使用率の監視ダッシュボードを作成

6. 再発防止策

具体的で実行可能なアクションアイテムを定義します。各アイテムには担当者と期限を設定します。

## 再発防止策

### 短期施策（1週間以内）

- [ ] **接続プールの自動スケーリング実装** 
  - 担当: 田中
  - 期限: 2024年12月18日
  - 詳細: トラフィック増加時に自動でプールサイズを調整

- [ ] **接続プール使用率のアラート設定**
  - 担当: 鈴木
  - 期限: 2024年12月15日
  - 詳細: 使用率80%でWarning、90%でCriticalアラート

### 中期施策（1ヶ月以内）

- [ ] **マーケティングキャンペーン事前通知プロセスの策定**
  - 担当: 佐藤（マーケティング）、田中（SRE）
  - 期限: 2025年1月10日
  - 詳細: キャンペーン実施2週間前に通知し、負荷テストを実施

- [ ] **自動負荷テストの導入**
  - 担当: 山田
  - 期限: 2025年1月15日
  - 詳細: 本番環境想定の負荷テストをCI/CDパイプラインに組み込む

### 長期施策（3ヶ月以内）

- [ ] **データベース接続のサーキットブレーカー実装**
  - 担当: 高橋
  - 期限: 2025年3月1日
  - 詳細: 障害時の部分的なサービス提供を可能にする

- [ ] **キャパシティプランニングプロセスの確立**
  - 担当: SREチーム全体
  - 期限: 2025年3月15日
  - 詳細: 四半期ごとのキャパシティレビューと予測

7. 学んだこと（Lessons Learned）

うまくいったこと: 迅速な原因特定、効果的なエスカレーション手順など
改善できること: モニタリング、アラート、手順書、コミュニケーションなど
幸運だったこと: より悪い事態にならなかった理由

## 学んだこと

### うまくいったこと ✅

- オンコールエンジニアが迅速に対応を開始（2分以内）
- APMツール（Datadog）により、原因箇所を素早く特定できた
- 手順書に沿った再起動手順により、安全に復旧できた

### 改善できること 🔧

- 接続プール使用率のモニタリングが不十分だった
- キャンペーンによるトラフィック増加を事前に把握できていなかった
- 自動スケーリング機構が未実装だった

### 幸運だったこと 🍀

- ピークタイム外での発生だったため、影響が限定的だった
- 完全なダウンタイムではなく、劣化にとどまった
- データの損失や破損は発生しなかった

8. 参考情報

関連するログ、メトリクス、グラフ、ドキュメントへのリンクを記載します。

## 参考情報

- [Datadogダッシュボード（インシデント時）](https://app.datadoghq.com/dashboard/xxx)
- [Slackインシデントチャンネル](https://slack.com/archives/C12345678)
- [PagerDutyインシデント](https://example.pagerduty.com/incidents/P123456)
- [関連するCode Change (PR #1234)](https://github.com/org/repo/pull/1234)

根本原因分析の手法

5 Whys（5回のなぜ）

最もシンプルで効果的な手法です。「なぜ？」を繰り返すことで、表面的な原因から根本原因を掘り下げます。

ポイント:

最低5回「なぜ？」を繰り返す（状況によっては3回または7回でも可）
各回答が論理的につながっているか確認する
人ではなくシステムやプロセスに焦点を当てる

フィッシュボーン図（特性要因図）

複数の要因が絡む複雑なインシデントに有効です。

タイムライン分析

時系列に沿って事象を整理し、どの時点で何が起こったかを可視化します。

ポストモーテムのベストプラクティス

1. タイムリーに実施する

インシデント解決後、できるだけ早く（24〜48時間以内）に実施します。

2. 事実に基づく

推測や憶測を避ける
ログ、メトリクス、証拠に基づいて記述する
不明な点は「不明」と明記する

3. 具体的で実行可能なアクションを定義する

悪い例（曖昧）:

「モニタリングを改善する」
「コミュニケーションを強化する」

良い例（具体的）:

「接続プール使用率80%で警告アラートを設定する（担当: 田中、期限: 12/15）」
「マーケティングキャンペーン2週間前に通知する運用フローを策定する（担当: 佐藤、期限: 1/10）」

4. 全員が参加できる環境を作る

心理的安全性を確保する
すべての意見を尊重する
ファシリテーターを立てて中立的に進行する

5. 広く共有する

ポストモーテムは組織全体の学習資産
社内Wikiやドキュメントリポジトリに公開する
定期的に過去のポストモーテムをレビューする

6. アクションアイテムを追跡する

各アイテムに担当者と期限を設定
進捗を定期的に確認
完了したら必ずクローズする

アクションアイテムの追跡

ポストモーテムの最大の失敗は、アクションアイテムが実行されないことです。JIRAやGitHub Issuesなどのトラッキングツールを活用し、必ず完了まで追跡しましょう。

7. 成功も祝う

うまくいったことも記録する
チームの迅速な対応を評価する
改善の成果を可視化する

ポストモーテムの保管と活用

ドキュメント管理

一元管理: Confluence、Notion、GitHub Wikiなど、アクセスしやすい場所に保管
検索可能: タグやカテゴリで分類し、検索しやすくする
バージョン管理: 更新履歴を残す

定期的なレビュー

四半期ごとに過去のポストモーテムをレビュー
パターンや傾向を分析
組織レベルの改善につなげる

メトリクスの追跡

ポストモーテム作成数
アクションアイテム完了率
MTTR（平均修復時間）の推移
同様のインシデントの再発率

実践例：Googleのポストモーテム文化

Googleでは、ポストモーテムは日常的に実施される重要なプロセスです。

特徴

公開が原則: 組織全体に公開され、誰でもアクセスできる
褒賞制度: 優れたポストモーテムは社内で表彰される
学習リソース: 新入社員のトレーニング教材としても活用
データ駆動: ポストモーテムから得られたデータで改善を推進

効果

インシデント対応時間の短縮
同様の問題の再発防止
チーム全体の技術力向上
組織のレジリエンス強化

Googleの「Non-Abstract Large System Design (NALSD)」面接

Googleの面接では、過去のポストモーテムで学んだ教訓が、システム設計の質問で活かされることがあります。ポストモーテムは個人のキャリア成長にも貢献します。

よくある失敗パターンと対策

失敗パターン1: 個人を責める

問題: 「〇〇さんが間違ったコマンドを実行したため」

対策: 「不適切なコマンドを実行できてしまうシステムの欠陥」と捉え、ガードレールやレビュープロセスを追加する

失敗パターン2: 曖昧なアクションアイテム

問題: 「今後気をつける」「もっと注意する」

対策: 具体的な技術的改善策を定義する（自動化、アラート追加、手順書改訂など）

失敗パターン3: アクションアイテムの未実施

問題: ポストモーテムを書いただけで満足し、改善が実施されない

対策: トラッキングツールで管理し、定期的に進捗をレビューする

失敗パターン4: 時間をかけすぎる

問題: 完璧なポストモーテムを書こうとして、数週間かかる

対策: 最初はドラフトでOK。重要なのはタイムリーに実施し、アクションを起こすこと

失敗パターン5: 共有しない

問題: 特定のチームだけで完結し、組織全体に共有されない

対策: 社内Wikiに公開し、関連チームに通知する

チェックリスト

以下のチェックリストを使って、ポストモーテムの質を確認しましょう。

まとめ

ポストモーテムは、SREにおける最も重要なプラクティスの一つです。

重要なポイント

非難のない文化: 個人ではなくシステムの問題に焦点を当てる
タイムリーな実施: インシデント解決後、できるだけ早く実施する
具体的なアクション: 実行可能で追跡可能な改善策を定義する
組織学習: 知見を共有し、チーム全体のレジリエンスを高める
継続的改善: アクションアイテムを完了まで追跡する

ポストモーテムを通じて、組織は失敗から学び、より堅牢で信頼性の高いシステムを構築することができます。「失敗は終わりではなく、学習の始まり」という文化を醸成することが、SREの成功の鍵です。

ポストモーテムとは​

目的​

非難のない文化（Blameless Culture）​

なぜ非難しないのか​

非難のない文化の実践​

ポストモーテムの実施タイミング​

実施すべきケース​

実施が推奨されるケース​

ポストモーテムのプロセス​

1. 実施時期​

2. 参加者​

3. 実施ステップ​

ポストモーテムテンプレート​

基本情報​

セクション構成​

1. エグゼクティブサマリー​

2. インパクト​

3. タイムライン​

4. 根本原因​

5. 解決策と対応​

6. 再発防止策​

7. 学んだこと（Lessons Learned）​

8. 参考情報​

根本原因分析の手法​

5 Whys（5回のなぜ）​

フィッシュボーン図（特性要因図）​

タイムライン分析​

ポストモーテムのベストプラクティス​

1. タイムリーに実施する​

2. 事実に基づく​

3. 具体的で実行可能なアクションを定義する​

4. 全員が参加できる環境を作る​

5. 広く共有する​

6. アクションアイテムを追跡する​

7. 成功も祝う​

ポストモーテムの保管と活用​

ドキュメント管理​

定期的なレビュー​

メトリクスの追跡​

実践例：Googleのポストモーテム文化​

特徴​

効果​

よくある失敗パターンと対策​

失敗パターン1: 個人を責める​

失敗パターン2: 曖昧なアクションアイテム​

失敗パターン3: アクションアイテムの未実施​

失敗パターン4: 時間をかけすぎる​

失敗パターン5: 共有しない​

チェックリスト​

まとめ​

重要なポイント​

参考資料​