故障复盘与OnCall体系

定位：工程实践方法论（工程方法论系列收官篇之一）。故障是系统在替团队说话：复盘是把一次故障的学费兑换成组织能力的过程。OnCall 则把"出事了找谁、谁说了算、怎么升级"提前写进制度。本篇衔接 问题定位步骤（技术侧如何收敛根因）与 观测性三件套（故障如何被第一时间发现）。回答定位之后的两件事：为什么会发生、如何不再发生。

复盘的定位：学习系统，不是追责系统

不追责（blameless）文化的前提与边界：

• 前提一：流程有护栏。发布有卡点（审批/灰度/自动化回归），操作有手册，值班有备份。护栏齐全仍出事，责任在系统设计不在个人；护栏缺失本身就是要复盘的第一根因。
• 前提二：信息要免责。复盘会上说出的"我当时图快跳过了自测"不能被拿去算绩效账。否则下一次所有人都只会说"我也不知道为什么"。追责换来的第一份成果就是信息断供，组织从此失去定位能力。
• 前提三：区分个人失误与组织失误。同类错重复犯、改进项屡次不闭环，是组织问题（流程/投入不足），继续追个人只会加速掩盖。
• 边界：不追责不等于不追账。故意违章、隐瞒不报、销毁现场——这三类不在免责范围内。免责保护的是"诚实的事故当事者"，不是"恶意的行为"。

时间线还原法

复盘的第一产物不是根因，是时间线。从第一个异常信号到完全恢复，把所有事件按时刻钉在一条轴上。

1）采集来源：告警记录、发布/配置变更单、网关日志、值班群消息（OnCall 记录）。每个决策动作（谁在几点几分执行了回滚、依据是什么）。 2）双轨对齐：变更轨（发布/配置/扩缩容）与故障轨（指标恶化/告警）画在同一张图。"变更领先于恶化"是最常见的因果证据。 3）记录"不知道"：某时刻为什么做了错误决策——信息不全？告警缺失？权限不够？这些空洞本身就是改进项的来源。 4）区分四个关键时间点：

时间点	定义	度量
T0 发生	故障真正开始（指标拐点，不是首条告警）	-
T1 发现	有人/系统感知	发现耗时 T1-T0（MTTD）
T2 止血	用户影响消除（回滚/降级生效）	止血耗时 T2-T1
T3 恢复	根因修复、告警清零	修复耗时 T3-T2

双轨时间线示例（变更轨与故障轨画在同一张图上）：

 变更轨 ── 14:00 库存服务发布 v2.3.1 ──────────── 14:25 回滚单提交
 故障轨 ── 14:06 线程池告警 ─ 14:08 下单错误率告警 ─ 14:11 OnCall 确认
            ─ 14:12 定位到新版本 ─ 14:14 决定回滚 ─ 14:20 回滚完成 ─ 14:22 清零
 读法：变更领先故障 6 分钟（强因果证据）；T1=14:06（MTTD=6min）；
       T2-T1=14min，其中 14:12~14:14 的两分钟在等审批 ← 直接产出改进项

复盘最常见的发现：MTTR 的大头不在"定位"而在"决策"。从确认问题到敢按下回滚按钮之间空转的 20 分钟。所以改进项常常是预案与授权问题，不是技术问题。若定位本身就慢，回到 问题定位步骤 补排查能力。若根本没及时发现，回到 观测性三件套 补监控覆盖。

根因分析：五问法与因果链图

对时间线上每一个"为什么"连问 5 次，直到落到系统性缺陷（流程/设计/防护缺失）。而不是落到某个人身上。

现象：下单接口错误率 5 分钟内升到 100%
 └─ 为什么1：库存服务线程池被打满，请求排队超时
     └─ 为什么2：新上线的查询 SQL 未走索引，单次全表扫描 40 万行
         └─ 为什么3：该查询条件字段没建索引，代码就发布了
             └─ 为什么4：DDL 变更单与代码发布单分属两个流程，无联动评审
                 └─ 为什么5：DDL 流程不感知"是否有待发布代码依赖该字段"（系统性缺陷）
                     → 改进项落在变更流程联动，而不是"某人忘了建索引"

• 因果链必须能解释全部现象：解释不了的子现象，说明链路没闭合，不要急着出改进项。
• 警惕"近因当根因"：把"代码 bug"当根因止步，改进项就永远是"下次仔细点"。根因的判据是：修了它，这一类（而不只是这一个）故障不再发生。
• 多因故障画因果链图（多叉树），给每个分支标注"必要条件/触发条件"。改进项优先打必要条件（防护），不只是触发条件（运气）。

改进项：SMART 化与闭环率

• S 具体：写"下单依赖库存服务增加熔断，错误率 >50% 持续 5s 触发"，不写"加强容错意识"。
• M 可度量：完成标准有验证方式——演练通过 / 指标达标 / 巡检规则生效。
• A 可达成：拒绝"重构整个库存系统"式口号项，拆到季度内可落地的粒度，否则注定烂尾。
• R 相关：每条都能对应回因果链上的某个节点。与根因无关的改进项是搭便车，塞多了稀释执行力。
• T 有时限：明确 owner + 截止时间，录入复盘跟踪表。

闭环率是复盘体系的唯一硬指标：闭环率 = 按期完成的改进项 / 总改进项，按周跟踪、按月公示。连续两个周期低于 60%，说明改进项产出过量或优先级失真——宁可砍数量，不放水延期。防护类改进项（监控/预案/流程卡点）优先级永远高于体验优化类。

OnCall 体系：排班、升级路径与作战室

定级是升级路径的输入，先定级再谈响应：

级别	定义	响应要求	通报要求
P0	核心链路全不可用 / 在产生资损	立即作战室，TL 到场指挥	立即通报管理层
P1	核心功能部分受损（灰度/单机房/单端）	15 分钟内止血或升级	30 分钟一报
P2	非核心功能异常，有绕行方案	值班内处理	记录在案
P3	边缘缺陷 / 体验问题	工单排期	周报汇总

定级的纪律：按影响面定级，不按原因定级——"只是配置写错了"不能把 P0 降成 P2。宁可先按高级响应再降级，不可反向。

 告警 → 一线值班（App 推送，5 分钟内响应）
         │ 无人确认 / 5 分钟未止血
         ▼
       升级二线（电话强提醒 + 域 owner 群）
         │ P1 级故障 / 15 分钟未止血
         ▼
       作战室（War Room）：拉群 + 语音桥，TL 指挥
         │ 影响持续扩大 / 需跨部门决策（客服公告/资损）
         ▼
       管理层通报：每 30 分钟一次状态广播（面向业务与客服）

• 排班：一线周班轮值，二线由熟悉该域的 owner 备份。交接班必须书面 handover（未闭环告警/进行中变更/已知风险三条必写）。大促与节假日双人值班。
• 升级路径：升级是默认动作而不是失败——"超过 X 分钟未止血自动升级"写进手册。值班同学永远不需要为升级道歉，只需要为不升级负责。
• 作战室：P1 成立，三角色缺一不可。指挥（决定动作优先级，不动手）。操作（执行止血，同一时刻只做一个变更）。记录（维护时间线，事后复盘直接取材）。作战室只做止血决策，根因分析一律后置到复盘会。
• OnCall 手册：每个域维护"接到某类告警先看什么、先做什么、找谁"。把新同学第一次值班的门槛从"到处问人"降到"翻手册"。

复盘的节奏与积累

• 节奏三拍：48 小时内出时间线初稿（记忆与聊天记录都在衰减）。一周内评审定稿（当事人 + 受影响业务方 + 三道防线负责人到场）。一个月后回看改进项闭环进度。
• 案例库积累：所有复盘归档进统一故障案例库，新人培训与 OnCall 手册从中取材。案例按"根因类别"（发布/依赖/容量/数据/变更流程）打标签，半年做一次分布统计。某一类根因占比上升，就是下一阶段稳定性投入的方向。
• 重复故障单独立项：同一根因第二次失守，复盘标题直接升级为"防线为什么没建起来"。上一轮复盘的改进项逐条对账——闭环率造假在第二次故障面前无处遁形。

一个 P1 故障的完整复盘模板

【标题】2026-xx-xx 库存服务故障复盘（P1，影响下单 12 分钟）
1. 概要      ：一句话说清"什么系统、什么影响、多长时间、当前状态"
2. 影响面    ：请求量/订单量/资损金额/客诉量——影响面不量化，故障定级就是拍脑袋
3. 时间线    ：T0~T3 四个关键点 + 每步动作与决策依据（含"当时不知道 X"）
4. 根因      ：因果链图 + 五问法结论（技术根因与流程根因分层写）
5. 为什么没拦住：监控（T1 为何晚）/ 发布（为何带病上线）/ 预案（止血为何慢）三道防线逐一复盘
6. 做得好的  ：先写这条——值班 3 分钟响应、回滚果断，值得固化的行为同样要记录
7. 改进项    ：SMART 表（事项/owner/期限/验收标准/优先级），录入跟踪表盯闭环率
8. 经验教训  ：一段话写给没参战的人也能看懂

第 5 节是模板的灵魂：复盘不是问"为什么会发生"，而是问"监控、发布、预案三道防线分别为什么失守"。三道防线的体系化建设见 3+1保障：高可用系统稳定性是如何炼成的？。机房级演练暴露的问题同样进这套复盘闭环，见 多活容灾与单元化。"慢但不错"的持续性劣化不是故障，走 性能优化方法论 的叙事闭环。

实践清单

• [ ] 每个故障都有时间线，T0~T3 四个时间点齐备且与告警/变更记录对得上
• [ ] 每条根因落点在系统性缺陷，没有一条改进项是"下次小心"
• [ ] 改进项全部有 owner/期限/验收标准，进跟踪表按周盯闭环率
• [ ] 升级路径写进手册，"15 分钟未止血自动升级"无需任何人请示
• [ ] 作战室三角色（指挥/操作/记录）在演练中实际跑过，不是纸面分工
• [ ] 重复故障单独立项：同根因二次失守，逐条对账上一轮改进项
• [ ] 复盘会 48 小时内开完（记忆与日志 retention 都在衰减），当事人全部到场
• [ ] 定级按影响面不按原因，宁可先高级响应再降级，不可反向
• [ ] 作战室记录员的原始记录直接归档案例库，复盘时间线从中取材而非事后拼凑
• [ ] 不追责的边界（违章/瞒报/毁现场不在免责内）团队周知且写在复盘制度第一页

一句话总结

时间线还原事实，五问法逼出系统性根因，SMART 改进项按闭环率验收。OnCall 把响应变成制度，作战室把混乱变成分工。 复盘的产出不是一份文档，而是下一场同类故障被提前拦住的概率。

2026-10 新增（工程方法论系列）。