Appearance
场景5——处理一次线上事故
场景描述
周三下午3点，监控告警疯狂响：
【P0告警】订单服务请求量下降90%
【P0告警】支付成功率从99.9%降到10%
【P0告警】用户投诉量激增这是线上事故场景。
和普通Bug不同，线上事故有几个特点：
- 影响大，用户正在受损
- 时间紧，每分钟都在损失
- 压力大，所有人都在盯着
这种情况下，更需要有章法地处理。
CPERF应用
C - Capture 捕获（2分钟内）
第一时间：确认事故范围
快速确认：
1. 影响范围：所有用户还是部分用户？
2. 核心功能：哪些功能受影响？
3. 持续时间：什么时候开始的？从监控看：
发现：
- 订单创建请求量正常
- 支付回调成功率暴跌
- 开始时间：14:52快速定义问题：
问题：支付功能异常，成功率从99.9%降到10%
影响：用户无法完成支付
开始：14:52（已持续约10分钟）P - Process 处理（并行进行）
事故处理的核心原则：先恢复，再定位。
优先级：
1. 恢复服务（止血）
2. 定位原因（找原因）
3. 根本解决（修复）恢复服务的常见方式：
方式1：回滚
最近有发布吗？有的话先回滚
方式2：降级
能不能临时关闭出问题的功能，保证其他功能正常？
方式3：切流
能不能切到备用系统？
方式4：扩容
是不是流量太大导致的？扩容能解决吗？本次事故处理：
查发布记录：14:45有一次发布
→ 决策：先回滚
回滚后：
→ 支付成功率回升到99.9%
→ 服务恢复定位原因：
对比14:45发布的代码变更：
发现：新代码修改了支付回调的签名校验逻辑
具体问题：漏了一个参数，导致签名校验失败E - Express 表达
事故过程中的沟通：
14:55（发现问题）：
"支付出问题了，正在排查，先别慌。"
15:00（定位方向）：
"怀疑是最近的发布导致的，准备回滚。"
15:05（执行恢复）：
"正在回滚，预计2分钟恢复。"
15:07（恢复完成）：
"已回滚，支付恢复正常，继续排查根因。"事故报告（事后）：
markdown
## 事故报告
### 基本信息
- 事故等级：P0
- 影响范围：所有用户支付功能
- 影响时间：14:52 - 15:07，共15分钟
- 影响量：约500笔支付失败
### 事故经过
- 14:45 发布新版本
- 14:52 支付成功率开始下降
- 14:55 收到告警，开始排查
- 15:00 定位到是发布导致，决定回滚
- 15:05 开始回滚
- 15:07 回滚完成，服务恢复
### 根因分析
- 直接原因：新代码签名校验逻辑bug
- 根本原因：代码Review漏检，测试覆盖不足
### 改进措施
1. 【短期】修复签名校验bug，补充单元测试
2. 【中期】支付模块增加发布后自动检查
3. 【长期】完善代码Review checklist，重点检查支付相关代码
### 后续跟进
- 联系支付失败的用户，引导重新支付
- 补偿措施：发放优惠券R - Review 复盘
事故复盘会：
复盘维度：
1. 发现时效
- 从问题发生到收到告警：3分钟
- 评估：可以接受，但能否更快？
2. 响应效率
- 从告警到开始排查：3分钟
- 评估：OK
3. 恢复时效
- 从开始处理到恢复：12分钟
- 评估：还行，但能否更快？回滚流程能否优化？
4. 根因分析
- 为什么这个bug没有在测试阶段发现？
- Code Review为什么没发现？根本原因分析：
5 Whys分析：
为什么支付失败？
→ 签名校验bug
为什么有bug？
→ 代码修改时漏了一个参数
为什么没发现？
→ Code Review没注意到
为什么Review没注意到？
→ 没有专门的支付模块Review checklist
为什么没有checklist？
→ 之前没出过类似问题，没想到要做F - Form 固化
事故处理SOP：
markdown
## 线上事故处理流程
### 第一阶段：确认（2分钟内）
1. 确认告警是否真实
2. 确认影响范围和严重程度
3. 拉相关人员进群
### 第二阶段：恢复（优先级最高）
1. 检查最近是否有发布，有的话考虑回滚
2. 评估是否可以降级/切流
3. 执行恢复操作
### 第三阶段：定位
1. 恢复后继续排查根因
2. 不要在用户受影响时慢慢查
### 第四阶段：复盘
1. 当天或第二天开复盘会
2. 产出事故报告
3. 制定改进措施关键要点
要点1：先恢复，再定位
错误做法：用户还在受影响，你在慢慢查原因
正确做法：先用最快的方式恢复服务，再查原因
能回滚就回滚
不能回滚就降级
不能降级就扩容或切流要点2：保持沟通
事故处理过程中，定期同步进展：
- 发现问题了
- 在排查
- 准备采取什么措施
- 预计多久恢复
- 已恢复
不要闷头干，让相关人知道进展。要点3：事故等级决定响应级别
P0（核心功能不可用）：
- 所有人放下手头工作
- 立即处理
- 领导层关注
P1（重要功能受损）：
- 优先处理
- 1小时内恢复
P2（一般问题）：
- 正常处理
- 当天解决
P3（轻微问题）：
- 排期处理要点4：复盘要找根本原因
不要只停留在直接原因：
"代码有bug" → 为什么有bug？为什么没测出来？
找到根本原因，才能防止类似问题再发生。要点5：改进措施要落地
复盘不是为了写报告，是为了改进。
改进措施要：
1. 具体可执行
2. 有责任人
3. 有完成时间
4. 有验证方式本场景的CPERF检查清单
markdown
□ Capture（发现阶段）
- 确认了影响范围吗？
- 确认了开始时间吗？
- 通知了相关人员吗？
□ Process（处理阶段）
- 优先考虑恢复而不是定位吗？
- 检查了最近的变更吗？
- 选择了最快的恢复方式吗？
□ Express（沟通阶段）
- 定期同步进展了吗？
- 恢复后通知相关方了吗？
- 事故报告完整吗？
□ Review（复盘阶段）
- 开复盘会了吗？
- 找到根本原因了吗？
- 改进措施具体吗？
□ Form（固化阶段）
- 更新了事故处理SOP吗？
- 改进措施落地了吗？事故报告模板
markdown
## 事故报告
### 基本信息
- 事故等级：
- 影响范围：
- 影响时间：
- 影响量：
### 事故经过
（时间线）
### 根因分析
- 直接原因：
- 根本原因：
### 改进措施
1. 【短期】
2. 【中期】
3. 【长期】
### 后续跟进小结
线上事故处理的核心方法：
- 先恢复，再定位
- 保持沟通，定期同步
- 复盘要找根本原因
- 改进措施要落地
记住：用户每多等一分钟，损失就多一分。速度是第一优先级。
下一章，我们看说服别人接受方案的场景。