事故案例模板
要点
- 事故案例记录系统故障的发现、定位、修复、复盘全过程
- 重点是时间线和根因分析——什么时候发现、怎么定位、根因是什么
- 事故案例的价值在于预防——写清楚怎么防止再发生
- 不要追究个人责任，聚焦系统改进
1. 适用场景
事故案例用于记录生产环境的系统故障、数据异常、安全事件等。
典型场景：
- 系统宕机或服务不可用
- 数据丢失或数据不一致
- 性能突然下降
- 安全漏洞被利用
- 配置错误导致业务异常
2. 模板结构
# [事故标题] - [严重程度] - [日期]
## 事故概要
一句话描述：什么系统、什么问题、影响多大、持续多久。
## 时间线
| 时间 | 事件 | 负责人 |
|------|------|--------|
| 10:00 | 监控告警：订单服务 P99 延迟 > 5s | 系统自动 |
| 10:05 | 值班工程师收到告警，开始排查 | 张三 |
| 10:15 | 定位到数据库连接池耗尽 | 张三 |
| 10:20 | 临时扩容数据库连接池 | 张三 |
| 10:25 | 服务恢复，告警解除 | 系统自动 |
## 影响
- 持续时间：25 分钟
- 影响范围：订单创建失败，约 500 单
- 用户影响：部分用户下单失败，需要重试
- 业务损失：约 10 万元
## 根因分析
直接原因：数据库连接池耗尽，新请求无法获取连接。
根本原因：
1. 慢查询导致连接占用时间过长
2. 连接池配置过小（最大 50 个连接）
3. 没有慢查询监控和告警
为什么没发现：
- 慢查询日志没有实时监控
- 连接池使用率没有告警阈值
## 修复措施
### 临时修复（已执行）
- 扩容数据库连接池到 200
- 重启订单服务，释放卡住的连接
### 长期修复（待执行）
- 优化慢查询（添加索引，查询改写）
- 添加连接池使用率监控，> 80% 告警
- 添加慢查询实时监控，> 1s 告警
## 复盘
### 做得好的
- 监控及时告警，5 分钟内发现
- 值班工程师响应快，25 分钟内恢复
### 需要改进的
- 慢查询监控缺失，依赖用户反馈
- 连接池配置没有压测验证
### 行动项
- [ ] 优化慢查询（负责人：李四，截止：本周五）
- [ ] 添加连接池监控（负责人：王五，截止：下周一）
- [ ] 压测验证连接池配置（负责人：张三，截止：下周五）3. 写作要点
时间线要精确
事故复盘的关键是时间线。精确到分钟：
- 什么时候发现（监控告警 vs 用户反馈）
- 什么时候响应
- 什么时候定位到原因
- 什么时候修复
时间线帮助评估：发现速度、响应速度、定位速度。
根因分析要深入
不要停在「直接原因」。用「5 个为什么」挖掘根本原因：
直接原因：数据库连接池耗尽
为什么：慢查询占用连接时间过长
为什么：查询没有索引
为什么：代码审查没有发现
为什么：没有慢查询监控
根本原因：缺乏数据库性能监控体系
行动项要具体
不要写「加强监控」。要写：
- 添加什么监控指标
- 告警阈值是多少
- 谁负责
- 截止时间
不追究个人责任
事故案例的目的不是找人背锅，而是改进系统。
不要写：「张三配置错误导致事故」 要写：「配置流程没有校验，容易出错」
4. 常见误区
只写修复，不写根因
「重启服务恢复了」不是案例，是操作记录。要写：为什么会挂、怎么防止再挂。
时间线太粗
「10 点发现问题，11 点修复」太粗。要精确到分钟，帮助评估响应速度。
行动项太模糊
「优化性能」「加强监控」不是行动项。要具体到：优化什么、怎么监控、谁负责、截止时间。
总结
事故案例的核心是时间线和根因分析。精确到分钟的时间线，深入的根因分析（5 个为什么），具体的行动项（谁、什么、截止时间）。不追究个人责任，聚焦系统改进。