软件项目开发全流程 · 第 28 课 · 事故响应与复盘
1、凌晨 3 点的电话
监控告警响起：支付接口错误率 100%。值班工程师睡眼惺忪地打开电脑——手在抖、脑子乱、不知道从哪查起。半小时过去了，用户还在骂，群里消息刷屏，老板在问"还有多久"。
事故响应拼的不是"个人英雄主义"，而是制度、预案和冷静的流程。本课讲：事故来了怎么办（响应），事后怎么学（复盘）。
2、事故分级：先定"严重度"
不是所有事故都要"全员拉群、CEO 到场"。先分级：
| 等级 | 定义 | 响应 |
|---|---|---|
| P0 / Sev1 | 核心业务全挂、数据丢失/泄露、影响大量用户 | 立即全员响应、CEO/CTO 知情、最高优先 |
| P1 / Sev2 | 主要功能不可用、明显影响部分用户 | 立即响应、值班 + 相关团队 |
| P2 / Sev3 | 次要功能异常、有绕行方案 | 工作时间内处理 |
| P3 / Sev4 | 轻微问题、体验瑕疵 | 排入计划 |
分级的意义：把注意力留给真正严重的事，避免"狼来了"消耗团队。
3、事故响应的角色分工
一次有序的响应，需要几个明确角色（可由不同人担任，事故小可兼任）：
| 角色 | 职责 |
|---|---|
| 事故指挥官（IC） | 总协调、做决策、对外沟通。不亲自埋头修 bug |
| 沟通负责人 | 对外/对内同步进展，让干系人安心 |
| 技术负责人（Tech Lead） | 组织技术排查与修复 |
| 记录员（Scribe） | 记录时间线与关键操作（复盘素材） |
为什么要"指挥官不亲自修"？ 因为一个人又修又协调必然顾此失彼。有专人指挥，效率高得多。
4、事故响应流程
① 发现（告警/用户反馈）
│
② 分级 & 拉群（确定 P 级、通知相关人）
│
③ 止血优先 ──▶ 回滚 / 关开关 / 切流量（先恢复服务！）
│ ⚠️ 不要一开始就深挖根因
│
④ 恢复确认（指标正常、核心路径可用）
│
⑤ 沟通同步（定期更新状态，别让干系人干等）
│
⑥ 根因分析（服务恢复后，从容排查）
│
⑦ 复盘 & 行动项（见下）最反直觉、也最关键的：先止血，后诊断。
错误做法：发现故障 → 试图立刻找根因 → 边查边修 → 服务一直挂
正确做法：发现故障 → 先回滚/关开关恢复 → 服务恢复 → 再慢慢查根因用户不关心"为什么"的那一刻，他们要的是服务先好起来。
5、事故沟通：别让信息真空
事故中最大的次生问题往往是信息不透明：干系人不知道进展，就会不断来问、施压、猜测。
原则：
- 定期更新（如每 15~30 分钟一条）：现状 + 已做 + 下一步 + 预计。
- 有状态页（Status Page） 的对外公示（"我们已知晓，正在处理"）。
- 指定发言人：避免多人各说各话。
- 诚实：不夸大、不隐瞒、不甩锅。
[10:15] 已确认支付接口 5xx，影响所有支付，定级 P1
[10:20] 已回滚至上一版本，错误率开始下降
[10:30] 服务已恢复正常，继续观察；将启动复盘6、无指责复盘（Blameless Postmortem）
事故结束后，必须复盘——但方式决定成败。
"无指责（Blameless）" 的意思不是"没人负责"，而是：追究"系统为什么让人犯错"，而非"哪个人犯了错"。
❌ 指责式："是小王误删了配置，批评处分。"
→ 结果：以后没人敢动、出事都隐瞒、同类事故照旧发生
✅ 无指责："配置删除没有二次确认、没有权限隔离、
没有灰度验证。系统设计上如何避免？"
→ 结果：改进系统，防止任何人再犯同样的错核心信条：人都会犯错，好的系统让错误难以发生、易于发现、后果可控。
7、复盘报告的结构
一份好的 Postmortem 包含：
1. 标题与摘要 一句话说清发生了什么、影响多大
2. 影响（Impact） 影响了多少用户、多久、损失什么
3. 时间线（Timeline）从发现到恢复的关键时间点
4. 根因（Root Cause）直接原因 + 更深的系统性原因（5 Whys）
5. 处置过程 做过哪些操作、为何这么选
6. 什么做得好 值得保留的（如告警及时、回滚快）
7. 什么可以更好 暴露的短板
8. 行动项（Action Items）谁、在何时前、做什么（可追踪！）5 Whys 示例：
问题：支付接口全挂
Why1 为什么？→ 部署的新版本有 bug
Why2 为什么 bug 上线了？→ 测试没覆盖这个分支
Why3 为什么没覆盖？→ 这个分支是新加的，测试没同步补
Why4 为什么没同步？→ 没有"改代码必须补测试"的强制检查
Why5 为什么没有检查？→ 流程缺失
→ 行动项：加 CI 覆盖率门禁 + Review 清单（系统性改进，不止修这个 bug）关键：行动项必须落地、可追踪——否则复盘白做，事故还会重演。
8、常见误区
| 误区 | 问题 | 正解 |
|---|---|---|
| 先找根因再恢复 | 服务长时间不可用 | 先止血（回滚/关开关） |
| 无分级 | 小事大动干戈 | 按 P 级响应 |
| 指挥官埋头修 | 无人协调、混乱 | IC 专职指挥 |
| 信息不透明 | 干系人焦虑、施压 | 定期同步 + 状态页 |
| 指责个人 | 隐瞒文化、事故重演 | 无指责复盘，改系统 |
| 复盘无行动项 / 不追踪 | 白复盘 | 行动项有主、有期限、可追踪 |
9、动手实验 🎯
任务：为贯穿项目「团队任务清单」做一次完整的事故演练 + 复盘。
- 制定分级标准：为你的项目写出 P0~P3 的定义与响应方式。
- 写 Runbook：为"接口 5xx 飙升"写一份处置手册（先查什么、怎么回滚）。
- 演练一次事故：故意部署一个会挂的版本（如 DB 连接池设成 1），触发告警。
- 走响应流程：分级 → 拉"虚拟群" → 先回滚止血 → 记录时间线（每个动作留时间戳）。
- 写复盘报告：按上面 8 段结构写一份完整 Postmortem（含 5 Whys、时间线）。
- 定行动项：给出 3 条可追踪的改进项，每条有 owner 和期限。
- 反思：这次事故中，如果换成"指责式"处理，团队行为会有什么不同？
第五阶段结束。下一阶段：维护与退役——从第 29 课「维护的四种类型」开始。
10、今天你带走的三句话
- 事故响应先止血、后诊断；分级、定角色、勤沟通。
- 无指责复盘：追系统、不追人——让错误难以发生。
- 行动项必须可追踪落地，否则复盘就是走过场。
下一阶段：维护与退役。