事故复盘
无指责事故复盘：时间线、直接原因、系统原因、防复发
用这个方法分析
上传录音或转写文本即可，未登录会先引导登录
产出长什么样
示例下面是一段虚构场景的示例产出，用来说明形态。真实分析会锚定你自己录音里的原话。
事故复盘示例：电商平台大促期间订单系统故障
场景：某电商平台在大促期间的订单系统故障导致价格显示错误，影响部分用户下单。
| 时点 | 事件 | 系统状态/影响 | 响应动作 |
|---|---|---|---|
| 10:00 | 大促开始，流量激增 | 系统负载超过预警线 | 运维团队增加服务器资源 |
| 10:15 | 价格缓存刷新服务出现延迟 | 部分商品价格显示为原价 | 无（告警未触发） |
| 10:20 | 用户投诉价格异常涌入客服系统 | 客服工单量激增200% | 客服主管启动应急话术 |
| 10:25 | 技术团队介入排查 | 发现缓存服务器节点故障 | 手动切换备用节点 |
| 10:30 | 价格显示恢复正常 | 投诉量开始下降 | 发布系统状态公告 |
| 因果层级 | 根本原因分析 |
|---|---|
| 直接原因 | 1. 大促流量导致核心价格缓存服务过载。 |
- (证据不足) 值班运营人员误操作价格规则，导致缓存刷新逻辑异常。 （原文无依据/推断：缺乏操作日志与证人证言佐证） | | 系统原因 | 1. 自动化扩容预案未覆盖缓存服务。
- 缺乏针对“价格显示”这一关键路径的专项监控与熔断机制。
- 大促前压测未模拟极端并发场景下的缓存失效。 |
| 防复发措施 | 负责人 | 验收标准 |
|---|---|---|
| 为价格缓存服务增加自动扩缩容能力。 | 架构组 | 通过模拟150%峰值压力测试，无服务中断。 |
| 新增“关键路径一致性”监控告警（如价格、库存），并设置自动熔断。 | 运维组 | 告警触发至运维介入平均时间（MTTA） < 30秒。 |
| 修订上线流程，高危操作（如价格规则变更）需双人复核并录屏。 | 产品运营组 | 流程文件发布并完成全员培训。 |
复盘结论：本次事故直接源于技术组件在压力下的脆弱性，而更深层是流程和监控的缺失。防复发措施需同时针对技术韧性与操作规范进行加固。正如复盘记录中张经理总结：“这次故障暴露了我们在流程和系统监控上的双重不足，必须优先解决流程问题，不能总依赖事后的人工响应。”
什么时候用它
用在内部会议这类录音上。当内容里出现下面这些信号时，它最派得上用场：
线上事故重大失误客诉爆发
输出的 4 个模块
产出形态是对照矩阵，不是一段分析文字——有形态才能沉淀、才能被下游用。
- 1事故时间线
- 2直接原因与系统原因
- 3检测与响应的失效点
- 4防复发措施与验收
它怎么保证不瞎说
亲证锚定
置信分层
约束与代价
证据不足时它会说「本场没有可供分析的对象，缺的是什么」，而不是编一个结论—— 这是硬要求，不是客套话。
常见问题
- 事故复盘适合分析什么样的录音？
- 适用于内部会议。典型触发信号：线上事故、重大失误、客诉爆发。一场录音即可。
- 用事故复盘会拿到什么？
- 产出形态是对照矩阵，包含 4 个模块：事故时间线、直接原因与系统原因、检测与响应的失效点、防复发措施与验收。
- 事故复盘不做什么？
- 不得据此对个人绩效定性；不得把推断当事实用于问责