故障排查的通用流程与思维框架

碰到一个线上故障，你第一步会做什么？

我以前刚带团队时，经常有人冲过来说："服务器挂了，快看看！"然后一群人围着日志乱翻。

这其实是典型的"无头苍蝇"式排查。效率极低不说，还容易漏掉关键线索。

后来我总结了一套通用流程。不管你是修服务器、调代码、还是处理硬件故障，这套框架都管用。说白了，就是给排查装上导航。

第一步：明确问题现象

别急着动手。先问清楚：到底出了什么问题？

• 现象是什么？ 比如"页面加载慢"还是"完全打不开"？
• 影响范围？ 是所有用户都挂了，还是只有某个地区？
• 出现时间？ 是刚上线后发生，还是已经持续半小时？
• 是否有规律？ 每次操作必现，还是偶尔抽风？

我的习惯是让报障人写一段完整描述。写不出来的话，我就自己操作一遍。嗯，这一步最容易被忽略，但往往决定后面能不能少走弯路。

第二步：收集信息与复现

光靠嘴说不够，得拿证据。

• 日志： 应用日志、系统日志、访问日志，按时间窗口拉出来。
• 监控： CPU、内存、磁盘、网络、QPS、错误率曲线。
• 配置： 最近有没有改过配置？谁改的？改了什么？
• 版本： 代码版本、中间件版本、依赖库版本。
• 复现： 尽量在测试环境复现。复现不了，至少留下现场快照。

我在项目中遇到过：有一次线上报"订单重复创建"，但日志里查不到任何异常。后来发现是业务方改了一个配置项，把幂等校验关了。如果没有收集配置变更信息，这问题能查三天。

第三步：提出假设与优先级排序

信息到手了，脑子里开始冒各种可能性。但别一个个试，要排优先级。

1. 先高概率、低成本： 比如检查数据库连接池是否满，看一眼监控就行。
2. 再高概率、高成本： 比如回滚版本，虽然有效但影响大。
3. 低概率的放最后： 比如怀疑内核bug，除非其他都排除了。

你想想看，如果一上来就去抓包分析网络协议，万一只是个配置写错了呢？白白浪费半小时。

第四步：验证假设（二分法/隔离法）

这一步最关键，也是最能体现功力的地方。我常用的两个办法：

举个例子：一个API响应超时，入口网关、认证服务、业务服务、数据库各环节都可能慢。我用二分法——先在业务服务这边打个时间戳，发现请求进来后3秒才到数据库，那问题就锁在业务服务内部。再接着二分法查，最后发现是某次代码升级里多了个循环等待锁。

第五步：定位根因

验证通过后，你得找到真正的"罪魁祸首"。不是表面现象，而是根本原因。

• 比如"CPU飙高"不是根因，根因可能是"死循环"或"频繁GC"。
• "接口报500"不是根因，根因可能是"连接池泄漏"或"索引缺失"。

我一般用"5Why法"：对每个现象连续问5个为什么，直到挖到代码/配置/环境层面的具体问题。问不出来就说明信息不够，继续收集。

第六步：修复与回归验证

改代码、改配置、重启……修复后别急着下班。

• 验证修复： 在相同场景下复现旧问题，确认不再出现。
• 回归测试： 看看有没有引入新问题。特别是改数据库索引时，查查慢查询有没有变多。
• 监控观察： 上线后至少观察15分钟，盯着关键指标。
• 记录复盘： 把现象、根因、修复方案、耗时写成文档。下次再遇到，直接搜索就行。

好，流程讲完了。下面这张图把这六步串了起来，你可以贴在工位边当速查表。

这套流程看起来简单，但真正执行起来，最难的是第三、四步。很多人跳过了假设排序，直接上手试——试到哪个算哪个。我见过最极端的情况：一个人连着重启了六台机器，最后才发现是DNS配置错了。

所以，记住：先想清楚，再动手。动手时一次只改一个。