线上事故响应流程

告警→定位→止损→复盘→改进——出事后前三分钟最重要

一、事故发生的三分钟——做对这三件事

告警响了，你的第一反应是什么？
  ❌ 慌 → 本能地打开代码找 bug → 找了 20 分钟没找到 → 用户一直在受影响
  ❌ 在群里说"我去看一下" → 没人知道你在看什么，也没人知道谁在协调

✅ 前三分钟的标准动作：
  第 1 分钟：确认影响面
    → 多少人受影响？核心功能还是边缘功能？哪个服务/接口？
    → 直接看监控面板，不是去猜

  第 2 分钟：宣布事故
    → 在事故响应群里发：时间、现象、影响面、当前在做什么
    → 指定 Incident Commander（事故指挥官，通常是第一个发现的人或 oncall）

  第 3 分钟：止损优先
    → 重启？回滚？降级？切流量？——先止血，再找根因

前三分钟的铁律：止血优先于查因。 用户不关心你用了什么架构，用户只关心"功能什么时候恢复"。你花 20 分钟定位到根因但用户已经流失了——这不是英雄，这是事故处理失败。

---

二、止损——四种武器

武器	怎么做	耗时	适用场景
Feature Flag	关掉有问题的新功能开关	秒级	新功能引发的故障
回滚	部署上一个已知稳定的版本	5-15 分钟	刚上线的新版有 bug
降级	关闭非核心功能，保证核心路径可用	分钟级	整体负载过高或有级联故障
切换	把流量切到备用集群/灾备环境	分钟级	基础设施故障（机房/云服务）

你至少要有两种止损手段。 如果只有一个"等运维回滚"——你的止损能力就是运维的响应速度，不靠谱。

---

三、事故指挥官——不是官衔，是职责

事故指挥官（IC）的职责不是自己修——是让修的人不被干扰。

IC 做什么：
  ① 宣布事故级别（P0/P1/P2），决定是否需要全团队 stop-the-line
  ② 确认影响面，通知 stakeholders（运营/客服/管理层）
  ③ 协调各小组分工：一组止血，一组查根因，一组和外部团队沟通
  ④ 记录时间线：几点几分做了什么，结果如何
  ⑤ 决定什么时候宣布事故结束

IC 不做什么：
  ① 不亲自排查代码（除非团队只有一个人）
  ② 不接受"好像修好了"——必须确认修复措施已验证

---

四、复盘——不追责，追根因

4.1 复盘不是批斗会

❌ "这次事故是谁的锅？"
  → 一旦开始追责，没有人会如实描述发生了什么。复盘的价值归零。

✅ "我们的什么流程/工具/监控放过了这个错误？"
  → 即使是一个人的疏忽——为什么系统允许一个人的疏忽造成事故？
  → 没有 code review 拦住？没有自动化测试覆盖？没有灰度？

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] 配置中心增加"新增配置项必须在所有环境存在"的校验 → 负责人：王五

4.3 复盘产出必须是 actionable 的

❌ "加强风险意识"
  → 这是鸡汤，不是改进措施。没人知道怎么执行。

✅ "发布流程增加一个环节：配置变更必须有第二个人的 review"
  → 有人负责、有时间节点、可以验证是否完成。

每一条改进措施都要有：做什么 + 谁做 + 什么时候做完。

---

五、事故分级——不是所有问题都是 P0

P0（Critical）：核心业务流程完全不可用
  → 登录、注册、支付、下单不可用
  → 全团队 stop-the-line，5 分钟内启动响应
  → 目标：15 分钟内止血

P1（High）：核心功能部分不可用 / 非核心功能完全不可用
  → 支付成功率下降但不完全中断、某个非核心页面 404
  → 指定至少 2 人处理，通报 stakeholders
  → 目标：2 小时内修复

P2（Medium）：非核心问题，不影响主流程
  → 某个管理后台页面样式错乱、边缘功能的性能下降
  → 正常 Sprint 中排优先级修复

不要把 P2 升级成 P1——不是要轻视问题，是不要把所有人的注意力频繁打断。

---

六、事故指挥官（IC）培训——不是看一两篇文档就会的

6.1 IC 的三个关键决策

事故指挥官不需要是技术最强的人——需要是当前能最快做决策的人。

时刻	决策	如果决策错了
事故宣布后 1 分钟	是否需要升级？拉谁？	小事故拉了大老板 → 浪费高层时间
止损阶段	选择哪种止损方式？	选错了 → 延长影响时间
定位阶段	超过 30 分钟还没找到根因——是否继续查还是拉更多人？	一个人钻牛角尖 → 事故持续更久

6.2 IC 交接——必须有仪式感

如果事故超过 2 小时，必须换 IC。交接时口述以下四句话：

"当前状态是 [影响范围+持续时间]。我们试过了 [已尝试的止损手段]。目前怀疑根因是 [最可能的根因]。接下来需要 [下一步行动]。"

写进事故群，新 IC 不需要翻聊天记录就能接手。

七、事故演练常态化

频率	演练类型	内容
每季度	桌面推演	围绕一个"最怕发生的场景"，团队过一遍响应流程——不需要实际操作
每半年	staging 实战	在 staging 注入真实故障，团队按真实流程响应
每年	生产演练	在生产环境注入可控故障（如限流、降级），验证监控和告警

演练后的两个产出：

1. 复盘报告：发现的问题 + 改进措施（和真事故一样的格式）
2. 更新 Runbook：如果步骤过期了，当场更新

八、小结

事故响应五个阶段：
1. 发现 → 监控告警、用户反馈
2. 止损 → 重启/回滚/降级/Feature Flag——先止血
3. 定位 → 30 分钟找不到 → 拉人
4. 复盘 → 5 Why 挖根因，不追责
5. 改进 → 每条有负责人和 deadline
6. 演练 → 平时不练，真出事一定手忙脚乱

最重要：前三分钟做对"确认影响面→宣布事故→止损优先"

行动清单：

• [ ] 检查是否有事故响应群和 oncall 值班表
• [ ] 下一个新功能加 Feature Flag
• [ ] 在 staging 环境做一次事故演练——验证流程有没有生锈
• [ ] 给 IC 备一张"IC 四句话交接卡"——真的出事故时大脑一片空白，需要提示