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

我在前面的专栏分析高可用复杂度的时候提出了一个问题：高可用和高性能哪一个更复杂，大部分同窗都分析出了正确的答案：高可用更复杂一些，主要缘由在于异常的场景不少，只要有一个场景遗漏，架构设计就存在可用性隐患，而根据墨菲定律“可能出错的事情最终都会出错”，架构隐患总有一天会致使系统故障。所以，咱们在进行架构设计的时候必须全面分析系统的可用性，那么如何才能作到“全面”呢？

我今天介绍的FMEA 方法，就是保证咱们作到全面分析的一个很是简单可是很是有效的方法。

FMEA 介绍

FMEA（Failure mode and effects analysis，故障模式与影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等，专栏采用“故障模式与影响分析”，由于这个中文翻译更加符合可用性的语境。FMEA 是一种在各行各业都有普遍应用的可用性分析方法，经过对系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以肯定失效对于系统的最终影响。

FMEA 最先是在美国军方开始应用的，20 世纪 40 年代后期，美国空军正式采用了 FMEA。尽管最初是在军事领域创建的方法，但 FMEA 方法如今已普遍应用于各类各样的行业，包括半导体加工、餐饮服务、塑料制造、软件及医疗保健行业。FMEA 之因此可以在这些差别很大的领域都获得应用，根本缘由在于 FMEA 是一套分析和思考的方法，而不是某个领域的技能或者工具。

回到软件架构设计领域，FMEA 并不能指导咱们如何作架构设计，而是当咱们设计出一个架构后，再使用 FMEA 对这个架构进行分析，看看架构是否还存在某些可用性的隐患。

FMEA 方法

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

• 给出初始的架构设计图。

• 假设架构中某个部件发生故障。

• 分析此故障对系统功能形成的影响。

• 根据分析结果，判断架构是否须要进行优化。

FMEA 分析的方法其实很简单，就是一个 FMEA 分析表，常见的 FMEA 分析表格包含下面部分。

1.功能点

当前的 FMEA 分析涉及的功能点，注意这里的“功能点”指的是从用户角度来看的，而不是从系统各个模块功能点划分来看的。例如，对于一个用户管理系统，使用 FMEA 分析时 “登陆”“注册”才是功能点，而用户管理系统中的数据库存储功能、Redis 缓存功能不能做为 FMEA 分析的功能点。

2.故障模式

故障模式指的是系统会出现什么样的故障，包括故障点和故障形式。须要特别注意的是，这里的故障模式并不须要给出真正的故障缘由，咱们只须要假设出现某种故障现象便可，例如 MySQL 响应时间达到 3 秒。形成 MySQL 响应时间达到 3 秒可能的缘由不少：磁盘坏道、慢查询、服务器到 MySQL 的链接网络故障、MySQL bug 等，咱们并不须要在故障模式中一一列出来，而是在后面的“故障缘由”一节中列出来。由于在实际应用过程当中，无论哪一种缘由，只要现象是同样的，对业务的影响就是同样的。

此外，故障模式的描述要尽可能精确，多使用量化描述，避免使用泛化的描述。例如，推荐使用“MySQL 响应时间达到 3 秒”，而不是“MySQL 响应慢”。

3.故障影响

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

故障影响也须要尽可能准确描述。例如，推荐使用“20% 的用户没法登陆”，而不是“大部分用户没法登陆”。要注意这里的数字不须要彻底精确，好比 21.25% 这样的数据实际上是没有必要的，咱们只须要预估影响是 20% 仍是 40%。

4.严重程度

严重程度指站在业务的角度故障的影响程度，通常分为“致命 / 高 / 中 / 低 / 无”五个档次。严重程度按照这个公式进行评估：严重程度 = 功能点重要程度 × 故障影响范围 × 功能点受损程度。一样以用户管理系统为例：登陆功能比修改用户资料要重要得多，80% 的用户比 20% 的用户范围更大，彻底没法登陆比登陆缓慢要更严重。所以咱们能够得出以下故障模式的严重程度。

• 致命：超过 70% 用户没法登陆。

• 高：超过 30% 的用户没法登陆。

• 中：全部用户登陆时间超过 5 秒。

• 低：10% 的用户登陆时间超过 5 秒。

• 中：全部用户都没法修改资料。

• 低：20% 的用户没法修改头像。

对于某个故障的影响到底属于哪一个档次，有时会出现一些争议。例如，“全部用户都没法修改资料”，有的人认为是高，有的人可能认为是中，这个没有绝对标准，通常建议相关人员讨论肯定便可。也不建议花费太多时间争论，争执不下时架构师裁定便可。

5.故障缘由

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

• 不一样的故障缘由发生几率不相同

例如，致使 MySQL 查询响应慢的缘由多是 MySQL bug，也多是没有索引。很明显“MySQL bug”的几率要远远低于“没有索引”；而不一样的几率又会影响咱们具体如何应对这个故障。

• 不一样的故障缘由检测手段不同

例如，磁盘坏道致使 MySQL 响应慢，那咱们须要增长机器的磁盘坏道检查，这个检查极可能不是当前系统自己去作，而是另外运维专门的系统；若是是慢查询致使 MySQL 慢，那咱们只须要配置 MySQL 的慢查询日志便可。

• 不一样的故障缘由的处理措施不同

例如，若是是 MySQL bug，咱们的应对措施只能是升级 MySQL 版本；若是是没有索引，咱们的应对措施就是增长索引。

6.故障几率

这里的几率就是指某个具体故障缘由发生的几率。例如，磁盘坏道的几率、MySQL bug 的几率、没有索引的几率。通常分为“高 / 中 / 低”三档便可，具体评估的时候须要有如下几点须要重点关注。

• 硬件

硬件随着使用时间推移，故障几率会愈来愈高。例如，新的硬盘坏道概率很低，但使用了 3 年的硬盘，坏道概率就会高不少。

• 开源系统

成熟的开源系统 bug 率低，刚发布的开源系统 bug 率相比会高一些；本身已经有使用经验的开源系统 bug 率会低，刚开始尝试使用的开源系统 bug 率会高。

• 自研系统

和开源系统相似，成熟的自研系统故障几率会低，而新开发的系统故障几率会高。

高中低是相对的，只是为了肯定优先级以决定后续的资源投入，没有必要绝对量化，由于绝对量化是须要成本的，并且不少时候都无法量化。例如，XX 开源系统是 3 个月故障一次，仍是 6 个月才故障一次，是没法评估的。

7.风险程度

风险程度就是综合严重程度和故障几率来一块儿判断某个故障的最终等级，风险程度 = 严重程度 × 故障几率。所以可能出现某个故障影响很是严重，但其几率很低，最终来看风险程度就低。“某个机房业务瘫痪”对业务影响是致命的，但若是故障缘由是“地震”，那几率就很低。例如，广州的地震几率就很低，5 级以上地震的 20 世纪才 1 次（1940 年）；若是故障的缘由是“机房空调烧坏”，则几率就比地震高不少了，多是 2 年 1 次；若是故障的缘由是“系统所在机架掉电”，这个几率比机房空调又要高了，多是 1 年 1 次。一样的故障影响，不一样的故障缘由有不一样的几率，最终获得的风险级别就是不一样的。

8.已有措施

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

• 检测告警

最简单的措施就是检测故障，而后告警，系统本身不针对故障进行处理，须要人工干预。

• 容错

检测到故障后，系统可以经过备份手段应对。例如，MySQL 主备机，当业务服务器检测到主机没法链接后，自动链接备机读取数据。

• 自恢复

检测到故障后，系统可以本身恢复。例如，Hadoop 检测到某台机器故障后，可以将存储在这台机器的副本从新分配到其余机器。固然，这里的恢复主要仍是指“业务”上的恢复，通常不太可能将真正的故障恢复。例如，Hadoop 不可能将产生了磁盘坏道的磁盘修复成没有坏道的磁盘。

9.规避措施

规避措施指为了下降故障发生几率而作的一些事情，能够是技术手段，也能够是管理手段。例如：

• 技术手段：为了不新引入的 MongoDB 丢失数据，在 MySQL 中冗余一份。

• 管理手段：为了下降磁盘坏道的几率，强制统一更换服务时间超过 2 年的磁盘。

10.解决措施

解决措施指为了可以解决问题而作的一些事情，通常都是技术手段。例如：

• 为了解决密码暴力破解，增长密码重试次数限制。

• 为了解决拖库致使数据泄露，将数据库中的敏感数据加密保存。

• 为了解决非法访问，增长白名单控制。

通常来讲，若是某个故障既能够采起规避措施，又能够采起解决措施，那么咱们会优先选择解决措施，毕竟能解决问题固然是最好的。但不少时候有些问题是系统本身没法解决的，例如磁盘坏道、开源系统 bug，这类故障只能采起规避措施；系统可以本身解决的故障，大部分是和系统自己功能相关的。

11.后续规划

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

例如：

• 地震致使机房业务中断：这个故障模式就没法解决，只能经过备份中心规避，尽可能减小影响；而机柜断电致使机房业务中断：能够经过将业务机器分散在不一样机柜来规避。

• 敏感数据泄露：这个故障模式能够经过数据库加密的技术手段来解决。

• MongoDB 断电丢数据：这个故障模式能够经过将数据冗余一份在 MySQL 中，在故障状况下重建数据来规避影响。

FMEA 实战

下面我以一个简单的样例来模拟一次 FMEA 分析。假设咱们设计一个最简单的用户管理系统，包含登陆和注册两个功能，其初始架构是：



初始架构很简单：MySQL 负责存储，Memcache（如下简称 MC）负责缓存，Server 负责业务处理。咱们来看看这个架构经过 FMEA 分析后，可以有什么样的发现，下表是分析的样例（注意，这个样例并不完整，感兴趣的同窗能够自行尝试将这个案例补充完整）。

通过上表的 FMEA 分析，将“后续规划”列的内容汇总一下，咱们最终获得了下面几条须要改进的措施：

• MySQL 增长备机。

• MC 从单机扩展为集群。

• MySQL 双网卡链接。

改进后的架构以下：



小结

今天我为你讲了 FMEA 高可用分析方法，而且给出了一个简单的案例描述如何操做。FMEA 是高可用架构设计的一个很是有用的方法，可以发现架构中隐藏的高可用问题，但愿对你有所帮助。

这就是今天的所有内容，留一道思考题给你吧，请使用 FMEA 方法分析一下 HDFS 系统的架构，看看 HDFS 是如何应对各类故障的，而且分析一下 HDFS 是否存在高可用问题。