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 次“为什么”
没有行动项	浪费时间	始终要有具体的后续步骤
不切实际的行动	永远无法完成	将范围限定在可实现的任务内
没有跟进	行动被遗忘	在工单系统中跟踪

最佳实践

应做

• 立即开始 - 记忆消退得很快
• 具体明确 - 确切时间、确切错误
• 包含图表 - 可视化证据
• 指派负责人 - 不留下无主行动项
• 广泛分享 - 组织学习

不应做

• 不要点名羞辱 - 永远不要
• 不要跳过小事故 - 它们会揭示模式
• 不要把它变成指责文档 - 那会扼杀学习
• 不要制造无效忙碌 - 行动应当有意义
• 不要跳过跟进 - 验证行动已完成