事故复盘是什么
事故恢复后系统还原时间线、根因与改进项：无指责复盘（blameless）聚焦系统与流程改进而非追责个人，鼓励如实披露以避免隐瞒。产出包括时间线、根因分析、影响范围、改进项与负责人；恢复后数日内评审，改进项进入待办并跟踪关闭。
基本信息
| 产出 | 时间线、根因分析、影响、改进项与负责人 |
|---|---|
| 原则 | 无指责（blameless），对事不对人 |
| 流程 | 恢复后数日内评审，改进项进入待办 |
| 文化 | 如实披露优先：隐瞒的代价高于错误本身 |
| 分级 | 按影响定复盘深度：小事故轻量、大事故正式 |
典型使用场景
- 线上事故：恢复后组织正式复盘
- 接近事故：险些酿成故障的事件同样值得复盘
- 发布事故：回滚与 revert 之后追溯触发链条
- 重复问题：同类事故再发，复查上次改进项是否闭环
- 组织学习：复盘文档共享，让其他团队对照自查
- 闭环核对：下次迭代回顾逐项确认改进项状态
复盘模板骨架
复盘模板骨架
## 影响
## 时间线（检测 → 响应 → 恢复）
## 根因分析（5 Whys 或因果链）
## 做对了什么 / 哪里可以更好
## 改进项（含负责人与期限）改进项写法对照
| 坏例子 | 问题 | 好例子 |
|---|---|---|
| 加强测试 | 不可验证 | 为结算服务补 3 条端到端用例，注明期限 |
| 提高警惕 | 无具体动作 | 为告警加值班升级路径，两周内落地 |
| 注意沟通 | 无责任主体 | 变更窗口接入群通知，由发布值班维护 |
改进项要可验证：加强测试不是改进项，为结算服务补充 3 条端到端用例并注明期限才是。
时间线从记录里重构：监控告警、聊天记录、发布日志都是证据，别只靠回忆。
复盘文档跨团队共享可搜可查，同类问题才能借鉴前车之鉴。