第二章 故障模式与影响分析：常见故障类型与FMEA基础
大家好，我是你们的讲师。今天我们来聊聊故障模式与影响分析，也就是FMEA。说实话，这玩意儿在系统稳定性治理里，就像医生手里的听诊器——看着简单，但用好了能救命。
我刚开始做SRE那会儿，总觉得故障是随机的，碰上了算倒霉。后来踩的坑多了才明白：大部分故障都是有迹可循的。你想想看，如果能把常见的故障模式提前识别出来，再评估一下影响范围，很多线上事故其实是可以避免的。
2.1 常见故障类型
故障从哪儿来？我习惯把它们分成四大类：硬件、软件、网络、人为。咱们一个一个说。
2.1.1 硬件故障
硬件故障是最「实在」的故障。硬盘坏了、内存挂了、电源烧了，这些都是实打实的物理损坏。我在项目中遇到过一台服务器运行了三年多，硬盘突然出现大量坏道，导致数据库写入延迟飙升到十几秒。
常见的硬件故障包括：
- 磁盘故障：坏道、磁盘控制器失效、SSD磨损
- 内存故障：ECC错误、内存泄漏导致OOM
- CPU故障：过热降频、核心损坏
- 电源故障：电源模块损坏、电压不稳
- 网络设备故障：交换机端口失效、光模块老化
2.1.2 软件故障
软件故障就复杂多了。说白了，代码是人写的，是人就会犯错。我见过最离谱的一次，是某个同事在配置文件中把超时时间写成了0，结果所有请求都立即超时，整个服务直接瘫痪。
常见的软件故障类型：
- 代码Bug：空指针、死循环、并发竞争条件
- 配置错误：参数写错、环境变量遗漏、配置格式错误
- 依赖问题：第三方库版本冲突、API变更不兼容
- 内存泄漏：对象未释放、连接池未关闭
- 性能退化：算法效率下降、缓存失效导致雪崩
2.1.3 网络故障
网络故障是最让人头疼的。为什么？因为它的影响范围特别大，而且排查起来特别费劲。你想想看，一个交换机挂了，可能影响几百台服务器的通信。
常见的网络故障：
- 链路中断：光纤被挖断、网线松动
- 网络延迟：跨区域传输延迟、带宽瓶颈
- 丢包：网络拥塞、设备性能不足
- DNS解析失败：DNS服务器宕机、域名配置错误
- 负载均衡故障：健康检查失效、后端节点剔除异常
嗯，这里要注意：网络故障很多时候不是「全有或全无」的。比如丢包率从0.01%涨到0.5%，看起来不多，但对实时性要求高的服务来说，可能就是灾难。
2.1.4 人为故障
最后这个，也是最难防的——人为故障。说白了，就是操作失误。我见过最经典的案例：某运维同学在凌晨三点执行数据库迁移脚本，结果把生产库和测试库搞混了，直接删了生产环境的核心表。
常见的人为故障：
- 误操作：删错数据、改错配置、执行错误命令
- 变更失误：未走变更流程、回滚方案缺失
- 沟通不畅：信息传递错误、责任边界模糊
- 疲劳操作：凌晨加班导致注意力不集中
2.2 故障影响评估方法
知道了故障类型，接下来要评估影响。我常用的方法有三个维度：
2.2.1 影响范围评估
这个故障会影响多少用户？多少服务？多少数据？
| 影响级别 | 描述 | 示例 |
|---|---|---|
| 单点影响 | 只影响单个实例或单个用户 | 某台服务器磁盘满 |
| 局部影响 | 影响某个功能模块或部分用户 | 支付服务不可用 |
| 全局影响 | 影响整个系统或所有用户 | 数据库主库宕机 |
2.2.2 影响时长评估
故障会持续多久？这取决于：
- 发现时间：监控是否及时告警
- 定位时间：是否有完善的排查工具
- 恢复时间：是否有自动恢复机制
我习惯用MTTR（平均修复时间）来衡量。一个成熟的系统，MTTR应该控制在15分钟以内。超过这个时间，用户就开始流失了。
2.2.3 影响深度评估
这个故障会造成什么后果？数据丢失？功能降级？还是完全不可用？
- 数据层面：是否涉及数据持久化？是否有备份？
- 功能层面：核心功能是否受影响？是否有降级方案？
- 业务层面：是否影响收入？是否影响品牌声誉？
2.3 FMEA基础
FMEA，全称是Failure Mode and Effects Analysis，故障模式与影响分析。说白了，就是系统性地找出「哪里可能出问题」以及「出了问题会怎样」。
2.3.1 FMEA的核心要素
一个完整的FMEA包含三个核心要素：
- 故障模式：故障的具体表现形式。比如「数据库连接超时」
- 故障原因：导致故障的根本原因。比如「连接池耗尽」
- 故障影响：故障带来的后果。比如「用户无法登录」
2.3.2 FMEA的评估维度
我一般用三个维度来量化评估：
| 维度 | 评分标准（1-10分） | 说明 |
|---|---|---|
| 严重度(S) | 1=无影响，10=灾难性 | 故障造成的后果有多严重 |
| 发生度(O) | 1=几乎不发生，10=频繁发生 | 故障发生的概率有多高 |
| 检测度(D) | 1=极易检测，10=极难检测 | 故障被发现的难易程度 |
然后计算风险优先级数（RPN）：RPN = S × O × D
RPN越高，说明这个故障越需要优先处理。我一般把RPN超过100的列为高风险项，必须制定改进措施。
2.3.3 一个简单的FMEA示例
拿「用户登录服务」举个例子：
| 故障模式 | 原因 | 影响 | S | O | D | RPN |
|---|---|---|---|---|---|---|
| 登录接口超时 | 数据库连接池耗尽 | 用户无法登录 | 8 | 4 | 3 | 96 |
| 验证码发送失败 | 短信服务商故障 | 用户无法注册 | 6 | 2 | 5 | 60 |
| 密码校验错误 | 加密算法版本不兼容 | 用户登录失败 | 7 | 1 | 8 | 56 |
你看，登录接口超时的RPN是96，接近100了。那我们就得优先处理它——比如增加连接池监控、设置合理的超时时间、做熔断降级。
2.4 小结
这一章我们聊了故障的四大类型、影响评估方法，还有FMEA的基础。说实话，FMEA看起来就是填个表格，但真正用好它，需要你对系统有足够深的理解。我建议你从自己负责的系统开始，挑一个核心功能做一次FMEA分析，你会发现很多之前没注意到的风险点。
下一章我们会聊故障的预防策略，包括冗余设计、限流降级这些实战技巧。到时候见。