线上事故复盘的正确姿势
事故复盘的价值取决于问的问题。问「谁的错」会得到沉默，问「系统为什么允许这个错误发生」才会得到改进。
无指责原则（Blameless）
人的失误是常态：疲劳、上下文切换、信息不全都会导致操作错误。健全的系统应该让「普通人在普通状态下」也不至于酿成大祸。复盘问的是：
- 什么条件让这个错误成为可能？
- 什么机制能让它更早被发现？
- 什么防线能让它的影响更小？
点名追责的复盘，下一次大家的第一反应是隐瞒和粉饰——损失的是最宝贵的信息。
复盘文档的骨架
1. 事故摘要：影响（多少用户、多久、什么功能）、发现方式（用户反馈还是监控）、恢复时间。
2. 时间线：按分钟记录。动作与信息分开写：
14:02 监控告警 P1：下单成功率 82%（阈值 95%）
14:05 值班响应，看到 FPM worker 打满
14:12 确认为 14:00 发布的 v2.3.1 引入，决定回滚
14:18 回滚完成，成功率恢复
时间线的价值在于暴露响应延迟：从告警到响应 3 分钟合理，从发现到决策 7 分钟就值得讨论。
3. 根因分析：追问到流程层面。技术原因是「N+1 查询」，流程原因是「上线前的压测没有覆盖这个查询路径」。前者只解释这一次，后者解释一类。
4. 改进项：每条要有负责人和期限，并区分类型：
| 类型 | 示例 | 特点 |
|---|---|---|
| 预防 | 压测纳入发布门禁 | 防复发 |
| 检测 | 该路径补监控与告警 | 缩短发现时间 |
| 缓解 | 限流/降级预案 | 缩小影响 |
| 修复效率 | 一键回滚脚本 | 缩短恢复时间 |
只写「加强 code review」这种无法验收的改进项，等于没有改进项。
5. 遗留风险：这次没解决、明确接受的。
检验复盘质量的两问
- 同类问题复发的可能性降低了吗？（改进项落地了吗）
- 下次类似事故，发现和恢复的时间会更短吗？
把每次复盘的改进项放进同一个看板追踪，季度回顾完成率。事故会过去，复盘沉淀下来的规则才是资产。