关键字: [亚马逊云科技， 混沌工程实践， 故障注入， 系统韧性提高， 分布式架构复杂性， 潜在问题发现]

在这场演讲中，亚马逊云科技的解决方案架构师彭云介绍了混沌工程的概念和实施方法，并分享了一个客户案例。他解释了混沌工程通过主动注入故障来发现系统潜在问题，持续提高系统韧性的重要性。他详细阐述了混沌工程的实施流程，包括定义系统稳态、制定实验假设、选择实验环境、设计实验、执行实验、复盘改进等步骤。最后，他分享了亚马逊云科技为一家支付公司实施混沌工程的案例，通过故障注入大幅提高了支付成功率，降低了故障率和恢复时长。彭云强调了混沌工程需要建立相应的规范和制度，持续迭代实施，才能不断提升系统韧性。

以下是小编为您整理的本次演讲的精华。

在当今时代，随着系统架构的不断演进，从过去的单体架构逐步发展为现在的复杂架构，包括微服务架构、事件驱动架构、分布式架构等。这种复杂的架构虽然带来了应用性和扩展性的提升，但同时也引入了巨大的复杂性。在这种情况下，我们很难预知某个维度发生故障时会对整个系统产生何种影响，也难以了解微服务之间的关系和依赖关系。如果发生底层故障，例如网络抖动，我们无法确定会影响哪些微服务，对整个系统造成什么影响。因此，我们需要一种新的方法来应对这种复杂性，那就是混沌工程。

混沌工程是在分布式系统上进行实验的学科，目的是建立应对抵御复杂系统中未知问题的能力以及信心。它包含两层含义:底层含义是，混沌工程是一个实验的科学，它帮助我们提前做实验来预知问题、提前发现问题，避免在生产环境中再出现类似问题。第二层意思是，我们将它理解为一个理念和一套方法论，让我们帮助客户建立相应的框架和规范，持续进行混沌工程的迭代，树立起一个持续改善系统韧性的规范。

一个完整的混沌工程实施流程大致分为以下几个部分:首先，我们需要定义一个稳态，这个稳态就是系统架构的理想状态、预期状态，作为实验的对照组。其次，我们要做一个实验的假设，分析系统潜在的风险，通过这些风险分析，得到一些原则的故障点，作为未来实验的注入点。第三，运行混沌工程实验。第四，当实验运行完毕后，我们要与当时定义的稳态去对比，验证实验结果。最后，根据实验结果，找到问题所在、问题根源，提出改进计划，持续迭代这个过程。

另一个重要维度是可观测性。也许发生故障，但我们无法观测到影响。我们要与稳态对比，就需要指标，因此可观测性和监控非常重要，我们要能监控到故障的发生。在定义好假设后，我们准备做实验。做实验前，我们要选择实验环境。针对实验环境，越靠近生产系统，实验效果就越好，但风险也越高。一旦故障注入对生产系统造成影响，可能会严重影响业务。所以我们要根据业务情况选择合适的测试环境。通常，如果是内容生产的相对休闲场景，生产环境短暂中断影响不太大。但如果是金融支付业务，1秒的中断影响都很大，这种情况就不适合在生产环境测试。

有了假设并选好实验环境后，我们就开始设计实验。实验设计要针对某个假设，确定如何注入故障、如何执行试验。我们要写得比较全面，包括针对哪个工作负载做实验、针对哪个服务做故障注入、要注入哪些故障、在什么环境注入、测试时长、停止条件等，把每次故障注入的信息补充完整。准备就绪后，我们建议先做一个演练，因为混沌工程相对复杂，当在公司开展这个项目时，会涉及多个相关部门，需要运维人员、业务部门人员、研发人员等多方配合。每个人都需要知道在这个过程中自己的职责是什么，需要关注哪些问题，什么时候关注什么指标，什么时候做什么事情。这是需要多部门横向联合的事情，所以直接上生产，大家可能都不知道该干什么，因此需要先做一个演练，把每个人的角色职责都定位好，让大家知道在这个过程中需要关注什么。

混沌工程实验做完后，我们需要复盘这个实验。既然已经故障注入了，实验结果也出来了，我们要观察到了什么，注入的是什么样的故障。我们原本期望这个故障注入后会发生什么问题，实际情况是否如此?如果不是，发生的是什么?实际情况与预期有何差异?这个差异是由什么造成的?造成差异的根本原因是什么?我们要分析，然后根据分析制定改进计划。除了制定改进计划，还有一点很重要，就是举一反三。在这个问题上注入这样的故障，发生了这样的问题，我们要反思是否还有类似情况也会发生这样的问题，是否要提前去排查、预防。所以复盘、制定改进计划，并跟踪这些改进计划的迭代，才是一个完整的实验。

做混沌工程时，我们需要一些相应的工具来帮助注入故障，甚至观察指标。我列举了几个混沌工程测试工具:Amazon Web Services Fault Injection Simulator(Amazon Web Services FIS)是亚马逊托管的故障注入工具，能针对亚马逊技术服务注入故障。Chaos Mesh是一个混沌工程测试框架，以插件方式可跨平台支持各种平台。Litmus和Powerfault是专门针对容器化的测试工具。可根据自己的业务情况灵活选择这些工具。Amazon Web Services FIS的设计与我们前面讲的混沌工程测试过程非常相似。它需要根据前面的假设设计一个实验模板，模板中定义针对哪个资源注入、注入什么样的故障(动作)、停止条件等，然后一个模板一个模板地执行。Amazon Web Services FIS支持多种动作，可以从官方文档查看。使用Amazon Web Services FIS做故障注入模拟的过程是:首先通过控制台或命令行创建一个实验模板，然后启动这个模板，模板会自动执行实验，对目标资源注入故障。注入故障后，Amazon EventBridge和Amazon CloudWatch会监控整个实验执行过程，并判断停止条件，当达到停止条件时终止故障注入过程。

另外，我们还有一个产品叫Amazon Resilience Hub，这是一个亚马逊托管的持续改进系统韧性的产品。我们首先在Resilience Hub中定义一个应用，设置一些策略后，Resilience Hub就会持续评估你的应用，给应用打分并提出改进计划和方案。它会给你一个报告和分数，同时可以根据改进计划自动触发告警，也可以自动创建实验模板，通过混沌工程去进行故障注入测试。有一个例子，当系统初步部署时，Resilience Hub经过一段时间的观察监测，会给系统的韧性打一个分，并提出一些改进建议。我们通过这些建议改进后，它会继续评估，给出新的分数。后续我们不断迭代改进，它会一直帮我们评估。这就是Resilience Hub的产品。

刚才我讲的是一个完整的混沌工程理论实施流程。接下来，我分享一个我们在中国区域实施过的案例。这家公司Permax是一个为出海企业提供跨境支付服务的公司，在新兴市场的市场占有率较高，跨境支付能力较强。在2023年开始，我们与他们一起实施了两期混沌工程，通过这个实施，让他的支付成功率大幅提高，因此这个案例也上了我们全球的案例库。这个项目的实施背景是:作为一个支付企业，Permax的核心竞争力在于在新兴市场有非常强的本地支付能力。要想有这样的竞争力，能够覆盖更加全面的本地支付方式，就需要不断提供新的本地支付方式，所以他们的产品迭代特别快，每周有两次版本迭代和发布。另外，作为支付业务，它的支付链路很长，而且支付业务对成功率非常敏感，一旦支付链路某一环有问题，整个支付就会失败。对于这种新兴企业来说，支付失败导致的客户流失是难以接受的，所以他们对系统稳定性要求非常高。

在这样的情况下，我们在2023年就与客户建议使用混沌工程的方法来提高系统韧性，最后执行效果还是比较好的。这个实施过程中，我们在前一个月的时间里都在与客户介绍混沌工程的概念、理念、方法论，动员公司的相关人员去理解和认可这个事情。在这个项目实施过程中，统一思想是一个很重要的阶段，所以第一阶段，我们花了很多时间，我们的专家一起与客户的架构师、运维、研发、CDO等一起介绍混沌工程理念，帮助大家都理解混沌工程能做什么，怎么去做。然后，我们有一个重要的时间就是去做假设，这也是非常困难的事情。我们要针对客户的业务部门、研发部门，首先梳理现有的服务，梳理业务，然后定义出详细的风险，先识别风险，再做风险的假设定义，这个过程花费了大量时间。到后面执行测试时，客户自己就可以根据不同案例选择不同工具，持续测试下去。大概整个项目用了3个月的时间完成了一轮测试。

在做业务调研阶段，我们梳理了业务模块、服务、每个服务的架构和实现方式、部署方式、发生故障时的处理方式等，对现有业务框架做了梳理。根据梳理结果，我们会做出一个风险识别表，也就是假设表。这个表会详细定义在哪个环节做故障注入、故障级别、可能影响哪些系统、期望结果、停止条件等，把我们之前讲的假设那一块的所有细节都体现在表中。这张表是做这个项目花费时间最长的部分，需要不断与客户讨论，因为很容易把假设定义得过于宽泛或模糊。所以要推敲在这个假设里，条件是什么?比如在什么业务量情况下、故障在哪个方向上、一台EC2实例发生故障怎么样?一个可用区发生故障怎么样?这些都要定义得很清楚，否则无法做对比。

整个项目实施下来，效果还是比较明显的。首先，我们从0开始把整个流程跑了一遍，确实识别出了很多问题，这些问题经过实验得到了改进。从业务上看，我们可以看到这样的效果:客户经过这样一期一期的项目，就在公司内部建立起了这样的机制，会定期执行混沌工程，定期做故障模拟。在这个过程中，最明显的结果指标是，经过两轮项目实施后，客户的故障率、故障数量明显比上一年减少了60%-70%，故障的恢复时长也降低了很多。我们还发现了一些未知的问题，当你这样故障注入后，实际会发生什么情况?比如在防火墙上就发现了几个确实存在的bug。通过这样的实验，就发现出来了。客户目前应该是一个季度会跑一遍。这是他们系统控制台的一个截图，他们会定义很多模板。在这个过程中，随着业务的发展和系统的建设，这个模板会不断补充，然后每个季度会去跑一遍，查看效果。

所以整个项目执行下来，我们一开始讲到的三个点:做实验、实施这个项目，另一个很重要的点就是客户理解这个项目，有了这个理念和信念，建立起相应的规范和制度。最后总结一下混沌工程的5大原则:第一，我们要建立一个围绕稳态的假设。第二，尽量让假设多样化。第三，如果可能的话，尽量在生产环境靠近的环境里面去测试。第四，让这个过程持续起来，迭代起来。混沌工程并不是一次性的项目执行一次就结束了，更多的是要形成一个制度、一个框架，然后持续定期地做下去，才能通过混沌工程持续提高系统的韧性。第五，要举一反三。在一个问题上注入故障，发现了一些问题，我们要反思是否还有类似情况也会发生这样的问题，从而提前去排查、预防。

总的来说，通过这个Permax的案例，我们可以看到混沌工程给客户带来了显著的效果，提高了系统的稳定性和韧性。更重要的是，客户理解并认可了混沌工程的理念，建立了相应的规范和制度，将其作为一种持续改进系统韧性的方法论。混沌工程的核心目的是通过主动注入故障来发现系统的潜在问题，提前暴露风险，从而持续提升系统的可靠性和韧性。它不仅是一个实验过程，更是一种理念和方法论，需要企业内部形成一种文化，将其制度化、常态化，才能真正发挥其价值。通过不断的实践、迭代和改进，企业可以建立起应对复杂系统中未知问题的能力和信心。

在这个Permax的案例中，作为一家为出海企业提供跨境支付服务的公司，其核心竞争力在于在新兴市场拥有非常强的本地支付能力。然而，要想持续保持这种竞争优势，就需要不断推出新的本地支付方式，使得他们的产品迭代速度非常快，每周都有两次版本迭代和发布。同时，作为支付业务，其支付链路极为冗长，对成功率的要求也异常严格，一旦支付链路的任何一个环节出现问题，整个支付就会失败。对于这种新兴企业来说，支付失败导致的客户流失是难以承受的，因此他们对系统的稳定性有着极高的要求。

正是基于这种背景，我们在2023年开始就与Permax的团队建议采用混沌工程的方法来提高其系统的韧性。在实施这个项目的过程中，我们花费了前一个月的时间，与客户的架构师、运维人员、研发人员、CDO等一起介绍混沌工程的概念、理念和方法论，努力让公司的相关人员都理解并认可这个事情。统一思想是这个项目实施的一个非常重要的阶段。

之后，我们进入了一个非常困难的阶段，那就是做假设。我们需要针对客户的业务部门和研发部门，首先梳理现有的服务和业务，然后定义出详细的风险点，先识别风险，再针对这些风险做出假设定义。这个过程花费了大量的时间。等到后面真正执行测试的时候，客户自己就可以根据不同的案例选择不同的工具，持续进行测试下去。整个项目用了3个月的时间完成了一轮测试。

在做业务调研的阶段，我们梳理了业务模块、服务、每个服务的架构和实现方式、部署方式、发生故障时的处理方式等，对现有业务框架进行了全面的梳理。根据梳理的结果，我们会做出一个风险识别表，也就是假设表。这个表会详细定义在哪个环节做故障注入、故障的级别、可能影响哪些系统、期望的结果、停止条件等，把我们之前讲的关于假设的所有细节都体现在表中。这张表是整个项目中花费时间最长的部分，因为我们需要不断与客户讨论，很容易把假设定义得过于宽泛或模糊。所以我们要推敲在这个假设里，条件是什么?比如在什么业务量情况下、故障在哪个方向上、一台EC2实例发生故障会怎样?一个可用区发生故障又会怎样?这些都需要定义得非常清晰，否则无法做对比。

整个项目实施下来，效果还是比较明显的。首先，我们从0开始把整个流程跑了一遍，确实识别出了很多问题，这些问题经过实验后得到了改进。从业务上看，我们可以看到这样的效果:客户经过这样一期一期的项目，就在公司内部建立起了这样的机制，会定期执行混沌工程，定期做故障模拟。在这个过程中，最明显的结果指标是，经过两轮项目实施后，客户的故障率、故障数量明显比上一年减少了60%-70%，故障的恢复时长也大幅降低。我们还发现了一些之前未知的问题，当你这样故障注入后，实际会发生什么情况?比如在防火墙上就发现了几个确实存在的bug，通过这样的实验才被发现出来。客户目前应该是按季度执行一次。这是他们系统控制台的一个截图，他们会定义很多模板。在这个过程中，随着业务的发展和系统的建设，这些模板会不断补充，然后每个季度都会运行一遍，查看效果。

所以整个项目执行下来，我们一开始讲到的三个点:做实验、实施这个项目，另一个很重要的点就是客户理解了这个项目，有了这个理念和信念，并建立起了相应的规范和制度。最后总结一下混沌工程的5大原则:第一，我们要建立一个围绕稳态的假设。第二，尽量让假设多样化。第三，如果可能的话，尽量在生产环境靠近的环境里面去测试。第四，让这个过程持续起来，迭代起来。混沌工程并不是一次性的项目执行一次就结束了，更多的是要形成一个制度、一个框架，然后持续定期地做下去，才能通过混沌工程持续提高系统的韧性。第五，要举一反三。在一个问题上注入故障，发现了一些问题，我们要反思是否还有类似情况也会发生这样的问题，从而提前去排查、预防。

总的来说，通过这个Permax的案例，我们可以看到混沌工程给客户带来了显著的效果，提高了系统的稳定性和韧性。更重要的是，客户理解并认可了混沌工程的理念，建立了相应的规范和制度，将其作为一种持续改进系统韧性的方法论。混沌工程的核心目的是通过主动注入故障来发现系统的潜在问题，提前暴露风险，从而持续提升系统的可靠性和韧性。它不仅是一个实验过程，更是一种理念和方法论，需要企业内部形成一种文化，将其制度化、常态化，才能真正发挥其价值。通过不断的实践、迭代和改进，企业可以建立起应对复杂系统中未知问题的能力和信心。

下面是一些演讲现场的精彩瞬间：

Peng Yun， a solutions architect from 亚马逊云科技， introduces the topic of continuously improving system resilience through chaos engineering， alongside Professor Gu Lei.

Before conducting the actual canary deployment， it is recommended to have a rehearsal to ensure everyone understands their roles and responsibilities in the process， as it involves coordination across multiple teams and departments.

亚马逊的 Chaos Engineering 产品 Fault Injection Simulated Experiment (FISE) 的设计过程与红豆工程的测试过程非常相似，定义了目标资源、注入故障类型和停止条件。

亚马逊云科技的混沌工程实践旨在通过主动注入故障来发现系统架构中的潜在问题，从而持续提高系统的韧性。随着系统架构日益复杂，混沌工程成为一种必要的手段，帮助企业提前发现问题并加以改进。实施混沌工程需要遵循一套严格的流程，包括定义稳态、制定假设、执行实验、分析结果并制定改进计划。在具体案例中，亚马逊云科技与一家支付公司合作，通过两轮混沌工程实践，显著降低了故障率和恢复时长，同时发现了一些未知的系统问题。该公司最终建立了定期执行混沌工程的机制，将其作为提高系统韧性的持续实践。混沌工程的五大原则是:建立围绕稳态的假设、多样化假设、尽可能接近生产环境测试、持续迭代以及形成制度化框架。只有将混沌工程作为一种理念和方法论，企业才能真正从中受益。

我们正处在Agentic AI爆发前夜。2025亚马逊云科技中国峰会提出，企业要从“成本优化”转向“创新驱动”，通过完善的数据战略和AI云服务，把握全球化机遇。亚马逊将投入1000亿美元在AI算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在AI时代突破。