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

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 表格如下：

翻译为中文是：

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

  1. 定义失效模式；

    可能的失效：金属片可能没有清理干净。

  2. 定义影响；

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

  3. 描述目标；

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

  4. 寻找根因；

    根因： 存在酒精无法溶解的污染物。 根因： 操作错误

  5. 列出风险的优先级；

    就是把失效模式和风险的优先级联系起来。每个失效被赋值为 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. 定义解决方案；

    失效模式：金属薄片没有清除干净。
    解决动作：操作员及时赋能培训清理技巧。

  2. 描述当前预防和检测方法；

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

  3. 重复重复再重复；

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

3.2 软件如何做 FMEA

3.2.1 简化的 FMEA

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

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

3.2.2 案例

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

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

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

四、总结

本文讲述了高可用架构和一个能够发现架构中隐藏高可用问题的方法：失效模式与影响分析（FMEA），通过硬件和软件领域的两个案例实战了一波 FMEA，给出我心中的简版的 FMEA，这其实就是我理解的 FMEA 的核心思想，希望对大家有帮助，之后工作和项目中也可以尝试使用一下。

参考文献

Using FMEA to Improve Software Reliability

一起学习

这里是 James Shangguan，欢迎私信或者微信交流，在 2024 年里面，我们一起提高认知。也欢迎大家关注我的公众号或博客园，点赞、留言、转发。你的支持，将是我更文的最大动力！

 

2024-01-29 09:04:46【出处】：https://www.cnblogs.com/sgh1023/p/17993615

=======================================================================================

posted on 2024-01-29 09:06  jack_Meng  阅读(31)  评论(0)  编辑  收藏  举报

导航