3. 故障分类与模式：常见故障类型、故障模式分析、优先级划分
做故障复现这么多年，我最大的体会是：不会分类，就没法下手。你想想看，一个系统出了几十个告警，如果眉毛胡子一把抓，最后大概率是哪个都查不透。
这一章，我们就聊聊怎么给故障分门别类，怎么分析它的模式，以及——更重要的——怎么排优先级。
3.1 常见故障类型：先分清楚敌人是谁
我个人习惯把故障分成三大类。这分类不是我发明的，但我在项目里反复验证过，确实好用。
| 故障类型 | 典型特征 | 我遇到的真实案例 |
|---|---|---|
| 硬件故障 | 物理损坏、信号异常、功耗超标 | 某次服务器集群半夜宕机，最后发现是电源模块电容鼓包了 |
| 软件故障 | 逻辑错误、竞态条件、内存泄漏 | 一个定时任务偶尔不执行，查了三天，发现是时区转换的闰秒处理有bug |
| 交互故障 | 协议不匹配、超时配置冲突、接口变更 | 两个微服务之间偶尔丢数据，原因是它们对消息体长度的理解不一致 |
我的小技巧： 拿到故障报告后，先花5分钟做「三选一」——到底是硬件、软件还是交互？这一步选对了，后面至少少走一半弯路。
3.2 故障模式分析：拆开来看，每个故障都有「套路」
故障模式分析，说白了就是给故障做「解剖」。我习惯用下面这个框架来拆解。
3.2.1 故障模式六要素
每个故障，我都会问自己六个问题：
- 触发条件——什么情况下它才会出现？
- 故障表现——用户或监控看到了什么？
- 影响范围——它影响了哪些功能或模块？
- 持续时间——是瞬时的，还是持续到人为干预？
- 恢复方式——重启就行，还是必须换硬件？
- 根因归属——是设计缺陷，还是运维操作失误？
举个例子。我曾经处理过一个「数据库连接池耗尽」的故障：
- 触发条件：业务高峰时段，并发请求超过连接池上限
- 故障表现：应用层报错「无法获取连接」，部分请求超时
- 影响范围：所有依赖该数据库的服务
- 持续时间：持续到连接被手动释放或服务重启
- 恢复方式：重启应用服务，临时扩容连接池
- 根因归属：设计缺陷——连接池大小未按峰值预估
核心观点： 故障模式分析不是写论文，而是为了快速定位。六要素填完，你基本就知道该从哪里下手了。
3.2.2 常见故障模式速查表
下面这张表，是我这些年积累下来的「高频故障模式」。你遇到类似情况，可以直接对照着查。
| 模式名称 | 典型场景 | 排查方向 |
|---|---|---|
| 雪崩效应 | 一个服务挂了，导致上游全部超时 | 检查熔断、限流、超时设置 |
| 资源泄漏 | 内存、句柄、连接数持续增长 | 检查资源释放逻辑，做压力测试 |
| 竞态条件 | 偶发、难以复现，多线程下才出现 | 加日志、加锁、做线程安全分析 |
| 配置漂移 | 同一套配置在不同环境表现不同 | 对比配置文件，检查配置中心 |
| 时序依赖 | 先A后B正常，先B后A就报错 | 检查启动顺序、依赖初始化 |
注意： 千万不要把「偶发」当成「没规律」。我曾经有一个故障，半年才出现三次，每次都在凌晨3点。后来发现是定时任务和日志归档撞在了一起。偶发，只是你还没找到规律。
3.3 优先级划分：把有限的精力，花在最该花的地方
故障来了，不是所有都要立刻扑上去。我见过不少团队，被低优先级的告警拖垮了精力，真正的大故障来了反而没力气处理。
3.3.1 我的优先级矩阵
我习惯用「影响范围 × 紧急程度」来排优先级。下面这个矩阵，我用了快十年。
3.3.2 各优先级处理策略
| 优先级 | 响应时间 | 处理方式 | 我的经验 |
|---|---|---|---|
| P1 | 立即（15分钟内） | 全员介入，先恢复再排查 | 先切流量或回滚，别在故障现场修代码 |
| P2 | 4小时内 | 指定负责人，制定修复计划 | 这类故障最容易「拖成P1」，要盯紧 |
| P3 | 24小时内 | 记录跟踪，定期回顾 | 我习惯每周五下午集中处理P3 |
| P4 | 无硬性要求 | 放入技术债务清单 | 别删，留着做趋势分析用 |
避坑指南： 我曾经犯过一个错——把P3的告警全部静默了。结果三个月后，这个「低优先级」的告警频率从每天1次变成了每小时50次，最后酿成了P1事故。所以，低优先级不等于不处理，只是处理节奏慢一点。
3.4 故障模式库：把经验沉淀下来
最后，我想聊聊「故障模式库」。这东西听起来高大上，其实就是一个文档——把你遇到过的故障，按我们上面说的分类、模式、优先级，一条条记下来。
我自己的模式库长这样：
# 故障模式库示例条目
---
ID: FM-2024-003
类型: 软件故障
模式: 资源泄漏
优先级: P2
触发条件: 长时间运行（>72小时）后，连接数达到上限
故障表现: 新请求无法建立连接，已有连接正常
根因: 连接池中的空闲连接未及时回收
解决方案: 增加空闲连接超时回收机制
复现步骤:
1. 启动服务
2. 持续发送请求72小时
3. 观察连接数曲线
验证方法: 修复后运行168小时，连接数稳定在阈值80%以下
我的建议： 模式库不需要很复杂，一个Markdown文件就够了。关键是——每次复现成功，都要更新它。我见过太多团队，故障复现完了就完了，下次遇到同样的坑，又从头查起。