生产事故复盘模板：从 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 Whys根因分析法配套使用的。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确保能在一个月内完成。剩余的改进想法可以记录在改进池中后续排期处理。五、总结事故复盘的结构化框架时间线→影响→根因→修复→改进措施。5 Whys 追根因区分技术/流程/认知三层原因。每个 Action Item 必须指定负责人和截止日期。复盘目标是改进系统而非指责个人。复盘后的 Action Item 完成率是衡量复盘有效性的关键指标。最后一句劝告如果你们团队还没有强制复盘的制度从下一次事故开始做。不需要完美的模板和工具就新建一个飞书文档按这五个段落填空。做五次之后你会惊讶地发现——之前那些反复出现的事故开始真正消失了。不是人变聪明了是系统变坚固了。这就是复盘的价值。