把事故写成站得住的复盘
用时间线、根因和可验证的改进项，替代「加强监控」式总结
你是事故复盘的主持人。根据下面的时间线和处置记录，写一份复盘：1）时间线只保留改变系统状态或决策的节点，统一标注时区；2）根因写到「哪个机制缺失、哪条假设不成立」，不要停在「人为误操作」；3）改进项分「已做/待做」，每条有负责人角色、截止时间和验证方式；4）单列「这次运气好的地方」。不要写「加强监控」「提高意识」这类无法验收的项。 [事故时间线/影响范围/处置记录]
使用建议
「运气好的地方」最能暴露系统真实余量；写不出这条，复盘通常还停在表面。
适合什么场景
- 事故已经影响到真实用户，工程和管理层需要一份共同认可的事实版本。
- 同类故障第二次发生，而上一次复盘的改进项显然没有落地。
不适合的场景
- 事故还在处置、根因未明：先止血，复盘晚一点写。
- 只响了一次告警，没有用户影响、没有状态变化：硬写复盘是在制造意义。
示例
输入
14:02 发布 v2.3 14:05 错误率 0.1% -> 8% 14:09 开始回滚 14:16 回滚完成，错误率恢复 14:30 发现回滚只撤了应用，没撤 DB migration 备注：当天大促，流量为平时 3 倍
你会得到
根因不能写成「发布导致」：回滚预案只覆盖应用、没覆盖 migration，回滚并未真正完成，这个机制缺失才是问题。大促 3 倍流量可能放大了影响，但不是根因，不要写进因果句。时间线要补上「谁在 14:09 决定回滚、依据哪个指标」，改进项应落到「回滚清单包含 migration 且演练过」，验证方式是下次发布前留一次 dry-run 记录。
常见误用
- 把复盘写成责任认定：大家开始防御性叙述，真正缺失的机制反而不会被写出来。
- 改进项写成「优化发布流程」：没有负责人和验证方式，三个月后还是同一句话。
可以这样改
- 加「站在当晚值班人的视角写信息缺口」，能补出监控面板之外的组织问题。
- 要求「每条改进项配一个可以失败的验证」，把「已修复」从声明变成证据。