概览

将弹性测试与混沌工程进行比较

弹性测试是确定性的。也就是说，它可以验证应用程序中已实现的弹性机制的已知特征，例如断路器、重试、故障转移或回退。它证实了这些应用程序组件是如何吸收受控中断的，而对用户的影响微乎其微，甚至没有影响。因此，弹性测试侧重于验证已知的故障模式，这些模式注入到应用程序组件中，目的是产生 pass/fail 结果。作为流程中的一个步骤，你应该持续运行弹性测试，以确保你的弹性态势不会出现回归。在弹性测试中，你通常不对真实组件运行测试，而是模拟 APIs 某个组件的测试。这种方法允许在受控环境中对故障场景进行一致、可重复的测试，使其适用于自动化管道集成和回归测试。

相比之下，混沌工程是非确定性的。也就是说，它基于假设，可以验证你的思维模型，即应用程序及其依赖关系（人员、流程和技术）如何吸收、适应并最终从意想不到的故障模式中恢复。因此，混沌工程侧重于 end-to-end验证未知的故障模式，目标是尽早发现缺陷，并在缺陷演变为大规模事件之前对其进行修复。混沌工程可以促进持续学习，应通过单独的混沌管道或临时实验来练习，这样你就可以在任何时间点运行多个实验，而不会阻碍开发人员部署代码的工作效率。

混沌工程过程通常从混乱游戏日开始，这是一个专门的活动，团队故意在应用程序中注入受控的错误或故障。游戏日是渐进的：它从较低级别的环境（例如开发或测试）开始，随着信心的增强，逐渐发展到更高级别的环境（例如舞台和预制环境）。通过系统地在这些环境中移动，团队可以在注入的故障进入生产之前验证其系统是否能正确容忍这些故障。这种有条不紊的进展确保了在生产环境中进行混沌实验时，团队已经对其系统的弹性能力建立了极大的信心。游戏日流程是一种主动的方法，用于识别应用程序架构和操作实践中的弱点和漏洞，同时消除意外生产中断期间的学习压力。

混沌工程的价值

复杂的系统在当今世界无处不在。从金融市场到医疗保健，它们在我们生活的许多方面都起着至关重要的作用。我们期望这些系统始终处于运行状态。但是，复杂的系统通常容易受到意外事件和行为的影响，这些事件和行为可能会产生重大后果。Organizations 需要为颠覆做好计划，而不必怀疑它是否会发生。他们可以通过在关键或任务关键型业务服务中应用场景测试来做到这一点。这就是混沌工程发挥作用的地方。

混沌工程提供了一种管理复杂系统的方法，可以帮助降低风险和提高弹性。为混沌实验做准备的过程要求团队对系统的行为提出假设，这可以加深他们对系统的构建方式和运行方式的理解。这种准备工作通常会揭示心理差距、架构见解和操作知识，否则这些知识可能仍未被发现。通过进一步了解复杂系统如何应对故障，混沌工程可以提高系统设计和管理的透明度和问责制。您的组织实施混乱工程的频率越高，他们在运营方面的准备就越充分。混沌工程可以帮助您建立设计弹性应用程序的最佳实践，这些应用程序可以在组件故障中幸存下来，而对用户影响最小甚至根本没有。这可以确保关键应用程序在预期的服务级别和抗冲击能力范围内运行，同时不断增强团队对自己系统的了解。

为不利条件做好准备

在此基础上 AWS，您将使用不同类型的服务，包括亚马逊弹性计算云 (Amazon EC2) 等区域服务、区域服务（例如亚马逊简单存储服务 (Amazon S3) Simple S3）、全球服务（例如 AWS Identity and Access Management （IAM）、第三方软件即服务 (SaaS) 服务和本地服务。每种类型的服务都会暴露出不同的故障域，您需要考虑这些故障域。您如何为自己造成的事件或您的组织无法控制的第三方造成的事件做好准备？

为了帮助了解您的应用程序可能如何应对不利条件，可以使用 AWS Fault Injection Service (AWS FIS)。 AWS FIS 是一项完全托管的服务，用于以受控方式运行故障注入实验。您可以使用此服务来注入 AWS提供的场景，例如可用区电源中断和跨区域连接问题，或者通过将该服务提供的各种故障操作链接在一起来构建自己的实验。 AWS FIS 使您的团队能够持续练习和学习他们的应用程序将如何应对常见故障，并在发现缺陷时对其进行修复。

练习受控混沌工程

控制混沌实验的关键原理是：

要成功扩展混沌工程，必须以受控的方式实施混沌实验。使用时 AWS FIS，您可以使用 Amazon CloudWatch 警报创建停止条件。您可以将这些条件合并到实验模板中，以确保实验在越界时停止并回滚到其上次已知状态。 AWS FIS 还提供安全杠杆。当你使用这些杠杆时， AWS FIS 会停止和回滚账户中所有正在运行的实验 AWS 区域，包括多账户实验，并阻止启动新的实验。这样可以防止在某些时间段内注入错误，例如交易时间、销售活动或产品发布，或者响应应用程序运行状况警报。在手动脱离安全杆之前，安全杆一直处于接合状态。

进行混沌实验时，应定义保护措施以防止环境中出现不良副作用，尤其是在实验有可能影响生产中的应用程序的情况下。在计划实验时，要预测它可能对环境中的其他应用程序产生的任何不利影响。例如，其他应用程序可能会收到来自实验一部分的应用程序的错误消息，如果它们共享基础架构，则可能会遇到高请求量或遇到资源争用。在进行实验之前，请记录这些风险并解决任何已知或不可接受的问题。