规划 AWS FIS 实验 - AWS 故障注入服务
基本原则和指南实验规划指南

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

规划 AWS FIS 实验

故障注入通过创建中断事件（如服务器故障或 API 限制）在测试或生产环境中对应用程序施加压力的过程。通过观察系统的响应，你可以进行改进。当您在系统上运行实验时，会帮助您以可控方式标识系统漏洞，以免影响依赖系统运行的客户。然后，您可以主动解决问题，预防不可预测的结果。

亚马逊建议您先熟悉以下原则和指南，再使用 AWS FIS 运行故障注入实验。

重要

AWS FIS 对系统中的真实 AWS 资源执行实际操作。因此，亚马逊强烈建议您先在预生产或测试环境中完成规划阶段和测试，然后再开始使用 AWS FIS 运行实验。

基本原则和指南

请先采取以下步骤，再开始 AWS FIS 实验：

  1. 标识实验的目标部署：首先标识目标部署。亚马逊建议您在首次实验时从预生产或测试环境开始。

  2. 查看应用程序架构：必须确保已标识了每个组件的所有应用程序组件、依赖项和恢复过程。首先查看应用程序架构。根据应用程序的不同，请参阅 AWS Well-Architected Framework。

  3. 定义稳定状态行为：根据技术和业务方面的重要指标（如延迟、CPU 负载、每分钟登录失败次数、重试次数或页面加载速度），定义系统的稳定状态行为。

  4. 提出假设：假设在实验过程中系统行为会如何变化。请按照以下格式提出假设：

    如果执行故障注入操作，则业务或技术指标的影响不应超过值。

    例如，对于身份验证服务可以假设：“如果网络延迟提高 10％，则登录失败次数增加不到 1％。” 实验结束后，您需要评估应用程序的弹性是否符合业务和技术预期。

此外，亚马逊建议您根据以下指南使用 AWS FIS：

  • 始终在测试环境中开始 AWS FIS 实验。切勿从生产环境开始。随着故障注入实验取得进展，您可以在除测试环境以外的其他可控环境中进行实验。

  • 从简单的小型实验开始，例如在某个目标上执行 aws:ec2:stop-instances 操作，从而增强团队对应用程序弹性的信心。

  • 故障注入会引发实际问题。请谨慎操作，同时确保在测试实例上进行首次故障注入，以免影响客户。

  • 测试，测试，再测试。故障注入旨在通过精心规划的实验在受控环境中实现。这有助于您对应用程序和工具承受动荡条件的能力建立信心。

  • 亚马逊强烈建议您先设置好性能出众的监控和警报程序，再开始实验。否则，您将无法理解或衡量实验造成的影响，这对于故障注入实践的持续开展至关重要。

实验规划指南

通过 AWS FIS，您可以对 AWS 资源运行实验，以测试应用程序或系统在故障条件下如何运行的理论。

以下是规划 AWS FIS 实验的推荐指南。

  • 查看中断历史记录：查看系统之前发生的中断和事件。这有助于您了解系统的整体健康状况和弹性。您应该先解决系统中的已知问题和漏洞，再在系统上运行实验。

  • 标识影响最大的服务：查看服务，并标识在停机或无法正常运行时对最终用户或客户影响最大的服务。

  • 标识目标系统：目标系统就是您要运行实验的系统。如果您从未使用过 AWS FIS 或此前从未进行过故障注入实验，亚马逊建议您先在预生产或测试系统上运行实验。

  • 咨询团队：询问团队顾虑。您可以提出假设以证明或反驳他们的担忧。也可以询问团队放心的方面。此问题可以揭示两种常见谬误：沉没成本谬误和确认偏见谬误。基于团队答案形成假设可提供有关系统状态现实的更多信息。

  • 查看应用程序架构：查看系统或应用程序，并确保已标识了每个组件的所有应用程序组件、依赖项和恢复过程。

    亚马逊建议您查看 AWS Well-Architected Framework。该框架可以帮助您为应用程序和工作负载构建安全高效、高性能和高弹性的基础设施。有关更多信息，请参阅 AWS Well-Architected。

  • 确定适用的指标 — 您可以使用 Amazon CloudWatch 指标监控实验对您的AWS资源的影响。当您的应用程序处于最佳性能时，您可以使用这些指标来确定基准或“稳定状态”。然后可以在实验期间或实验结束后监控指标以确定影响。有关更多信息，请参见 使用 Amazon CloudWatch 监控 AWS FIS 的使用情况指标。

  • 为系统定义可接受的性能阈值：标识代表系统可接受的稳定状态的指标。您将使用此指标来创建代表实验停止条件的一个或多个 CloudWatch 警报。如果触发警报，实验将自动停止。有关更多信息，请参阅 AWS FIS 的停止条件。