本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
规划你的 AWS FIS实验
故障注入是通过创建破坏性事件（例如服务器中断或API限制）在测试或生产环境中对应用程序施加压力的过程。通过观察系统的响应，你可以进行改进。当您在系统上运行实验时，会帮助您以可控方式标识系统漏洞，以免影响依赖系统运行的客户。然后，您可以主动解决问题，预防不可预测的结果。
在开始运行故障注入实验之前，请使用以下命令 AWS FIS，我们建议您熟悉以下原则和准则。
重要
AWS FIS在真实的环境中执行真实的动作 AWS 系统中的资源。因此，在你开始使用之前 AWS FIS要运行实验，我们强烈建议您先完成计划阶段并在预生产或测试环境中完成测试。
基本原则和指南
在开始实验之前 AWS FIS，请采取以下步骤：
-
标识实验的目标部署：首先标识目标部署。亚马逊建议您在首次实验时从预生产或测试环境开始。
-
查看应用程序架构：必须确保已标识了每个组件的所有应用程序组件、依赖项和恢复过程。首先查看应用程序架构。根据应用程序的不同，请参阅 AWS Well-Architected 框架。
-
定义稳态行为 — 根据重要的技术和业务指标（例如延迟、负载、每分钟登录失败、重试次数或页面CPU加载速度）定义系统的稳定状态行为。
-
提出假设：假设在实验过程中系统行为会如何变化。请按照以下格式提出假设：
如果
fault injection action已执行，business or technical metric impact不应超过value.例如，对于身份验证服务可以假设：“如果网络延迟提高 10％，则登录失败次数增加不到 1％。” 实验结束后，您需要评估应用程序的弹性是否符合业务和技术预期。
我们还建议在使用时遵循以下准则 AWS FIS:
-
一定要开始试验 AWS FIS在测试环境中。切勿从生产环境开始。随着故障注入实验取得进展，您可以在除测试环境以外的其他可控环境中进行实验。
-
从简单的小型实验开始，例如在某个目标上执行 aws:ec2:stop-instances 操作，从而增强团队对应用程序弹性的信心。
-
故障注入会引发实际问题。请谨慎操作，同时确保在测试实例上进行首次故障注入，以免影响客户。
-
测试，测试，再测试。故障注入旨在通过精心规划的实验在受控环境中实现。这有助于您对应用程序和工具承受动荡条件的能力建立信心。
-
亚马逊强烈建议您先设置好性能出众的监控和警报程序，再开始实验。否则，您将无法理解或衡量实验造成的影响，这对于故障注入实践的持续开展至关重要。
实验规划指南
随着 AWS FIS，你在你的上面做实验 AWS 资源，用于测试您对应用程序或系统在故障条件下将如何运行的理论。
以下是规划您的建议指南 AWS FIS实验。
-
查看中断历史记录：查看系统之前发生的中断和事件。这有助于您了解系统的整体健康状况和弹性。您应该先解决系统中的已知问题和漏洞，再在系统上运行实验。
-
标识影响最大的服务：查看服务，并标识在停机或无法正常运行时对最终用户或客户影响最大的服务。
-
标识目标系统：目标系统就是您要运行实验的系统。如果你不熟悉 AWS FIS或者您以前从未进行过故障注入实验，我们建议您首先在预生产或测试系统上运行实验。
-
咨询团队：询问团队顾虑。您可以提出假设以证明或反驳他们的担忧。也可以询问团队放心的方面。此问题可以揭示两种常见谬误：沉没成本谬误和确认偏见谬误。基于团队答案形成假设可提供有关系统状态现实的更多信息。
-
查看应用程序架构：查看系统或应用程序，并确保已标识了每个组件的所有应用程序组件、依赖项和恢复过程。
我们建议您查看 AWS Well-Architected 框架。该框架可以帮助您为应用程序和工作负载构建安全高效、高性能和高弹性的基础设施。有关更多信息，请参阅 AWS Well-Architected。
-
确定适用的指标 — 您可以监控实验对您的影响 AWS 使用 Amazon CloudWatch 指标的资源。当您的应用程序处于最佳性能时，您可以使用这些指标来确定基准或“稳定状态”。然后可以在实验期间或实验结束后监控指标以确定影响。有关更多信息，请参阅 使用 Amazon CloudWatch 监控 AWS FIS 的使用情况指标。
-
为系统定义可接受的性能阈值：标识代表系统可接受的稳定状态的指标。您将使用此指标来创建代表实验停止条件的一个或多个 CloudWatch 警报。如果触发警报，实验将自动停止。有关更多信息，请参阅 AWS FIS 的停止条件。
