1. 故障排查概述：概念、重要性、通用流程

故障排查，说白了就是当系统出了幺蛾子时，我们怎么快速定位问题、把服务拉回来。很多人觉得这活儿靠运气、靠直觉。其实不是。我自己摸爬滚打十几年，踩过的坑比代码还多，慢慢发现：真正靠谱的排查，背后都有一套固定的逻辑框架。今天我们就来把这张底牌翻出来看看。

1.1 到底什么是故障排查

故障排查，英文叫 Troubleshooting，不是瞎猜，也不是重启大法。它是一套系统性方法——从观察现象开始，到假设验证，再到根因定位，最后修复验证。你想想看，如果没有这套方法，遇到问题就抓瞎，那跟修车全靠踹两脚有什么区别？

我个人的习惯是：先把故障定义清楚。什么叫“定义清楚”？就是能用一句话说清“谁出了什么问题，对用户产生了什么影响”。例如：“数据库主库响应延迟超过5秒，导致用户登录页面超时”。而不是“系统很慢”。只有定义清楚，后续才能对症下药。

还有一个容易被忽视的点：故障不等于 Bug。Bug 是代码写错了，故障可能是配置不对、资源耗尽、网络抖动，甚至某个同事手滑删了表。我在一家电商公司见过最离谱的“故障”——其实是运维同学在测试环境跑压测，结果压测流量配错了域名，把生产链路打崩了。你看，这根本不算代码问题，但排查过程是一模一样的。

1.2 为什么这件事这么重要

重要性我不多说，但可以给你三个现实视角：

1. 影响面：一次重大故障，可能让公司损失几百万，甚至直接丢掉客户。我当年在金融公司，一次核心交易链路中断 12 分钟，合规罚款加用户赔偿，金额让我瞠目。
2. 效率：没有方法地排查，一小时、两小时、甚至一天都找不出原因。而按照流程走，平均 15 分钟就能定位到根因。这差距就是团队里“有经验”和“没经验”的分水岭。
3. 团队信任：每次出问题，老板和产品都会眼巴巴看着你。如果你每次都慌得一批，别人怎么信你？反过来，你沉下心，按步骤来，哪怕暂时没找到，大家也知道你在控制节奏。

说白了，故障排查能力就是运维工程师的核心竞争力，没有之一。

1.3 通用流程：五个关键步骤

下面这张图是我自己整理出来的通用流程，几乎适用于所有类型的故障。从“发现问题”到“复盘归档”，一步都不能跳。

1.4 每一步怎么走？我自己的实操经验

第一步：发现与告警

问题往往不是你主动找到的，而是告警先响。这时候最忌讳的是马上冲进去查日志。先冷静，问三个问题：

• 什么时间开始？持续了多久？
• 影响范围多大？是全挂还是部分？
• 有没有明显的变更刚刚上线？

我记得有一回半夜被告警吵醒，告警说“API 错误率飙升”，我第一反应是代码漏洞，折腾了十分钟才发现——原来是同事刚刚更新了 nginx 配置，把上游的 timeout 改成了 1 秒。你看，如果一开始就查代码，方向偏到姥姥家。

第二步：信息收集

收集信息要全而精。全是指不遗漏：日志、监控图、调用链、系统资源（CPU/内存/IO/网络）、甚至最近的操作日志。精是指只抓关键窗口：故障发生前后各五分钟的数据。

第三步：假设与验证

这是最能体现工程师水平的一步。好的工程师不是靠猜，而是靠假设 - 验证 - 排除的循环。我常用 MECE 法则——将可能的根因分门别类，互斥且穷尽。例如：

每个假设都要用最小成本、最快速度去验证。能看监控就不上机器，能查日志就不重启。

第四步：修复与验证

修复分两步：先止血，再根治。
止血：切流量、回滚版本、重启、加机器，目的是让服务尽快可用。
根治：定位到根因后写代码改配置，走变更流程。

验证同样重要。修复完不是说“好了就完事了”，要观察至少一个业务周期（通常 10~30 分钟），确认没有复发。我吃过亏：有一次改了数据库索引，业务秒级恢复，但没注意到索引变更导致慢查询变成了全表扫描，十分钟后把从库打飘了。

第五步：复盘与归档

这一步最容易被忽略，但恰恰是团队成长的关键。复盘不是为了追责，而是为了让相同的错误不再重复。我个人建议输出一份故障报告，包含：

• 故障时间线（精确到秒）
• 根因分析（5 Whys）
• 临时措施与最终解决方案
• 改进 CheckList

归档后，下一次遇到类似问题，直接搜文档，效率翻倍。

1.5 流程之外的三个原则

说了这么多流程，我再补充三个原则，都是我这些年踩坑总结出来的：

1. 不要慌，先收数据。 人一慌就会乱操作，乱操作就会让线索消失。只要数据在手，问题就跑不掉。
2. 每次只改一个变量。 排查时最怕“试试这个，再试试那个”，最后把自己绕晕。如果你改了多个地方才恢复，你永远不知道根因是哪个。
3. 能用脑子想，不要靠手试。 动手前花 30 秒想清楚：这个操作会不会让故障恶化？有没有回滚方案？没有把握就不要碰生产。