postmortem-writing

ポストモーテムの作成

組織的な学習を促進し、インシデントの再発を防ぐ、効果的で非難のないポストモーテムを作成するための包括的なガイドです。

このスキルを使用する場面

• インシデント後のレビューを実施するとき
• ポストモーテム文書を作成するとき
• 非難のないポストモーテム会議を進行するとき
• 根本原因と寄与要因を特定するとき
• 実行可能なフォローアップ項目を作成するとき
• 組織的な学習文化を構築するとき

中核となる概念

1. 非難のない文化

非難を重視する姿勢	非難のない姿勢
「誰がこれを引き起こしたのか?」	「どのような状況がこれを許したのか?」
「誰かがミスをした」	「システムがこのミスを許した」
個人を罰する	システムを改善する
情報を隠す	学びを共有する
発言することへの恐れ	心理的安全性

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

• SEV1 または SEV2 のインシデント
• 顧客に影響する 15 分を超える停止
• データ損失またはセキュリティインシデント
• 深刻になり得たヒヤリハット
• 前例のない障害モード
• 通常とは異なる介入を要したインシデント

クイックスタート

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

Day 0: Incident occurs
Day 1-2: Draft postmortem document
Day 3-5: Postmortem meeting
Day 5-7: Finalize document, create tickets
Week 2+: Action item completion
Quarterly: Review patterns across incidents

テンプレートと詳細な実施例

テンプレートの完全なライブラリと詳細な実施例は references/details.md にあります。具体的なテンプレートが必要なときは、そのファイルを読んでください。

テンプレート 2: なぜなぜ分析 (5 Whys)

# 5 Whys Analysis: [Incident]

## Problem Statement

Payment service experienced 47-minute outage due to database connection exhaustion.

## Analysis

### Why #1: Why did the service fail?

**Answer**: Database connections were exhausted, causing all new requests to fail.

**Evidence**: Metrics showed connection count at 100/100 (max), with 500+ pending requests.

---

### Why #2: Why were database connections exhausted?

**Answer**: Each incoming request opened a new database connection instead of using the connection pool.

**Evidence**: Code diff shows direct `DriverManager.getConnection()` instead of pooled `DataSource`.

---

### Why #3: Why did the code bypass the connection pool?

**Answer**: A developer refactored the repository class and inadvertently changed the connection acquisition method.

**Evidence**: PR #1234 shows the change, made while fixing a different bug.

---

### Why #4: Why wasn't this caught in code review?

**Answer**: The reviewer focused on the functional change (the bug fix) and didn't notice the infrastructure change.

**Evidence**: Review comments only discuss business logic.

---

### Why #5: Why isn't there a safety net for this type of change?

**Answer**: We lack automated tests that verify connection pool behavior and lack documentation about our connection patterns.

**Evidence**: Test suite has no tests for connection handling; wiki has no article on database connections.

## Root Causes Identified

1. **Primary**: Missing automated tests for infrastructure behavior
2. **Secondary**: Insufficient documentation of architectural patterns
3. **Tertiary**: Code review checklist doesn't include infrastructure considerations

## Systemic Improvements

| Root Cause    | Improvement                       | Type       |
| ------------- | --------------------------------- | ---------- |
| Missing tests | Add infrastructure behavior tests | Prevention |
| Missing docs  | Document connection patterns      | Prevention |
| Review gaps   | Update review checklist           | Detection  |
| No canary     | Implement canary deployments      | Mitigation |

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

# Quick Postmortem: [Brief Title]

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

## What Happened

API latency spiked to 5s due to cache miss storm after cache flush.

## Timeline

- 10:00 - Cache flush initiated for config update
- 10:02 - Latency alerts fire
- 10:05 - Identified as cache miss storm
- 10:08 - Enabled cache warming
- 10:12 - Latency normalized

## Root Cause

Full cache flush for minor config update caused thundering herd.

## Fix

- Immediate: Enabled cache warming
- Long-term: Implement partial cache invalidation (ENG-999)

## Lessons

Don't full-flush cache in production; use targeted invalidation.

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

ポストモーテム会議の進行

## Meeting Structure (60 minutes)

### 1. Opening (5 min)

- Remind everyone of blameless culture
- "We're here to learn, not to blame"
- Review meeting norms

### 2. Timeline Review (15 min)

- Walk through events chronologically
- Ask clarifying questions
- Identify gaps in timeline

### 3. Analysis Discussion (20 min)

- What failed?
- Why did it fail?
- What conditions allowed this?
- What would have prevented it?

### 4. Action Items (15 min)

- Brainstorm improvements
- Prioritize by impact and effort
- Assign owners and due dates

### 5. Closing (5 min)

- Summarize key learnings
- Confirm action item owners
- Schedule follow-up if needed

## Facilitation Tips

- Keep discussion on track
- Redirect blame to systems
- Encourage quiet participants
- Document dissenting views
- Time-box tangents

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

アンチパターン	問題点	より良いアプローチ
責任追及	学習を止めてしまう	システムに焦点を当てる
浅い分析	再発を防げない	「なぜ」を 5 回問う
アクション項目がない	時間の無駄	常に具体的な次のステップを用意する
非現実的なアクション	決して完了しない	達成可能なタスクに絞る
フォローアップがない	アクションが忘れられる	チケットシステムで追跡する

ベストプラクティス

やるべきこと

• すぐに始める - 記憶は急速に薄れる
• 具体的にする - 正確な時刻、正確なエラー
• グラフを含める - 視覚的な証拠
• 担当者を割り当てる - 放置されたアクション項目を作らない
• 広く共有する - 組織的な学習

やってはいけないこと

• 名指しで辱めない - 決して
• 小さなインシデントを飛ばさない - それらはパターンを明らかにする
• 責任追及の文書にしない - それは学習を殺す
• 無駄な作業を作らない - アクションは意味のあるものであるべき
• フォローアップを飛ばさない - アクションが完了したことを確認する