故障排查基础：分类、方法论与工具链
大家好，我是老张。今天咱们聊聊故障排查的底层逻辑。说实话，我见过太多运维新人一上来就扎进日志里，像无头苍蝇一样乱撞。结果呢？折腾半天，问题没定位到，反而把生产环境搞得更乱了。
为什么会这样？说白了，就是缺少一套系统化的故障排查思维。今天我就把这套「心法」拆开揉碎了讲给你听。
一、故障分类与分级：先搞清楚你面对的是什么
我个人习惯，遇到任何故障，第一件事不是动手，而是先分类。你想想看，网络抖动和数据库死锁，排查思路能一样吗？
1. 按故障来源分类
| 分类 | 典型场景 | 排查方向 |
|---|---|---|
| 硬件故障 | 磁盘坏道、内存ECC错误、网卡丢包 | dmesg、smartctl、硬件监控 |
| 软件故障 | OOM、死锁、配置错误、版本兼容 | 日志、堆栈、配置审计 |
| 网络故障 | 延迟抖动、丢包、DNS解析失败 | ping、traceroute、tcpdump |
| 人为故障 | 误操作、变更回滚失败、权限错配 | 审计日志、变更记录 |
| 外部依赖故障 | 云服务商宕机、第三方API超时 | 依赖监控、降级策略 |
我的经验：有一次线上告警说「服务不可用」，我排查了半小时才发现是上游的Redis集群挂了。从那以后，我养成了先看依赖链路的习惯。你想想看，如果一开始就盯着自己的代码，方向就错了。
2. 按故障严重程度分级
这里我推荐大家用P0-P4的分级方式。嗯，这个分级直接决定了你的响应速度和资源投入。
- P0（紧急）：核心业务完全不可用，比如支付接口挂了、用户登录失败。需要立即响应，全员投入。
- P1（严重）：核心功能部分受损，比如某个API响应超时、页面加载慢。需要15分钟内响应。
- P2（一般）：非核心功能异常，比如后台报表生成失败。可以走正常工单流程。
- P3（轻微）：体验问题，比如某个按钮样式错乱。排期修复即可。
- P4（建议）：优化建议，比如日志格式不规范。纳入技术债管理。
注意：我曾经见过一个团队，把P3的故障当成P0来处理，结果全员熬夜加班，第二天核心业务反而出问题了。分级不是摆设，它是资源调度的依据。
二、故障排查方法论：5W1H 与 PDCA
方法论这东西，听起来很虚，但真正用起来，能帮你节省至少一半的排查时间。我建议你把它刻在脑子里。
1. 5W1H 分析法：问对问题，才能找对答案
遇到故障，先问自己六个问题：
- What（发生了什么？）—— 是服务挂了？还是响应慢了？具体现象是什么？
- When（什么时候发生的？）—— 是持续性的？还是偶发的？有没有时间规律？
- Where（影响范围？）—— 是单台机器？还是整个集群？是某个地域？还是全局？
- Who（谁影响的？）—— 是代码变更？是配置修改？还是外部依赖？
- Why（为什么？）—— 根本原因是什么？是设计缺陷？还是资源不足？
- How（如何解决？）—— 临时方案是什么？长期方案是什么？
实战案例：有一次线上告警「订单创建成功率下降50%」。我按5W1H走了一遍：
- What：订单创建接口超时率飙升
- When：10分钟前，正好是灰度发布后5分钟
- Where：只影响新版本节点，旧版本正常
- Who：新发布的代码中，有一个数据库连接池配置被改小了
- Why：连接池耗尽，请求排队超时
- How：立即回滚，修复配置后重新发布
整个过程不到15分钟。如果没有这套方法论，我可能还在看CPU、看内存、看网络...浪费时间。
2. PDCA 循环：持续改进的闭环
故障排查不是修完就完了。我建议你养成PDCA的习惯：
- Plan（计划）：制定排查方案，确定优先级和资源分配。
- Do（执行）：按方案执行排查，记录每一步的发现。
- Check（检查）：验证排查结果是否正确，临时方案是否有效。
- Act（行动）：制定长期修复方案，更新监控告警，完善应急预案。
我的习惯：每次故障处理完，我都会写一份「故障复盘报告」。内容包括：故障时间线、根因分析、临时方案、长期方案、改进措施。这份报告不仅是给领导看的，更是给自己看的。下次遇到类似问题，翻出来看看，能省不少事。
三、故障排查工具链概览：工欲善其事，必先利其器
工具这东西，不在多，在于精。我见过有人电脑上装了上百个工具，真正用起来的不到10个。下面是我个人常用的工具链，按排查阶段分类：
1. 监控告警阶段
| 工具 | 用途 | 我的评价 |
|---|---|---|
| Prometheus + Grafana | 指标采集与可视化 | 开源标配，灵活度高 |
| ELK / Loki | 日志聚合与搜索 | 排查问题时，日志是第一手资料 |
| Alertmanager | 告警管理与路由 | 别让告警变成噪音 |
2. 问题定位阶段
- 网络层：ping、traceroute、mtr、tcpdump、Wireshark
- 系统层：top、htop、vmstat、iostat、sar、dmesg
- 应用层：jstack、jmap、arthas、strace、perf
- 数据库层：慢查询日志、show processlist、explain、pg_stat_activity
避坑指南：我曾经在排查一个CPU飙升问题时，用top看了半天，发现是Java进程占满了CPU。然后我直接用jstack打印线程堆栈，发现是一个死循环。如果当时我盲目重启，问题根本不会解决。记住：工具要用对地方。
3. 根因分析阶段
- 代码层面：Git blame、代码审查、diff对比
- 配置层面：配置中心审计、版本对比、变更记录
- 依赖层面：链路追踪（Jaeger、Zipkin）、依赖拓扑图
4. 恢复与复盘阶段
- 自动化恢复：Ansible、SaltStack、Kubernetes自愈
- 复盘工具：Confluence、Notion、故障复盘模板
我的建议：不要试图记住所有工具的用法。你只需要记住：遇到什么问题，该用什么工具。比如网络问题，先ping再tcpdump；应用问题，先看日志再看堆栈。工具是死的，思路是活的。
总结
好了，今天的内容就到这里。总结一下：
- 故障分类分级帮你快速判断问题的严重程度和排查方向。
- 5W1H帮你问对问题，PDCA帮你形成闭环。
- 工具链是手段，不是目的。别被工具绑架了。
下一章，我会带你深入实战，用真实案例演示如何一步步排查一个典型的「服务不可用」故障。到时候，咱们把今天学的方法论和工具链串起来用一遍。
我是老张，咱们下章见。