线上出问题之后，团队的反应通常是赶紧修，修完松一口气，然后进入下一个需求。过几个月类似的问题再来一次，大家才想起来上次好像也这样。复盘的价值就在这里：把一次性的记忆变成团队的知识。
时间线与影响面
时间线要写事实，不写感受。每一行是时间和事件，精确到分钟。
- 14:02 监控首次告警，接口错误率超过阈值
- 14:05 值班同学确认告警，开始排查
- 14:18 定位到数据库连接池耗尽
- 14:26 扩容实例，错误率回落
- 14:40 确认恢复，关闭事件
时间线里要标出两个关键点：故障开始的时间，和发现的时间。两者之间的差值就是检测能力的问题，比修复速度更值得关注。
影响面用可量化的方式写：多少用户、多长时间、哪些功能不可用、有没有数据丢失或错乱。不要写部分用户受影响，这种表述没有信息量。如果拿不到精确数字，就写估算方法和区间，并说明误差来源。诚实的估算比一个看起来精确的假数字有用。
根因与触发条件
这两件事要分开。根因是系统里长期存在的缺陷，触发条件是让它显形的那个事件。
举个例子。根因是连接池没有上限，触发条件是一次营销活动带来的流量峰值。只写流量太大，等于什么都没说，因为流量总会有峰值，而缺陷一直都在。
我习惯追问几层：为什么会耗尽，因为查询变慢；为什么变慢，因为少了一个索引；为什么少索引，因为上线时没走慢查询评审。问到能落地行动的那一层停下。
行动项
- 每项都有负责人和日期，不写尽快
- 区分止血项和根治项，止血项先做
- 优先选能自动发现同类问题的措施，比如加监控和断言
- 行动项不超过五条，多了就没人跟
我见过一份复盘列了十七条行动项，三个月后完成两条。数量本身不是成果。
别让它变成甩锅
复盘跑偏通常从问谁改的代码开始。这个问题一出口，后面所有人都会开始自我保护，信息立刻变少。
主持人的作用是把讨论拉回系统和流程。同一个错误能被犯下，说明系统允许它发生。人的疏忽是现实，但把疏忽当成结论就停止了改进。
一个实用的做法是让当事人先讲，其他人后问，问题只问发生了什么和当时看到了什么，不问为什么没想到。前者能拿到细节，后者只会拿到道歉。
复盘的产出应该是一份能公开的文档，新人入职时可以读。如果文档写得像检讨书，没人会去读第二遍。