一、故障排查概述

说实话，干了这么多年运维，我见过太多人在故障面前手忙脚乱了。有的人上来就重启，有的人直接翻文档，还有的人干脆打电话求助。这些做法不能说错，但效率真的不高。

故障排查，说白了就是一套系统化的方法。它不是玄学，也不是靠运气。我个人的理解是：用最短的时间，找到问题的根因，然后把它干掉。

什么是故障排查

故障排查，英文叫 Troubleshooting。它不是一个动作，而是一整套流程。你想想看，系统出问题了，你总得先知道问题在哪，然后才能动手修吧？

我在项目中遇到过这么一件事：有一次线上数据库响应突然变慢，开发同学二话不说就开始加索引。结果呢？加了半天，问题更严重了。后来我一查，发现是磁盘 IO 被打满了，跟索引半毛钱关系都没有。

所以，故障排查的核心就三点：

• 定位问题：症状是什么？影响范围多大？
• 分析根因：为什么会这样？是代码问题还是环境问题？
• 解决问题：怎么修？修完之后怎么验证？

故障排查的流程

我习惯把故障排查分成五个步骤。这五个步骤不是死规矩，但照着做，至少不会跑偏。

第一步：收集信息

故障发生了，第一件事不是修，而是问。问谁？问用户、问监控、问日志。

• 用户怎么说？「页面打不开了」「接口报 502 了」
• 监控怎么说？CPU 飙到 99% 了？内存快爆了？
• 日志怎么说？有没有 ERROR 级别的报错？

嗯，这里要注意：信息收集得越全，后面分析就越省事。我曾经因为少看了一条日志，多花了两个小时排查。

第二步：确定范围

问题影响多大？是单台机器还是整个集群？是某个用户还是所有用户？

举个例子：如果只有一个人报故障，那可能是他网络有问题。如果所有人都报故障，那肯定是服务端出事了。这个判断，能帮你省掉大量无用功。

第三步：假设验证

根据已有信息，提出几个可能的根因。然后一个一个去验证。

我常用的方法是「二分法」：把可能的原因分成两半，先验证最可能的那一半。比如网络问题，先看是不是 DNS 解析失败，再看是不是防火墙拦截了。

第四步：定位根因

这一步，就是找到那个「罪魁祸首」。可能是代码里的一个空指针，也可能是配置文件里少了一个分号。

我见过最离谱的一次，是某个同事把生产环境的数据库连接池配成了 1。结果并发一上来，所有请求都在排队。排查了整整一天，最后发现是配置文件的注释写错了。

第五步：修复与验证

找到根因了，那就修吧。修完之后，一定要验证。怎么验证？

• 功能验证：业务正常了吗？
• 压力验证：扛得住吗？
• 回滚方案：万一修坏了，能快速回退吗？

故障排查的思维模型

流程是死的，人是活的。真正拉开差距的，是思维方式。我总结了几种常用的思维模型，分享给你。

1. 5W1H 分析法

这是最基础的模型。问自己六个问题：

维度	问题	示例
What	发生了什么？	接口返回 500 错误
When	什么时候开始的？	今天上午 10:15 分
Where	影响哪些模块？	订单服务、支付服务
Who	谁影响的？	刚上线的版本 v2.3.1
Why	为什么会这样？	数据库连接池耗尽
How	怎么修复？	扩容连接池，重启服务

这六个问题问完，问题基本就清晰了。说白了，就是「把模糊的问题，变成具体的问题」。

2. 因果链分析

故障很少是单一原因导致的。很多时候，是多个因素叠加在一起，才出了问题。

举个例子：

• 表象：用户登录失败
• 直接原因：Redis 连接超时
• 间接原因：Redis 所在机器 CPU 被打满
• 根本原因：某个定时任务在高峰期执行了全量数据同步

你看，如果不追到最底层，只修了 Redis 连接超时，问题迟早还会再出现。

3. 排除法

这个最简单，也最实用。把所有可能的原因列出来，一个一个排除。

我习惯用「二分排除法」：先看是不是网络问题，再看是不是应用问题，最后看是不是数据问题。每一层再继续二分，直到找到根因。

4. 逆向思维

有时候，正向推理走不通，那就反过来想。

比如：系统突然变慢了。正向想，可能是代码效率低。逆向想，会不会是资源被抢占了？一查，果然有个后台任务在疯狂写日志，把磁盘 IO 占满了。

这种思维方式，说白了就是「跳出问题本身，从外部找原因」。

总结一下

故障排查这件事，说难也难，说简单也简单。难的是，你永远不知道下一个故障会是什么样。简单的是，只要掌握了方法和思维模型，大部分问题都能搞定。

我个人觉得，做运维最重要的不是技术有多牛，而是心态要稳。遇到故障别慌，按流程走，用思维模型分析，一步一步来。实在搞不定，就求助。别死扛，也别乱动。

嗯，这一章就聊到这。下一章，我们聊聊具体的日志分析工具，比如 grep、awk、sed 这些老伙计。到时候我会分享一些实战中总结出来的骚操作，保证让你眼前一亮。