高可用一直都是很复杂的一个存在，主要是因为异常的场景太多，只要遗漏一个场景，架构设计就存在可用性隐患，根据墨菲定律 “可能出错的事情最终都会出错”，架构隐患总有一天会导致系统故障。
今天学习的内容是FMEA方法，保证我们做到全面分析的一个非常简单但是非常有效的方法。
FMEA介绍
FMEA（Failure mode and effects analysis，故障模式与影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等。FMEA 是一种在各行各业都有广泛应用的可用性分析方法，通过对系统范围内潜在的故障模式加以分析，并按照严重程度进行分类，以确定失效对于系统的最终影响。
在软件架构设计领域，FMEA不能指导架构设计，而是当我们设计出一个架构后，再使用FMEA对这个架构进行分析，看看架构是否存在某些可用性的隐患。
FMEA方法
在架构设计领域，FMEA的具体分析方法是：
- 给出初始的架构设计图。
- 假设架构中某个部件发生故障。
- 分析此故障对系统功能造成的影响。
- 根据分析结果，判断架构是否需要进行优化。
FMEA分析的方法其实很简单，就是一个FMEA分析表，常见的包含以下几部分：
1.功能点
当前的FMEA分析涉及的功能点，这里的“功能点”指的是从用户角度来看的，而不是系统各个模块功能点划分来看的。
2.故障模式
故障模式指的是系统会出现什么样的故障，包括故障点喝故障形式，需要特别注意的是，这里的故障模式并不需要给出真正的故障原因，我们只需要假设出现某种故障现象即可，例如MySQL响应时间超过3秒，造成MySQL响应时间超过3秒的原因有很多：磁盘坏道、慢查询、服务器到MySQL的连接网络故障、MySQL bug等，我们并不需要在故障模式中一一列出，在实际应用过程中，不管哪种原因，只要现象一样，对业务的影响就是一样的。
3.故障影响
当发生故障模式中描述的故障时，功能点具体会受到什么影响，常见的影响有：功能点偶尔不可用、功能点完全不可用、部分用户功能点不可用、功能点响应缓慢、功能点出错等。
4.严重程度
严重程度指站在业务的角度故障的影响程度，一般分为“致命 / 高 / 中 / 低 / 无”五个档次。严重程度按照这个公式进行评估：严重程度 = 功能点重要程度 × 故障影响范围 × 功能点受损程度。
5.故障原因
故障模式只描述了故障现象，这里分析故障原因：
- 不同的故障原因发生概率不相同
例如，导致 MySQL 查询响应慢的原因可能是 MySQL bug，也可能是没有索引。很明显“MySQL bug”的概率要远远低于“没有索引”；而不同的概率又会影响我们具体如何应对这个故障。
- 不同的故障原因检测手段不一样
例如，磁盘坏道导致 MySQL 响应慢，那我们需要增加机器的磁盘坏道检查，这个检查很可能不是当前系统本身去做，而是另外运维专门的系统；如果是慢查询导致 MySQL 慢，那我们只需要配置 MySQL 的慢查询日志即可。
- 不同的故障原因的处理措施不一样
例如，如果是 MySQL bug，我们的应对措施只能是升级 MySQL 版本；如果是没有索引，我们的应对措施就是增加索引。
6.故障概率
概率是指具体故障原因发生的概率，一般分为“高 / 中 / 低”三档即可，具体评估的时候需要有以下几点需要重点关注。
- 硬件，硬件随着使用时间推移，故障概率会越来越高。
- 开源系统。成熟的开源系统bug率低，刚发布的开源系统bug率相对高一些；自己已经有使用经验的开源系统 bug 率会低，刚开始尝试使用的开源系统 bug 率会高。
- 自研系统。和开源系统类似，成熟的自研系统bug率低一点，新开发的bug率就高一些。
7.风险程度
风险程度就是综合严重程度和故障概率来一起判断某个故障的最终等级，风险程度 = 严重程度 × 故障概率。因此可能出现某个故障影响非常严重，但其概率很低，最终来看风险程度就低。同样的故障影响，不同的故障原因有不同的概率，最终得到的风险级别就是不同的。
8.已有措施
针对具体的原因，系统是否提供某些措施来应对。
- 检测告警：检测故障，系统自己不针对故障进行处理，需要人工干预。
- 容错：检测到故障后，系统能够通过备份手段应对。
- 自恢复：检测到故障后，系统能够自己恢复。
9.规避故措施
规避措施为了降低故障发生概率而做一些实际，可以是技术手段也可以是管理手段。
10.解决措施
解决措施指为了能够解决问题而做的一些事情，一般都是技术手段。
11.后续规划
综合前面的分析，就可以看出哪些故障我们目前还缺乏对应的措施，哪些已有措施还不够，针对这些不足的地方，再结合风险程度进行排序，给出后续的改进规划。这些规划既可以是技术手段，也可以是管理手段；可以是规避措施，也可以是解决措施。同时需要考虑资源的投入情况，优先将风险程度高的系统隐患解决。
