ポストモーテム執筆

組織の学習を促進し、インシデント再発を防ぐ効果的でセーフな文化を築くポストモーテム執筆の包括的ガイド。

このスキルをいつ使うか

• インシデント後のレビュー実施
• ポストモーテム文書の作成
• セーフなポストモーテム会議の進行
• 根本原因と関連要因の特定
• 実行可能なフォローアップアイテムの作成
• 組織学習文化の構築

コアコンセプト

1. セーフな文化

責任追及型	セーフ型
「誰が原因か？」	「どの条件がこれを許したのか？」
「誰かが間違いを起こした」	「システムが間違いを許した」
個人を罰する	システムを改善する
情報を隠す	学習を共有する
発言への恐怖	心理的安全性

2. ポストモーテムトリガー

• SEV1 または SEV2 インシデント
• カスタマー向けの15分以上の障害
• データ損失またはセキュリティインシデント
• 深刻になる可能性があった未然防止案件
• 新規の障害パターン
• 通常と異なる対応が必要なインシデント

クイックスタート

ポストモーテムタイムライン

Day 0: インシデント発生
Day 1-2: ポストモーテム文書のドラフト作成
Day 3-5: ポストモーテム会議
Day 5-7: 文書の最終化、チケット作成
Week 2+: アクションアイテム完了
Quarterly: インシデント全体のパターン確認

テンプレート

テンプレート1: 標準ポストモーテム

# Postmortem: [Incident Title]

**Date**: 2024-01-15
**Authors**: @alice, @bob
**Status**: Draft | In Review | Final
**Incident Severity**: SEV2
**Incident Duration**: 47 minutes

## Executive Summary

2024年1月15日、決済処理サービスが47分間の障害を経験し、約12,000人のカスタマーが影響を受けました。根本原因はデプロイメント v2.3.4 での設定変更がきっかけとなったデータベース接続プール枯渇でした。インシデントは v2.3.3 へのロールバックと接続プール制限の増加で解決されました。

**Impact**:

- 12,000人のカスタマーが購入完了不可
- 推定売上損失: $45,000
- 847件のサポートチケット作成
- データ損失またはセキュリティ上の影響なし

## Timeline (All times UTC)

| Time  | Event                                           |
| ----- | ----------------------------------------------- |
| 14:23 | Deployment v2.3.4 completed to production       |
| 14:31 | First alert: `payment_error_rate > 5%`          |
| 14:33 | On-call engineer @alice acknowledges alert      |
| 14:35 | Initial investigation begins, error rate at 23% |
| 14:41 | Incident declared SEV2, @bob joins              |
| 14:45 | Database connection exhaustion identified       |
| 14:52 | Decision to rollback deployment                 |
| 14:58 | Rollback to v2.3.3 initiated                    |
| 15:10 | Rollback complete, error rate dropping          |
| 15:18 | Service fully recovered, incident resolved      |

## Root Cause Analysis

### What Happened

v2.3.4 デプロイメントにはデータベースクエリパターンの変更が含まれており、頻繁に呼び出されるエンドポイントの接続プールが意図せず削除されていました。各リクエストがプールされた接続を再利用する代わりに、新しいデータベース接続を開いていました。

### Why It Happened

1. **直接原因**: `PaymentRepository.java` のコード変更がプールされた `DataSource` を直接 `DriverManager.getConnection()` 呼び出しで置き換えた。

2. **関連要因**:
   - コードレビューが接続ハンドリング変更を見逃した
   - 接続プール動作に特化した統合テストがない
   - ステージング環境は低いトラフィックでこの問題をマスクしていた
   - データベース接続メトリクス警告閾値が高すぎた (90%)

3. **5 Whys分析**:
   - なぜサービスが失敗したのか？ → データベース接続が枯渇
   - なぜ接続が枯渇したのか？ → 各リクエストが新しい接続を開いた
   - なぜ各リクエストが新しい接続を開いたのか？ → コードが接続プールをバイパスした
   - なぜコードが接続プールをバイパスしたのか？ → 開発者がコードベースパターンに不慣れ
   - なぜ開発者が不慣れだったのか？ → 接続管理パターンのドキュメントがない

### System Diagram

[Client] → [Load Balancer] → [Payment Service] → [Database] ↓ Connection Pool (broken) ↓ Direct connections (cause)

## Detection

### What Worked
- エラーレートアラートがデプロイメント後8分以内に発火
- Grafana ダッシュボードが接続スパイクを明確に表示
- オンコール対応が迅速 (2分の確認応答)

### What Didn't Work
- データベース接続メトリクス警告閾値が高すぎた
- デプロイメント相関アラートがない
- カナリアデプロイメントはこれを早期に捕捉したはず

### Detection Gap
デプロイメントが 14:23 に完了しましたが、最初のアラートは 14:31 に発火しました (8分)。デプロイメント対応アラートはより高速に検出できたはずです。

## Response

### What Worked
- オンコールエンジニアが素早くデータベースを問題として特定
- ロールバック決定が決定的
- インシデントチャネルでの明確なコミュニケーション

### What Could Be Improved
- 問題と最近のデプロイメントの関連性を特定するのに10分かかった
- デプロイメント履歴の確認が手動だった
- ロールバックに12分かかった (より高速化できる)

## Impact

### Customer Impact
- 12,000人のユニークなカスタマーが影響を受けた
- 平均影響時間: 35分
- 847件のサポートチケット (影響を受けたユーザーの23%)
- カスタマー満足度スコアが12ポイント低下

### Business Impact
- 推定売上損失: $45,000
- サポートコスト: ~$2,500 (エージェント時間)
- エンジニアリング時間: ~8人時間

### Technical Impact
- データベースプライマリが昇圧負荷を経験
- インシデント中に一部レプリカラグが発生
- システムへの永続的なダメージはなし

## Lessons Learned

### What Went Well
1. アラートがカスタマーレポート前に問題を検出
2. チーム圧力下での効果的なコラボレーション
3. ロールバック手順が順調に機能
4. コミュニケーションが明確でタイムリー

### What Went Wrong
1. コードレビューが重要な変更を見逃した
2. 接続プール用のテストカバレッジギャップ
3. ステージング環境が本番トラフィックを反映していない
4. アラート閾値が適切にチューニングされていない

### Where We Got Lucky
1. インシデントが営業時間中に完全なチームが利用可能な時に発生
2. データベースが完全に失敗することなく負荷を処理
3. 同時に他のインシデントが発生しなかった

## Action Items

| Priority | Action | Owner | Due Date | Ticket |
|----------|--------|-------|----------|--------|
| P0 | 接続プール動作の統合テストを追加 | @alice | 2024-01-22 | ENG-1234 |
| P0 | データベース接続アラート閾値を70%に低減 | @bob | 2024-01-17 | OPS-567 |
| P1 | 接続管理パターンをドキュメント化 | @alice | 2024-01-29 | DOC-89 |
| P1 | デプロイメント相関アラートを実装 | @bob | 2024-02-05 | OPS-568 |
| P2 | カナリアデプロイメント戦略を評価 | @charlie | 2024-02-15 | ENG-1235 |
| P2 | 本番類似トラフィックでステージングをロードテスト | @dave | 2024-02-28 | QA-123 |

## Appendix

### Supporting Data

#### Error Rate Graph
[Link to Grafana dashboard snapshot]

#### Database Connection Graph
[Link to metrics]

### Related Incidents
- 2023-11-02: User Service での類似接続問題 (POSTMORTEM-42)

### References
- [Connection Pool Best Practices](internal-wiki/connection-pools)
- [Deployment Runbook](internal-wiki/deployment-runbook)

テンプレート2: 5 Whys分析

# 5 Whys Analysis: [Incident]

## Problem Statement

決済サービスがデータベース接続枯渇による47分間の障害を経験しました。

## Analysis

### Why #1: なぜサービスが失敗したのか？

**Answer**: データベース接続が枯渇し、すべての新しいリクエストが失敗しました。

**Evidence**: メトリクスが接続数 100/100 (最大値)、500+個のペンディング要求を示しました。

---

### Why #2: なぜデータベース接続が枯渇したのか？

**Answer**: 接続プールを使用する代わりに、各受信リクエストが新しいデータベース接続を開きました。

**Evidence**: コード差分は直接 `DriverManager.getConnection()` をプール化された `DataSource` の代わりに使用していることを示しています。

---

### Why #3: なぜコードが接続プールをバイパスしたのか？

**Answer**: 開発者がリポジトリクラスをリファクタリングし、意図せずに接続取得方法を変更しました。

**Evidence**: PR #1234 は変更を示しており、別のバグ修正中に実施されました。

---

### Why #4: なぜこれがコードレビューで捕捉されなかったのか？

**Answer**: レビュアーが関数的変更 (バグ修正) に焦点を当て、インフラストラクチャ変更に気づきませんでした。

**Evidence**: レビューコメントはビジネスロジックのみを議論しています。

---

### Why #5: なぜこのタイプの変更のセーフティネットがないのか？

**Answer**: 接続プール動作を検証する自動テストがなく、接続パターンについてのドキュメントがありません。

**Evidence**: テストスイートには接続ハンドリング用のテストがなく、ウィキに関連記事がありません。

## Root Causes Identified

1. **Primary**: インフラストラクチャ動作の自動テスト欠落
2. **Secondary**: アーキテクチャパターンのドキュメント不足
3. **Tertiary**: コードレビューチェックリストにインフラストラクチャ考慮事項が含まれていない

## Systemic Improvements

| Root Cause    | Improvement                       | Type       |
| ------------- | --------------------------------- | ---------- |
| テスト欠落     | インフラストラクチャ動作テストを追加 | Prevention |
| ドキュメント欠落 | 接続パターンをドキュメント化 | Prevention |
| レビュー間隙   | レビューチェックリストを更新   | Detection  |
| カナリアなし   | カナリアデプロイメントを実装   | Mitigation |

テンプレート3: クイックポストモーテム (軽微なインシデント)

# Quick Postmortem: [Brief Title]

**Date**: 2024-01-15 | **Duration**: 12 min | **Severity**: SEV3

## What Happened

キャッシュ削除後のキャッシュミスストームによりAPI遅延が5秒にスパイク。

## Timeline

- 10:00 - 設定更新のためキャッシュをフラッシュ開始
- 10:02 - 遅延アラートが発火
- 10:05 - キャッシュミスストームとして特定
- 10:08 - キャッシュウォーミングを有効化
- 10:12 - 遅延が正常化

## Root Cause

軽微な設定更新のための完全キャッシュフラッシュが雷群を引き起こした。

## Fix

- 即時: キャッシュウォーミングを有効化
- 長期: 部分的キャッシュ無効化を実装 (ENG-999)

## Lessons

本番環境で完全フラッシュを実施しないでください。代わりに対象とした無効化を使用します。

ファシリテーションガイド

ポストモーテム会議の実施

## Meeting Structure (60 minutes)

### 1. Opening (5 min)

- セーフな文化の重要性を思い出させる
- 「私たちは学ぶためにここにいるのであって、責任を追及するためではありません」
- 会議の規範をレビュー

### 2. Timeline Review (15 min)

- 時系列で出来事をウォークスルー
- 明確化に関する質問をする
- タイムライン内のギャップを特定

### 3. Analysis Discussion (20 min)

- 何が失敗したか？
- なぜ失敗したか？
- これを許した条件は何か？
- これを防いだはずのものは？

### 4. Action Items (15 min)

- 改善をブレインストーミング
- 影響と努力で優先順位付け
- 責任者と期限を割り当て

### 5. Closing (5 min)

- 主な学習をまとめる
- アクションアイテム責任者を確認
- 必要に応じてフォローアップをスケジュール

## Facilitation Tips

- 議論をトラックに保つ
- 責任をシステムにリダイレクト
- 静かな参加者に励ましを与える
- 異議を唱える見方をドキュメント化
- 脱線を時間制限

避けるべきアンチパターン

Anti-Pattern	Problem	Better Approach
責任追及ゲーム	学習をシャットダウン	システムに焦点を当てる
浅い分析	再発を防ばない	「なぜ」を5回問う
アクションアイテムなし	時間の無駄	常に具体的な次のステップを用意
非現実的なアクション	完了されない	達成可能なタスクにスコープを絞る
フォローアップなし	アクションが忘れられる	チケットシステムで追跡

ベストプラクティス

Do's

• すぐに開始 - 記憶は速く薄れる
• 具体的に - 正確な時間、正確なエラー
• グラフを含める - 視覚的証拠
• 責任者を割り当てる - 孤児アクションアイテムなし
• 広く共有 - 組織学習

Don'ts

• 名指しと恥晒しをしないでください - 絶対に
• 小さなインシデントをスキップしないでください - パターンを明らかにします
• 責任追及文書にしないでください - それは学習を殺します
• 忙しい仕事を作らないでください - アクションは意味があるべきです
• フォローアップをスキップしないでください - アクション完了を検証します