复盘的目标是改进而不是定责
自动化事故的复盘之所以容易流于形式，多是因为焦点放错了地方：把讨论集中在「谁改的」，而不是「为什么这个改动能一路通过到生产」。有效的复盘围绕三件事展开——把时间线还原清楚、把影响面量化、把促成条件的链条找出来。结论必须落到可验证的改进项上，否则下一次事故的经过会和这次高度雷同，只是换了一个触发点。
基本信息
| 适用对象 | 批量执行、发布与配置变更引发的事故 |
|---|---|
| 产出物 | 时间线、影响面、根因与促成条件、改进项清单 |
| 时间口径 | 检测时间、响应开始时间、恢复时间、完全恢复时间 |
| 改进项要求 | 有负责人、有期限、可验证 |
| 纪律要求 | 无责讨论，聚焦机制而非个人 |
复盘要覆盖的四部分
- 时间线：从变更发起到完全恢复的关键节点，包含检测与响应延迟
- 影响面：受影响主机与业务数量、持续时间、是否有数据损失
- 原因链：直接触发的技术原因与让它得以发生的流程原因分列
- 改进项：按优先级排序，每项写明负责人、期限与验证方式
- 预案修正：本次用到或缺失的预案是否需要补充与演练
- 知识沉淀：把结论写成可检索的条目，纳入下次变更的检查清单
取证与时间线素材
取证与时间线素材
journalctl --since '2 hours ago' -u myapp --no-pager | head -50 # 服务侧时间点
git log --since='3 hours ago' --pretty='%h %ad %an %s' | head -20 # 变更来源
last -n 20 # 登录记录，确认操作者
ausearch -ts recent -m EXEC | tail -20 # 审计层面的执行记录
tail -n 100 run-*.log # 执行日志，用于核对实际命中主机
ps -eo pid,lstart,cmd | head -20 # 进程启动时间，辅助判断何时重启改进项类型与验证
| 改进类型 | 例子 | 验证方式 |
|---|---|---|
| 技术防护 | 增加范围校验或默认预演 | 构造一次误操作场景验证被拦住 |
| 流程调整 | 变更前需范围确认记录 | 抽查最近若干次变更是否留存 |
| 监控补齐 | 增加任务异常告警 | 演练触发一次告警 |
| 预案完善 | 补充回滚步骤与耗时 | 非生产环境完整演练并计时 |
| 知识沉淀 | 结论纳入检查清单 | 检查清单实际被引用 |
原因要分成两层写：直接原因解释「为什么这次会坏」，促成条件解释「为什么它会一路通过到生产」。只写直接原因时，改进项往往停留在「以后注意」，而下一次换个触发方式依然会发生。
时间线要用统一时区与真实时间戳，不要凭记忆写「大概过了十分钟」。检测延迟与响应延迟是最有价值的两个数字，它们直接决定改进方向是补监控还是补流程。