24 - FMEA方法排除架构可用性隐患的利器.docx

《24 - FMEA方法排除架构可用性隐患的利器.docx》由会员分享，可在线阅读，更多相关《24 - FMEA方法排除架构可用性隐患的利器.docx（10页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、24 | FMEA方法，排除架构可用性隐患的利器 我在前面的专栏分析高可用困难度的时候提出了一个问题：高可用和高性能哪个更困难，大部分同学都分析出了正确的答案：高可用更困难一些，主要缘由在于异样的场景许多，只要有一个场景遗漏，架构设计就存在可用性隐患，而依据墨菲定律可能出错的事情最终都会出错，架构隐患总有一天会导致系统故障。因此，我们在进行架构设计的时候必需全面分析系统的可用性，那么如何才能做到全面呢？ 我今日介绍的FMEA 方法，就是保证我们做到全面分析的一个特别简洁但是特别有效的方法。 FMEA 介绍 FMEA（Failure mode and effects analysis，故障模式与

2、影响分析）又称为失效模式与后果分析、失效模式与效应分析、故障模式与后果分析等，专栏采纳故障模式与影响分析，因为这个中文翻译更加符合可用性的语境。FMEA 是一种在各行各业都有广泛应用的可用性分析方法，通过对系统范围内潜在的故障模式加以分析，并根据严峻程度进行分类，以确定失效对于系统的最终影响。 FMEA 最早是在美国军方起先应用的，20 世纪 40 年头后期，美国空军正式采纳了 FMEA。尽管最初是在军事领域建立的方法，但 FMEA 方法现在已广泛应用于各种各样的行业，包括半导体加工、餐饮服务、塑料制造、软件及医疗保健行业。FMEA 之所以能够在这些差异很大的领域都得到应用，根本缘由在于 FM

3、EA 是一套分析和思索的方法，而不是某个领域的技能或者工具。 回到软件架构设计领域，FMEA 并不能指导我们如何做架构设计，而是当我们设计出一个架构后，再运用 FMEA 对这个架构进行分析，看看架构是否还存在某些可用性的隐患。 FMEA 方法 在架构设计领域，FMEA 的详细分析方法是： 给出初始的架构设计图。 假设架构中某个部件发生故障。 分析此故障对系统功能造成的影响。 依据分析结果，推断架构是否须要进行优化。 FMEA 分析的方法其实很简洁，就是一个 FMEA 分析表，常见的 FMEA 分析表格包含下面部分。 1.功能点 当前的 FMEA 分析涉及的功能点，留意这里的功能点指的是从用户角

4、度来看的，而不是从系统各个模块功能点划分来看的。例如，对于一个用户管理系统，运用 FMEA 分析时 登录注册才是功能点，而用户管理系统中的数据库存储功能、Redis 缓存功能不能作为 FMEA 分析的功能点。 2.故障模式 故障模式指的是系统会出现什么样的故障，包括故障点和故障形式。须要特殊留意的是，这里的故障模式并不须要给出真正的故障缘由，我们只须要假设出现某种故障现象即可，例如 MySQL 响应时间达到 3 秒。造成 MySQL 响应时间达到 3 秒可能的缘由许多：磁盘坏道、慢查询、服务器到 MySQL 的连接网络故障、MySQL bug 等，我们并不须要在故障模式中一一列出来，而是在后面

5、的故障缘由一节中列出来。因为在实际应用过程中，不管哪种缘由，只要现象是一样的，对业务的影响就是一样的。 此外，故障模式的描述要尽量精确，多运用量化描述，避开运用泛化的描述。例如，举荐运用MySQL 响应时间达到 3 秒，而不是MySQL 响应慢。 3.故障影响 当发生故障模式中描述的故障时，功能点详细会受到什么影响。常见的影响有：功能点间或不行用、功能点完全不行用、部分用户功能点不行用、功能点响应缓慢、功能点出错等。 故障影响也须要尽量精确描述。例如，举荐运用20% 的用户无法登录，而不是大部分用户无法登录。要留意这里的数字不须要完全精确，比如 21.25% 这样的数据其实是没有必要的，我们只

6、须要预估影响是 20% 还是 40%。 4.严峻程度 严峻程度指站在业务的角度故障的影响程度，一般分为致命 / 高 / 中 / 低 / 无五个档次。严峻程度根据这个公式进行评估：严峻程度 = 功能点重要程度 × 故障影响范围 × 功能点受损程度。同样以用户管理系统为例：登录功能比修改用户资料要重要得多，80% 的用户比 20% 的用户范围更大，完全无法登录比登录缓慢要更严峻。因此我们可以得出如下故障模式的严峻程度。 致命：超过 70% 用户无法登录。 高：超过 30% 的用户无法登录。 中：全部用户登录时间超过 5 秒。 低：10% 的用户登录时间超过 5 秒。 中：全

7、部用户都无法修改资料。 低：20% 的用户无法修改头像。 对于某个故障的影响究竟属于哪个档次，有时会出现一些争议。例如，全部用户都无法修改资料，有的人认为是高，有的人可能认为是中，这个没有肯定标准，一般建议相关人员探讨确定即可。也不建议花费太多时间争辩，争吵不下时架构师裁定即可。 5.故障缘由 故障模式中只描述了故障的现象，并没有单独列出故障缘由。主要缘由在于不管什么故障缘由，故障现象相同，对功能点的影响就相同。那为何这里还要单独将故障缘由列出来呢？主要缘由有这几个： 不同的故障缘由发生概率不相同 例如，导致 MySQL 查询响应慢的缘由可能是 MySQL bug，也可能是没有索引。很明显My

8、SQL bug的概率要远远低于没有索引；而不同的概率又会影响我们详细如何应对这个故障。 不同的故障缘由检测手段不一样 例如，磁盘坏道导致 MySQL 响应慢，那我们须要增加机器的磁盘坏道检查，这个检查很可能不是当前系统本身去做，而是另外运维特地的系统；假如是慢查询导致 MySQL 慢，那我们只须要配置 MySQL 的慢查询日志即可。 不同的故障缘由的处理措施不一样 例如，假如是 MySQL bug，我们的应对措施只能是升级 MySQL 版本；假如是没有索引，我们的应对措施就是增加索引。 6.故障概率 这里的概率就是指某个详细故障缘由发生的概率。例如，磁盘坏道的概率、MySQL bug 的概率、

9、没有索引的概率。一般分为高 / 中 / 低三档即可，详细评估的时候须要有以下几点须要重点关注。 硬件 硬件随着运用时间推移，故障概率会越来越高。例如，新的硬盘坏道几率很低，但运用了 3 年的硬盘，坏道几率就会高许多。 开源系统 成熟的开源系统 bug 率低，刚发布的开源系统 bug 率相比会高一些；自己已经有运用阅历的开源系统 bug 率会低，刚起先尝试运用的开源系统 bug 率会高。 自研系统 和开源系统类似，成熟的自研系统故障概率会低，而新开发的系统故障概率会高。 中学低是相对的，只是为了确定优先级以确定后续的资源投入，没有必要肯定量化，因为肯定量化是须要成本的，而且许多时候都没法量化。例

10、如，XX 开源系统是 3 个月故障一次，还是 6 个月才故障一次，是无法评估的。 7.风险程度 风险程度就是综合严峻程度和故障概率来一起推断某个故障的最终等级，风险程度 = 严峻程度 × 故障概率。因此可能出现某个故障影响特别严峻，但其概率很低，最终来看风险程度就低。某个机房业务瘫痪对业务影响是致命的，但假如故障缘由是地震，那概率就很低。例如，广州的地震概率就很低，5 级以上地震的 20 世纪才 1 次（1940 年）；假如故障的缘由是机房空调烧坏，则概率就比地震高许多了，可能是 2 年 1 次；假如故障的缘由是系统所在机架掉电，这个概率比机房空调又要高了，可能是 1 年 1 次。

11、同样的故障影响，不同的故障缘由有不同的概率，最终得到的风险级别就是不同的。 8.已有措施 针对详细的故障缘由，系统现在是否供应了某些措施来应对，包括：检测告警、容错、自复原等。 检测告警 最简洁的措施就是检测故障，然后告警，系统自己不针对故障进行处理，须要人工干预。 容错 检测到故障后，系统能够通过备份手段应对。例如，MySQL 主备机，当业务服务器检测到主机无法连接后，自动连接备机读取数据。 自复原 检测到故障后，系统能够自己复原。例如，Hadoop 检测到某台机器故障后，能够将存储在这台机器的副本重新安排到其他机器。当然，这里的复原主要还是指业务上的复原，一般不太可能将真正的故障复原。例如

12、，Hadoop 不行能将产生了磁盘坏道的磁盘修复成没有坏道的磁盘。 9.规避措施 规避措施指为了降低故障发生概率而做的一些事情，可以是技术手段，也可以是管理手段。例如： 技术手段：为了避开新引入的 MongoDB 丢失数据，在 MySQL 中冗余一份。 管理手段：为了降低磁盘坏道的概率，强制统一更换服务时间超过 2 年的磁盘。 10.解决措施 解决措施指为了能够解决问题而做的一些事情，一般都是技术手段。例如： 为了解决密码暴力破解，增加密码重试次数限制。 为了解决拖库导致数据泄露，将数据库中的敏感数据加密保存。 为了解决非法访问，增加白名单限制。 一般来说，假如某个故障既可以实行规避措施，又可

13、以实行解决措施，那么我们会优先选择解决措施，终归能解决问题当然是最好的。但许多时候有些问题是系统自己无法解决的，例如磁盘坏道、开源系统 bug，这类故障只能实行规避措施；系统能够自己解决的故障，大部分是和系统本身功能相关的。 11.后续规划 综合前面的分析，就可以看出哪些故障我们目前还缺乏对应的措施，哪些已有措施还不够，针对这些不足的地方，再结合风险程度进行排序，给出后续的改进规划。这些规划既可以是技术手段，也可以是管理手段；可以是规避措施，也可以是解决措施。同时须要考虑资源的投入状况，优先将风险程度高的系统隐患解决。 例如： 地震导致机房业务中断：这个故障模式就无法解决，只能通过备份中心规避

14、，尽量削减影响；而机柜断电导致机房业务中断：可以通过将业务机器分散在不同机柜来规避。 敏感数据泄露：这个故障模式可以通过数据库加密的技术手段来解决。 MongoDB 断电丢数据：这个故障模式可以通过将数据冗余一份在 MySQL 中，在故障状况下重建数据来规避影响。 FMEA 实战 下面我以一个简洁的样例来模拟一次 FMEA 分析。假设我们设计一个最简洁的用户管理系统，包含登录和注册两个功能，其初始架构是： 初始架构很简洁：MySQL 负责存储，Memcache（以下简称 MC）负责缓存，Server 负责业务处理。我们来看看这个架构通过 FMEA 分析后，能够有什么样的发觉，下表是分析的样例（

15、留意，这个样例并不完整，感爱好的同学可以自行尝试将这个案例补充完整）。 经过上表的 FMEA 分析，将后续规划列的内容汇总一下，我们最终得到了下面几条须要改进的措施： MySQL 增加备机。 MC 从单机扩展为集群。 MySQL 双网卡连接。 改进后的架构如下： 小结 今日我为你讲了 FMEA 高可用分析方法，并且给出了一个简洁的案例描述如何操作。FMEA 是高可用架构设计的一个特别有用的方法，能够发觉架构中隐藏的高可用问题，希望对你有所帮助。 这就是今日的全部内容，留一道思索题给你吧，请运用 FMEA 方法分析一下 HDFS 系统的架构，看看 HDFS 是如何应对各种故障的，并且分析一下 HDFS 是否存在高可用问题。 欢迎你把答案写到留言区，和我一起探讨。信任经过深度思索的回答，也会让你对学问的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）