1950年，当时美国Grumman公司为了在研发新的喷射战斗机时评估飞机操作系统某一元件的失效分析，开始采用了FMEA方法。
随后FMEA逐渐在各航空运用起来。到了20世纪60年代，随着美国NASA阿波罗计划的发展，FMEA被引入到航天工业。之后随着FMEA被汽车工业、各大电子工业应用，FMEA越来越被工程行业所重视，并于1970年左右引进到我们的航空航天及汽车工业上。
从20世纪中叶发展到现在，FMEA方法有了数个版本的迭代。随着IT工业的崛起，FMEA也被引入到软件架构设计领域，用于帮助分析被设计的架构是否存在可用性方面的隐患。
FMEA方法使用步骤
1，根据系统架构设计图，假设其中某部分发生故障。
2，分析这一故障对系统功能可能造成的影响。
3，根据分析后的结论判断是否需要对架构进行优化调整。
给出初始的架构设计图。假设架构中某个部件发生故障。分析此故障对系统功能造成的影响。根据分析结果，判断架构是否需要进行优化。
一张常见的FMEA表格
总共包含11个分析项：功能点、故障模式、故障影响、严重程度、故障原因、故障概率、风险程度、已有措施、规避措施、解决措施和后续规划。
下面我们来看一下每一项的具体含义。
1，功能点
功能点是指目前我们需要分析的功能点。注意，这里的功能点并不是从技术或系统角度看的功能点，而是“站在用户角度看”的功能点。
例子：用户查看账单是一个功能点，但是账单数据如何存储就不是功能点。
2，故障模式
故障模式是指系统可能出现的故障点和故障形式。我们在这一项中只需要描述出故障的现象，描述中尽可能精确量化。
例子：服务器响应时间超过3秒。
3，故障影响
出现“故障模式”中说明的故障情况时，当前的“功能点”会有什么影响。
例子：60%的用户无法查看账单。
4，严重程度
严重程度的评估需要站在业务的角度来看故障的影响。可以使用这条公式：严重程度 = 功能点重要程度 × 故障影响范围 × 功能点受损程度。严重程度可以分为无、低、中、高、极高等几个等级。
严重程度的等级划分需要根据具体的业务类型来划分。像电商业务中，如果有5%的用户无法将商品加入购物车，这个严重程度将是极高，因为直接影响的是收入。而如果是有20%的用户无法修改自己的昵称，则严重程度可以划分为中，因为这个故障对收入的影响没有强烈的影响。
5，故障原因
相同功能点下可能有相同的故障模式，但是其原因可能不一样。例如查询账单功能点出现无法连接数据库的故障模式，但故障原因可以是网络故障或者服务器磁盘没有空间。
6，故障概率
故障概率是指上述故障原因发生的概率，可以分为低中高三种等级。实践中有三种类型的故障的概率需要重点关注。
硬件。硬件设备的故障概率并不是固定的，而是会随着使用时间的推移而增加。
各大开源系统。刚诞生的开源系统的故障概率相对会高一些。而一些已经发展多年，比较成熟的开源系统的故障概率则相对较低。
自研系统。故障概率与各大开源系统的情况有点相似，刚开发刚上线的系统的故障概率会相对高，而已成熟、运行多年的系统的故障概率会相对低。
7，风险程度
风险程度 = 严重程度 × 故障概率。由于与故障概率相关，所以有些影响非常大的故障其风险程度不一定会很高。例如重大自然灾害对机房的影响可能是毁灭性的，但其发生概率会比较低，因此风险程度也相对低。由此得出的风险程度可以指导我们后续的工作。
8，已有措施
已有措施就是系统架构中是否有提供一些可采取的措施来对应当前的故障。可以是检测告警、容错、自我恢复等方面。
9，规避措施
为了降低某一故障发生的概率，我们是否在技术、管理流程方面有相关的可行手段。
10，解决措施
解决措施是指为了解决某一故障而采取的手段。对于软件架构来讲，一般可用的手段就是技术手段。
解决措施与规避措施看似相同，但面对实际情况时，是有多不同的。一个故障如果我们能用某种措施来解决掉的话，就无需使用规避措施了（因为已无故障可规避）。所以解决措施是优于规避措施的。
11，后续规划
经过了前面10项的分析，我们已经能看出整个架构中存在的问题和不足，欠缺了怎样的应对措施。这是我们可以整体给出后续可以使用的各种手段或者措施，从而形成应对故障的后续规划。
FMEA是分析系统架构设计高可用问题方面的利器，不过上述11点并不是强制必须填满每一项，我们实际应用时可以根据所面对的业务场景适当作出调整或剪裁。
参考资料：
1，《从0开始学架构》
作者：皇子
weixin公号：@IT小皇子