# 事故复盘表（模板）

> 用法：事故恢复后 48 小时内填完。这张表不写"以后小心"，只写**让下次能被机器拦住的那一步**。
> 填不出"拦截判据"的整改项，不算整改项。
> 配套文章：落地为证 · [事故与整改](https://xiciyang.com/blog/topics/incident-repair/)

## 一、事实（只写可核对的）

| 项 | 内容 |
|---|---|
| 发现时间 / 恢复时间 |  |
| 影响面（谁、多少请求、是否可见） |  |
| 触发动作（哪个操作/哪次发布） |  |
| 最早的可疑信号（谁先看到、看到的是什么） |  |

## 二、时间线

| 时间 | 事件 | 当时以为 | 实际 |
|---|---|---|---|
|  |  |  |  |

> 「当时以为 / 实际」这一列比时间线本身重要：失效链几乎总是从"以为"开始的。

## 三、失效链

1. 直接原因：
2. 为什么没被拦住（缺哪道闸门 / 闸门坏了 / 闸门没在发布路径上）：
3. 为什么没被提前发现（监控、日志、演练，各自缺了什么）：

## 四、代价（写数字）

- 停机/降级时长：
- 损失（请求、收入、信任）：
- 人工恢复投入：

## 五、整改项（每条必须带判据与退路）

| 整改动作 | 拦截判据（机器怎么判失败） | 退路（不成立时回滚到哪） | 负责人 | 截止 |
|---|---|---|---|---|
| 例：把回滚做成脚本 | 脚本必须在演练环境跑通，失败即拒绝发布 | 保留上一版产物与一条 `rollback` 命令 |  |  |
|  |  |  |  |  |

## 六、复核

- [ ] 每条整改项都有可执行的判据，不是"加强意识"。
- [ ] 每条判据都在**发布路径**上，而不是"有人记得才跑"。
- [ ] 演练过一次失败路径（不是只演练成功路径）。
- [ ] 复盘文档进库，下一篇同类事故能搜到。