👤 个人开发者简化版：不用写正式复盘报告，出事后花 10 分钟回答三个问题即可—— ① 发生了什么 + 怎么恢复的？② 根因是什么（连问 5 个"为什么"）？③ 下次怎么防止？ 记进 knowledge-card-template 一张卡就够，重点是别让同一个坑踩第二次。
在事故发生后系统性地分析根因、总结教训、制定改进措施，将事故转化为组织知识，防止同类问题再次发生。
- 生产环境服务中断/降级
- 数据丢失或损坏
- 安全漏洞被利用
- 发布导致严重问题
- 任何影响用户的 P0/P1 级事件
| 级别 | 定义 | 示例 | 响应时间 |
|---|---|---|---|
| P0 | 核心服务完全不可用 | 全站宕机、数据全部丢失 | 立即 |
| P1 | 核心功能严重受损 | 支付不可用、大量用户报错 | 15 分钟 |
| P2 | 非核心功能异常 | 通知延迟、部分页面慢 | 1 小时 |
| P3 | 轻微影响 | 个别用户偶发错误 | 4 小时 |
P0/P1 应急流程：
1. 确认事故（监控告警/用户报告）
2. 评估影响面（多少用户受影响？哪些功能？）
3. 止血（优先恢复服务，不急于找根因）
- 回滚部署
- 重启服务
- 切换备用
- 降级（关闭非核心功能）
4. 通知相关方（用户/团队）
5. 持续监控直到恢复
6. 确认恢复
应急原则：
- 先止血，后查因
- 不确定时回滚（回滚比排查快）
- 保留现场日志和数据（用于后续分析）
- 记录时间线（什么时候发现、什么时候做了什么）
时间： 事故恢复后 1-3 天内（记忆还新鲜）
参与人： 事故相关者（个人开发则自己）
议程：
- 回顾时间线（5 min）
- 分析根因（15 min）
- 讨论改进措施（15 min）
- 分配行动项（5 min）
5 Whys 方法：
为什么服务宕机？→ 内存溢出 (OOM)
为什么内存溢出？→ 一次性加载了 100 万条数据
为什么加载这么多？→ 导出功能没有分页
为什么没有分页？→ 最初数据量小，没考虑增长
为什么没考虑？→ 没有性能预算和大数据量测试
→ 根因：缺少性能预算和压力测试
分析维度：
- 直接原因（什么触发了事故）
- 根本原因（为什么没有预防）
- 发现原因（为什么没有更早发现）
- 恢复原因（为什么恢复花了这么久）
每个改进项必须：
- 具体可执行（不是"加强注意"）
- 有负责人
- 有截止日期
- 可验证完成
改进类型：
| 类型 | 示例 |
|---|---|
| 预防 | 添加内存限制、分页查询 |
| 检测 | 添加内存使用告警 |
| 恢复 | 自动化回滚脚本 |
| 流程 | 大数据量功能必须压测 |
原则：
- 复盘对事不对人
- 目标是改进系统，不是追责
- 每个人都可能在系统中犯错
- 关注"为什么系统允许这个错误发生"
- 鼓励主动报告和暴露问题
- 事故已分级
- 应急响应及时（止血优先）
- 时间线已记录
- 根因已分析（5 Whys）
- 复盘会议已召开
- 改进措施具体可执行
- 每个改进项有负责人和截止日期
- 复盘文档已归档
- 改进项已纳入 backlog 跟踪
- 必要时通知了受影响用户
| 输出物 | 格式 | 存放位置 |
|---|---|---|
| 事故报告 | Markdown | docs/incidents/YYYY-MM-DD-title.md |
| 改进行动项 | Issue/清单 | 项目管理工具 |
| 时间线记录 | 文档 | 事故报告内 |
| 误区 | 正确做法 |
|---|---|
| 修好了就不复盘 | 必须复盘，防止再犯 |
| 复盘变成批斗会 | 无责文化，关注系统改进 |
| 根因停在表面 | 用 5 Whys 追到根本 |
| 改进措施太模糊 | 具体、可执行、有截止日期 |
| 改进项提了不跟踪 | 纳入 backlog，定期检查完成情况 |