事故复盘停在「下次注意」—— 三个月后同类事故再来一次 · 复盘的价值在改进项闭环，初稿是闭环的起点
本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。 案例设定：驭数科技（虚构）事故日：周四 15:23，运维群弹出告警 —— 标准版部分客户的巡检上报超时。17:40 恢复，影响 9 家客户、累计异常 96 分钟。陈默要求周五上午出复盘。以往复盘的流程是江晓连夜翻群消息、凭记忆拼时间线、初稿写到凌晨两点 —— 而上上次复盘的三条改进项，有一条落空了。
注意标橙色那一份 —— 02_事故响应群消息.txt。它微信运维群 · 2026-08-27，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。
短是因为「时间线证据结构、5Why 分层规则、改进项闭环审计」都在能力包里。产品经理只要把原始记录扔进来。
江晓把告警记录、响应群消息、影响面、配置变更、旧改进项全部扔进来 —— 初稿的骨架五份原料里四份是现成的系统记录。
| 时间 | 节点 | 证据 |
|---|---|---|
| 08-26 22:15 | 配置变更（埋雷） | 运维平台记录 |
| 08-27 15:23 | 告警触发 | 监控 |
| 15:31 | 响应启动 | 群消息 |
| 16:05 | 根因定位（1 台未生效） | 群消息（谭锐） |
| 16:32 | 配置重推 | 群消息 |
| 17:40 | 恢复确认 | 监控 |
时间线的第一个节点是前一天的配置变更 —— 事故的起点不在告警响起时，在变更发生时 —— 复盘的时间线从「埋雷」画起，改进项才能改对地方。
| 指标 | 数值 | 口径 |
|---|---|---|
| 受影响客户 | 9 家（标准版 96 家中的 9.4%） | 按实例归属 |
| 累计异常时长 | 96 分钟（15:23-17:40） | 监控口径 |
| 客户工单 | 14 条（安抚 + 重报指引） | 客服记录 |
| 直接处置投入 | 8 人时（运维 3 + 研发 4 + 客服 1） | 群消息与工时折算 |
影响面的四个数字全部带口径 —— 「9.4%」的分母是 96 家标准版客户，私有化 44 家因独立部署未受影响 —— 数字化的影响面是后续一切讨论（赔付、告知、改进优先级）的地基。
| 层级 | 追问 | 证据强度 |
|---|---|---|
| Why1 | 上报为什么超时？—— DB 连接池耗尽 | 监控+群消息 |
| Why2 | 连接池为什么耗尽？—— 1 台实例配置未生效（上限偏低） | 运维平台记录 |
| Why3 | 为什么没发现未生效？—— 平台显示「成功」 | 待验证：状态校验机制缺失？ |
| Why4 | 为什么显示成功？—— 配置下发无生效核验 | 待验证（需运维平台方确认） |
| Why5 | 为什么没有核验？—— 制度与工具双缺 | 制度层 · 复盘会讨论 |
5Why 的五层里三层带证据、两层标待验证 —— Why3/Why4 涉及运维平台的机制细节，需要平台方确认后才能定稿。「待验证」不是初稿的瑕疵，是诚实的标志 —— 会上没人反驳的假设会固化成『真相』，那才是复盘最大的病。
| 旧改进项 | 状态 | 与本次的关联 |
|---|---|---|
| 发布检查配置生效验证 | VA-02 已落实 | 若本次是发布引发则可拦 |
| 配置变更双人复核 | 执行中 | 昨晚变更走了复核，未拦住 |
| 变更后 24h 加严监控 | 落空 | 若闭环，今晨即可发现 |
第三条改进项的落空与本次事故直接相关 —— 更有意思的是第二条：双人复核执行了但没拦住（复核的是「操作正确」不是「生效结果」）—— 改进项要「可验收」才有意义，「加严监控」这种没有责任人和验收标准的写法，落空是宿命。
| 材料结构 | 状态 |
|---|---|
| 时间线 + 影响面 + 5Why 证据链 | 已成稿 |
| 根因认定（Why3-5 待验证项） | 留白 · 会议讨论 |
| 改进项清单 | 留白 · 建议从「配置生效核验」与「改进项验收标准」两题入手 |
| 责任认定 | 不预设 · 事实部分已含各环节响应时长 |
初稿的克制：响应时长（告警到响应 8 分钟、定位 34 分钟）都在合理区间的事实已经摆在时间线里 —— 「运维响应慢」这类伤人的定性不需要写 —— 排除性的数据自己会说话。
答不上来的问题，比答得漂亮的问题更能决定这场演示的结果
返回场景引入页，可查看完整案例背景、演示步骤与提示词