从“定义韧性”到“证明韧性”：解读下一代 AWS Resilience Hub 的推荐韧性测试
很多团队在完成韧性策略定义和应用程序评估之后，会卡在同一个问题上：这些策略在真实故障下到底管不管用？手工设计故障注入实验门槛不低——要选故障类型、定目标资源、判断什么算成功，而且架构一变，实验就可能过时。下一代 AWS Resilience Hub 推出的“推荐韧性测试”正是针对这一断层：它基于 Resilience Hub 已掌握的服务资源、依赖关系和韧性策略，自动生成由 AWS Fault Injection Service（FIS）驱动的实验，并依据成功标准和恢复时间目标（RTO）给出通过/失败结论。本文基于 AWS Architecture Blog 的公开内容，梳理这项能力的测试类型、运行机制与结果解读框架。
一、四项开箱即用的测试，覆盖两类验证目标
依据现有素材，推荐韧性测试在发布时提供四项预配置测试，并根据服务的架构和韧性策略进行选择：
- 可用区：恢复——注入单个可用区电力中断的症状，影响该可用区内的计算、网络、存储和数据库资源，验证服务能否检测到可用区受损、继续在健康可用区运行，并在定义的 RTO 内恢复。该测试还有助于发现此前未意识到的单可用区依赖。
- 依赖验证——阻断 AWS 区域内的依赖关系，观察服务在依赖不可用时的行为。若启用了依赖发现，默认预先选择查询量最高的已发现软依赖，用户也可调整选择，针对单个依赖或特定组。
- 多区域：隔离——阻断两个区域之间的连接，包括网络流量、跨区域数据复制和选定的依赖关系，验证服务能否独立于某个区域运行。适用于主动-主动和主动-被动架构，也是多区域恢复测试的有用前奏。
- 多区域：恢复——在所选区域的依赖关系中引入故障，确认服务在恢复区域内于定义的 RTO 内恢复并保持健康。恢复操作由用户自行执行，例如触发故障转移或执行 Amazon Application Recovery Controller（ARC）区域切换计划。
这四项测试实际上对应两类验证逻辑：恢复类测试关注“能否在 RTO 内恢复”，持续类测试关注“受损期间是否始终保持健康”。
二、三层结构与通过/失败判定
每项测试在三个层级上运作：
- 测试模板：预配置的建议，指定故障操作、目标资源类型和参数。
- 测试：模板为某个服务配置后的实例，包含成功告警、停止条件和设置。
- 测试运行：单次执行，范围限定为当前资源，产生带结果和报告的通过/失败结论。
判定规则因测试类型而异：
- 恢复测试（可用区恢复、多区域恢复）：当所有成功标准在策略定义的 RTO 内恢复到健康状态，并保持到测试结束时，测试通过。这不仅验证“恢复了”，还验证“恢复得足够快”。
- 持续测试（依赖验证、多区域隔离）：当所有成功标准从故障注入到测试结束期间始终保持在阈值内时，测试通过，证明服务在整个受损期间保持健康。
素材特别强调了一个容易被误判的点：受损资源预期是不健康的，因此成功标准应反映服务健康状况和客户体验，例如订单成功率或端到端可用性，而不是单个资源的状态。此外，用户还可以配置仅用于可观测性的额外告警，这些告警会出现在结果和报告中，但不影响测试结果。
三、依赖验证为何成为需求最高的能力
在四项测试中，依赖验证是客户需求最多的能力之一。原因并不复杂：现代应用依赖数十个服务，而“缺少哪个依赖时应用仍能正常工作”恰恰是构建韧性应用的关键问题。
依赖发现：让隐藏依赖浮出水面
定义依赖有两种方式：一是开启依赖发现，该功能使用 DNS 查询日志分析，具有 35 天回溯窗口和持续轮询，自动识别服务调用的 AWS 服务、内部端点和第三方端点；二是在配置测试时直接手动输入 DNS 端点。
依赖发现的价值在于揭示团队可能未察觉的依赖，包括意外的跨区域调用、关键的第三方依赖，以及平时低频访问、却可能在事件期间引发故障的服务。
软依赖与硬依赖：分类决定测试预期
定义依赖后，建议将每个依赖分类为软依赖或硬依赖：
| 分类 | 何时使用 | 示例 | 测试验证的内容 |
|---|---|---|---|
| 软依赖 | 服务在缺少该依赖时会降级，但仍能继续运行 | 分析 API、通知服务、功能开关、推荐引擎 | 应用能优雅地处理依赖缺失，测试应通过 |
| 硬依赖 | 该依赖不可用时服务会失败 | 主数据库、身份验证服务、凭证交换 | 应用能检测到故障并优雅处理，测试可能失败（这是预期且具有信息价值的） |
故障注入如何落地
下一代 Resilience Hub 使用 AWS FIS 操作阻断与所选依赖的连接，自动定位服务中发现的资源，在计算层注入 100% 数据包丢失：
| 故障操作 | 作用 |
|---|---|
| aws:ssm:send-command | 丢弃从 Amazon EC2 实例发往所选依赖的流量 |
| aws:ecs:task-network-packet-loss | 丢弃从 Amazon ECS 任务（EC2 和 AWS Fargate）发往所选依赖的流量 |
| aws:eks:pod-network-packet-loss | 丢弃从 Amazon EKS Pod 发往所选依赖的流量 |
测试启动时会将操作与服务中发现的资源匹配，没有资源匹配某个操作的目标类型时则跳过该操作。这意味着测试会自动适应 EC2、ECS、EKS 或其组合的计算环境。但素材也提示了额外设置要求：ECS 任务定义中需要有 AWS Systems Manager Agent 容器，EKS Pod 需要配置 Kubernetes 服务账户，EC2 实例需要安装 AWS Systems Manager Agent。
四、两次测试运行：通过和失败分别意味着什么
素材给出了同一服务、相同成功告警下的两次依赖验证测试运行，对比很直观。
软依赖被阻断——通过。 被阻断的依赖是 Payment Gateway 和 Notification Service，两个成功告警（心跳可用性与端到端订单处理）从测试操作开始到结束均保持 OK。应用在没有这两个依赖的情况下继续正常运行，订单流持续处理，心跳持续响应。这证明依赖分类准确，应用能够优雅降级。
图 1：软依赖测试运行，两个成功告警在整个测试期间均保持 OK 状态
硬依赖被阻断——失败。 被阻断的依赖是 Amazon Cognito 和 AWS Security Token Service（AWS STS）。心跳 canary 全程保持绿色，应用并未变得不可用；但订单流 canary 在注入故障后立即转为告警状态，并持续到测试结束。没有身份验证和凭证交换，应用无法完成业务关键的订单流。这确认了两者属于硬依赖，同时也表明故障被控制住了：应用没有级联为完全失败，而是让需要身份验证的特定业务流优雅地失败。
图 2：硬依赖测试运行，订单流告警进入告警状态，而心跳告警保持健康
五、结果解读：不要只看通过或失败
素材提供了一个值得技术团队直接借用的决策框架：测试结果并非简单的通过或失败，关键在于将结果与依赖分类对照解读。
| 场景 | 预期结果 | 含义 | 下一步行动 |
|---|---|---|---|
| 软依赖被阻断 → 测试通过 | 是 | 优雅降级正常工作，分类准确 | 无需操作 |
| 软依赖被阻断 → 测试失败 | 否 | 依赖可能被错误分类为软依赖，实际是硬依赖；或降级逻辑存在缺口 | 审查应用行为，重新分类或修复降级路径 |
| 硬依赖被阻断 → 测试失败 | 是 | 确认了分类，关键功能确实受影响 | 验证故障是否优雅（无级联故障、无数据损坏、无挂起连接），考虑增加重试/回退以未来重新分类为软依赖 |
| 硬依赖被阻断 → 测试通过 | 否 | 依赖可能被错误分类，实际可能是软依赖；也可能该依赖未被按预期调用 | 调查应用是否比预期更具弹性，或依赖是否未被实际调用，酌情重新分类或修复应用逻辑 |
这个框架的实用之处在于：通过的测试仍可能暴露被错误分类的依赖，失败的测试也可以确认某个依赖确实是关键性的。测试的价值不只是给出一个结论，而是驱动架构认知的修正。
六、配置要点与工程注意事项
依据素材，配置依赖验证测试时，控制台会引导完成六个部分：基本设置（测试持续时间可设 1 分钟到 12 小时，默认 30 分钟；以及依赖区域）、要阻断的依赖（最多选择 10 个依赖，可展开“其他依赖项”纳入硬依赖或手动输入 DNS 地址）、测试操作（FIS 故障操作）、测试告警（成功告警与可选的其他告警，每次配置更新共享 5 个的限制）、停止条件与报告日志、测试权限。
几个容易被忽略的工程细节：
- 停止条件是护栏：作为停止条件的 Amazon CloudWatch 告警被触发时会自动停止测试以保护工作负载，最多选择五个，且必须位于运行测试的账户以及注入故障的 Region 中。
- 报告与日志：若在服务上配置了 Amazon S3 桶作为报告目标，每次测试运行后会生成包含测试配置、告警状态、时间线和结果的报告；日志可发送到 S3 或 CloudWatch Logs，Resilience Hub 不收取发送日志的费用，但会收取摄取和存储费用。
- IAM 权限会随配置变化：单账户设置需要执行角色，多账户设置需要在运行测试的账户中有编排器角色、在每个包含目标资源的账户中有目标角色。素材明确提示，更新测试设置可能改变所需权限，应始终查看 IAM 角色说明确认权限正确。
- 实践是从单个软依赖开始：逐步建立对应用故障处理能力的信心，再纳入硬依赖。
趋势判断：韧性验证正在从“专家手工作业”走向“策略驱动的常态化运行”
从这项能力的设计可以看出一个清晰的趋势：韧性验证的门槛正在被平台能力吸收。过去需要深厚故障注入专业知识才能完成的实验设计，正在变成基于既有策略和资源发现的预配置测试；过去一次性的演练，正在变成可按季度、每月或按需重复运行的常态化验证。
另一个值得关注的信号是“证据链”的形成。每次测试运行都会捕获当前资源的时点快照，依据韧性策略生成通过/失败结果，并随时间输入到合规和报告工作流中。这意味着韧性不再只是架构评审时的定性描述，而是可以积累、可审计的运行记录。
当然，依据现有素材判断，这套能力也有其边界：它依赖 Resilience Hub 对服务的既有评估，依赖发现基于 DNS 查询日志分析（35 天回溯窗口），故障注入需要相应的 Agent 或服务账户配置，多区域恢复测试中的恢复操作仍需用户自行执行。它降低的是实验设计与结果判定的门槛，而不是替代团队对架构和业务流的理解。
结论
下一代 AWS Resilience Hub 的推荐韧性测试，把“了解架构”和“证明架构在故障下保持稳定”之间的障碍拆掉了一部分。四项基于 AWS FIS 的推荐测试覆盖可用区恢复、依赖验证、多区域隔离和多区域恢复，配合成功标准与 RTO 给出通过/失败结论，并通过决策框架帮助团队修正依赖分类和降级逻辑。
对于刚开始这项工作的团队，素材给出的路径很明确：从依赖验证测试入手，先阻断单个软依赖，理解应用如何处理依赖丢失，再逐步扩展到硬依赖、可用区恢复和多区域测试。素材显示，推荐韧性测试现已在所有支持下一代 AWS Resilience Hub 的 AWS 商业区域推出，更多信息可参考 AWS Resilience Hub 用户指南和产品页面。
