Recommended resilience testing in the next generation of AWS Resilience Hub

AWS Resilience Hub下一代推荐弹性测试 | AWS架构博客

AWS Resilience Hub下一代推荐弹性测试

已定义弹性策略并评估过应用程序的组织通常面临一个共同的下一步：验证这些应用程序在发生故障时是否能按预期运行。手动设计故障注入实验需要深厚的专业知识。您需要知道应注入哪些故障、针对哪些资源，以及如何判断结果是否算作成功。许多团队不知道如何入手，而手动构建的实验随着架构演变可能很快过时。

AWS Resilience Hub下一代推荐弹性测试解决了这一问题。这是全新功能，可帮助您验证服务如何响应和从故障场景中恢复。这些测试已预先配置，并由AWS故障注入服务（AWS Fault Injection Service，FIS）提供支持。

推荐弹性测试利用AWS Resilience Hub已掌握的关于您服务的信息，包括资源、依赖关系和弹性策略。借助这些信息，AWS Resilience Hub会自动生成FIS实验，注入故障，并根据您的成功标准和恢复时间目标（RTO）评估结果。该评估将决定测试结果是通过还是失败。过去需要手动设计实验的过程，现在已转变为开箱即用的测试，内置基于策略的成功评估。每次测试运行都会自动生成报告，可通过Resilience Hub控制台访问。

客户经常询问应测试哪些故障模式以及我们能提供哪些指导性测试建议。AWS Resilience Hub通过在发布时提供四个测试来回应，这些测试根据您的服务架构和弹性策略进行选择。

可用性区域：恢复 – 验证您的服务能否检测并从可用性区域故障中恢复。该测试会在单个可用性区域中注入电力中断的特征，影响该区域内的计算、网络、存储和数据库资源。它会确认您的服务能检测到受损的可用性区域，在健康区域继续运行，并在您定义的RTO内恢复到健康状态。它还可以揭示您可能未意识到的单可用性区域依赖关系。

依赖关系验证 – 验证当AWS区域内的依赖项出现故障时，您的服务如何响应。如果已启用依赖项发现功能，默认会预先选择查询量最高的软依赖项。您可以调整选择以针对特定依赖项或特定组。依赖关系验证测试会阻断区域内的依赖项，以查看当它们不可用时您的服务表现如何。它可以帮助您验证当软依赖项出现故障时服务是否保持健康，并揭示您可能未意识到的硬依赖项。您还可以包含已知的硬依赖项以了解其影响，并确认当它们不可用时服务能否检测到并作出响应。我们建议从单个软依赖项开始，然后逐步扩展。

多区域：隔离 – 验证当无法连接到其他区域时，您的服务是否能够独立于某个区域运行。该测试会阻断两个区域之间的连接，包括网络流量、跨区域数据复制和部分依赖项。此测试适用于主动-主动和主动-被动架构，并且也是进行多区域恢复测试的有用前提。

多区域：恢复 – 验证在某个区域受损后，您的服务是否能在定义的恢复时间目标（RTO）内恢复并为客户端提供服务。该测试会在选定区域的依赖项中引入故障。通过成功告警，它会确认您的服务在恢复区域中于定义的RTO内恢复并在测试期间保持健康状态。您需要自行执行恢复操作，例如触发故障转移或执行Amazon Application Recovery Controller (ARC)区域切换计划。

每个测试在三个层级上运行。测试模板是预配置的推荐方案，指定故障操作、目标资源类型和参数。测试是您为服务配置的模板实例，包含您的成功告警、停止条件和设置。测试运行是单次执行，作用于当前资源并产生通过/失败的结果、结果和报告。您可以按季度、月度或按需运行相同的测试。要达到通过/失败的结果，可以在测试中使用成功标准。

选择能反映服务健康状况和客户体验的成功标准，例如订单成功率或端到端可用性，而不是单个资源的状态。预期受损资源会处于不健康状态。您验证的是整个服务是否吸收了故障。结合您的弹性策略，这些标准决定了通过/失败的结果。

对于恢复测试（可用性区域恢复和多区域恢复），当所有成功标准在策略中定义的RTO内恢复到健康状态并持续到测试结束时，测试通过。这不仅验证了服务是否恢复，还验证了恢复速度是否足够快以满足既定目标。

对于持续测试（依赖项验证和多区域隔离），当所有成功标准从故障注入到测试结束始终保持阈值时，测试通过，证明服务在故障期间始终保持健康。

您还可以选择仅用于可观测性的附加告警，例如监控受损区域的退化情况。这些内容会显示在结果和报告中，但不会影响测试结果。

深入解析：依赖项验证

在四个推荐的弹性测试中，依赖项验证是客户最常请求的功能之一，原因显而易见。现代应用程序依赖数十个服务，了解应用程序在不依赖哪些服务的情况下仍能运行，是构建弹性应用的关键。依赖项验证测试可确定当特定依赖项不可用时，应用程序是否仍能继续运行。

依赖项验证的工作原理

依赖性验证测试会阻断您在AWS区域中选择的依赖项的连接，以观察当这些依赖项不可用时您的服务行为。它验证当软依赖项受损时您的服务是否保持健康，并揭示您可能未曾意识到的硬依赖项。您还可以包含已知的硬依赖项，以了解其故障影响。

这是一项持续测试。与衡量是否满足恢复时间目标（RTO）的恢复测试不同，当所有成功警报从注入故障到测试结束始终保持在“正常”状态时，依赖性验证测试即通过。

依赖项发现

您可以通过以下两种方式定义依赖项：

• 启用依赖项发现功能。此功能使用DNS查询日志分析（包含35天回溯窗口）和持续轮询，自动识别您的服务调用的AWS服务、内部端点和第三方端点。依赖项发现功能会揭示您可能未意识到的依赖项，包括意外的跨区域调用、关键的第三方依赖项以及在事件期间可能导致故障的不常访问服务。

• 在配置测试时直接手动输入DNS端点。

定义完依赖项后，建议将每个依赖项分类为软依赖或硬依赖。

| 分类 | 使用场景 | 示例 | 测试验证内容 | |------|----------|------|--------------| | 软依赖 | 服务性能下降但可继续运行 | 分析API、通知服务、功能标志、推荐引擎 | 应用程序能优雅处理缺失。测试应通过 | | 硬依赖 | 依赖项不可用时服务会失败 | 主数据库、认证服务、凭证交换 | 应用程序能检测失败并优雅处理。测试可能失败（这是预期且具有信息性的） |

先决条件

开始前，请确保已在下一代Resilience Hub中至少创建并评估了一个服务。您还需要为下一代Resilience Hub指定一个AWS Identity and Access Management (IAM) 服务角色，用于运行弹性测试。该角色可在下一代Resilience Hub控制台中创建，或指定现有角色。

配置测试

在下一代Resilience Hub的服务仪表板中，选择“测试”选项卡。您将看到四个推荐的弹性测试。选择“依赖项验证”，然后选择“编辑测试配置”。

配置页面将引导您完成六个部分：

#### 1. 基本设置

测试时长：故障操作运行的时间长度。设置范围为1分钟到12小时（默认：30分钟）。测试持续时间结束后，测试会额外花费几分钟评估结果后再结束。

依赖项区域：您要测试依赖项故障的AWS区域，即部署服务的AWS区域。

#### 2. 要阻断的依赖项

这是软依赖和硬依赖区分直接影响测试的地方。

默认行为：

• 查询量最高的已发现软依赖项会预先选中。如果未分类任何软依赖项，则不会预选任何项。

• 已发现的依赖项：一个已预先填充所选AWS区域中发现的依赖项的复选框。您可以选择最多10个依赖项进行测试。

• (可选) 其他依赖项：展开此部分以添加硬依赖项或未在主要选择中列出的依赖项。如果您未运行任何依赖项发现，可以使用此字段输入一个将被阻断为依赖项的DNS地址。

最佳实践：从一个软依赖项开始，逐步扩展，先在包含硬依赖项之前逐步建立对应用程序故障处理能力的信心。

#### 3. 测试动作（故障动作）

Resilience Hub 的下一代功能使用 AWS FIS 动作来阻断与所选依赖项的连接，自动定位服务中发现的资源。故障动作会在计算层注入 100% 的数据包丢失，阻断到所选依赖项的流量：

故障动作

作用说明

aws:ssm:send-command

阻断来自 Amazon 弹性计算云（Amazon EC2）实例到所选依赖项的流量

aws:ecs:task-network-packet-loss

阻断来自 Amazon 弹性容器服务（Amazon ECS）任务（EC2 和 AWS Fargate）到所选依赖项的流量

aws:eks:pod-network-packet-loss

阻断来自 Amazon 弹性 Kubernetes 服务（Amazon EKS）Pod 到所选依赖项的流量

当测试开始时，系统会将动作匹配到服务中发现的资源。如果某个动作的目标类型没有匹配到资源，该动作将被跳过。这意味着测试会自动适应您的计算环境，无论您是在 Amazon EC2、Amazon ECS、Amazon EKS 上运行，还是它们的组合。

额外设置要求：这些动作的设置取决于您的计算类型。您需要在 Amazon ECS 任务定义中包含 AWS Systems Manager Agent 容器，在 Amazon EKS Pod 中配置 Kubernetes 服务账户，或在 Amazon EC2 实例上安装 AWS Systems Manager Agent。

#### 4. 测试警报

警报决定测试是否通过或失败。选择从您的服务中发现的、反映服务性能和客户体验的警报。例如，电商服务的订单成功率或支付系统的处理交易量。

• 成功警报：Resilience Hub 的下一代功能使用这些警报来验证您的服务是否通过或失败测试。选择衡量服务在 AWS 区域内健康状况的警报。

• (可选) 其他警报：在测试运行期间被跟踪并在报告中显示，但不会影响测试结果。使用其他警报进行可观测性，监控这些警报在依赖项受损期间的表现。

如何通过测试：如果所有成功警报在测试动作结束前始终保持正常状态，则测试通过。

成功标准和其他警报在每个配置更新中共享最多 5 个的限制。

#### 5. 停止条件、报告和日志

停止条件：作为防护网的 Amazon CloudWatch 警报。如果触发，将自动停止测试以保护您的工作负载。最多可选择五个警报。这些警报必须位于运行测试的账户和注入故障的 AWS 区域中。

(可选) 报告：如果您在服务中配置了 Amazon 简单存储服务（Amazon S3）存储桶作为报告目标，Resilience Hub 的下一代功能将在每次测试运行后生成报告，包含测试配置、警报状态、时间线和结果。

日志：可选择将测试日志发送到 Amazon S3 存储桶或 Amazon CloudWatch Logs 以进行更深入的分析。Resilience Hub 的下一代版本不收取发送日志的费用，但适用数据摄入和存储费用。

#### 6. 测试权限

测试需要 IAM 角色来授予对 AWS 服务和资源的访问权限。对于单账户设置，您需要一个执行角色。对于多账户设置，您需要在运行测试的账户中创建一个编排角色，并在包含目标资源的每个账户中创建一个目标角色。您可以直接从 AWS 管理控制台创建角色并预配置所需权限，或使用现有角色。保存后，该角色将默认用于未来的测试运行。

注意：更新测试设置可能会更改所需的 IAM 权限。所需权限会根据信任策略、故障操作和选择的测试选项而有所不同。始终查看 IAM 角色说明以确认权限是否正确。

运行测试：成功与失败的表现

通过比较不同依赖分类的结果，可以明确依赖性验证测试的价值。我们将演示在相同服务上使用相同成功警报的两次测试运行：一次阻止软依赖，一次阻止硬依赖。

测试运行：阻止软依赖 — 通过 ✅

阻止的依赖项：

• 支付网关。

• 通知服务。

成功警报：

• canary-heartbeat-canary-failure-us-east-2：监控服务健康检查可用性。

• canary-order-flow-canary-failure-us-east-2：监控端到端订单处理。

图 1：软依赖测试运行，两个成功警报在整个测试期间保持正常状态

结果说明：从测试操作开始到测试结束，两个警报始终保持正常状态（实心绿色）。应用程序在没有支付网关和通知服务的情况下继续正常运行。订单流程持续处理，心跳持续响应。服务优雅地处理了软依赖项的缺失，完全符合设计预期。

证明结论：这些依赖项被正确分类为软依赖。您的应用程序可以容忍这些依赖项的丢失，在不影响面向客户的订单流程的情况下抑制通知。

测试运行：阻止硬依赖 — 失败 ❌

• Amazon Cognito。

• AWS 安全令牌服务（AWS STS）。

图 2：硬依赖测试运行，订单流程警报进入警报状态，而心跳警报保持健康

结果说明：心跳金丝雀在整个测试期间保持绿色。应用程序没有变得不可用。但订单流程金丝雀在注入故障后立即转为警报状态（红色），并一直保持到测试结束。在没有 Amazon Cognito（认证）和 AWS STS（凭证交换）的情况下，应用程序无法完成关键业务订单流程。

证明结论：Amazon Cognito 和 AWS STS 被正确分类为硬依赖。测试确认了它们的缺失会影响关键功能，但更重要的是，它还表明故障已被隔离。应用程序没有演变为完全故障，它在继续响应（心跳通过）的同时，需要认证的具体业务流程优雅地失败。

测试结果不仅仅是通过或失败。一个通过的测试仍可能暴露出依赖项分类错误的问题，而一个失败的测试则可以确认该依赖项确实关键。关键的是将测试结果与依赖项的分类进行比对，从而判断架构是否按预期运行，并采取相应措施。

以下决策框架可帮助您解读每个测试的结果，理解其含义，并决定下一步操作。

场景 | 预期结果 | 含义 | 下一步操作 --- | --- | --- | --- 软依赖被阻断 → 测试 | 通过 | 是 | 降级处理正常运作。分类准确。 | 无需操作。您的架构能正确处理此故障。 失败 | 否 | 依赖项可能被错误分类为软依赖，而实际上应为硬依赖。或降级逻辑存在漏洞。 | 检查应用行为。重新分类为硬依赖，或修复降级路径。

硬依赖被阻断 → 测试 | 确认分类。缺少此依赖项会影响关键功能。 | 验证故障是否优雅（无级联故障、无数据损坏、无挂起连接）。考虑是否可添加重试/降级机制，以便未来重新分类为软依赖。

依赖项可能被错误分类。它实际上可能是软依赖。这也可能表明依赖项未按预期被调用。 | 调查应用是否比预期更具弹性，或依赖项是否未被正确使用。如适用请重新分类或修复应用逻辑。

摘要

下一代AWS Resilience Hub推荐的弹性测试消除了了解架构与验证其在故障下表现之间的障碍。它基于AWS FIS构建了四项AWS推荐测试，涵盖可用区恢复、依赖项验证、多区域隔离和多区域恢复。您可以从策略定义和故障模式评估直接过渡到基于证据的验证，无需从零构建实验。

您可以从依赖项验证测试开始，了解应用如何处理依赖项丢失。随着计划成熟，逐步扩展到可用区恢复和多区域测试。每次测试运行都会捕获当前资源的实时快照，根据弹性策略评估通过/失败结果，并随时间推移将结果反馈到合规性和报告工作流中。

推荐的弹性测试现已在所有支持下一代AWS Resilience Hub的AWS商业区域提供。要了解更多并开始使用，请访问AWS Resilience Hub用户指南和AWS Resilience Hub产品页面。

作者简介