FMEA方法，排除架构可用性隐患的利器

极客时间：《从 0 开始学架构》:FMEA方法，排除架构可用性隐患的利器

FMEA 方法，就是保证我们做到全面分析的一个非常简单但是非常有效的方法。

1、FMEA 介绍

FMEA（Failure mode and effects analysis，故障模式与影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等，FMEA 是一种在各行各业都有广泛应用的可用性分析方法，通过对系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以确定失效对于系统的最终影响。

FMEA 方法

在架构设计领域，FMEA 的具体分析方法是：

• 给出初始的架构设计图。
• 假设架构中某个部件发生故障。
• 分析此故障对系统功能造成的影响。
• 根据分析结果，判断架构是否需要进行优化。

常见的 FMEA 分析表格包含下面部分

1、功能点

当前的 FMEA 分析涉及的功能点，这里的“功能点”指的是从用户角度来看的，而不是从系统各个模块功能点划分来看的。

2、故障模式

故障模式指的是系统会出现什么样的故障，包括故障点和故障形式。需要特别注意的是，这里的故障模式并不需要给出真正的故障原因，我们只需要假设出现某种故障现象即可。

故障模式的描述要尽量精确，多使用量化描述，避免使用泛化的描述。如Mysql响应时间达到3秒，而不是MySQL 响应慢。

3、故障影响

当发生故障模式中描述的故障时，功能点具体会受到什么影响。常见的影响有：功能点偶尔不可用、功能点完全不可用、部分用户功能点不可用、功能点响应缓慢、功能点出错等。

故障影响也需要尽量准确描述。

4、严重程度

严重程度指站在业务的角度故障的影响程度，一般分为“致命 / 高 / 中 / 低 / 无”五个档次。严重程度按照这个公式进行评估：严重程度 = 功能点重要程度 × 故障影响范围 × 功能点受损程度。

5、故障原因

“故障模式”中只描述了故障的现象，并没有单独列出故障原因。主要原因在于不管什么故障原因，故障现象相同，对功能点的影响就相同。那为何这里还要单独将故障原因列出来呢？主要原因有这几个：

• 不同的故障原因发生概率不相同
• 不同的故障原因检测手段不一样
• 不同的故障原因的处理措施不一样

6、故障概率

这里的概率就是指某个具体故障原因发生的概率。一般分为“高 / 中 / 低”三档即可，具体评估的时候需要重点关注硬件/开源系统/自研系统/

7、风险程度

风险程度就是综合严重程度和故障概率来一起判断某个故障的最终等级，风险程度 = 严重程度 × 故障概率。因此可能出现某个故障影响非常严重，但其概率很低，最终来看风险程度就低。

8、已有措施

针对具体的故障原因，系统现在是否提供了某些措施来应对，包括：检测告警、容错、自恢复等。

9、规避措施

规避措施指为了降低故障发生概率而做的一些事情，可以是技术手段，也可以是管理手段。

10、解决措施

解决措施指为了能够解决问题而做的一些事情，一般都是技术手段。

• 为了解决密码暴力破解，增加密码重试次数限制。
• 为了解决拖库导致数据泄露，将数据库中的敏感数据加密保存。
• 为了解决非法访问，增加白名单控制。

11、后续规划

综合前面的分析，就可以看出哪些故障我们目前还缺乏对应的措施，哪些已有措施还不够，针对这些不足的地方，再结合风险程度进行排序，给出后续的改进规划。

附：FMEA分析表举例