【稳定性】FMEA方法在系统可用性设计上的应用
最近在跟进软件系统的交付质量专项，需要解决的就是在软件交付之后出现故障过多的问题，这是一个较为宏观的问题，而有一个核心的点就在于系统可用性方案设计上的问题，设计上有了风险隐患点，测试上大概率也无法测试出风险隐患点（软件质量是设计出来的，不是测试出来的），那么上线之后就必然会出现问题，因此需要有一个方法来找到系统可用性设计上的风险隐患点，那么在系统设计的过程中尽量规避它们，同时能为测试用例提供明确的方向，这个方法就是FMEA。
一、什么是FMEA
FMEA，Failure mode and effects analysis，故障模式与影响分析。FMEA是一种可靠性设计的重要方法。它实际上是FMA（故障模式分析）和FEA（故障影响分析）的组合。它对各种可能的风险进行评价、分析，以便在现有技术的基础上消除这些风险或将这些风险减小到可接受的水平。FMEA之所以能够在各个领域得到应用，根本原因在于FMEA是一套分析和思考的方法，而不是某个领域的技能或者工具，是"道"层面的东西。
二、FMEA的目标
2.1 在设计系统架构的时候，经常会遗漏掉一些关键环节的隐患的容错考虑，这些盲点没有在高可用设计中被考虑到；
2.2 同时也在测试case中被忽略，那么上线之后，当隐患暴露，那么极大可能对线上系统稳定性造成巨大影响。
因此我们做FMEA的目的是：能够容易、低成本地对产品或过程进行修改，从而减轻事后危机的修改；找到能够避免或减少这些潜在失效发生的措施。
三、FMEA在架构设计中的使用
回到软件架构设计领域，FMEA并不能知道我们如何做架构设计，而是当我们设计出一个架构后，再使用FMEA对这个架构进行分析，看看架构是否还存在某些可用性的隐患。
在架构设计领域，FMEA的具体方法是：
>给出初始的架构设计图
>假设架构中某些部件发生了故障
>分析此故障对系统功能造成的影响
>根据分析结果，判断架构是否需要进行优化
3.1 功能点
从用户角度分析的功能点，而不是从模块功能划分。
3.2 故障模式
系统会出现什么样的故障，包括故障点和故障形式。故障模式不是原因，只需要假设出某种故障现象即可。
3.3 故障影响
当发生故障模式中描述的故障时，功能点具体会受到什么影响。常见的影响有：功能点偶尔不可用、功能点完全不可用、部分用户功能点不可用、功能点响应缓慢、功能点出错；
故障影响需要通过数字尽量准确描述。比如"20%用户无法登陆"等。
3.4 严重程度
站在业务的角度故障的影响程度，一般分为"致命 、 高 、 中 、低、无"五个档次。
严重程度评估公式：严重程度 = 功能点重要程度 * 故障影响范围 * 功能点受损程度。
3.5 故障原因
"故障模式"中只描述了故障的现象，并没有单独列出故障原因。主要原因在于不管什么故障原因，故障现象相同 ，对功能点的影响就相同。为何单独列出故障原因？
·不同的故障原因发生概率不相同
·不同的故障原因检测手段不一样
·不同的故障原因处理措施不一样
3.6 故障概率
某个故障原因发生的概率。例如mysql没有索引的概率，接口不可用的概率，redis挂掉的概率。一般分为"高、中、低"三个档次。
3.7 风险程度
风险程度就是综合严重程度和故障概率来一起判断某个故障的最终等级，风险程度 = 严重程度 * 故障概率。
3.8 已有措施
针对具体的故障原因，系统现在是否提供概率某些措施来应对，包括：检测告警、容错、自恢复等。
3.9 规避措施
为了降低故障发生概率而做的一些事情，可以是技术手段，也可以是管理手段。
3.10 解决措施
解决措施指为了能够解决问题而做的一些事情，一般都是技术手段。
3.11 后续规划
综合分析，勘测处哪些故障是我们目前还缺乏的应对的措施，哪些已有措施还不够，针对不足地方，结合风险程度进行排序，给出后续改进规划。这些规划既可以是技术手段，也可以是管理手段；可以是规避措施，也可以是解决措施。
四、FMEA实战
一次FMEA分析。
4.1 初始架构：
4.2 架构说明
业务场景：用户在注册，下单，支付等等各个环节需要去验证它是否是欺诈用户，数据库中存储的是用户的信用分，第三方服务是某个对接了国家信用数据的供应商，mysql中存储的就是用户的信用数据。
流程非常清晰，分为同步和异步两个流程，第一个是请求读本地数据的流程；第二个是请求第三方刷新本地数据并接收回调的流程 ；
4.2.1)第一个同步流程：
1)客户端发送请求到service中；
2)service接收到请求之后读取mysql中数据并返回给客户端client；
4.2.2)第二个异步流程：
1)客户端发送请求到service中；
2)service接收到请求之后请求第三方服务；
3)接收第三方服务回调并将数据写入mysql；
4)通知客户端数据刷新完毕；
4.3 FMEA分析
| 功能点 |
故障模式 |
故障影响 |
严重程度 |
故障原因 |
故障概率 |
风险程度 |
已有措施 |
规避措施(事前) |
解决措施(事中事后) |
后续规划 |
| 同步/异步 |
Mysql无法访问 |
无法读取/写入用户信用数据，影响增量用户注册，存量欺诈用户拦截 |
高 |
Mysql机房断电 |
中 |
中 |
无 |
无 |
无 |
mysql异地灾备 |
| 同步/异步 |
Mysql无法访问 |
无法读取/写入用户信用数据，影响增量用户注册，存量欺诈用户拦截 |
高 |
Mysql单机故障 |
中 |
中 |
无 |
无 |
无 |
mysql冗余 |
| 同步/异步 |
Mysql响应时间超时 |
1.20%的用户无法同步获取用户信用数据； 2.50%新增用户无法完成注册流程 |
高 |
慢查询导致mysql运行缓慢 |
高 |
高 |
慢查询检测 |
上线sql慢查询review |
1.慢查询监控 2.慢查询优化 |
无 |
| 同步/异步 |
Mysql响应时间超时 |
1.20%的用户无法同步获取用户信用数据； 2.50%新增用户无法完成注册流程 |
高 |
流量过大导致mysql被拖垮，响应过慢 |
高 |
高 |
无 |
无 |
无 |
1.增加缓存减轻mysql压力； 2.业务测对mysql的访问进行限流； |
| 同步/异步 |
service无法访问 |
1.100%的用户无法同步获取用户信用数据 2.100%无法注册 |
高 |
Service服务宕机 |
低 |
高 |
机器冗余集群化 |
集群部署 |
无 |
无 |
| 异步 |
第三方服务无法访问 |
无法从第三方获取用户信用数据，影响注册转换率 |
高 |
第三方服务宕机 |
中 |
高 |
无 |
无 |
无 |
1.签署协议让第三方服务按照约定SLA提供服务 2.多供应商冗余 |
| 异步 |
第三方服务回调失败 |
无法从第三方获取用户信用数据，影响注册转换率 |
中，新用户每天很少100个 |
回调网络中断 |
中 |
低 |
无 |
无 |
无 |
1.增加流程控制表，对超时没有回调结果任务进行重试 |
| 异步 |
client无法获取回调结果 |
注册用户无法第一时间准入 |
低 |
1.网络中断 2.service服务宕机 |
低 |
低 |
无 |
无 |
无 |
1.增加消息队列中间件保证回调消息高可用 |
后续规划需要改进的措施：
1)mysql异地灾备，mysql冗余；
2)增加缓存cache降低对mysql的访问压力；
3)增加流程控制表，对超时没有回调结果任务进行重试
4)增加消息队列中间件保证回调消息高可用
最后，如何验证你的改进规划和措施是有效的？通过放火演练，即在所谓的混沌工程。
4.4 改进后的架构
当然改进之后的架构也并非尽善尽美，如何保证cache和mysql一致性也是一个问题。
最后，如何验证你的改进规划和措施是有效的？通过放火演练，即在所谓的混沌工程。
Author：忆之独秀
Email：[email protected]
注明出处：https://lavorange.blog.****.net/article/details/109275853