# REL 12. 如何测试可靠性？
<a name="rel-12"></a>

在为工作负载采用韧性设计以应对生产压力以后，测试是确保其按设计预期运行，并且提供所预期韧性的唯一方式。

**Topics**
+ [

# REL12-BP01 使用行动手册调查故障
](rel_testing_resiliency_playbook_resiliency.md)
+ [

# REL12-BP02 执行事后分析
](rel_testing_resiliency_rca_resiliency.md)
+ [

# REL12-BP03 测试可扩展性和性能要求
](rel_testing_resiliency_test_non_functional.md)
+ [

# REL12-BP04 使用混沌工程测试韧性
](rel_testing_resiliency_failure_injection_resiliency.md)
+ [

# REL12-BP05 定期进行 GameDay 活动
](rel_testing_resiliency_game_days_resiliency.md)

# REL12-BP01 使用行动手册调查故障
<a name="rel_testing_resiliency_playbook_resiliency"></a>

 通过在行动手册中记录调查流程，对并不十分了解的故障场景实现一致且及时的响应。行动手册是在确定哪些因素导致故障场景时要执行的预定义步骤。所有流程步骤的结果都将用于确定要采取的后续步骤，直到问题得到确定或上报。

 行动手册是您必须要执行的主动计划，以便有效采取被动措施。当在生产中遇到行动手册未涉及的故障场景时，首先要解决问题（灭火）。然后回过头来思考您在解决问题时采取的措施，并将这些措施作为新条目添加到行动手册中。

 请注意，行动手册可用于对特定事件做出响应，运行手册则用来达成特定的结果。通常，运行手册适用于例行活动，而行动手册则用于对非例行事件做出响应。

 **常见反模式：**
+  计划在以下情况下部署工作负载：不清楚诊断问题或响应事件的流程。
+  关于在对事件进行调查时从哪些系统收集日志和指标的计划外的决定。
+  指标和事件保留的时间不够长，无法检索到数据。

 **建立此最佳实践的好处：**使用行动手册可确保始终如一地遵循流程。编写行动手册可以减少手动操作导致的错误。通过实现行动手册自动化，可以消除团队成员干预的需要，或者在他们开始干预时便向他们提供更多信息，从而缩短事件响应时间。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>
+  使用行动手册来发现问题。行动手册是用于调查问题的书面程序。在行动手册中记录流程，实现对故障场景的一致而及时的响应。行动手册必须包含所需的信息和指导，让足够熟练的员工能够收集适用信息、确定故障的潜在来源、隔离故障，并确定成因（即执行事后分析）。
  +  以代码形式实施行动手册。为行动手册编写脚本，以代码形式执行运营，确保一致性并减少由手动流程引起的错误。行动手册可以由代表不同步骤的多个脚本组成，这些步骤可能是确定问题成因所必需的。系统可能会在运行手册活动过程中调用或执行行动手册活动，也可能针对响应发现的事件而提示执行行动手册活动。
    +  [使用 AWS Systems Manager 自动执行运营行动手册](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/) 
    +  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
    +  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
    +  [什么是 AWS Lambda ？](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 
    +  [什么是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
    +  [使用 Amazon CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 

## 资源
<a name="resources"></a>

 **相关文档：**
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html) 
+  [使用 AWS Systems Manager 自动执行运营行动手册](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/) 
+  [使用 Amazon CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 
+  [使用金丝雀（Amazon CloudWatch Synthetics）](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 
+  [什么是 Amazon EventBridge？](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html) 
+  [什么是 AWS Lambda ？](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 

 **相关示例：**
+  [根据行动手册和运行手册自动完成操作](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

# REL12-BP02 执行事后分析
<a name="rel_testing_resiliency_rca_resiliency"></a>

 审核影响客户的事件，确定这些事件的成因和预防措施。利用这些信息来制定缓解措施，限制或防止再次发生同类事件。制定程序，以便迅速有效地做出响应。根据目标受众，适当传达事件成因和纠正措施。如果需要，可将这些原因告知他人。

 评测为什么现有测试找不到问题。如果还没有，为此案例增设测试。

 **期望结果：**您的团队采用一致且一致的方法来处理事后分析。一种机制是[错误更正（COE）流程](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)。COE 流程有助于您的团队识别、理解和解决事件的根本原因，同时还可以建立防护机制，以限制同一事件再次发生的可能性。

 **常见反模式：**
+  查找事件成因，但不继续深入探究其他潜在问题和缓解问题的方法。
+  只找出人为错误原因，但不提供任何培训或可防止人为错误的自动化功能。
+  只注重追究责任，而不去了解根本原因，营造恐惧文化，阻碍开诚布公的交流 
+  见解分享不畅，事件分析结果仅限于一小群人知道，其他人无法从中吸取经验教训 
+  没有收集制度性知识的机制，因此无法以最新最佳实践的形式保存经验教训，从而失去宝贵见解，导致根本原因相同或相似的事件反复发生 

 **建立此最佳实践的好处：**如果其他工作负载实施了相同的成因，执行事后分析并共享分析结果可帮助缓解这些工作负载的故障风险，让它们能够在事件发生之前实施缓解或自动恢复措施。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

 有效的事后分析让您有机会针对系统中其他地方使用的架构模式存在的问题，提出常见的解决方案。

 COE 流程的基础是记录和解决问题。建议定义一种标准化的方法来记录关键的根本原因，并确保其得到分析和处理。为事后分析流程分配明确的责任人。指派负责的团队或个人来监督事件调查和后续行动。

 鼓励注重学习和改进而不是互相推脱责任的文化。强调目标是防止将来发生事件，而不是惩罚某些人。

 为执行事后分析制定明确定义的程序。这些程序应概述要采取的步骤、要收集的信息以及在分析期间要解决的关键问题。彻底调查事件，除直接原因外，还要找出根本原因和成因。使用诸如*[五个为什么](https://en.wikipedia.org/wiki/Five_whys)*之类的技巧来深入研究潜在问题。

 维护从事件分析中吸取的经验教训的存储库。这些制度性知识可以作为未来的事件和预防工作的参考。分享在事后分析中发现的结果和洞察，并考虑召开公开的事后审查会议，讨论经验教训。

### 实施步骤
<a name="implementation-steps"></a>
+  在执行事后分析时，确保整个过程不是以追究责任为目的。这使事件中涉及到的人员能够冷静地看待建议的纠正措施，并促进诚实的自我评测和团队间的协作。
+  定义记录关键问题的标准化方法。此类文档的示例结构如下所示：
  +  发生了什么？ 
  +  客户和您的业务受到了什么影响？ 
  +  根本原因是什么？ 
  +  您有哪些数据来支持这一点？ 
    +  例如，指标和图表 
  +  对关键支柱有什么影响，特别是在安全方面？ 
    +  在构造工作负载时，您需要基于业务环境在各个支柱之间做出权衡。这些业务决策可以推动您的工程优先事务。在开发环境中，您可能会通过降低可靠性来降低成本；而对于任务关键型解决方案，您可能会通过增加成本来提高可靠性。安全始终是头等大事，因为您必须保护您的客户。
  +  您获得了哪些经验教训？ 
  +  您采取了哪些纠正措施？ 
    +  操作项 
    +  相关术语 
+  为执行事后分析制定明确定义的标准操作程序。
+  设置标准化事件报告流程。全面记录所有事件，包括最初的事件报告、日志、通信和事件期间采取的行动。
+  请记住，并不是发生了停机才叫做事件。这可能是未遂事件，也可能是系统能够履行其业务功能，但以意外的方式运行。
+  根据反馈和经验教训，持续改进事后分析流程。
+  在知识管理系统中记录关键调查发现，并考虑应添加到开发人员指南或部署前清单中的任何模式。

## 资源
<a name="resources"></a>

 **相关文档：**
+  [Why you should develop a correction of error (COE)](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/) 

 **相关视频：**
+ [Amazon’s approach to failing successfully ](https://aws.amazon.com/builders-library/amazon-approach-to-failing-successfully/)
+ [AWS re:Invent 2021 - Amazon Builders' Library: Operational Excellence at Amazon](https://www.youtube.com/watch?v=7MrD4VSLC_w)

# REL12-BP03 测试可扩展性和性能要求
<a name="rel_testing_resiliency_test_non_functional"></a>

 使用负载测试等技术来验证工作负载是否满足扩展和性能要求。

 在云中，可以按需为工作负载创建生产规模测试环境。可以使用云来预置一个与预期生产环境非常接近的测试环境，而不是依赖于缩减的测试环境（这可能会导致对生产行为的预测不准确）。此环境有助于您更准确地模拟应用程序面临的现实世界条件来进行测试。

 除了性能测试工作外，还务必验证基础资源、扩展设置、服务配额和韧性设计在负载之下是否按预期运行。这种整体方法验证应用程序可根据需要可靠地扩展和执行，即使在最苛刻的条件下也不例外。

 **期望结果：**即使在峰值负载下，工作负载也会保持其预期的行为。您可以主动解决随着应用程序发展和演变而可能出现的任何与性能有关的问题。

 **常见反模式：**
+  您使用的测试环境与生产环境不太匹配。
+  您将负载测试视为单独的一次性活动，而不是部署持续集成（CI）管道不可或缺的部分。
+  您没有定义明确且可衡量的性能要求，例如响应时间、吞吐量和可扩展性目标。
+  您在不切实际或负载不足的情况下执行测试，并且无法针对峰值负载、突然激增和持续高负载进行测试。
+  您没有通过超出预期的负载限制来对工作负载进行压力测试。
+  您使用了不充分或不适当的负载测试和性能分析工具。
+  您缺乏全面的监控和警报系统来跟踪性能指标和检测异常情况。

 **建立此最佳实践的好处：**
+  负载测试有助于您在系统投入生产之前识别其潜在的性能瓶颈。在模拟生产级流量和工作负载时，您可以确定系统可能难以处理负载的领域，例如响应时间慢、资源限制或系统故障。
+  当您在各种负载条件下测试系统时，可以更好地了解支持工作负载所需的资源需求。这些信息有助于您在资源分配方面做出明智的决策，并防止资源过度配置或配置不足。
+  要识别潜在的故障点，您可以观察工作负载在高负载条件下的性能。这些信息有助于您通过酌情实施容错机制、失效转移策略和冗余措施，来提高工作负载的可靠性和韧性。
+  您可以尽早发现并解决性能问题，这有助于避免系统中断、响应时间缓慢和用户不满意所带来的代价高昂的后果。
+  在测试期间收集的详细性能数据和分析信息有助于您排查生产环境中可能出现的与性能相关的问题。这可以加快事件响应和解决速度，从而减少对用户和组织运营的影响。
+  在某些行业，主动性能测试有助于工作负载达到合规标准，从而降低受处罚或出现法律问题的风险。

 **在未建立这种最佳实践的情况下暴露的风险等级：**高 

## 实施指导
<a name="implementation-guidance"></a>

 第一步是定义全面的测试策略，该策略涵盖扩展和性能要求的各个方面。首先，根据业务需求（例如吞吐量、延迟直方图和错误率），明确定义工作负载的服务级别目标（SLO）。接下来，设计一套测试来模拟各种负载场景，范围涵盖从平均使用量到突然激增和持续的峰值负载，并验证工作负载的行为是否符合 SLO。这些测试应自动执行，并集成到持续集成和部署管道中，以便在开发过程的早期阶段发现性能回归情况。

 要有效地测试扩展和性能，请投资购买正确的工具和基础设施。这包括可以生成真实用户流量的负载测试工具、用于识别瓶颈的性能分析工具以及用于跟踪关键指标的监控解决方案。重要的是，您应该验证测试环境在基础设施和环境条件方面是否与生产环境紧密匹配，以使您的测试结果尽可能准确。为了更轻松且可靠地复制和扩展类似于生产环境的设置，请使用基础设施即代码和基于容器的应用程序。

 扩展和性能测试是一个持续的过程，而不是一次性活动。实施全面的监控和警报来跟踪应用程序在生产环境中的性能，并使用这些数据来不断完善测试策略和优化工作。定期分析性能数据来识别新出现的问题，测试新的扩展策略，并实施优化以提高应用程序的效率和可靠性。当您采用迭代方法并不断从生产数据中学习时，可以验证应用程序是否能够适应不断变化的用户需求，并随着时间的推移保持韧性和最佳性能。

### 实施步骤
<a name="implementation-steps"></a>

1.  制定明确且可衡量的性能要求，例如响应时间、吞吐量和可扩展性目标。这些要求应基于工作负载的使用规律、用户预期和业务需求。

1.  选择并配置负载测试工具，该工具可以准确地模仿生产环境中的负载规律和用户行为。

1.  设置与生产环境（包括基础设施和环境条件）紧密匹配的测试环境，来提高测试结果的准确性。

1.  创建涵盖各种场景的测试套件，范围从平均使用规律到峰值负载、快速激增和持续的高负载。将测试集成到持续集成和部署管道中，以便在开发过程的早期阶段发现性能回归情况。

1.  开展负载测试来模拟真实的用户流量，并了解应用程序在不同负载条件下的行为。要对应用程序进行压力测试，请超出预期负载并观察其行为，例如响应时间降级、资源耗尽或系统故障，这有助于确定应用程序的突破点并为扩展策略提供信息。通过逐步增加负载来评估工作负载的可扩展性，并衡量性能影响，来确定扩展限制并规划未来的容量需求。

1.  实施全面的监控和警报，来跟踪性能指标，检测异常，并在超过阈值时启动扩展操作或通知。

1.  持续监控和分析性能数据，来确定需要改进的领域。对测试策略和优化工作进行迭代。

## 资源
<a name="resources"></a>

 **相关最佳实践：**
+  [REL01-BP04 监控和管理配额](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html) 
+  [REL06-BP01 为工作负载监控全部组件（生成）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html) 
+  [REL06-BP03 发送通知（实时处理和报警）](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html) 

 **相关文档：**
+  [加载测试应用程序](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html) 
+  [AWS 上的分布式负载测试](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) 
+  [应用程序性能监控](https://aws.amazon.com/what-is/application-performance-monitoring/) 
+  [Amazon EC2 Testing Policy](https://aws.amazon.com/ec2/testing/) 

 **相关示例：**
+  [Distributed Load Testing on AWS (GitHub)](https://github.com/aws-solutions/distributed-load-testing-on-aws) 

 **相关工具：**
+  [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html) 
+  [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 
+  [Apache JMeter](https://jmeter.apache.org/) 
+  [K6](https://k6.io/) 
+  [Vegeta](https://github.com/tsenart/vegeta) 
+  [Hey](https://github.com/rakyll/hey) 
+  [ab](https://httpd.apache.org/docs/2.4/programs/ab.html) 
+  [wrk](https://github.com/wg/wrk) 
+ [AWS 上的分布式负载测试](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/)

# REL12-BP04 使用混沌工程测试韧性
<a name="rel_testing_resiliency_failure_injection_resiliency"></a>

 在生产环境中或尽可能接近生产的环境中定期运行混沌试验，了解系统如何应对不利条件。

 **期望结果：**

 除了在事件期间验证已知预期工作负载行为的韧性测试之外，还可以通过以故障注入实验或注入意外负载的形式应用混沌工程，定期验证工作负载的韧性。将混沌工程和韧性测试结合起来，这可以让您提升信心，相信工作负载能够经受组件故障，并可从意外中断中恢复，而影响极小甚至没有影响。

 **常见反模式：**
+  进行韧性设计，但不验证故障发生时工作负载如何作为一个整体运行。
+  从不在真实环境和预期负载下进行试验。
+  不将实验视为代码，也不在整个开发周期中维护实验。
+  不将混沌实验作为 CI/CD 管道的一部分，也不在部署之外运行。
+  在确定要对哪些故障进行试验时，没有想到使用过去的事件后分析。

 **建立此最佳实践的好处：**注入故障来验证工作负载的韧性，这可以让您提升信心，相信韧性设计的恢复程序会在真正发生故障的情况下发挥作用。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

 利用混沌工程，您的团队能够在服务提供商、基础设施、工作负载和组件级别，以可控的方式不断注入真实世界的干扰（模拟），而对客户的影响极小甚至没有影响。其可让团队从故障中学习，观察、测量和提高工作负载的韧性，并验证在发生事件时，系统会发出警报并通知团队。

 当持续执行时，混沌工程可突出工作负载中的缺陷，这些缺陷若不加以解决，可能会对可用性和运营产生负面影响。

**注意**  
混沌工程是在系统上进行实验的学科，目的是建立对系统抵御生产环境中失控条件的能力以及信心。– [混沌工程原则](https://principlesofchaos.org/) 

 如果系统能够经受住这些干扰，则应将混沌实验作为自动回归测试来加以维护。这样一来，应将混沌实验作为系统开发生命周期（SDLC）的一部分，以及作为 CI/CD 管道的一部分来执行。

 为了确保工作负载能够经受住组件故障，请在实验中注入实际事件。例如，对 Amazon EC2 实例的丢失或主 Amazon RDS 数据库实例的失效转移进行试验，并验证工作负载没有受到影响（或影响极小）。使用组件故障的组合来模拟可能因可用区中断而引起的事件。

 对于应用程序级故障（如崩溃），您可以从内存和 CPU 耗尽等压力源开始。

 为了验证因间歇性网络中断而引发的外部依赖项的[回退或失效转移机制](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)，组件应通过在指定时间段（从几秒到几小时不等）内阻止对第三方提供商的访问来模拟此类事件。

 其他降级模式可能会影响功能的使用并降低响应速度，这通常会导致服务中断。性能下降的常见原因是，关键服务的延迟增加以及网络通信不可靠（丢包）。对于这些故障（包括延迟、丢弃的消息和 DNS 故障等网络效应）的实验，可能包括无法解析名称、无法访问 DNS 服务或无法建立与依赖服务的连接。

 **混沌工程工具：**

 AWS Fault Injection Service（AWS FIS）是一项完全托管式服务，用于运行故障注入实验，而这些实验可用作 CD 管道的一部分，或在管道之外使用。AWS FIS 是在混沌工程 GameDay 活动期间使用的一个不错选择。该服务支持在不同类型的资源中同时引入故障，包括 Amazon EC2、Amazon Elastic Container Service（Amazon ECS）、Amazon Elastic Kubernetes Service（Amazon EKS）和 Amazon RDS 等资源。这些故障包括终止资源、强制失效转移、对 CPU 或内存施加压力、节流、延迟和数据包丢失。由于该服务已与 Amazon CloudWatch 警报集成，您可以设置停止条件作为防护机制，在实验导致意外影响时回滚。

![\[图中显示了 AWS Fault Injection Service 与 AWS 资源集成，让您能够为工作负载运行故障注入实验。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/fault-injection-simulator.png)


故障注入实验也有多种第三方选项。其中包括开源工具（例如 [Chaos Toolkit](https://chaostoolkit.org/)、[Chaos Mesh](https://chaos-mesh.org/) 和 [Litmus Chaos](https://litmuschaos.io/)），以及商用工具（例如 Gremlin）。为了扩大可在 AWS 上注入的故障范围，AWS FIS [与 Chaos Mesh 和 Litmus Chaos 集成](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/)，让您能够在多个工具之间协调故障注入工作流程。例如，您可以使用 Chaos Mesh 或 Litmus 故障对容器组的 CPU 运行压力测试，同时使用 AWS FIS 故障操作终止随机选择的集群节点百分比。

## 实施步骤
<a name="implementation-steps"></a>

1.  确定哪些故障要用于实验。

    评测工作负载的设计是否具有韧性。这种设计使用 [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html) 的最佳实践创建，考虑到了基于关键依赖项、以往事件、已知问题以及合规性要求的风险。列出每个旨在保持韧性的设计元素及其旨在缓解的故障。有关创建此类列表的更多信息，请参阅《[Operational Readiness Review](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)》白皮书，了解如何创建流程来防止以往事件再次发生。故障模式与影响分析（FMEA）流程提供了一个框架，可对故障及其对工作负载的影响执行组件级分析。Adrian Cockcroft 在《[Failure Modes and Continuous Resilience](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5)》中更详细地概述了 FMEA。

1.  为每个故障指定一个优先级。

    先进行粗略的分类，如高、中或低。要评测优先级，请考虑故障的频率和故障对整体工作负载的影响。

    考虑给定故障的频率时，请分析此工作负载的以往数据（如有）。如果没有以往数据，则使用在类似环境中运行的其他工作负载的数据。

    考虑给定故障的影响时，故障的范围越大，影响通常也越大。还要考虑工作负载设计和目的。例如，访问源数据存储的能力对于进行数据转换和分析的工作负载至关重要。在这种情况下，您要确定访问故障以及节流访问和延迟插入等实验的优先级。

    事件后分析是了解故障模式的频率和影响的良好数据来源。

    使用指定的优先级来确定首先对哪些故障进行实验，以及开发新的故障注入实验的顺序。

1.  对于执行的每项实验，请遵循下图中的混沌工程和持续韧性飞轮。  
![\[混沌工程和持续韧性飞轮图，显示了“改进”、“稳定状态”、“假设”、“进行实验”和“验证”阶段。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/chaos-engineering-flywheel.png)

    

   1.  将稳定状态定义为指示正常行为的工作负载的一些可测量输出。

       如果工作负载运行可靠且符合预期，则显示为稳定状态。因此，定义稳定状态之前，请验证工作负载是否运行状况良好。稳定状态并不一定意味着故障发生时对工作负载没有影响，因为一定百分比的故障可能在可接受的范围内。稳定状态是您将在实验期间观察到的基线，如果下一步中定义的假设结果不符合预期，则会突出显示异常。

       例如，可以将某个支付系统的稳定状态定义为处理 300 TPS，成功率为 99%，且往返时间为 500 毫秒。

   1.  形成一个关于工作负载如何应对故障的假设。

       一个好的假设是基于工作负载预计如何缓解故障来保持稳定状态。该假设指出，如果发生特定类型的故障，系统或工作负载将继续保持稳定状态，因为该工作负载在设计时就有特定缓解措施。应在假设中具体说明特定的故障类型和缓解措施。

       假设可以使用以下模板（但其他措辞也可以接受）：
**注意**  
 如果发生*具体故障*，则*工作负载名称*工作负载将*描述缓解控制措施*，以此维持*业务或技术指标影响*。

       例如：
      +  如果 Amazon EKS 节点组中 20% 的节点出现故障，则 Transaction Create API 将在不到 100 毫秒的时间内继续处理 99% 的请求（稳定状态）。Amazon EKS 节点将在五分钟内恢复，容器组将在实验开始后八分钟内得到调度并处理流量。警报将在三分钟内发出。
      +  如果单个 Amazon EC2 实例发生故障，订单系统的弹性负载均衡运行状况检查会让弹性负载均衡仅向剩余的运行状况良好的实例发送请求，而 Amazon EC2 Auto Scaling 将替换故障实例，从而保持服务器端（5xx）错误增长率低于 0.01%（稳定状态）。
      +  如果主 Amazon RDS 数据库实例发生故障，则供应链数据收集工作负载将失效转移并连接到备用 Amazon RDS 数据库实例，以保持不到 1 分钟的数据库读写错误（稳定状态）。

   1.  通过注入故障来进行实验。

       默认情况下，实验应具有故障保护机制，可承受工作负载。如果知道工作负载将发生故障，则不要进行实验。混沌工程应该用于寻找已知的不确定因素或未知的不确定因素。*已知的不确定因素*是您知道但不完全理解的东西，而*未知的不确定因素*是您既不知道也不完全理解的东西。对已知发生了故障的工作负载进行实验，并不会为带来新的见解。您应该仔细规划实验，明确影响范围，并提供一种可在出现意外动荡时应用的回滚机制。如果尽职调查表明工作负载应该能经受住实验，才继续这项实验。有几种注入故障的选项。对于 AWS 上的工作负载，[AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 提供了许多称为[操作](https://docs.aws.amazon.com/fis/latest/userguide/actions.html)的预定义故障模拟。您还可以定义在 AWS FIS 中运行的自定义操作（使用 [AWS Systems Manager 文档](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html)）。

       我们不鼓励使用自定义脚本进行混沌实验，除非这些脚本能够了解工作负载的当前状态，能够发出日志，并在可能的情况下提供回滚和停止条件的机制。

       支持混沌工程的有效框架或工具集应跟踪实验的当前状态，发出日志，并提供回滚机制以支持实验的受控执行。从 AWS FIS 这样的成熟服务开始，该服务支持您在明确定义的范围内和安全机制下进行实验，可在实验引入了意外动荡的情况下回滚实验。要了解更多使用 AWS FIS 的实验，另请参阅 [Resilient and Well-Architected Apps with Chaos Engineering 实验室](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)。此外，[AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 将分析工作负载，并创建您可以选择在 AWS FIS 中实施和执行的实验。
**注意**  
 对于每项实验，要清楚地了解其范围及影响。建议首先在非生产环境中模拟故障，再在生产环境中运行。

       应使用实际负载，通过[金丝雀部署](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)在生产环境中进行实验，尽可能同时启动控制和实验系统部署。在非高峰时间进行实验是一种很好的做法，可以减小首次在生产环境中试验时的潜在影响。此外，如果使用实际的客户流量会带来太大的风险，您可以在生产基础设施上针对控制和实验部署使用合成流量进行实验。当不能使用生产环境时，在尽可能接近生产环境的预生产环境中进行实验。

       您必须建立和监控防护机制，确保实验对生产流量或其他系统的影响不会超过可接受的限度。建立停止条件，以便在实验达到您定义的防护机制指标的阈值时停止实验。这应该包括工作负载的稳定状态指标，以及针对您要注入故障的组件的指标。[综合监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)（也称为用户金丝雀）是一个通常应作为用户代理包含的指标。[AWS FIS 的停止条件](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html)应纳入实验模板中，每个模板最多可以有五个停止条件。

       混沌的原则之一是尽量缩小实验范围并减小其影响：

       虽然必须考虑到一些短期负面影响，但混沌工程师有责任和义务确保实验产生的影响极小且可控。

       验证范围和潜在影响的一种方法是首先在非生产环境中进行实验，确认停止条件的阈值是否在实验期间按预期激活，以及是否具有可观测性来捕获异常，而不是直接在生产环境中进行实验。

       运行故障注入实验时，确保所有责任方均知情。与适当的团队（如运营团队、服务可靠性团队和客户支持团队）沟通，让他们知道实验将在何时运行以及预期会发生什么。为这些团队提供沟通工具，以便在他们看到任何不利影响时通知进行实验的人员。

       必须将工作负载及其底层系统恢复到最初的已知良好状态。通常，工作负载的韧性设计会自我修复。但一些故障设计或失败实验可能会让工作负载处于意外的失败状态。在实验结束时，您必须意识到这一点，并恢复工作负载和系统。使用 AWS FIS，您可以在操作参数中设置回滚配置（也称为后期操作）。后置操作可将目标返回到操作运行之前的状态。无论是自动执行（如使用 AWS FIS）还是手动执行，这些后期操作都应包含在描述如何检测和处理故障的行动手册中。

   1.  验证假设。

      [混沌工程原则](https://principlesofchaos.org/)为如何验证工作负载的稳定状态提供了以下指导：

      关注系统的可测量输出，而不是系统的内部属性。短时间内对该输出的测量构成了系统稳态的代理。整个系统的吞吐量、错误率和延迟百分比都可以是代表稳态行为的相关指标。通过关注实验过程中的系统行为模式，混沌工程验证系统确实在工作，而不是试图验证它如何工作。

       在之前的两个示例中，我们包括了服务器端（5xx）错误增长率低于 0.01% 和数据库读写错误持续时间不到 1 分钟的稳态指标。

       5xx 错误是一个很好的指标，因为此类错误是工作负载客户端会直接经历的故障模式的结果。数据库错误测量适合作为故障的直接结果，但是还应补充一个客户端影响测量，例如失败的客户请求或向客户端显示的错误。此外，在工作负载客户端直接访问的任何 API 或 URI 上包含一个综合监控（也称为用户金丝雀）。

   1.  改进工作负载设计，提高韧性。

       如果未保持稳定状态，则调查如何改进工作负载设计来缓解故障，并应用 [AWS Well-Architected 可靠性支柱](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)的最佳实践。可以在 [AWS Builder’s Library](https://aws.amazon.com/builders-library/) 中找到其他指导和资源，其中包含有关如何[改进运行状况检查](https://aws.amazon.com/builders-library/implementing-health-checks/)或[在应用程序代码中结合采用重试与回退](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)的文章，等等。

       实施这些更改后，再次进行实验（如混沌工程飞轮中的虚线所示），确定更改的效果。如果验证步骤表明假设成立，则工作负载将处于稳定状态，循环将继续。

1.  定期进行实验。

    混沌实验是一个循环，作为混沌工程的一部分，应定期进行实验。在工作负载满足实验的假设后，实验应实现自动化，作为 CI/CD 管道的回归部分持续运行。要了解如何做到这一点，请参阅关于[如何使用 AWS CodePipeline 进行 AWS FIS 实验](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/)的博客。这个关于反复[在 CI/CD 管道中进行 AWS FIS 实验](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html)的实验室让您能够动手实践。

    故障注入实验也是 GameDay 活动的一部分（请参阅 [REL12-BP05 定期进行 GameDay 活动](rel_testing_resiliency_game_days_resiliency.md)）。GameDay 活动会模拟故障或事件，以便验证系统、流程和团队的响应。其目的是实际执行团队在发生意外事件时会执行的操作。

1.  捕获和存储实验结果。

   必须捕获并持久保存故障注入实验的结果。包括所有必要的数据（如时间、工作负载和条件），以便以后能够分析实验结果和趋势。结果示例可能包括控制面板的屏幕截图、从指标数据库进行的 CSV 转储，或实验中事件和观察结果的手写记录。[使用 AWS FIS 进行实验记录](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html)可作为这种数据捕获的一部分。

## 资源
<a name="resources"></a>

 **相关最佳实践：**
+  [REL08-BP03 将韧性测试作为部署的一部分进行集成](rel_tracking_change_management_resiliency_testing.md) 
+  [REL13-BP03 测试灾难恢复实施以验证实施效果](rel_planning_for_recovery_dr_tested.md) 

 **相关文档：**
+  [什么是 AWS Fault Injection Service？](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 
+  [什么是 AWS Resilience Hub？](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 
+  [混沌工程原则](https://principlesofchaos.org/) 
+  [Chaos Engineering: Planning your first experiment](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde) 
+  [Resilience Engineering: Learning to Embrace Failure](https://queue.acm.org/detail.cfm?id=2371297) 
+  [混沌工程案例](https://github.com/ldomb/ChaosEngineeringPublicStories) 
+  [避免在分布式系统中回退](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) 
+  [用于混沌实验的金丝雀部署](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) 

 **相关视频：**
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering (ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg) 
+  [AWS re:Invent 2019: Improving resiliency with chaos engineering (DOP309-R1)](https://youtu.be/ztiPjey2rfY) 
+  [AWS re:Invent 2019: Performing chaos engineering in a serverless world (CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA) 

 **相关工具：**
+  [AWS Fault Injection Service](https://aws.amazon.com/fis/) 
+ AWS Marketplace：[Gremlin 混沌工程平台](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney) 
+  [Chaos Toolkit](https://chaostoolkit.org/) 
+  [Chaos Mesh](https://chaos-mesh.org/) 
+  [Litmus](https://litmuschaos.io/) 

# REL12-BP05 定期进行 GameDay 活动
<a name="rel_testing_resiliency_game_days_resiliency"></a>

 安排 GameDay 来定期练习旨在应对影响工作负载的事件和损害的过程。让负责处理生产场景的团队参与进来。这些练习有助于强制实施相关措施，来防止生产事件对用户造成影响。当您在现实条件下实践响应过程时，可以在实际事件发生之前发现并解决任何差距或弱点。

 GameDay 活动会模拟类似于生产的环境中的事件，以便测试系统、流程和团队的响应。其目的是执行团队在实际发生事件时会执行的相同操作。这些练习有助于您了解可以从哪些方面作出改进，并有助于培养组织在处理各种事件和损害方面的经验。这些练习应该定期开展，这样，团队就知道如何建立根深蒂固的应对习惯。

 GameDay 可让团队做好准备，以便更充满信心地处理生产事件。经过良好练习的团队更有能力快速检测和应对各种场景。这可以显著改善就绪状态和韧性态势。

 **期望结果：**您在一致、有计划的基础上运行韧性 GameDay。这些 GameDay 被视为业务运营中正常和预期的组成部分。您的组织已经建立了备灾文化，当出现生产问题时，团队已经做好了充分的准备，可以有效地做出响应，高效地解决问题并减轻对客户的影响。

 **常见反模式：**
+  您记录过程，但从不练习这些过程。
+  您不让业务决策者参与测试练习。
+  您开展了 GameDay，但没有通知所有相关的利益相关者。
+  您只关注技术故障，但不涉及业务利益相关者。
+  您未将从 GameDay 中吸取的经验教训纳入恢复过程。
+  您将失败或错误归咎于团队。

 **建立此最佳实践的好处：**
+  增强响应技能：在 GameDay，团队在模拟的事件中练习其职责并测试其沟通机制，从而在生产环境中做出更加协调和高效的响应。
+  识别和解决依赖关系：复杂的环境通常涉及各种系统、服务和组件之间错综复杂的依赖关系。GameDay 有助于您识别和解决这些依赖关系，并验证运行手册过程是否正确涵盖了关键系统和服务，以及是否可以及时纵向扩展或恢复这类系统和服务。
+  培养韧性文化：GameDay 有助于培养组织内部的韧性思维。当您让跨职能团队和利益相关者参与时，这些练习可以提高整个组织对韧性重要性的认识、协作和共同理解。
+  持续改进和适应：定期的 GameDay 有助于您不断评测和调整韧性策略，从而使这些策略在不断变化的环境中保持相关性和有效性。
+  增强对系统的信心：成功的 GameDay 有助于您树立信心，确信系统能够承受中断并从中恢复。

 **在未建立这种最佳实践的情况下暴露的风险等级：**中 

## 实施指导
<a name="implementation-guidance"></a>

 设计并实施了必要的韧性措施后，请开展 GameDay 来验证生产中的一切是否按计划进行。GameDay，尤其是第一个 GameDay，应让所有团队成员都参与，并应事先向所有利益相关者和参与者告知日期、时间和模拟场景。

 在 GameDay 期间，参与的团队会根据规定的过程模拟各种事件和潜在的场景。参与者密切监控和评测这些模拟事件的影响。如果系统按设计运行，则应激活自动检测、扩展和自我修复机制，且对用户几乎没有影响。如果团队观察到任何负面影响，他们就会回滚测试，并通过相应运行手册中记载的自动手段或手动干预来纠正已发现的问题。

 要持续提高韧性，记录和吸取经验教训至关重要。该过程是一个*反馈循环*，它系统化地从 GameDay 捕获见解，并使用这些见解来增强系统、流程和团队能力。

 为协助您重现系统组件或服务可能意外出现故障的现实场景，请将模拟故障作为 GameDay 练习注入。团队可以在受控的环境中测试其系统的韧性和容错能力，并模拟其事件响应和恢复流程。

 借助 AWS，可以使用基础设施即代码，通过生产环境的副本来开展 GameDay。通过此过程，可以在与生产环境非常相似的安全环境中进行测试。考虑使用 [AWS Fault Injection Service](https://aws.amazon.com/fis/)来创建不同的故障场景。使用诸如 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 [AWS X-Ray](https://aws.amazon.com/xray/) 之类的服务来监控 GameDay 期间的系统行为。使用 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 来管理和运行行动手册，并使用 [AWS Step Functions](https://aws.amazon.com/step-functions/) 来编排重复出现的 GameDay 工作流程。

### 实施步骤
<a name="implementation-steps"></a>
+  **制定 GameDay 计划：**制定结构化计划来定义 GameDay 的频率、范围和目标。让关键利益相关者和主题专家参与规划和实施这些练习。
+  **为 GameDay 做好准备：**

  1.  确定主要的业务关键服务，这些服务是 GameDay 的重点。对支持这些服务的人员、流程和技术进行编目和映射。

  1.  制定 GameDay 的日程，让相关团队做好参与事件的准备。准备好自动化服务来模拟计划的场景并运行相应的恢复流程。诸如 [AWS Fault Injection Service](https://aws.amazon.com/fis/)、[AWS Step Functions](https://aws.amazon.com/step-functions/) 和 [AWS Systems Manager](https://aws.amazon.com/systems-manager/) 等 AWS 服务有助于您自动实施 GameDay 的各个方面，例如注入故障和启动恢复操作。
+  **运行模拟：**在 GameDay，运行计划的场景。观察并记录人员、流程和技术对模拟事件的反应。
+  **开展练习后回顾：**GameDay 结束后，召开回顾会议来回顾所吸取的教训。确定需要改进的领域以及改善运营韧性所需的任何措施。记录您的调查发现，并跟踪任何必要的更改，来增强韧性策略和完成准备工作。

## 资源
<a name="resources"></a>

 **相关最佳实践：**
+  [REL12-BP01 使用行动手册调查故障](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html) 
+  [REL12-BP04 使用混沌工程测试韧性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html) 
+  [OPS04-BP01 确定关键绩效指标](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html) 
+  [OPS07-BP03 使用运行手册执行程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) 
+  [OPS10-BP01 使用流程来管理事件、意外事件和问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html) 

 **相关文档：**
+  [什么是 AWS GameDay？](https://aws.amazon.com/gameday/) 

 **相关视频：**
+  [AWS re:Invent 2023 - Practice like you play: How Amazon scales resilience to new heights](https://www.youtube.com/watch?v=r3J0fEgNCLQ&t=1734s) 

 **相关示例：**
+  [AWS Workshop - Navigate the storm: Unleashing controlled chaos for resilient systems](https://catalog.us-east-1.prod.workshops.aws/workshops/eb89c4d5-7c9a-40e0-b0bc-1cde2df1cb97) 
+  [Build Your Own Game Day to Support Operational Resilience](https://aws.amazon.com/blogs/architecture/build-your-own-game-day-to-support-operational-resilience/)