Vue.js

Appearance

On this page

场景2——排查一个线上Bug ​

场景描述 ​

周二上午，运营同事在群里说：

"@开发 用户反馈下单失败，已经有好几个人说了，
能看一下吗？"

附带几张用户截图，都是点击"提交订单"按钮没反应。

这是线上Bug排查场景。

你可能的第一反应是直接看代码，但这不是最高效的方式。

CPERF应用 ​

C - Capture 捕获 ​

第一步：定义问题

"下单失败"可能是很多问题：

可能的情况：
1. 前端按钮无响应
2. 请求发了但后端报错
3. 后端正常但返回失败
4. 特定条件下才失败

需要先搞清楚问题是什么。

收集信息：

问运营：
1. 大概有多少用户反馈？
2. 是所有用户都有问题，还是部分用户？
3. 是特定的商品/支付方式有问题，还是都有问题？
4. 问题是什么时候开始的？

运营回复：
"大概5-6个人反馈了，好像都是用支付宝的。
今天上午才开始有反馈，昨天没人说。"

看监控数据：

服务器日志：发现从今早9点开始有支付回调失败
错误信息：支付宝回调签名验证失败
报错数量：40多次

问题定义：

问题：支付宝支付回调签名验证失败
触发条件：用户选择支付宝支付
开始时间：今早9点
影响范围：所有支付宝订单

P - Process 处理 ​

问题分类：

这是一个因果排查问题——找到导致签名验证失败的原因。

假设可能的原因：

假设1：代码改动导致
→ 查最近的发布记录：今早没有发布，排除

假设2：配置改动导致
→ 查配置变更记录：今早8:50运维改过支付配置，有嫌疑

假设3：第三方问题
→ 查支付宝公告：没有变更通知，先排除

假设4：证书过期
→ 查证书有效期：到明年，排除

定位原因：

查看8:50的配置变更：
运维把支付宝appId从生产环境的换成了测试环境的
原因：运维在测试一个新功能，不小心改到了生产环境

问题根因：

支付宝appId被错误改成测试环境的值，
导致签名验证失败

E - Express 表达 ​

向运营反馈（简洁版）：

"问题找到了，是配置问题，正在修复，预计5分钟恢复。"

向领导汇报（完整版）：

"支付宝支付问题排查结果：

问题：今早9点开始，支付宝支付全部失败
原因：8:50的配置变更把appId改成了测试环境的值
影响：约40笔订单受影响
解决：已恢复正确配置，支付已恢复
后续：
1. 排查受影响的订单，联系用户重新支付
2. 配置变更流程增加二次确认机制"

R - Review 复盘 ​

复盘排查过程：

做得好的：
1. 先收集信息再排查，没有盲目看代码
2. 假设驱动排查，有条理
3. 快速定位到配置变更

可以改进的：
1. 一开始没有第一时间看监控，浪费了一些时间
2. 配置变更应该有审批流程，避免误操作

复盘根本原因：

直接原因：运维误改配置
根本原因：
1. 配置变更没有审批流程
2. 生产和测试环境配置没有隔离

F - Form 固化 ​

记录排查模式：

线上问题排查流程：
1. 先看监控和日志，定位问题范围
2. 查最近的变更（代码发布、配置变更）
3. 假设可能原因，逐一验证
4. 定位根因后先修复，再分析

改进措施：

1. 配置变更增加审批流程
2. 生产环境配置和测试环境物理隔离
3. 配置变更后自动触发健康检查

关键要点 ​

要点1：先收集信息，再动手排查 ​

❌ 一收到问题就看代码
✅ 先问清楚问题的范围、条件、时间

信息收集得越充分，排查方向越准确。

要点2：假设驱动排查 ​

列出可能的原因 → 逐一验证 → 排除或确认

假设1：代码改动 → 查发布记录 → 排除
假设2：配置变更 → 查变更记录 → 确认
假设3：第三方问题 → 查公告 → 排除

要点3：从变更入手 ​

线上问题大概率是最近的变更导致的：

查什么变更：
1. 代码发布
2. 配置变更
3. 数据库变更
4. 依赖服务变更

问什么问题：
- 最近有发布吗？
- 有配置改动吗？
- 有依赖服务变更吗？

要点4：先恢复，再分析 ​

发现问题 → 快速恢复 → 事后分析

不要在用户还在受影响的时候慢慢分析原因。
先让系统恢复正常，再做深入分析。

要点5：区分直接原因和根本原因 ​

直接原因：运维误改配置
→ 解决：恢复正确配置

根本原因：配置变更没有审批流程
→ 解决：增加审批流程

只解决直接原因，下次还会出问题。
要解决根本原因，防止类似问题再发生。

本场景的CPERF检查清单 ​

markdown
□ Capture
  - 问题的范围清楚了吗？（多少用户、什么条件）
  - 问题的时间清楚了吗？（什么时候开始）
  - 看过监控和日志了吗？

□ Process
  - 列出了可能的原因吗？
  - 查过最近的变更了吗？
  - 逐一验证假设了吗？
  - 找到根因了吗？

□ Express
  - 向相关方反馈进展了吗？
  - 说明了问题原因和影响吗？
  - 提出了改进措施吗？

□ Review
  - 复盘排查过程了吗？
  - 区分了直接原因和根本原因吗？
  - 制定了防止再发的措施吗？

□ Form
  - 记录了排查模式吗？
  - 落实改进措施了吗？

排查流程模板 ​

markdown
## 问题基本信息
- 问题描述：
- 影响范围：
- 开始时间：
- 发现方式：

## 排查过程
### 假设1：
- 验证方式：
- 结果：

### 假设2：
- 验证方式：
- 结果：

## 根因分析
- 直接原因：
- 根本原因：

## 解决措施
- 临时方案：
- 长期方案：

## 后续改进
1. ...
2. ...

小结 ​

线上Bug排查的核心方法：

  1. 先收集信息，定义问题范围
  2. 假设驱动，逐一验证
  3. 从最近的变更入手
  4. 先恢复，再分析
  5. 区分直接原因和根本原因

下一章，我们看技术选型决策场景。

在 GitHub 上编辑此页