事故不可避免，但同类事故反复出现，通常不是技术问题，而是治理问题。
很多复盘停留在“谁改了什么”，却没有回答更关键的问题：为什么这个问题能进入生产，下一次如何被提前拦截？
本文提供一份可直接套用的事故复盘模板。
【场景：一次接口超时引发连锁故障】
典型过程：
- 某接口 RT 激增。
- 上游线程池被阻塞，重试放大流量。
- 依赖服务熔断，核心链路降级。
- 用户侧出现大面积失败。
问题并不只是“慢 SQL”或“机器不够”，而是系统防线没有形成闭环。
【步骤1：还原时间线（Timeline）】
复盘的第一步是客观事实，不是主观判断。
建议记录：
- T0：首次告警时间
- T1：影响范围扩大时间
- T2：止损动作开始时间
- T3：服务恢复时间
- T4：完全恢复验证时间
目标：量化 MTTA（发现时长）与 MTTR（恢复时长）。
【步骤2：明确影响面（Impact）】
最小必填项：
- 影响用户数
- 影响接口/业务域
- 影响时长
- 经济损失（若有）
没有影响面评估，优先级排序会失真。
【步骤3：根因分析（Root Cause）】
建议采用“技术根因 + 机制根因”双层分析。
示例：
- 技术根因：索引失效导致慢查询。
- 机制根因：上线评审未覆盖 SQL 执行计划检查。
只修技术根因，问题很可能换个形式再次出现。
【步骤4：止损动作（Mitigation）】
复盘要明确“当时做了什么”，并评估动作有效性。
例如：
- 开启限流
- 临时降级非核心功能
- 回滚版本
- 扩容数据库读节点
每个动作都要写：执行时间、负责人、效果。
【步骤5：防复发清单（Action Items）】
整改项必须可执行、可验收、可追踪：
- 增加 SQL 上线前 EXPLAIN 检查
- 为核心接口补充压测基线
- 增加“错误率 + 延迟”组合告警
- 将降级开关纳入值班手册
建议每项都带 owner、截止日期、验收标准。
【可复用复盘模板】
1. 事故摘要：发生了什么
2. 时间线：告警、止损、恢复关键节点
3. 影响评估：用户、业务、时长、损失
4. 根因分析：技术根因 + 机制根因
5. 处置过程：做了哪些动作，效果如何
6. 防复发项：owner + deadline + 验收标准
7. 经验沉淀：更新哪些规范与手册
【复盘质量检查清单】
- 是否基于客观数据而非主观判断？
- 是否明确了影响范围与时长？
- 是否拆分技术根因与机制根因？
- 是否有可执行的防复发项？
- 是否指定 owner 与截止时间？
- 是否更新了评审规范与演练手册？
下期预告：
《Java 面试高频系统设计题：回答框架与踩坑点》
