4. 故障排查方法论：从5W1H到根因分析
故障排查这事儿，干久了你会发现，技术问题往往不是最难搞的。最难搞的，是乱。是大家一窝蜂冲上去，你改一下配置，我重启一下服务，最后问题莫名其妙好了，谁也不知道真正原因是什么。
所以我一直强调，故障排查必须有一套方法论。没有方法，你就是在碰运气。今天这一章，我就把压箱底的那套东西拿出来聊聊。
4.1 故障排查的5W1H原则
5W1H不是什么新鲜概念，但用在故障排查上，特别好使。说白了，就是让你在动手之前，先把问题搞清楚。
| 要素 | 含义 | 故障排查中的具体问题 |
|---|---|---|
| What | 发生了什么 | 具体是什么故障？是服务挂了，还是响应慢了？错误码是什么？ |
| Why | 为什么会发生 | 初步判断可能的原因是什么？代码变更？配置修改？外部依赖？ |
| Where | 发生在哪里 | 影响哪个机房？哪个集群？哪个服务实例？哪个用户群体？ |
| When | 什么时候发生的 | 首次出现时间？持续多久？是否有规律？是否与发布窗口重合？ |
| Who | 谁发现的/谁影响的 | 监控告警发现的？用户反馈的？影响了多少用户？ |
| How | 如何发生的/如何复现 | 复现步骤是什么？触发条件是什么？ |
举个例子。有一次半夜被叫起来，说支付接口超时。我按5W1H捋了一遍：
- What：支付接口HTTP 503，响应时间超过30秒。
- Why：初步怀疑是数据库连接池耗尽。
- Where：只影响华南区机房，其他区域正常。
- When：22:15开始，持续至今。
- Who：监控告警触发，影响约2000笔交易。
- How：复现？直接请求接口即可复现。
你看，这么一整理，排查方向就很清晰了——直奔华南区机房的数据库连接池。
4.2 故障定级与响应流程
不是所有故障都值得半夜爬起来。我见过有些团队，磁盘使用率到80%就发P0告警，结果运维天天睡不好觉，真正出大事的时候反而麻木了。
故障定级，核心就两个维度：影响范围和影响程度。
| 级别 | 定义 | 响应要求 | 示例 |
|---|---|---|---|
| P0 | 核心业务完全不可用，影响大量用户 | 立即响应，5分钟内拉起应急群，全员投入 | 支付接口全挂、数据库主库宕机 |
| P1 | 核心功能严重受损，但非完全不可用 | 15分钟内响应，安排核心人员处理 | 下单成功率低于50%、首页加载超10秒 |
| P2 | 非核心功能异常，或影响少量用户 | 1小时内响应，可走常规工单流程 | 某个报表页面打不开、个别用户登录失败 |
| P3 | 轻微问题，不影响业务 | 24小时内处理，可排入迭代 | 页面样式错乱、日志中少量WARN |
响应流程这块，我推荐一个简单的三阶段模型：
- 止血阶段：先恢复服务，别管原因。重启、回滚、切流量，怎么快怎么来。
- 排查阶段：服务恢复后，再慢慢查根因。这时候可以看日志、查监控、拉代码。
- 根治阶段：找到根因后，修复代码或配置，并补充监控和告警。
很多人容易犯一个错——止血和排查混在一起。一边重启一边看日志，结果重启完了，日志也被冲掉了。我的建议是：先止血，再排查，分清楚。
4.3 故障复盘与根因分析
故障复盘，不是为了追责。是为了下次不再掉进同一个坑里。
我参与过上百次复盘，发现一个规律：大多数故障的根因，都不是"某个人操作失误"，而是"系统设计有缺陷"。
根因分析，我常用5 Whys法。就是连续问五个"为什么"，直到找到真正的根因。
现象：线上服务OOM（内存溢出）。
- 为什么OOM？→ 因为堆内存被占满，GC无法回收。
- 为什么堆内存被占满？→ 因为有一个缓存Map无限增长。
- 为什么缓存Map无限增长？→ 因为没有设置过期策略。
- 为什么没有设置过期策略？→ 因为开发同学不知道这个Map会被频繁写入。
- 为什么开发同学不知道？→ 因为代码评审没有覆盖到这个逻辑，且没有相关的监控。
真正的根因：代码评审流程不完善 + 缺少缓存容量监控。
你看，问到最后，根因往往落在流程和机制上。这才是复盘要解决的问题。
复盘报告怎么写？我一般包含这几个部分：
- 故障概述：一句话说清楚发生了什么。
- 时间线：从故障发生到恢复，精确到分钟。
- 根因分析：用5 Whys或其他方法，找到真正的根因。
- 改进措施：列出具体的TODO，并指定负责人和截止时间。
- 经验教训：这次故障教会了我们什么。
嗯，这里要注意一点：时间线一定要客观。不要写"10:00 发现故障，10:05 开始排查"，要写"10:00 监控告警触发，10:03 值班人员确认，10:05 拉起应急群"。越客观，越能发现问题。
4.4 知识体系总览
下面这张图，是我对故障排查方法论的一个总结。你可以把它当作一个检查清单，每次遇到故障，照着走一遍。
你想想看，有了这套方法论，是不是心里踏实多了？遇到故障不再慌，按步骤来就行。说白了，故障排查拼的不是手速，是思路。