zhaoxuya520 事后复盘（Postmortem）
参考来源：Google《Site Reliability Engineering》Chapter 15、Etsy Just Culture、PagerDuty Postmortem Guide。
适用场景
- P1 / P2 事故后（必做）
- P3 事故（可选，有学习价值时）
- 重复发生的问题
- "差点出事"（Near Miss）
核心原则
1. Blameless（不追责）
追流程不追人
"为什么系统允许这个错误发生？"
2. 24~72 小时内完成
记忆新鲜时写
3. 必须有改进项
没有 Action Items 的复盘 = 没复盘
4. 改进项必须跟踪
有负责人 + 截止时间 + 状态
5. 公开透明
团队都能看到（学习）
6. 5 Whys 找根因
不停在表面
复盘流程
1. 事故关闭后 24 小时内
- IC 发起复盘
- 收集时间线 + 日志 + 指标
↓
2. 写 Postmortem 文档
- 用模板
- 时间线精确到分钟
- 5 Whys 根因分析
↓
3. 复盘会议（30~60 分钟）
- 参与人：IC + 相关工程师 + PM
- 走时间线
- 讨论根因
- 确定改进项
↓
4. 改进项分配
- 每项有负责人 + 截止时间
- 录入 Jira / Linear
↓
5. 跟踪
- 每周检查改进项状态
- 下次复盘回看上次改进项
↓
6. 沉淀
- field-journal
- Runbook 更新
- 告警规则更新
- pitfalls 更新
5 Whys 方法
规则：
- 每个 Why 必须有证据
- 不停在"人犯了错"
- 追到系统 / 流程层面
示例：
Why 1：用户无法登录
Why 2：认证服务返回 500
Why 3：Redis 连接超时
Why 4：Redis 内存满了
Why 5：没有配置 maxmemory-policy（淘汰策略）
根因：Redis 配置缺失 + 没有内存告警
不是根因：
❌ "运维忘了配置"（追责）
✅ "配置检查清单缺少 Redis 内存策略项"（流程）
改进项分类
1. 检测改进（更早发现）
- 新增告警规则
- 降低告警阈值
- 增加监控覆盖
2. 预防改进（不再发生）
- 代码修复
- 配置修复
- 流程改进
- 自动化检查
3. 缓解改进（影响更小）
- 降级方案
- 限流
- 灾备切换
- 回滚加速
4. 响应改进（恢复更快）
- Runbook 更新
- 告警路由优化
- 升级路径优化
配套模板
templates/postmortem-template.md— 完整 Postmortem 文档（摘要 + 时间线 + 5 Whys + 改进项）
质量自检
□ 24~72 小时内完成
□ 时间线精确到分钟
□ 5 Whys 到系统层面
□ 不追责
□ 改进项有负责人 + 截止
□ 改进项可执行（不是"加强注意"）
□ 公开透明
□ 沉淀到 field-journal
□ Runbook 更新
□ 告警规则更新
常见坑
- 追责——"谁部署的？"→ 团队不敢报告
- 5 Whys 停在表面——"代码有 Bug"不是根因
- 改进项太宽泛——"加强监控"不可执行
- 改进项不跟踪——写完就忘
- 不开会——只写文档没讨论
- 拖延——2 周后才写，记忆模糊
- 不公开——只有当事人知道
- 不回看——上次改进项没人检查
与其他 skill 的协作
上游：
incident-response → 事故记录
下游：
on-call-runbook → Runbook 更新
reliability-engineering → SLO / 错误预算调整
field-journal → 经验沉淀
devops-engineer monitoring-alerting → 告警改进