FMEA：总监和架构师都在用的高可用架构分析方法

记得之前准备春晚项目的时候，团队成员在一起过架构，老板最常问的问题是“这个组件挂了怎么办?有什么影响？”，我当时还在心里默默嘀咕：这咋都这么容易挂呢？其他组件不做高可用的吗？最近看到FMEA，我恍然大悟：哦，这原来不就是 FMEA 吗？原来是我“有眼无珠，识不得真神啊”！

本篇来浅谈一下高可用架构、FMEA 以及使用 FMEA 进行架构分析的改进，适合有一定项目经验的工程师阅读。

一、高可用架构

1.1 什么是高可用

当我们谈到高可用时，都会说到可用性。那么，什么是可用性？我们知道，任何东西都有不可用的时候，比如，法拉利也会有抛锚的时候；身体特别健康的人，也难免会头疼感冒；即使是地球，也可能会有毁灭的一天；更何况是服务器/线上应用，硬件故障和软件故障都可能导致不可用。可见，我们没办法做到东西的 100%可用性，只能做到高可用（可能无限接近但始终无法到达 100%）。

1.2 高可用的度量

我们如何来量化服务的“高”可用呢？为了清晰描述高可用，于是就有了SLA（Service-Level Agreement，服务水平协议）的概念。SLA 是服务提供商与客户之间定义的正式承诺。服务提供商与受服务用户之间具体达成了承诺的服务指标——质量、可用性、责任。

那么，SLA 该如何计算呢？

通俗的定义：SLA =可用时长/（可用时长+不可用时长）。
不通俗的定义：SLA =f（MTBF，MTTR）。
MTBF（Mean Time Between Failures）：平均故障间隔，通俗一点就是一个东西多长时间坏一次。
MTTR（Mean Time To Repair or Mean Time To Recovery）：平均修复时间，意思是一旦东西坏了，需要多长时间去修复或者恢复它。

可见，提高 SLA 只有两个方法：一是提高系统的可用时长，二是降低系统的不可用时长。或者说，提高 MTBF，降低 MTTR。

1.3 高可用实现与架构之道

上述的提高高可用的方法只是理论层面的，在工程上其实也有相关的指导思想和架构方法。

当说起高可用实现的时候，浮现在脑海里的是大约在大学时期读过的一本自传。这本自传的书名记不清了，内容讲述的关于李开复的。李开复在做语音识别的时候，需要向别人展示研究成果，但是机器的识别概率只有 80%，达不到目标。那怎么办呢？没有什么事情是一台机器不能解决的，如果有，那就再加一台：一台机器识别的概率是 80%，那么不能识别概率是 20%，两台机器同时不能识别的概率就是 20% * 20% = 4%，那么识别的概率就是 96%。这种巧妙的方式让我最早感受到了概率和高可用的神奇。

毕业工作后，我接触到了业内五花八门的高可用方案，逐渐发现高可用实现方式其实是万变不离其宗，不管是计算高可用还是存储高可用；不管是异地多活、负载均衡、主备架构、主从架构等，本质上都是通过“冗余”来实现高可用。

用通俗点语言来讲，就是一台机器不够就两台，两台不够就四台；一个机房可能故障断网断电，那就部署两个机房；一条通道可能故障，那就用两条，两条不够那就用三条（移动、电信、联通一起上）。高可用的“冗余”解决方案，其实是通过增加机器来“冗余”处理单元的手段，来达到服务高可用的目的。

二、初识 FMEA

当系统实现了一套高可用架构上线之后，从此就可以“高枕无忧”了吗？其实不然，还需要择时进行架构分析与改进（毕竟好的架构是演进出来的），FMEA 开始走到舞台中央了。

2.1 什么是 FMEA

失效模式与影响分析——FMEA（Failure Mode and Effects Analysis）也称为：潜在故障模式和影响分析，故障模式、影响和关键性分析 (FMECA)，是由美国军方于 20 世纪 40 年代开始使用的一种过程分析工具，用于识别设计、制造或装配过程、产品或服务中所有可能的故障。

失败模式 ：指的是某事物可能失败的方式或模式。故障是指任何可能发生的错误或缺陷，可以是潜在的，也可以是实际的。
影响分析 ：指的是分析和研究发生失败（或者故障）的造成的影响和后果。

虽然 FMEA 并不是为软件而生，但是同样可以运用于软件领域。通俗的来讲，FMEA 就是一种分析方法，这种方法可以通过假设某组件故障，然后分析影响的途径，从而可以及早发现和识别系统问题、更好地规划后续工作、达到提高系统或者产品的可靠性的目的。

2.2 何时使用 FMEA

上面说的“择时”，究竟是什么时候呢？FMEA 可以在这些时候进行：

当设计一个新系统或者重新设计系统架构的时候
当现有系统或服务以新方式应用的时候
当为现有系统或服务规划改进目标的时候
在系统建设的整个生命周期中定期进行

三、FMEA 实战

如何做 FMEA？这个问题应该在软件领域应该还没有一个业界认可的标准的流程。我翻阅了资料，找到一些我认为比较靠谱的流程，在这里分享一下，大佬可以评论区交流。

3.1 传统制造流程如何做 FMEA

3.1.1 步骤总览

典型的 FMEA 其实是一个团队活动或者团队会议。在会议上，可以开展以下几个必要的步骤：

定义失效模式——可能出现什么样的错误
定义影响——谁（哪个模块，功能，函数）会遭受牵连
描述目标——出现失效模式会发生什么样的事
寻找根因——为什么会发生这样的事
定义策略动作——如何避免
定义当前预防&检测措施——我们已经（尚未）做的措施
重复开展以上步骤，并输出到 FMEA 的表格中。

3.1.2 案例

下面是一个源自《Using FMEA to Improve Software Reliability》（链接放在文稿末尾，感兴趣可自行阅读）的例子，例子本身要做的事情是使用导热胶带将 PCB 板附着到金属散热片。对于这个生产流程来说我们应该不用过多了解，只需要通过这个例子熟悉下 FMEA 的步骤。

FMDA 表格如下：

翻译为中文是：

步骤编号	步骤名称	失效模式	影响	目标	根因	S	O	D	RPN	应对动作	当前方案
1	用酒精清理金属片
2	把导热胶铺在边缘
3	清理底座
4	用力按压散热片，使之贴到导热胶带上
5	用酒精清洗导热槽
6	把 LED 灯带放置在散热片上，施重压在灯带外的区域

定义失效模式；

可能的失效：金属片可能没有清理干净。
定义影响；

直接结果：铺上的导热胶没有完全黏着，导致热胶路径开裂，从而导致 PCB 过热或直接整块脱落。
描述目标；

影响：导热胶没有黏着，导热路径脱离，PCB 过热
谁会受到影响：过热通常需要期间承受一定的压力才会出现，生产测试中可能发现不了；很有可能将该缺陷带给客户。
寻找根因；

根因：存在酒精无法溶解的污染物。根因：操作错误
列出风险的优先级；

就是把失效模式和风险的优先级联系起来。每个失效被赋值为 1-10 之间的三个指标。

严重程度（S）：1（无关紧要）到 10（灾难性）
出现的可能性（O）: 1 ( 不可能 ) 到 10（不可避免）
可检测性（D）：1（肯定能被检测）到 10（不可检测）

这三个数乘起来就是风险优先级参数（RPN）。RPN 越大，改善的必要性就越高。
S x O x D = RPN

影响：导热胶带没有完全黏住，导热路径脱离，PCB 过热。


严重程度	6	缩短 PCB 组件寿命
可能性	2	经过恰当的训练，这不太可能发生
可检测性	3	在生产过程中很容易被检测

RPN： 6 x 2 x 3 = 36

定义解决方案；

失效模式：金属薄片没有清除干净。
解决动作：操作员及时赋能培训清理技巧。
描述当前预防和检测方法；

失效模式：金属薄片没有清除干净。
当前方法：在产线上岗之前对操作员进行培训、在生产中展示工作指南。
重复重复再重复；

重复步骤 1-7，得到一个完整的表格。我们筛选出最有价值的措施来做系统设计和改造工作。

3.2 软件如何做 FMEA

3.2.1 简化的 FMEA

按照 FMEA 理论，FMEA 分析需要通过一次或多次会议完成，参与人应该包括：系统 Owner、项目 Leader、领域专家（架构师）参加、相关开发、测试等人员。当然这样效果肯定是最好的，实际情况可能无法在同一时间召集大家都来参加会议。特别是在“降本增笑，开猿节流”的大背景下，我们日常的工作肯定是更卷了，时间变得更宝贵了。我根据日常工作经验，结合 FMEA 核心思想和分析流程，总结出一个简化版的流程和表格，供大家参考。自己在架构 Review 或者设计过程中可以先问自己几个问题：

系统中的组件可能发生故障吗？
如果发生了故障，有什么影响？
故障发生的可能性有多大？影响是否严重？（可以使用 RPN 进行量化）
当前的解决方案或者预案是什么？是立即优化还是排期后续优化？

3.2.2 案例

下面是一个简单的例子来模拟一次 FMEA 分析。假设这是一个博客管理系统，具有最基础的登录注册功能、发布和查看博客等功能。其系统架构如图：

下表是我分析的样例，仅供参考。


序号	功能模块	失效模式	故障影响	根本原因	风险等级评估（可使用 RPN 方式进行评估）	当前已有解决方案或预案	短期方案	长期方案
1	用户登录	MySQL 数据库无法访问	用户无法登录，页面提示“系统异常”	数据库服务器宕机	高	无	完善监控，若发现宕机联系 DBA 进行处理；补充备库	故障时自动进行主备切换
2	用户登录	MySQL 数据库响应时间达到 3s	用户登录体验受影响	数据库慢查询	中	无	定期扫描慢查询，进行治理	分库分表等数据治理方案
3