postmortem

Postmortem

References: Google "Site Reliability Engineering" Chapter 15, Etsy Just Culture, PagerDuty Postmortem Guide.

Applicable Scenarios

• After a P1 / P2 incident (required)
• P3 incident (optional, when there is learning value)
• Recurring problems
• "Near Miss"

Core Principles

1. Blameless（不追责）
   追流程不追人
   "为什么系统允许这个错误发生？"

1. Complete within 24–72 hours Write while memories are fresh

2. Must have improvement items A postmortem without Action Items = no postmortem

3. Improvement items must be tracked Owner + deadline + status

4. Open and transparent Visible to the whole team (learning)

5. 5 Whys to find root cause Don't stop at the surface

## 复盘流程

```text
1. 事故关闭后 24 小时内
   - IC 发起复盘
   - 收集时间线 + 日志 + 指标
   ↓
2. 写 Postmortem 文档
   - 用模板
   - 时间线精确到分钟
   - 5 Whys 根因分析
   ↓
3. 复盘会议（30~60 分钟）
   - 参与人：IC + 相关工程师 + PM
   - 走时间线
   - 讨论根因
   - 确定改进项
   ↓
4. 改进项分配
   - 每项有负责人 + 截止时间
   - 录入 Jira / Linear
   ↓
5. 跟踪
   - 每周检查改进项状态
   - 下次复盘回看上次改进项
   ↓
6. 沉淀
   - field-journal
   - Runbook 更新
   - 告警规则更新
   - pitfalls 更新

5 Whys Method

规则：
  - 每个 Why 必须有证据
  - 不停在"人犯了错"
  - 追到系统 / 流程层面

示例：
  Why 1：用户无法登录
  Why 2：认证服务返回 500
  Why 3：Redis 连接超时
  Why 4：Redis 内存满了
  Why 5：没有配置 maxmemory-policy（淘汰策略）

  根因：Redis 配置缺失 + 没有内存告警
  
  不是根因：
  ❌ "运维忘了配置"（追责）
  ✅ "配置检查清单缺少 Redis 内存策略项"（流程）

Improvement Item Categories

1. 检测改进（更早发现）
   - 新增告警规则
   - 降低告警阈值
   - 增加监控覆盖

2. 预防改进（不再发生）
   - 代码修复
   - 配置修复
   - 流程改进
   - 自动化检查

3. 缓解改进（影响更小）
   - 降级方案
   - 限流
   - 灾备切换
   - 回滚加速

4. 响应改进（恢复更快）
   - Runbook 更新
   - 告警路由优化
   - 升级路径优化

Supporting Templates

• templates/postmortem-template.md — Complete Postmortem document (summary + timeline + 5 Whys + improvement items)

Quality Self-Check

□ 24~72 小时内完成
□ 时间线精确到分钟
□ 5 Whys 到系统层面
□ 不追责
□ 改进项有负责人 + 截止
□ 改进项可执行（不是"加强注意"）
□ 公开透明
□ 沉淀到 field-journal
□ Runbook 更新
□ 告警规则更新

Common Pitfalls

1. Assigning blame—"Who deployed it?" → the team becomes afraid to report
2. 5 Whys stops at the surface—"The code has a Bug" is not a root cause
3. Improvement items too broad—"Strengthen monitoring" is not actionable
4. Improvement items not tracked—Forgotten as soon as they are written
5. No meeting—Only writing a document without discussion
6. Procrastination—Writing 2 weeks later, with fuzzy memories
7. Not made public—Only the people involved know
8. No review—No one checks the previous improvement items

Collaboration with Other Skills

上游：
  incident-response → 事故记录

下游：
  on-call-runbook → Runbook 更新
  reliability-engineering → SLO / 错误预算调整
  field-journal → 经验沉淀
  devops-engineer monitoring-alerting → 告警改进