架构设计 4-高可用架构之FMEA方法

导读：《架构设计》系列为极客时间李运华老师《从0开始学架构》课程笔记。本文为第三部分，主要介绍 FMEA 方法，以及如何将 FMEA 方法应用于架构设计之中以提高服务可用性。

什么是FMEA

FMEA（Failure mode and effects analysis，故障模式与影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等

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

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

FMEA 分析表

功能点

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

故障模式

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

故障模式的描述要尽量精确，多使用量化描述，避免使用泛化的描述

故障影响

当发生故障模式中描述的故障时，功能点具体会受到什么影响。常见的影响有：

功能点偶尔不可用
功能点完全不可用
部分用户功能点不可用
功能点响应缓慢
功能点出错等

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

严重程度

严重程度指站在业务的角度故障的影响程度

一般分为“致命 / 高 / 中 / 低 / 无”五个档次

严重程度按照这个公式进行评估：严重程度 = 功能点重要程度 × 故障影响范围 × 功能点受损程度

故障原因

不同的故障原因发生概率不相同

不同的故障原因检测手段不一样

不同的故障原因的处理措施不一样

故障概率

这里的概率就是指某个具体故障原因发生的概率。具体评估的时候需要重点关注：

硬件：硬件随着使用时间推移，故障概率会越来越高
开源系统：成熟的开源系统 bug 率低，刚发布的开源系统 bug 率相比会高一些；自己已经有使用经验的开源系统 bug 率会低，刚开始尝试使用的开源系统 bug 率会高
自研系统：和开源系统类似，成熟的自研系统故障概率会低，而新开发的系统故障概率会高

风险程度

风险程度就是综合严重程度和故障概率来一起判断某个故障的最终等级

风险程度 = 严重程度 × 故障概率。因此可能出现某个故障影响非常严重，但其概率很低，最终来看风险程度就低

已有措施

针对具体的故障原因，系统现在是否提供了某些措施来应对。主要措施：

检测告警：最简单的措施就是检测故障，然后告警，系统自己不针对故障进行处理，需要人工干预。
容错：检测到故障后，系统能够通过备份手段应对。例如，MySQL 主备机，当业务服务器检测到主机无法连接后，自动连接备机读取数据。
自恢复：检测到故障后，系统能够自己恢复。例如，Hadoop 检测到某台机器故障后，能够将存储在这台机器的副本重新分配到其他机器。

规避措施

规避措施指为了降低故障发生概率而做的一些事情。主要手段：

技术手段：为了避免新引入的 MongoDB 丢失数据，在 MySQL 中冗余一份。
管理手段：为了降低磁盘坏道的概率，强制统一更换服务时间超过 2 年的磁盘。

解决措施

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

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

后续规划

综合前面的分析，就可以看出哪些故障我们目前还缺乏对应的措施，哪些已有措施还不够，针对这些不足的地方，再结合风险程度进行排序，给出后续的改进规划。这些规划既可以是技术手段，也可以是管理手段；可以是规避措施，也可以是解决措施。同时需要考虑资源的投入情况，优先将风险程度高的系统隐患解决。

个人理解

FMEA 方法是一种分析问题的方法，一共列出了 11 个点，我们在分析架构问题的时候，按照每个点逐一去适配、分析。有点按图索骥的意思，简单理解，就是它给我们一些要分析的点，避免分析问题的时候动抓一把，西抓一把的。个人认为，FMEA 方法在在线服务领域一个很好的应用场景就是复盘或者叫case study。

reference

从 0 开始学架构

关注公众号回复 “架构设计” 获取全部思维导图