高可用在一般情况下相对于高性能更复杂一些，主要原因在于异常的场景很多，只要有一个场景遗漏，架构设计就存在可用性隐患

什么是FMEA

FMEA（Failure mode and effects analysis，故障模式与影响分析）

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

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

FMEA 方法

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

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

这里是功能点指站在用户角度的功能点，例如：登录，而不是系统功能，例如：Redis的缓存功能不能算。

故障模式指的是系统会出现什么样的故障，包括故障点和故障形式.

我们并不需要在故障模式中一一列出来故障可能原因，而是在后面的“故障原因”一节中列出来。

因为在实际应用过程中，不管哪种原因，只要现象是一样的，对业务的影响就是一样的。

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

需要尽可能量化，但没必要非常精确。

严重程度指站在业务的角度故障的影响程度，一般分为“致命 / 高 / 中 / 低 / 无”五个档次。

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

对于某个故障的影响到底属于哪个档次，有时会出现一些争议。简单讨论即可，争执不下架构师决定。

一般分为“高 / 中 / 低”三档即可，具体评估的时候需要有以下几点需要重点关注。

硬件

硬件随着使用时间推移，故障概率会越来越高。例如，新的硬盘坏道几率很低，但使用了 3 年的硬盘，坏道几率就会高很多。
开源系统

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

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

高中低是相对的，只是为了确定优先级以决定后续的资源投入，没有必要绝对量化，因为绝对量化是需要成本的，而且很多时候都没法量化。例如，XX 开源系统是 3 个月故障一次，还是 6 个月才故障一次，是无法评估的。

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

风险程度 = 严重程度 × 故障概率。

此处也可以结合PMP中的风险定性进行分析。

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

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

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

例如：为了解决密码暴力破解，增加密码重试次数限制。

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

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

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

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

这些规划既可以是技术手段，也可以是管理手段；可以是规避措施，也可以是解决措施。

同时需要考虑资源的投入情况，优先将风险程度高的系统隐患解决。