线上事故响应流程
# 线上事故响应流程
告警→定位→止损→复盘→改进——出事后前三分钟最重要
# 一、事故发生的三分钟——做对这三件事
告警响了，你的第一反应是什么？
❌ 慌 → 本能地打开代码找 bug → 找了 20 分钟没找到 → 用户一直在受影响
❌ 在群里说"我去看一下" → 没人知道你在看什么，也没人知道谁在协调
✅ 前三分钟的标准动作：
第 1 分钟：确认影响面
→ 多少人受影响？核心功能还是边缘功能？哪个服务/接口？
→ 直接看监控面板，不是去猜
第 2 分钟：宣布事故
→ 在事故响应群里发：时间、现象、影响面、当前在做什么
→ 指定 Incident Commander（事故指挥官，通常是第一个发现的人或 oncall）
第 3 分钟：止损优先
→ 重启？回滚？降级？切流量？——先止血，再找根因
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
前三分钟的铁律：止血优先于查因。 用户不关心你用了什么架构，用户只关心"功能什么时候恢复"。你花 20 分钟定位到根因但用户已经流失了——这不是英雄，这是事故处理失败。
# 二、止损——四种武器
| 武器 | 怎么做 | 耗时 | 适用场景 |
|---|---|---|---|
| Feature Flag | 关掉有问题的新功能开关 | 秒级 | 新功能引发的故障 |
| 回滚 | 部署上一个已知稳定的版本 | 5-15 分钟 | 刚上线的新版有 bug |
| 降级 | 关闭非核心功能，保证核心路径可用 | 分钟级 | 整体负载过高或有级联故障 |
| 切换 | 把流量切到备用集群/灾备环境 | 分钟级 | 基础设施故障（机房/云服务） |
你至少要有两种止损手段。 如果只有一个"等运维回滚"——你的止损能力就是运维的响应速度，不靠谱。
# 三、事故指挥官——不是官衔，是职责
事故指挥官（IC）的职责不是自己修——是让修的人不被干扰。
IC 做什么：
① 宣布事故级别（P0/P1/P2），决定是否需要全团队 stop-the-line
② 确认影响面，通知 stakeholders（运营/客服/管理层）
③ 协调各小组分工：一组止血，一组查根因，一组和外部团队沟通
④ 记录时间线：几点几分做了什么，结果如何
⑤ 决定什么时候宣布事故结束
IC 不做什么：
① 不亲自排查代码（除非团队只有一个人）
② 不接受"好像修好了"——必须确认修复措施已验证
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
# 四、复盘——不追责，追根因
# 4.1 复盘不是批斗会
❌ "这次事故是谁的锅？"
→ 一旦开始追责，没有人会如实描述发生了什么。复盘的价值归零。
✅ "我们的什么流程/工具/监控放过了这个错误？"
→ 即使是一个人的疏忽——为什么系统允许一个人的疏忽造成事故？
→ 没有 code review 拦住？没有自动化测试覆盖？没有灰度？
1
2
3
4
5
6
2
3
4
5
6
# 4.2 复盘报告的结构
## 事故概要
- 时间：2024-01-15 14:30 - 15:20（持续 50 分钟）
- 级别：P1（核心支付功能不可用）
- 影响：约 500 个订单支付失败，直接损失约 ¥8000
## 时间线
14:28 部署 v2.3.1 到生产环境
14:30 监控告警：支付接口错误率从 0.01% 升至 5%
14:32 IC 宣布 P1 事故，启动止损
14:35 确认和 v2.3.1 有关，开始回滚
14:40 回滚到 v2.3.0，错误率降到 0.01%——止血完成
14:45 确认支付功能恢复正常
15:20 事故结束，开始写复盘
## 根因分析（5 Why）
为什么支付失败？
→ 支付接口返回 500
为什么返回 500？
→ 支付服务调用新版本的配置中心，配置缺失
为什么配置缺失？
→ v2.3.1 新增了一个必填配置项，发布时没有同步到生产配置中心
为什么没有同步？
→ 发布 checklist 里没有"检查新增配置项"这一步
为什么 checklist 没有？
→ 我们从未有正式的发布 checklist
## 改进措施
□ [P0 立即] 紧急修复 v2.3.1 并验证配置完整 → 负责人：张三，今天完成
□ [P1 本周] 制定发布 checklist 模板 → 负责人：李四，本周五前
□ [P2 下 Sprint] 配置中心增加"新增配置项必须在所有环境存在"的校验 → 负责人：王五
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# 4.3 复盘产出必须是 actionable 的
❌ "加强风险意识"
→ 这是鸡汤，不是改进措施。没人知道怎么执行。
✅ "发布流程增加一个环节：配置变更必须有第二个人的 review"
→ 有人负责、有时间节点、可以验证是否完成。
每一条改进措施都要有：做什么 + 谁做 + 什么时候做完。
1
2
3
4
5
6
7
2
3
4
5
6
7
# 五、事故分级——不是所有问题都是 P0
P0（Critical）：核心业务流程完全不可用
→ 登录、注册、支付、下单不可用
→ 全团队 stop-the-line，5 分钟内启动响应
→ 目标：15 分钟内止血
P1（High）：核心功能部分不可用 / 非核心功能完全不可用
→ 支付成功率下降但不完全中断、某个非核心页面 404
→ 指定至少 2 人处理，通报 stakeholders
→ 目标：2 小时内修复
P2（Medium）：非核心问题，不影响主流程
→ 某个管理后台页面样式错乱、边缘功能的性能下降
→ 正常 Sprint 中排优先级修复
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
不要把 P2 升级成 P1——不是要轻视问题，是不要把所有人的注意力频繁打断。
# 六、小结
事故响应的五个阶段：
1. 发现 → 监控告警、用户反馈、oncall 值班发现
2. 止损 → 重启/回滚/降级/Feature Flag——先止血，再查因
3. 定位 → 对着监控面板 + 日志找根因。如果 30 分钟找不到 → 拉人帮忙
4. 复盘 → 5 Why 挖根因，产出 actionable 的改进措施，不追责
5. 改进 → 每条措施有负责人和 deadline，下次 Retro 验收
最重要的一句话：前三分钟做对"确认影响面→宣布事故→止损优先"，比后面三小时做对一切都重要。
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
行动清单：
- [ ] 你们团队有事故响应群吗？没有的话建一个，把 oncall 值班表贴进去
- [ ] 你上一次发布有没有可用的 Feature Flag？没有的话给下一个功能加上
- [ ] 模拟一次事故——在 staging 环境断开一个服务，团队按流程走一遍（谁当 IC？怎么宣布？怎么止损？）
上次更新: 2026/06/15, 14:32:53
