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

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

>给出初始的架构设计图

>假设架构中某些部件发生了故障

>分析此故障对系统功能造成的影响

>根据分析结果，判断架构是否需要进行优化

1 功能点

从用户角度分析的功能点，而不是从模块功能划分。

2 故障模式

系统会出现什么样的故障，包括故障点和故障形式。故障模式不是原因，只需要假设出某种故障现象即可。

3 故障影响

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

故障影响需要通过数字尽量准确描述。比如"20%用户无法登陆"等。

4 严重程度

站在业务的角度故障的影响程度，一般分为"致命、高、中、低、无"五个档次。

严重程度评估公式：严重程度 = 功能点重要程度 * 故障影响范围 * 功能点受损程度。

5 故障原因

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

·不同的故障原因发生概率不相同

·不同的故障原因检测手段不一样

·不同的故障原因处理措施不一样

6 故障概率

某个故障原因发生的概率。例如mysql没有索引的概率，接口不可用的概率，redis挂掉的概率。一般分为"高、中、低"三个档次。

7 风险程度

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

8 已有措施

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

9 规避措施

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

10 解决措施

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

11 后续规划

综合分析，勘测处哪些故障是我们目前还缺乏的应对的措施，哪些已有措施还不够，针对不足地方，结合风险程度进行排序，给出后续改进规划。这些规划既可以是技术手段，也可以是管理手段；可以是规避措施，也可以是解决措施。

ITPub博客

FMEA在架构设计中的应用分析