生产事故复盘模板：从 Timeline 到 Action Item 的结构化方法-拓冰建站

生产事故复盘模板：从 Timeline 到 Action Item 的结构化方法

一、"复盘"两个字让人心虚——大家知道又要互相指责了

事故复盘容易变成问责大会。
"谁改的配置？" "为什么没加监控？" "测试为什么没发现？"
这种复盘产出的是防御性陈述，不是系统改进。

好的复盘是工程活动，不是人事活动。
目标是找到系统的脆弱点并加固。
不是找到责任人并惩罚。
Blame-free 文化是前提——如果做不到，复盘连开都不要开。

我在多个团队中观察到一个规律：那些把复盘当成"找责任人"的团队，事故率不会显著下降。原因很简单——没人愿意坦诚地回顾自己犯的错。大家学会了"美化 Timeline"、"弱化影响范围"、"推卸根因到第三方依赖"。
而那些建立 Blame-free 文化的团队，事故率在半年内下降了 30-50%，因为每一次事故都产生了一批真正有效的 Action Item。

Blame-free 不是不追责。它是指：复盘的焦点是"发生了什么、为什么发生、怎么防止再次发生"，而不是"谁的锅"。
人都会犯错，惩罚犯错的人不会让错误减少——只会让错误更隐蔽。
加固系统（加校验、加自动化、加卡点）才能让同样的错误无法再次发生。

说到底，复盘的价值不在于解决某一次具体事故，而在于用这一次事故的代价，换取整个系统未来 100 次类似场景的安全性。

二、结构化复盘的五段框架

flowchart TB A[事故发现] --> B[1. 时间线 Timeline] B --> C[2. 影响范围 Impact] C --> D[3. 根因分析 Root Cause] D --> E[4. 修复过程 Resolution] E --> F[5. 改进措施 Action Items] D --> G{技术根因} D --> H{流程根因} D --> I{认知根因} G --> J[代码/配置/架构缺陷] H --> K[Review/测试/发布流程缺失] I --> L[假设错误/知识盲区]

五段框架的设计是和"5 Why's"根因分析法配套使用的。
Timeline 是事实陈述——不带判断，只记录客观时间点。
Impact 是影响量化——不是"影响很大"，而是"影响了 3200 个用户、造成了约 ¥15,000 的损失、消耗了 0.03% 的 Error Budget"。
Root Cause 是深度分析——用 5 Whys 追问 5 次，直到找到根本原因。
Resolution 是修复记录——区分"即时修复（止血）"和"永久修复（根治）"。
Action Items 是改进承诺——每条 Action Item 必须有负责人和截止日期。

五个段落的递进关系非常清晰：事实 → 影响 → 原因 → 修复 → 改进。
如果有人跳过了 Timeline 和 Impact 直接开始讨论"谁的锅"，主持人有责任把话题拉回正轨。
一个好的复盘模板就像一架"认知轨道"，让讨论沿着客观分析的路径走，而不是滑向主观指责。

三、复盘文档模板

# 事故复盘报告 ## 元信息 - 事故编号: INC-2026-0709-001 - 严重级别: P1 (核心功能中断) - 影响时长: 47 分钟 (14:03 - 14:50) - 复盘日期: 2026-07-10 - 参与人: (角色，不写姓名) --- ## 1. 时间线 (Timeline) | 时间 | 事件 | 来源 | |:---|:---|:---| | 14:03 | 监控告警：订单服务错误率 45% | Prometheus | | 14:04 | 值班开始排查 | - | | 14:08 | 发现数据库连接池耗尽 | Grafana | | 14:12 | 定位到新版本引入了慢查询 | 慢查询日志 | | 14:15 | 决策：回滚到上一版本 | - | | 14:20 | 回滚完成，错误率下降 | - | | 14:25 | 确认服务恢复 | - | | 14:50 | 积压消息消费完毕 | Kafka | **时间线要点**: - 发现时间 (MTTD): 0 分钟 (告警实时) - 定位时间 (MTTI): 9 分钟 - 恢复时间 (MTTR): 17 分钟 - 总影响时间: 47 分钟 --- ## 2. 影响范围 | 维度 | 详情 | |:---|:---| | 受影响服务 | 订单服务、支付服务（下游） | | 影响用户数 | 约 3200 人 | | 失败请求数 | 12,450 次 | | 业务损失 | 约 ¥15,000 (失败订单) | | Error Budget 消耗 | 0.03% (剩余 0.07%) | --- ## 3. 根因分析 (5 Whys) **Q1: 为什么订单服务错误率飙升？** A: 数据库连接池耗尽。 **Q2: 为什么连接池会耗尽？** A: 新增的聚合查询耗时 3.2 秒，每个连接被长时间占用。 **Q3: 为什么这个慢查询会上线？** A: Code Review 没有关注查询性能，只检查了逻辑。 **Q4: 为什么没有性能测试？** A: 性能测试只在功能开发的最后阶段做，这个 PR 赶时间直接合并了。 **Q5: 为什么赶时间？** A: 需求排期没有考虑性能验证的缓冲时间。 **根因**: 流程缺少"数据库变更必须附带 EXPLAIN 分析报告"的卡点。 --- ## 4. 修复过程 **即时修复**: - 14:15 - 回滚至 v1.2.0 - 14:20 - 验证服务可用 **永久修复**: - 添加缺失的数据库索引（`idx_created_at_status`） - 重构聚合查询，拆分为两次简单查询 + 应用层聚合 - 增加连接池监控告警（> 80% 使用率触发） --- ## 5. 改进措施 (Action Items) | # | 措施 | 类型 | 负责人 | 截止日期 | 状态 | |:---|:---|:---|:---|:---|:---| | 1 | CI 增加 EXPLAIN 分析检查 | 流程 | 待指定 | 7/17 | todo | | 2 | 数据库变更 PR 模板增加性能评估项 | 流程 | 待指定 | 7/14 | todo | | 3 | 连接池使用率 > 80% 告警 | 监控 | 待指定 | 7/12 | todo | | 4 | 重构订单列表聚合查询 | 代码 | 待指定 | 7/14 | todo | | 5 | 团队培训：数据库索引设计 | 认知 | 待指定 | 7/21 | todo | --- ## 6. 经验分类 **做得好的**: - 告警及时，MTTD 为 0 分钟 - 回滚决策果断，没有尝试在线修复 **需要改进的**: - 数据库变更缺少性能检查卡点 - 连接池使用率没有设置告警阈值 **如果再次发生**: - 值班可直接回滚，无需上级审批（更新 Runbook）

这个模板有一个容易被忽视但非常重要的细节：Timeline 的"来源"列。
每个时间点的事件都必须有可验证的来源——Prometheus 告警记录、Grafana 截图、慢查询日志、Kafka 消费滞后指标。
这避免了"凭记忆复盘"的常见问题——人的记忆是片段化和美化的，日志是客观的。
复盘必须以日志为准，而不是以任何人的口述为准。

四、复盘的有效性检查

复盘后一个月，检查 Action Item 完成率。
如果完成率 < 50%，说明复盘只是走形式。
建议指定每个 Action Item 的负责人和截止日期。
在下一次周会上过一遍进度。

复盘的频率也很重要。
P0/P1 事故必须 24 小时内复盘。
P2 事故可在本周内复盘。
P3 及以下是数据统计，不强制复盘。

有两个指标可以衡量复盘文化的健康度。
第一个是 Action Item 完成率——理想目标是 80% 以上。
第二个是"重复事故率"——有没有相同根因的事故再次发生？如果 3 个月内出现了第二次同类事故，说明上一次的 Action Item 没有真正落地或没有覆盖到根因。
这两个指标应该纳入团队的月度运营报告。

另外，复盘的 Action Item 应该有分类和优先级。
不要一个事故产出 20 条 Action Item，每条都标 P1——这样反而没人会真正执行。
建议每次复盘产出 3-5 条高优先级的 Action Item，确保能在一个月内完成。
剩余的改进想法可以记录在"改进池"中，后续排期处理。