混沌工程&FMEA——可用性隐患分析治理最佳拍档

本文讨论了混沌工程和 FMEA 在软件架构设计中的应用，目的是提升系统可用性。首先解释了 FMEA，一种起源于美国军方的风险评估工具，用于预防产品或服务中的问题。文章详细说明了 FMEA 在软件架构中的步骤，如功能点识别、故障模式描述、影响分析、严重度评级、故障原因和概率分析、风险度计算，以及措施制定。接着介绍了混沌工程，这是一种测试分布式系统弹性的方法，通过模拟故障来识别问题。结合两者，文章通过案例分析展示了如何运用混沌工程和FMEA进行架构优化和效果验证。强调了持续治理的重要性，并介绍了腾讯云云顾问混沌平台的应用，它支持架构管理和可用性治理。总结认为，混沌工程与FMEA结合能有效提升系统可用性。

在软件架构设计领域，设计一个高可用的架构往往比高性能的架构更加复杂。主要是因为架构越复杂，涉及到的组件就更多，会出现故障的地方就越多，只要有一个故障在设计的时候被遗漏，那么这个架构设计理论就存在可用性隐患，依照经典的“墨菲定律”，可能发生故障的地方最终都会发生，那么这个可用性隐患迟早都会发生，这只是时间问题。那么有什么科学高效的方法可以帮助我们在做系统架构设计的时候（当然也可以是对现有架构的分析改进等环节），尽可能“全面”地分析系统的可用性呢？

混沌工程+FMEA(Failure Model and Effects Analysis，故障模式与影响分析)就是一套进行可用性隐患治理分析的非常有效的方法。

01、什么是 FMEA？

故障模式和影响分析 (FMEA) 最早由美国军方于 20 世纪 40 年代发现，用于识别设计、流程、产品和服务中所有可能的问题或故障。此工具通常在产品或服务的设计或提案阶段使用，以积极研究可能的风险并发现其影响。FMEA 包含两个部分：

• 故障模式：发生的故障、问题和事宜。
• 影响分析：故障影响的分析。

FMEA 是一种主动发现业务流程中潜在故障的方法，通过找出故障可能发生的位置并确定其影响，防止故障发生或减轻其影响。FMEA 是一种系统性方法，用于识别和解决故障原因，有助于防止代价高昂的制造问题，提高产品质量和服务可靠性，并提高客户满意度。

尽管最初是在军事领域建立的方法，但 FMEA 方法现在已广泛应用于各种各样的行业，包括半导体加工、餐饮服务、塑料制造、软件及医疗保健行业。FMEA 之所以能够在这些差异很大的领域都得到应用，根本原因在于 FMEA 是一套分析和思考的方法，而不是某个领域的技能或者工具。

02、为何需要 FMEA?

FMEA 是一种风险评估工具通常在设计阶段或对现有流程提出变更建议时执行，以便主动了解可能发生故障的位置并发现这些故障的可能严重性。执行 FMEA 很重要，因为它有助于确定需要优先对流程的哪些部分进行变更，以消除或降低故障概率。

03、FMEA 分析

应用到软件系统架构领域，FMEA 的分析步骤可以参考下图。

FMEA 其实就是填写一张分析表，分析表包含如下信息。

3.1 功能点

FMEA 分析的功能点是从客户的角度出发的，而不是从架构部件角度出发的。比如商城系统的登录功能可以视为一个功能点，而不是将存储模块视为一个功能点。

3.2 故障模式

故障模式就是描述系统可能发生的各种故障形式，比如 MySQL 数据库服务中断10s。这里的故障模式不是说具体的故障原因，而是呈现出来的故障形式，相同的故障形式可能会由多种故障原因（网络隔离，主节点宕机等）导致。对于故障模式的描述应当尽可能量化，避免使用泛化的描述。比如这里描述为 MySQL 数据库服务不可用就比较泛化，很难评估具体的影响范围，通常 MySQL 短时不可用和长时间不可用是两个不同概念，对系统的影响有可能是云泥之别。

3.3 故障影响

描述某类故障模式对系统产生的具体影响，比如，造成20%用户无法登录商城。和故障模式的描述一样，也是尽量用量化描述，这样才对影响有一个具体的印象。

3.4 严重程度

即是对不同的故障模式下的故障影响进行评级，可以根据具体业务设定不同的评定标准。下面是一个简单的示例。

• 致命：超过50%的用户无法登录。
• 严重：超过20%的用户无法登录。
• 高：超过10%的用户无法登录。
• 中：超过60%用户登录时间超过 5 秒。
• 低：10% 的用户登录时间超过 5 秒。

3.5 故障原因

“故障模式”中只描述了故障的现象，并没有单独列出故障原因。主要原因在于不管什么故障原因，故障现象相同，对功能点的影响就相同。那为何这里还要单独将故障原因列出来呢？主要原因有这几个：

• 故障原因发生概率不相同 例如，导致 MySQL 查询响应慢的原因可能是 MySQL bug，也可能是没有索引。很明显“MySQL bug”的概率要远远低于“没有索引”；而不同的概率又会影响我们具体如何应对这个故障。
• 故障原因检测手段不一样 例如，磁盘坏道导致 MySQL 响应慢，那我们需要增加机器的磁盘坏道检查，这个检查很可能不是当前系统本身去做，而是另外运维专门的系统；如果是慢查询导致 MySQL 慢，那我们只需要配置 MySQL 的慢查询日志即可。 故障原因的处理措施不一样
• 例如，如果是 MySQL bug，我们的应对措施只能是升级 MySQL 版本；如果是没有索引，我们的应对措施就是增加索引。

3.6 风险程度

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

风险程度 = 严重程度 × 故障概率。

因此可能出现某个故障影响非常严重，但其概率很低，最终来看风险程度就低。比如，故障模式是机房断电，故障原因是海啸；从业务层面来看，机房断电带来的影响可能是致命的，但是海啸发生的概率是极低的，综合评估下来因海啸导致的机房断电的风险程度就是比较低的。

3.7 已有措施

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

3.8 规避方法

规避措施指为了降低故障发生概率而做的一些事情，可以是技术手段，也可以是管理手段。例如：

• 技术手段：为了避免新引入的 MongoDB 丢失数据，在 MySQL 中冗余一份。
• 管理手段：为了降低磁盘坏道的概率，强制统一更换服务时间超过 2 年的磁盘。

3.9 解决措施

解决措施指为了能够解决问题而做的一些事情，一般都是技术手段。例如：为了解决发生单机房掉电故障，在其他机房再部署一套容灾服务。

3.10 后续规划

综合前面的分析，就可以看出哪些故障我们目前还缺乏对应的措施，哪些已有措施还不够，针对这些不足的地方，再结合风险程度进行排序，给出后续的改进规划。

04、混沌工程&FMEA

FMEA 可以帮助我们在对系统架构进行可用性分析，诸如功能点、故障模式、故障原因以及故障概率通常可以针对架构进行静态分析得出，但是对于故障影响、严重程度、风险程度这类分析点通过静态分析一般来讲是经验值，不可靠的；而这类分析点才是做好高可用设计的关键。

通常，在进行 FMEA 分析时，正如之前图中描述的一样，是假定架构中的某个部件发生异常，然后基于此，去分析系统会出现什么样的表现，很显然，这一阶段对分析者（通常是架构师）的经验有很强的依赖；对于新设计的架构，架构师也许可以通过其丰富的经验精准地评估故障影响、严重程度、风险程度；一旦分析一个存量的架构，或者需要在原有架构上新增其他架构，就算有再丰富的经验，通常很难评估出系统面对故障时真正的表现以及产生的影响。

因此，FMEA 方法是科学有效的，但是想要较好地落地实践却绝非易事。实践过程中最大的难点就是模拟某个部件发生异常。而混沌工程正好可以大大降低模拟故障的成本，并且爆炸半径可控，因为混沌工程是引入真实有效的故障，可以让架构师真实地看到系统的真实表现，而不是依靠其经验，更易得出精准故障影响、严重程度、风险程度评估。

05、什么是混沌工程？

混沌工程是一种在分布式软件系统中进行测试的方法，旨在通过主动引入故障和错误场景来验证其在面对随机中断时的弹性。这种方法基于混沌理论，即系统中的微小变化可能导致不可预测的宏观行为。混沌工程的目标是识别并修复系统中的潜在问题，从而提高系统的稳定性和可靠性。并根据系统在各种压力下的行为表现来确定优化策略的一种系统稳定性保障手段（类似“疫苗”）。

06、混沌&FMEA 实践案例

下面以一个简单的商城系统为例，介绍使用腾讯云云顾问混沌平台以及 FMEA 实践案例。

6.1 梳理架构

下图是使用「腾讯云云顾问-云架构」画的一个简单的云上商城系统架构，用户经过 DNS Pod 域名解析之后，到达 CLB，经过 CLB 转发到对应的 Nginx 集群中，Nginx 做负载均衡，将流量分发到对应的模块服务上，MySQL 负责数据存储，Redis 做缓存。

6.2 FMEA 静态分析

上表是针对该架构进行的 FMEA 静态分析示例，有兴趣的同学可以尝试分析架构的其他部件。

从表中3个分析点中，1号和3号分析点的故障模式很明显是单点故障，通过静态分析就能够确定所带来的故障影响以及严重程度。

相对于2号分析点，仅仅通过静态分析，并不能得到量化的影响，只能是推测出可能产生「部分用户登录延迟达到 3s 以上，部分用户登录出现超时无法登录」的影响，但是实际上呢？

• 到底多少百分比的用户会登录失败？
• 到底多少百分比的用户只是出现登录延迟？
• 除了这这2个能预见的影响还有没有其他的影响？
• ......

6.3 混沌工程注入动态量化分析

很显然，仅仅通过对架构图分析，很难回答上面的几个问题。这个时候，可以通过腾讯云云顾问混沌平台，针对2号分析点的故障模式，对运行用户服务的 CVM 注入「主机内网络延迟」故障。

通过正常的打量测试，便可以得到量化故障带来的实际影响，而不单单是推测。像这种类似的简单混沌分析，可以通过「腾讯云云顾问-云架构」中的混沌插件模式，快速选中对应节点进行混沌演练。

配置故障动作参数。

执行混沌故障演练。

通过混沌工程，主动向用户服务所在 CVM 资源注入「主机网络延迟」故障，我们可以分析故障的具体影响。

假设我们这里分析得出约在 300QPS 下，90%的用户出现登录延迟3s，10%的用户会出现超时无法登录。那么我们对于2号分析点就有一个量化的影响指标而不再是一个模糊的印象了，也就对架构就有了一个更加准确的理解，这对于后续的可用性优化非常关键。

6.4 可用性优化措施设计

经过 FMEA 静态分析以及混沌动态分析之后，就可以根据业务需要，对于需要优化的隐患进行架构优化，设计对应的措施。

• 1号分析点：很明显的单点问题，可以增加部署冗余的 CLB。
• 2号分析点：经过混沌故障分析，在系统设计的 300QPS 访问下，90%的用户都能正常登录，虽然有延迟，但是比完全不能登录的影响程度要好很多；为了减少延迟的用户以及进一步降低无法登录的用户量，架构层面可以采用部署一套冗余的用户服务，系统层面可以在 Nginx 增加网络探测能力，动态调整请求分发。
• 3号分析点：发生 CDB 主节点故障通常是客户侧很难预测的场景，架构层面同样可以部署一个冗余的数据库，与主库不在同一个可用区，并通过 DTS 与主库保持数据实时同步；系统层面需要数据访问中间层具备主库不可用时，及时切换至备库的故障转移能力。

接下来，我们可以进一步完善 FMEA 分析表格。

6.5 解决措施混沌验证

在设计并实施好对应故障模式下的解决措施之后，系统就一定完全按照预想的故障应对措施进行故障转移吗？想必没人敢打保票吧。就算是真正发生和预想的故障完全一致的场景，因为解决措施的实施过程很难保证万无一失，保不齐其中某一个小细节有遗漏，那么对应的应对措施是否能完全有效，这里是需要打个问号的；换言之，心里还是没有底的。

因此，在实施措施之后，进行混沌验证是很有必要的，通过再次主动引入故障，同样可以清晰准确将系统的韧性展示出来，如果验证通过之后，那么这个措施就被认为是有效的，真正上线之后在面对相同故障时，对系统的可用性是有清晰的把握的，不至于胆战心惊。

继续以之前商城的案例，假设我们按照 FMEA 分析表格中的解决措施进行可用性优化，优化后的架构图如下：

对优化的架构进行混沌验证，就不再是针对某个分析点单独的验证，当然也可以进行单独的验证。对于单独的验证场景，同样可以使用之前提到的在云架构-混沌插件中进行；若想要更加灵活和复杂的故障场景模拟（比如同时模拟 CLB 以及 CDB 故障），可以前往「腾讯云云顾问混沌平台控制台」进行复杂混沌演练编排。

这里以在控制台创建演练为例，演练编排如下：

按照演练编排进行混沌演练，并在演练过程及时记录系统表现，观察系统是否按照预期的措施处理引入的各种故障以及设计的解锁措施是否真的有效。

6.6 持续的可用性治理

在完成混沌验证之后，对 FMEA 分析表中的故障模式应该都有比较清晰把握了，从架构层面和系统层面都应该具备了应对故障模式发生时影响的能力，整个系统的可用性相较于之前得到大幅度提升。

相应的解决措施经过混沌验证有效之后，就可以把对应措施移动到“已有措施”栏位，同时也将该措施沉淀为团队的可用性治理经验，便于后续的可用性治理经验复用，提高可用性治理效率。

腾讯云云顾问混沌平台提供演练计划可以方便用户快速对类似 FMEA 分析表中的各种分析点进行混沌 Game-Day。

Gameday（游戏日）是混沌工程实践中的一个概念，指的是在一个特定的时间段内，团队成员共同参与并组织一系列混沌实验。这些实验可以包括故意引入故障、中断网络连接、关闭服务器等，以测试系统的弹性和故障恢复能力。Gameday 的目的是模拟真实世界中可能发生的故障场景，从而帮助团队提前发现和解决潜在问题，提高系统的稳定性和可靠性。

一次可用性治理可以解决当前系统存在的可用性隐患，可一旦系统进行迭代变更，或多或少又会引入新的结构和部件；为了能够让整个系统可用性稳定，持续的可用性治理是必不可少的环节，若只在系统设计之初进行一次可用性分析与治理，那么越到到后面，前面所做的一切可用性治理努力带来的成果将会不断被稀释直至消失。

正是因为如此，腾讯云云顾问混沌平台也基于架构纬度，提供了「应用管理」，是一套完整的可用性治理解决方案，可以将架构图涉及到各种组件资源统一纳管，依靠腾讯云云顾问-云巡检每天巡检资源/架构隐患的数据，计算出整体架构的可用性分数，并提供混沌验证，验证得分也将成为可用性分数的一部分。用户通过应用管理，可以清晰地看到目前存在的隐患，以及整体可用性分数的趋势，便于进行持续的可用性治理。

不仅如此，腾讯云云顾问-混沌插件也整合这部分能力，可以在架构图上清晰地看到各个部件节点的隐患信息，并结合腾讯的隐患治理经验推荐演练方案，用户可以随时快捷进行混沌演练可用性分析或者可用性验证。

07、小结

本篇向大家介绍了一种有效的可用性治理方法 FMEA，并以一个简单的案例介绍了如何借助腾讯云云顾问混沌平台进行实践。FMEA 只是一种方法论，并没有完全的固定的模式，其中的分析栏目可以根据具体业务酌情取舍，最终的目的都是提高系统的可用性。正如文中提到的，FMEA 虽然理论上有效，但是实践起来的成本相对较高。混沌工程的理念刚好和 FMEA 的实施过程中的难点契合！可谓是可用性隐患分析治理最佳拍档。混沌与 FMEA 搭配使用，可用性治理变得有效同时还更高效。