故障模式与影响分析（FMEA）

FMEA 这玩意儿，说白了就是「事前找茬」。

系统还没上线，代码还没跑起来，我们就得坐下来，把可能出问题的地方一个个揪出来。我刚开始做稳定性工作时，总觉得这是浪费时间——有这功夫不如多写几行代码。直到有一次线上事故，事后复盘发现，如果提前做过 FMEA，那个问题根本不会发生。嗯，从那以后，我再也不敢跳过这个步骤了。

FMEA 基础概念

FMEA 的全称是 Failure Mode and Effects Analysis，中文叫「故障模式与影响分析」。它是一套系统化的方法，用来识别潜在的故障模式，分析它们的影响，然后制定措施来降低风险。

核心就三个问题：

• 什么东西会坏？（故障模式）
• 坏了会怎样？（影响分析）
• 我们该怎么办？（改进措施）

你想想看，这其实跟医生看病很像。先问症状（故障模式），再判断病情严重程度（影响），最后开药方（改进措施）。

FMEA 有几个关键角色：

• 功能：系统或组件应该做什么
• 故障模式：功能失效的具体表现
• 影响：故障对系统、用户或业务造成的后果
• 原因：导致故障发生的根本原因
• 控制措施：预防或检测故障的手段

严重度 / 频度 / 探测度评分标准

FMEA 的核心是三个维度的评分：严重度（S）、频度（O）、探测度（D）。每个维度 1-10 分，分数越高越危险。

严重度（Severity）

故障发生后，对系统或用户的影响程度。说白了就是「这事儿有多严重」。

评分	描述	示例
1-2	几乎无影响，用户无感知	页面加载慢 100ms
3-4	轻微影响，部分功能降级	某个非核心按钮不可用
5-6	中等影响，核心功能受损	下单流程中断，但数据不丢
7-8	严重影响，系统不可用	全站 502，持续 10 分钟
9-10	灾难性影响，数据丢失或资损	用户余额清零，无法恢复

频度（Occurrence）

故障发生的可能性。说白了就是「这事儿多久来一次」。

评分	描述	参考概率
1	几乎不可能发生	< 1/10000
2-3	很少发生	1/10000 - 1/1000
4-6	偶尔发生	1/1000 - 1/100
7-8	经常发生	1/100 - 1/10
9-10	几乎必然发生	> 1/10

频度评分要基于历史数据和经验判断。我个人的习惯是，先看线上监控数据，如果没有数据，就参考类似系统的故障频率。

探测度（Detection）

故障被发现的难易程度。说白了就是「出事了多久能发现」。

评分	描述	示例
1	几乎肯定能被发现	有自动化告警，秒级响应
2-3	容易被发现	有监控，但延迟几分钟
4-6	可能被发现	需要人工巡检才能发现
7-8	很难被发现	用户投诉后才知晓
9-10	几乎不可能被发现	数据静默错误，无任何告警

RPN 风险优先级计算

RPN 的全称是 Risk Priority Number，风险优先级数。计算公式很简单：

RPN = 严重度（S） × 频度（O） × 探测度（D）

三个维度的分数相乘，得到一个 1 到 1000 之间的数值。数值越大，风险越高，越需要优先处理。

举个例子：

• 某个故障的严重度是 8（严重影响），频度是 5（偶尔发生），探测度是 3（容易被发现）
• RPN = 8 × 5 × 3 = 120

另一个故障：

• 严重度是 4（轻微影响），频度是 9（几乎必然发生），探测度是 8（很难被发现）
• RPN = 4 × 9 × 8 = 288

你看，第二个故障虽然严重度低，但因为频度高、难发现，RPN 反而更高。这就是 RPN 的价值——它帮你找到那些「不起眼但很要命」的风险。

下面这张图展示了 FMEA 的核心流程：

做完 FMEA 后，你会得到一张表格，里面列出了所有潜在的故障模式、它们的 S/O/D 评分、RPN 值，以及对应的改进措施。这张表就是你的「风险地图」，后续的稳定性工作都要围绕它来展开。