本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 连续混沌工程实验生命周期
如[上一节](implementation.md)所述，你可以用不同的方式实现混沌工程实验。在所有情况下，进行有意义的混乱实验的关键是了解应用程序、历史事件和已实施的补救措施，并清楚地了解需要调查的领域，例如弹性或安全性。你对应用程序的了解可以帮助你对应用程序的潜在弱点提出假设，并了解在注入故障时它将如何检测、修复和恢复。
混沌实验生命周期包括以下步骤：
1. 定义实验的目标。
1. 选择目标应用程序。
1. 对齐思维导图。
1. 解决应用程序的已知问题。
1. 定义假设和实验。
1. 确保实验准备就绪。
1. 运行受控场景和实验。
1. 从实验中吸取教训并对其进行微调。
这些步骤如图所示，并在以下各节中讨论。
## 定义目标并设定期望
在每次实验之前，请确保您的目标和期望是具体的、可衡量的、可实现的、相关的和有时限的。明确定义以下内容：
+ **识别**系统和服务中的潜在故障或弱点，以了解它们可能如何影响用户。这包括识别可能的故障模式，例如服务器崩溃、网络故障或软件错误，并评估它们对系统整体性能和可靠性的潜在影响。
+ 通过定义系统和服务的关键风险指标 (KRIs) 来@@ **量化**故障的影响。这包括在延迟、吞吐量和错误率等指标偏离稳定状态时测量故障的影响。通过了解此类偏差的影响，您可以根据业务风险确定缓解故障的优先顺序。
+ **制定**并**验证**缓解或预防故障的策略。这包括确定潜在的解决方案，例如冗余、错误更正或备用策略，并在受控环境中测试其有效性。通过验证这些策略，您可以确保有效预防或缓解故障，并且可以放心地将其部署到生产系统中。
+ **改善**事件响应和灾难恢复流程。通过在受控环境中重播故障，您可以测试事件响应流程，识别潜在的瓶颈或差距，并完善灾难恢复程序。这有助于确保您做好准备，以便在发生意外故障时快速有效地做出响应。
## 选择目标应用程序
混沌工程是一项强大的技术，但需要深思熟虑的优先级排序才能最大限度地提高价值。在决定将混沌工程工作重点放在哪里时，首先要考虑企业的关键服务。要求您的团队在软件开发生命周期阶段进行迭代，然后首先开始在测试环境中注入错误。关键业务应用程序与收入、客户体验和核心运营直接相关。对这些服务的混乱实验可以发现漏洞，如果不加以解决，这些漏洞可能会严重影响组织乃至整个市场。例如，首先关注面向客户的服务，例如交易系统或订单系统。优先考虑这些中央服务可以为每投入的时间提供最大的保护。
在关键服务之后，查看基础组件，例如数据库、消息队列、网络和共享服务 APIs。它们可能被用作整个组织的共享组件或服务，因此它们的故障将导致广泛的问题。确认基础设施服务的弹性可以让人们确信它们不会削弱其上方的依赖应用程序。例如，关闭 Kafka 集群的混沌工程实验揭示了很多关于下游应用程序容错能力的信息。尽管系统基础设施不是直接面向客户的，但它是一个主要的混乱工程目标。
别忘了绘制人员、流程、设施信息和第三方依赖关系的心理差距，因为如果这些差距与组织的影响容忍度目标不一致，可能会造成重大干扰。有关衡量混沌工程投资回报率的更多信息，请阅读战略文档中的 [“量化混沌工程的投资回报率](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-chaos-engineering-journey/roi-chaos-engineering.html)*”。将混沌工程作为战略必要性*进行投资。
下图显示了在不同服务层级上运行混沌实验的投资回报。
## 对齐思维导图（应用程序发现）
当你进行临时实验或游戏日时，你将通过举行白板会议来开始应用程序发现过程，重点是绘制应用程序的细节。（如果你在混沌管道中运行实验，那么通过定义目标应用程序，你已经对齐了思维导图。） 理解心理差距的一个好方法是让最年轻的团队成员先画出应用程序的示意图，然后让更高级的工作人员逐步添加到图表中。这将揭示不同经验等级之间在理解方面存在的任何差距。
该图应描述应用程序的直接上游和下游依赖关系，以及任何关键的第三方集成。确保通过应用程序的请求的预期流程保持一致。绘制关键工作流程和用户旅程，以清楚地了解客户如何使用该应用程序。考虑使用[序列图](https://en.wikipedia.org/wiki/Sequence_diagram)来捕获这些信息。
在这次协作会议之后，团队应该对应用程序、其关键依赖关系和监控能力有一个共同的思维模型，并了解风险，以便做出明智的决定，继续或取消潜在的混乱实验。
## 解决应用程序的已知问题
混沌工程实验旨在主动发现应用中的缺陷。通过注入延迟增加、服务器重启或可用区电源损坏等故障，您可以验证您的应用程序是否能够容忍实际中断。但是，此过程假设目标应用程序具有基本的稳定性和运行状况。在已经存在问题的应用程序上进行混沌实验有可能掩盖更深层次的问题。
在进行混沌工程之前，团队应解决其应用程序中的任何已知缺陷、错误和性能问题。
## 定义假设和实验
过去导致您的应用程序或组织内其他应用程序中断的事件可以成为混乱实验想法的绝佳来源。例如，之前的中断是由配置错误还是缺少弹性模式引发的？ 回顾事件历史并通过混沌实验重现现实世界失败的根本原因，是培养未来应对类似问题的适应能力的有效方法。
实验概念的另一个宝贵来源可以直接来自最熟悉应用程序的工程师、架构师和操作员。允许团队成员提交他们认为可能会严重干扰应用程序的假设失败场景，这样您就可以根据内部知识收集想法。然后，应用团队可以评估这些拟议方案中哪些可能产生最大的潜在影响或暴露最大的未知风险。针对此类高风险、鲜为人知的场景进行混沌实验可以产生重要的学习并防止将来出现问题。
第三个想法来自于进行弹性建模，以预测可能导致已确定的业务损失的情况。一些弹性建模练习采用基于组件的方法来构建弹性模型，而另一些则采用基于系统的方法。基于组件的方法会问这样一个问题：“当组件 *x* 处于极端负载下或出现故障时会发生什么？” 然后，开发弹性模型的团队推测了这种情景对更广泛应用的影响，并确定了目前为检测和减轻该情景的影响而采取的监测和预防性控制措施。或者，基于系统的方法遵循自上而下的流程来突出显示应用程序的不良状态，例如 “网络店面显示过时的库存水平”，并邀请应用程序团队预测哪些或哪些条件会导致应用程序以这种方式运行。
## 确保实验准备就绪
您需要可量化的指标来衡量不利条件对应用程序及其行为的影响，如前面关于可[观察](getting-started.md#observability)性的部分所述。能够测量应用程序的行为使您能够确定不利条件是否对应用程序产生了影响以及影响程度。
要了解您的应用程序是否受到影响，最好的方法是测量其稳定状态。稳定状态衡量正常运行的样子，通常与给定应用程序的业务和客户体验指标保持一致。在进入下一步之前，请确保具备可观察性以了解影响，并准备好回滚机制，以防实验结果不如预期。
## 运行受控实验和场景
在 AWS，我们不建议对正在生产的应用程序进行初始混沌实验。混沌实验的目的是学习一些关于应用程序在压力条件下的行为的新知识。在实验过程中，应用程序的行为可能是不可预测的，因此首次在生产环境中进行实验可能会对客户产生影响。因此，您应始终在影响真实用户可能性最小的较低级别环境中运行初始混乱实验，然后在验证并确信您的应用程序可以吸收、适应注入的操作并从中恢复过来之后，在您的环境中进行迭代。
使用记录关键细节的文档（类似于附录中提供的[实验计划文件）对每个实验进行全面规划](sample-planning.md)。要包括的一些关键领域是稳态定义、假设和失效注入方法。混沌实验的规划、执行和分析可以在单个工件中完成。
完成实验的书面计划后，准备好所有必要的代码，以注入文档中概述的计划中断。
为了捕捉实验期间的潜在影响，请确保可观测性机制到位。如果您还没有自动捕获实验结果（例如 AWS FIS 实验报告）的方法，请确定将在执行过程中记笔记、捕获仪表板屏幕截图并带领团队完成实验的团队成员。
## 学习和微调
每次实验结束后，作为一个团队聚在一起回顾和反思混沌实验。有意识地努力保持无可指责的心态。你的目标应该是进行开放、建设性的对话，完全侧重于获得最大限度的学习，而不是指责。
首先回顾实验的稳态定义和假设。应用程序的行为是否符合预期？ 有没有让假设失效的意外？ 讨论对应用程序在实验期间反应的观察结果，包括好与坏。收集的数据——指标、日志、屏幕截图等——应该准确地讲述发生了什么。
以好奇心而不是判断力来进行此次数据审查，并根据所学知识确定可以改进应用程序设计、文档、监控或其他功能的领域。这些行动项目被列为后续项目，以提高应用程序的弹性。
通过这种无可指责的方法，你可以坦率地谈论出了什么问题以及如何解决问题。假设参与其中的每个人都有积极的意图，并相信他们正在努力取得良好的结果。您的共同目标是通过持续学习和适应实现组织发展和进步。以建设性、无可指责的方式进行的混沌实验审查为您的团队提供了一个安全的空间，让他们获得宝贵的见解，从而使您的应用程序和组织从长远来看更加可靠和有弹性。重点仍然放在学习上，而不是人们身上。要在团队中传播所学知识，请在中心位置发布[实验结果报告](sample-result.md)并公布结果，以便其他人可以从中吸取教训。