1. 故障排查基础：思维模型、分级机制与通用流程
大家好，我是老张。做运维这行十几年了，踩过的坑比吃过的盐还多。今天咱们聊聊故障排查的基础——说白了，就是遇到问题别慌，心里有张地图。
很多人觉得排查故障靠经验、靠直觉。我不完全同意。经验当然重要，但如果没有一套系统的方法论，你就像在黑屋子里找开关，全靠瞎摸。我刚开始带团队时，就吃过这个亏。
1.1 故障排查的思维模型
先说说思维模型。这东西听起来玄乎，其实就是一套固定的思考套路。我个人习惯用两种：STAR 和 5W1H。
STAR 模型
STAR 本来是面试用的，但用在故障排查上，意外地好用。
| 字母 | 含义 | 故障排查中的应用 |
|---|---|---|
| S | Situation（情境） | 当前系统状态、环境、版本 |
| T | Task（任务） | 系统本该做什么 |
| A | Action（行动） | 你做了什么操作 |
| R | Result（结果） | 实际发生了什么 |
举个例子。有一次线上数据库突然变慢，我第一反应不是去看慢查询，而是先问自己：
- Situation：数据库是 MySQL 8.0，16核32G，跑了半年没重启过
- Task：正常处理业务请求，平均响应时间应该在 10ms 以内
- Action：半小时前刚上线了一个新功能，加了几个索引
- Result：现在响应时间飙到了 500ms
你看，这么一梳理，问题方向就清晰了——大概率是新索引导致的。果然，有个索引建错了字段。
5W1H 模型
5W1H 更细一些。我一般在 STAR 之后用，用来深挖根因。
- What：发生了什么故障？
- When：什么时候开始的？
- Where：影响范围多大？哪个模块？
- Who：谁发现的？谁最近改过东西？
- Why：为什么会这样？
- How：怎么恢复的？怎么避免？
嗯，这里要注意。很多人问完 Why 就停了。我曾经也是这样，结果同一个故障反复出现。后来我养成了习惯——必须把 How 也问清楚，尤其是「怎么避免」。
1.2 故障分级与响应机制
不是所有故障都值得半夜爬起来。我见过有人因为一个非核心页面 502 就拉全组开会，也见过有人把核心支付链路挂了当普通报警处理。这两种，都挺要命的。
所以，分级很重要。下面是我在团队里推的一套标准：
| 级别 | 定义 | 响应时间 | 处理方式 |
|---|---|---|---|
| P0 | 核心业务完全不可用，或数据丢失 | 5分钟内响应 | 立即拉群，全员介入 |
| P1 | 核心业务部分受损，或大面积报错 | 15分钟内响应 | 值班工程师处理，必要时升级 |
| P2 | 非核心功能异常，有替代方案 | 2小时内响应 | 正常工单流程 |
| P3 | 体验问题，不影响功能 | 下一个工作日 | 排期修复 |
响应机制方面，我建议搞一个「故障响应三板斧」：
- 止血：先恢复服务，别管根因。回滚、重启、切流量，哪个快用哪个。
- 排查：服务稳定了，再慢慢查原因。
- 复盘：写故障报告，定改进措施。
你想想看，很多人搞反了顺序。服务都挂了，还在那查日志、看代码。等查出来，用户早跑光了。
1.3 故障排查的通用流程
最后说说通用流程。我把它总结成 6 步，画了张图，你一看就明白。
这 6 步看着简单，但每一步都有坑。我挑几个重点说说。
第 2 步：收集信息
信息要全，但别贪多。我见过有人一上来就拉几 G 的日志，结果看了一天也没看出名堂。我的做法是：先看监控大盘，再看关键指标，最后才翻日志。顺序很重要。
第 3 步：假设验证
别只做一个假设。我习惯列 3 个最可能的根因，然后逐个排除。用二分法——先看是网络问题还是应用问题，再看是代码问题还是配置问题。一层层缩小范围。
第 6 步：复盘归档
这一步最容易被忽略。故障恢复了，大家就散了。但说实话，不复盘的故障，等于白修。我要求团队每次故障后 48 小时内必须出故障报告，内容包括：故障时间线、根因分析、改进措施、责任人。
嗯，说到责任人，不是追责，是跟踪改进项的落地。这个区别很重要。
好了，故障排查的基础就聊到这儿。记住一句话：故障不可怕，可怕的是没有方法。有了这套思维模型和流程，你至少不会在黑屋子里乱摸开关了。