undefined

FMEA 方法-排除架构可用性隐患

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

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

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

从用户角度来看，而不是从系统各个模块功能点划分来看。比如，对于一个用户管理系统，使用 FMEA 分析时，登录/注册就是功能点

故障模式指的是系统会出现什么样的故障，包括故障点和故障形式。需要特别注意的是，这里的故障模式并不需要给出真正的故障原因，我们只需要假设出现某种故障现象即可，比如：MySQL 的响应时间达到 3 秒。此外，故障模式的描述要尽量精确，多使用量化描述，避免使用泛化的描述。不应该是 MySQL 响应慢

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

故障影响也需要尽量准确描述。例如，推荐使用“20% 的用户无法登录”，而不是“大部分用户无法登录”。

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

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

不同的故障原因发生概率不相同。例如：MySQL查询慢可能是 MySQL bug，也可能是没有索引。不过出现 bug 的概率远远低于没有索引；而不同的概率又影响我们具体如何应对这个故障
不同的故障原因检测手段不一样。例如：MySQL 响应慢可能是慢查询，也可能是 MySQL的磁盘坏了。检测方法就不一样
不同的故障原因的处理措施不一样。如果是 MySQL bug，那就升级 MySQL 版本；如果是没有索引，那就增加索引

这里的概率就是指某个具体故障原因发生的概率。例如，磁盘坏道的概率、MySQL bug 的概率、没有索引的概率。一般分为“高 / 中 / 低”三档即可

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

“某个机房业务瘫痪”对业务影响是致命的，但如果故障原因是“地震”，那概率就很低。如果故障的原因是“机房空调烧坏”，则概率就比地震高很多了。同样的故障影响，不同的故障原因有不同的概率，最终得到的风险级别就是不同的。

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

检测告警，系统自己不针对故障进行处理，需要人工干预。
容错，检测到故障后，系统能够通过备份手段应对。例如，MySQL 主备机，当业务服务器检测到主机无法连接后，自动连接备机读取数据。
自恢复，检测到故障后，系统能够自己恢复。例如，Hadoop 检测到某台机器故障后，能够将存储在这台机器的副本重新分配到其他机器。当然，这里的恢复主要还是指“业务”上的恢复，一般不太可能将真正的故障恢复。例如，Hadoop 不可能将产生了磁盘坏道的磁盘修复成没有坏道的磁盘。

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

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

一般来说，如果某个故障既可以采取规避措施，又可以采取解决措施，那么我们会优先选择解决措施，毕竟能解决问题当然是最好的。但很多时候有些问题是系统自己无法解决的，例如磁盘坏道、开源系统 bug，这类故障只能采取规避措施

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