Architecting AI-powered resilience framework on AWS

在 AWS 上构建 AI 驱动的弹性框架 | AWS 架构博客

在 AWS 上构建 AI 驱动的弹性框架

当你的生产系统发生故障时，你通常会以一种痛苦的方式发现，你的弹性测试遗漏了关键的依赖项。在 AWS 上构建一个 AI 驱动的弹性框架，可以帮助你在客户之前发现这些弱点。

你的系统并非因为基础设施不具有弹性而失败，而是因为人们假设了弹性，而没有实际验证。每一次部署都会引入新的依赖项，每一次配置更改都会创建未经测试的路径，而设计意图与运行时行为之间的每一个差距，都是一个等待暴露的风险。在一个客户期望始终在线可用性的世界中，发现这些弱点的成本不仅仅是技术上的。它以收入损失、信任削弱和完全可以避免的事件来衡量。

在本文中，你将学习如何构建和实现一个五层 AI 驱动的弹性框架，该框架可以自动发现依赖项、生成有针对性的实验，并与现有的持续集成/持续部署（CI/CD）管道集成。首先，我们将探讨弹性测试中的关键挑战。然后，我们将逐步介绍解决这些挑战的五层架构。最后，我们将展示如何实现该框架，并提供试点、扩展和组织范围部署的逐步部署指南。

传统的弹性测试可能需要数周时间，因为所需的信息自然分布在架构图、运行手册、代码仓库和随着每次部署而不断演变的团队知识中。在这些基础上设计有意义的混沌实验需要大多数团队不具备的专业知识。以下是这个 AI 驱动的框架如何在数小时内发现你的基础设施依赖项，并在不需要专业知识的情况下生成有针对性的实验。

AWS Resilience Hub、AWS Fault Injection Service、Amazon Bedrock AgentCore 和 AWS Systems Manager 协同工作，可以在数小时内发现基础设施依赖项，根据你的特定架构定制实验，并在影响客户之前识别弱点。

随着下一代 AWS Resilience Hub 现在提供原生依赖项发现和生成式 AI 驱动的故障模式分析，该框架通过自动化实验生成、将弹性测试嵌入到 CI/CD 管道中，并通过托管在 Amazon Bedrock AgentCore 上的自定义 AI 代理创建一个持续验证循环，扩展了这些功能。

关键概念

在深入架构之前，以下是本文中使用的几个关键术语：

• 混沌工程 —— 通过在系统上进行实验，以增强其在生产环境中承受动荡条件的信心。

• 平均故障恢复时间（MTTR） —— 故障后恢复服务的平均时间。

• 恢复时间目标（RTO） —— 你的应用可接受的最大停机时间。

• 恢复点目标（RPO） —— 最大可接受的数据丢失，以时间衡量。

• 左移（Shift-left） —— 在开发周期早期进行测试，以在问题到达生产环境之前发现它们。

• 熔断器 —— 一种自动机制，用于检测服务故障，并通过临时阻止对失败服务的请求来防止级联故障。

• 金丝雀发布 — 一种先向一小部分用户推出更改以验证功能，然后再全面部署的技术。

适用对象

本文面向负责系统可靠性的云架构师、DevOps 工程师和站点可靠性工程（SRE）团队。你应该了解 AWS 服务、分布式系统架构和 CI/CD 管道。虽然具备混沌工程经验有帮助，但并非必需。该框架降低了传统上阻碍采用的专家门槛。

弹性测试的挑战

当基础设施变化迅速时，文档往往滞后。支付服务的路由更改可能不会在架构图中体现，导致单点故障（如单一可用区的认证依赖）未被记录和测试。支付服务调用的遗留认证 API 仅在一个可用区运行，这是一个关键的单点故障。但文档没有反映这一点，因为三周前有人进行了“快速修复”并忘记更新架构图。

分布式系统包含数百个相互连接的组件。在持续部署更改时，手动跟踪每个依赖变得不切实际。上个月创建的文档已经遗漏了数十个新依赖。

如果没有专门的专家来设计有意义的实验，弹性测试可能具有挑战性。当弹性测试针对你的实际架构并持续运行时，其效果最佳。通用的故障注入和一次性测试运行可能会留下漏洞，尤其是在系统随时间变化时。

专业知识门槛阻止了许多组织完全采用混沌工程。有效的混沌工程需要理解分布式系统架构、故障模式分析、实验范围管理和安全实验设计。没有这些专业知识，你只能避免进行弹性测试，或者进行表面的测试，从而遗漏关键的漏洞。

根据 2024 年 IBM 安全服务基准报告，具备成熟响应能力的组织将平均故障恢复时间（MTTR）减少了约 50%，并且在每次事件中可节省高达 58% 的成本，与响应能力较弱的组织相比。然而，Gartner 的研究显示，68% 的组织将系统复杂性的增加作为采用混沌工程的原因，而 50% 的组织承认在发生故障时并未做好准备。

该框架自动化了发现过程。自动化发现将基础设施映射从数周缩短到数小时，通常在单账户环境中拥有数千个资源的情况下，初始评估可在 2 至 4 小时内完成。后续运行仅处理 AWS Config 跟踪的更改，因此你的架构图可以保持最新，而无需手动操作。托管在 AgentCore Runtime 上的代理分析你的 AWS CloudFormation 模板、代码仓库和运行时行为，以识别所有连接，包括人工审计可能遗漏的隐藏依赖。实验模板分析你的特定架构并生成有针对性的测试，验证你的实际故障模式，从而消除了对专门混沌工程专业知识的需求。将该框架持续集成到你的 CI/CD 管道中，可以在更改到达生产环境之前捕获回归，将弹性从一次性项目转变为嵌入开发工作流程中的持续实践。

解决方案概述

该框架通过自动发现基础设施依赖关系，并在系统发生变化时持续验证其弹性，从而弥补这些不足。AI代理部署在AgentCore运行时环境中，以实现安全且可扩展的执行，它们能够自动发现系统依赖关系，分析架构模式，并根据您的实际风险配置创建有针对性的实验。测试范围覆盖您的整个应用组合，同时降低对专业知识的要求。

图1。五层人工智能驱动的弹性架构

五层架构图，其中AWS Resilience Hub被标记为“下一代”，具有原生依赖发现和生成式AI故障模式分析功能，作为中央协调中心。第1至4层（发现、测试生成、实验、差距分析）位于顶部，每层都连接到中心。第5层（持续验证）位于下方，包括CI/CD、漂移检测和仪表板。图中叠加了三个虚线反馈循环：差距分析将“架构更新”反馈给发现层，持续验证将“实验学习”发送到测试生成层，SSM文档将“验证过的恢复程序”输入测试生成层内的FIS模板。

每一层都建立在前一层的基础上，形成一个全面的验证策略。该架构与AWS Well-Architected可靠性支柱对齐，特别是测试可靠性最佳实践领域。发现层映射您的基础设施。测试生成层根据该映射创建相关的实验。实验层安全地执行这些测试。差距分析层识别需要修复的内容。持续验证层帮助验证随着系统演变，改进措施是否持续有效。

现在您已经了解了整体策略，让我们详细查看每一层，首先从发现层如何自动映射您的基础设施开始。

发现层

发现层通过自动识别基础设施组件及其依赖关系，构成了整个架构的基础。下一代AWS Resilience Hub提供原生依赖发现功能，能够识别您的应用程序所依赖的AWS服务、内部端点和第三方端点。部署在Amazon Bedrock AgentCore上的自定义代理（具有对AWS API的读取权限）通过代码级分析扩展了这种原生发现功能，扫描您的代码仓库，查找硬编码依赖项、连接字符串、超时配置和重试逻辑，这些是基础设施级发现无法检测到的。部署在Amazon Bedrock AgentCore上的自定义代理处理基础设施发现。Amazon Bedrock AgentCore运行时提供专用的MicroVM会话隔离，支持最长可达八小时的长时间运行发现会话，并在无需您管理基础设施的情况下处理扩展和安全性。运行时内置的可观测性（跟踪、日志和指标）可与您现有的Amazon CloudWatch仪表板原生集成，无需额外的仪器配置。

AgentCore 托管的代理会查询包括 Amazon Elastic Compute Cloud（Amazon EC2）、Amazon Relational Database Service（Amazon RDS）、AWS Lambda、Amazon DynamoDB 和 Amazon Simple Storage Service（Amazon S3）在内的服务，以构建全面的资源清单。它会分析 AWS CloudFormation 模板和 Terraform 配置，以了解您预期的架构，并访问代码仓库，以识别应用程序中硬编码的依赖项、连接字符串和超时配置。AWS Config 提供配置数据并跟踪随时间的变化。对于拥有数千个资源的环境，此发现过程可在 2 至 4 小时内完成。

图 2. AI 驱动的发现工作流程

工作流程图分为两个泳道。泳道 1（蓝色）显示 AWS Resilience Hub 本机基础设施级发现，通过查询 AWS 服务 API（Amazon EC2、Amazon RDS、AWS Lambda、Amazon S3、Elastic Load Balancing、Amazon DynamoDB）获取服务拓扑、端点和 Multi-AZ 配置。泳道 2（黄色）显示运行在 Amazon Bedrock AgentCore 上的代理执行代码级发现——扫描仓库（通过 IAM 权限访问 CodeCommit、GitHub、GitLab）并分析 CloudFormation/Terraform 模板，以识别连接字符串、超时和断路器。两个泳道的数据都会输入到一个综合的依赖关系图中，然后流入 AWS Resilience Hub 的评估引擎。输出包括单点故障、依赖关系图（基础设施 + 代码）、基准弹性评分、配置漂移和弹性差距。AWS Config 并行监控配置。一个虚线的反馈箭头从评估引擎返回到 AgentCore 代理，标记为“架构更新与学习”。对于典型的单账户环境，初始映射可在 2 至 4 小时内完成；后续运行仅处理 AWS Config 跟踪的更改。

测试生成层

虽然下一代 Resilience Hub 包含一个基于生成式 AI 的故障模式评估，可以通过静态分析识别潜在的弱点，但此测试生成层会将这些建议转换为可执行的 AWS 故障注入服务实验模板，包括安全防护措施、逐步扩展的范围和针对您特定架构的业务影响评分。

基于发现的基础设施，测试生成层会为您的特定架构创建有针对性的混沌实验。托管在 AgentCore 运行时上的代理使用 Amazon Bedrock 基础模型来分析您的基础设施上下文，并结合您在 AWS Resilience Hub 中定义的 RTO（恢复时间目标）、RPO（恢复点目标）和可用性目标，来识别单点故障并生成与您的业务需求相一致的假设驱动的测试场景。每个假设都会根据潜在的业务影响进行评分，优先对面向客户的系统和组件进行实验，这些系统和组件的架构模式表明了高可用性的意图。每个实验都基于您在 AWS Resilience Hub 中定义的应用程序层级、架构模式（如面向互联网的负载均衡器和 Amazon API Gateway 端点）、依赖性分析和 AWS 资源标签进行业务影响评分。这确保了实验优先针对面向客户的系统和影响最大的组件。通过发现层的代码仓库分析，系统可以检测到您的应用程序使用了 Amazon RDS Multi-AZ 但缺乏适当的连接重试处理，并设计数据库故障转移测试来验证您的实际恢复机制，而不是通用的网络中断测试。

对于您的生产环境，请实施一个手动审批工作流程，让您的基础设施团队在执行实验模板之前对其进行审查。AWS Step Functions 协调审批关卡。Step Functions 是一种工作流管理服务，可以将多个 AWS 服务协调到无服务器工作流中。

实验层

在创建有针对性的实验后，实验层会在您的基础设施上运行混沌测试，并采用多层安全防护措施。AWS 故障注入服务通过内置的安全机制执行混沌测试。实验从最小范围开始（仅影响您资源的 1%），然后根据您的风险容忍度和验证结果逐步扩大（例如，1% → 5% → 10% → 25%）。这遵循了 AWS Well-Architected 可靠性支柱中推荐的渐进式部署策略，类似于金丝雀部署，其中更改逐步推出以限制影响范围。Amazon CloudWatch 报警作为停止条件，在实验违反您的服务等级协议（SLA）之前停止实验，SLA 是定义预期正常运行时间和性能的合同。请将报警阈值设置在 SLA 限制以下的适当位置。如果您的 SLA 允许 1% 的错误率，请将停止条件配置为在 0.1% 时触发。

差距分析层

在您的实验完成后，差距分析层会处理结果以识别弱点并优先进行修复。AWS Resilience Hub 将实验结果与您的弹性策略进行关联，按架构、运营、数据保护和测试维度对差距进行分类。每个差距都会根据严重性（多大程度上违反了您的弹性策略）、发生可能性（这种故障模式发生的频率）和业务影响（如果在您的环境中发生这种故障的成本）进行优先级评分。

持续验证层

持续验证层将弹性测试集成到您的开发流程中。正确的方法取决于您的部署速度和测试目标。

对于大多数团队来说，使用轻量级的策略即代码检查（例如使用 Open Policy Agent 验证基础设施即代码和 Dockerfile）可以在几秒钟内完成，并且可以自然地集成到每次提交的 CI/CD 流程中。这可以在代码进入预发布环境之前，捕获基本的配置问题，例如缺少健康检查或单可用区部署。

全面的弹性评估更适合作为预生产阶段的门禁，由重大架构变更触发，而不是每次提交都触发。对于常规部署，轻量级的弹性回归测试（验证一组关键的故障场景，如数据库故障转移、可用区丢失和断路器激活）会自动运行，以捕获代码或配置变更导致的意外弹性退化。这种双层方法可以为重大变更提供全面的安全验证，同时为日常部署提供持续的回归覆盖，而不会减慢您的流程。您的新代码和基础设施变更会触发自动的弹性评估，在开发阶段而非部署后识别潜在的弱点，将这种左移策略直接嵌入到您的 CI/CD 工作流程中。

策略即代码检查为每次流水线运行增加几秒钟。全面的弹性评估每个实验大约增加 2-3 分钟。

AWS Config 漂移检测可以识别绕过部署流水线的手动更改，帮助保持架构与经过测试的配置一致。

图 3. CI/CD 流水线中的弹性测试

流程图显示了一个具有双层弹性测试的 CI/CD 流水线。第一行展示了标准的流水线流程：开发人员提交代码 → 构建与单元测试 → 部署到测试环境 → 弹性回归测试（绿色六边形门，每次部署运行 3-5 个关键场景，耗时约 2-3 分钟） → 集成测试 → 部署到预发布环境。从预发布环境，如果检测到架构变更，流程会下降到第二行：全面弹性评估（橙色六边形门，使用 AWS Resilience Hub、FIS 和 Bedrock 在约 15-45 分钟内运行 15-20 个实验） → 手动批准门 → 部署到生产环境 → 持续监控。如果没有检测到架构变更，预发布环境会直接跳到批准门。两个弹性门都有失败路径（红色），会阻止部署并返回给开发人员。图例和侧边栏总结了这两个层级。

通过反馈实现持续改进

实验结果反馈到发现和测试生成层，创建一个持续改进的循环。当实验揭示未记录的依赖项时，发现层会更新您的架构图。当修复操作成功解决故障模式时，Systems Manager 自动化文档会捕获这些过程供将来使用。Bedrock 代理分析实验结果，以优化假设生成，降低持续通过的场景优先级，并关注随着架构演变而出现的风险区域。

主要优势

现在您已经了解了每一层是如何协同工作的，让我们来探讨这种架构为您组织带来的具体优势。

更快的基础设施发现：手动的基础设施发现需要分布式团队投入大量精力，包括资源的分类、依赖关系的追踪和配置的验证。通过自动发现，可以利用程序化查询云服务 API、分析基础设施即代码模板和映射依赖关系，将这一过程从数周缩短至数小时。实施后，该框架可以扩展到您的整个应用组合，而无需按比例增加人员配置。

消除专业知识障碍：即使没有混沌工程专家，您也可以使用自动化场景实施弹性测试。可以从 AWS 故障注入服务场景库开始，使用常见的故障模式，然后扩展到特定于您架构的场景，并根据您应用的具体故障模式进行定制。

主动识别风险：自动发现揭示了手动审计经常遗漏的关键单点故障，包括硬编码的端点、缺少的断路器和缺失的健康检查。系统会识别基础设施中的漏洞，并根据对业务的影响进行优先级排序，使您的团队能够优先处理风险最高的项目。

通过自动化修复实现更快的恢复：自动化修复通过消除对常见故障模式的环境手动干预，减少了平均恢复时间。AWS Systems Manager 自动化文档将混沌实验中发现的恢复程序进行编码。当 Amazon CloudWatch 告警检测到系统中的故障模式时，AWS Systems Manager 会自动执行修复操作，比手动响应更快地处理问题。

持续的弹性验证：将弹性评估集成到 CI/CD 管道中，可以在生产部署之前捕获回归，使系统在演进过程中保持弹性，而不是将其视为一次性验证。

框架组件

AWS Resilience Hub 作为中央协调层，定义您的弹性策略，运行评估并跟踪改进。根据您的业务影响分析，为每个应用层级定义 RTO（恢复时间目标）和 RPO（恢复点目标）。

Amazon Bedrock 提供了驱动发现和测试创建的人工智能能力。AgentCore Runtime 提供了托管的运行层，处理会话隔离、扩展、身份管理和可观测性，使您的代理能够在生产环境中安全运行，而无需基础设施开销。

在 Amazon Bedrock AgentCore 上部署自定义代理，这是一个框架无关的托管运行时，支持使用 Strands、LangChain 或自定义 Python 构建的代理。代理使用 Amazon Bedrock 将您的基础设施上下文与架构模式、AWS 文档和最佳实践进行分析。AgentCore Runtime 内置的工具网关在发现过程中提供受控且安全的访问您的 AWS API 的方式。

AWS 故障注入服务在您的基础设施上运行受控的混沌实验，并具有内置的安全机制。预构建的操作涵盖了常见的故障场景：终止 Amazon EC2 实例、注入网络延迟、限制 API 调用、故障转移 Amazon RDS 数据库以及在您的环境中中断可用区连接。

AWS Systems Manager 将您的恢复力框架扩展到默认的 AWS 故障注入服务操作之外。您可以创建自定义的自动化文档，将恢复程序编码化，并将手动操作手册转换为自动化的自愈响应。在构建自定义操作时，您需负责正确的回滚流程和服务状态的恢复。请以您对生产操作手册所应用的严谨程度来设计这些内容。

AWS Config 持续监控您的资源配置并跟踪变更。AWS Config 规则验证您的资源是否符合恢复力策略。例如，它们会验证您的 Amazon RDS 实例是否使用多可用区部署，并确认您的自动扩展组是否跨越多个可用区。

先决条件

要实现此框架，您需要：

• 具有管理权限的 AWS 账户。

• 对以下服务的 AWS 身份和访问管理（IAM）权限：AWS Resilience Hub、AWS Fault Injection Service、Amazon Bedrock AgentCore、AWS Systems Manager 和 AWS Config。对于每个服务，请遵循最小权限原则。有关每个服务所需的最低权限，请参阅相应的服务文档。

• Amazon Bedrock AgentCore 启动工具包默认创建广泛的开发/测试权限。在生产部署之前，请将这些权限缩小到最小权限。

• 安装并配置了 AWS 命令行界面（AWS CLI）。

• 对 AWS CloudFormation 或 Terraform 的基本了解。

• 一个可用于测试的非关键应用程序。

• 预计时间：试点实施需要 4–6 小时（由 2–3 名熟悉您 AWS 环境的工程师组成团队）。

• 成本意识：此实施会创建可计费的 AWS 资源，包括 AWS Resilience Hub、AWS Fault Injection Service、Amazon Bedrock AgentCore、AWS Systems Manager、AWS Config 和 Amazon CloudWatch。测试完成后，请遵循清理程序以避免持续收费。

入门

如果您是混沌工程的新手，分阶段推出可以在扩展范围之前建立信心。

试点阶段（1–2 周，2–3 名工程师）

• 从您的产品组合中选择一个架构清晰且非关键的应用程序。

• 在您的应用程序运行的区域中启用 AWS Config。

• 使用 Strands、LangChain 或自定义 Python 打包您的发现代理代码。

• 使用 Amazon Bedrock AgentCore 启动工具包在 Amazon Bedrock AgentCore 上部署打包后的代理。AgentCore 运行时处理计算、会话管理和安全性，使您可以专注于代理逻辑和发现范围。运行时在多步骤基础设施发现工作流程中维护有状态的工作上下文（包括工具状态和内存）。

• 在 AWS Resilience Hub 中运行基线恢复力评估，以识别初始的架构差距。Resilience Hub 会根据 Well-Architected 最佳实践评估您的架构，并建立您的初始恢复力状态。下一步部署的 Bedrock 代理在此基础上进行扩展，发现未记录的依赖项，并生成超出标准建议的针对性实验。

验证：检查 AWS Resilience Hub 控制台，查看已完成的评估报告，其中显示基线恢复力分数和识别出的差距。您应该看到每种中断类型（可用区、区域、应用程序）的恢复力分数以及推荐操作的列表。

• 在使用试点验证安全性后，将规模扩展到跨不同层级的 3–5 个应用程序。

• 配置自动测试创建，以针对每个应用程序的架构开发特定的实验。

• 在低流量期间，从 1% 的范围开始运行受控的混沌实验。

验证：在 AWS Fault Injection Service 控制台中查看实验状态是否为“已完成”，并检查 Amazon CloudWatch 指标以确认 1% 的范围已应用且未触发停止条件。

• 分析结果，以识别跨应用程序的常见模式。

企业规模（8–12 周，专用的韧性团队）

• 将韧性评估扩展到 CI/CD 管道中，进行全面的跨账户验证。

• 在组织单位之间配置集中式报告。

• 设置跨账户的实验协调。

• 使用 AWS Organizations 在组织单位之间分发共享的实验模板。

• 部署分布式工作池，以在多个应用程序之间进行并行测试。

• 使用 Amazon QuickSight 实施高管仪表板，以跟踪整个产品组合中的韧性趋势。

何时迁移到企业模式

当满足以下任一条件时，考虑采用下一节中介绍的企业部署模式：

• 您在多个 AWS 账户中管理数十个应用程序。

• 多个业务部门需要基于不同的风险容忍度、合规要求或客户 SLA 的差异化韧性策略。

• 合规要求需要跨账户的集中审计跟踪。

• 您的测试节奏超过了单账户设置所能处理的范围。

企业部署的设计考虑

当您准备扩大试点规模时，请考虑这些企业部署模式，它们可以处理在大型组织中管理韧性测试所面临的独特挑战。

图 4. 企业可扩展性模式

图示显示了多账户结构，与原生的 AWS Resilience Hub 和 AWS Organizations 集成。一个中央管理账户连接到生产（Production）和非生产（Non-Production）组织单位，其中包含分布式的应用程序账户。该框架通过跨账户的 FIS 协调（跨组织单位的协调实验）和通过 Organizations 分发的共享 FIS 实验模板，扩展了这种原生集成。基于优先级的调度显示了第一级关键任务（每周评估，100+ 应用程序）、第二级业务关键（每月评估，500+ 应用程序）和第三级非关键（每季度评估，1000+ 应用程序）。分布式工作池跨多个 AWS 区域（us-east-1、us-west-2、eu-west-1、ap-southeast-1）运行，通过 Amazon EventBridge、Amazon QuickSight 仪表板、Amazon CloudWatch 日志和 Amazon SNS 通知进行集中监控。

多账户架构

下一代 AWS Resilience Hub 支持模块化弹性策略，您可以根据系统、用户旅程或服务级别进行分配。如果您管理着跨不同业务单元的超过 100 个应用程序，应选择这种多账户策略。当您拥有数千个应用程序时，从单个账户同时评估所有工作负载变得不切实际。采用集中式架构模式（即“中心枢纽”账户管理共享服务，而“分支”账户包含独立工作负载的“中心-分支”模型），并结合集中式的弹性测试基础设施和分布式的应用所有权。在您的中心管理账户中部署 AWS Resilience Hub 和 AWS Fault Injection Service。您的生产账户包含应用程序工作负载和本地的 AWS Config 记录器。下一代 AWS Resilience Hub 与 AWS Organizations 本机集成，使中央团队能够定义弹性策略，并从单一仪表板监控所有账户和区域的态势。此框架通过跨账户实验协调和跨组织单位共享实验模板，扩展了本机多账户可见性。有关如何构建多账户环境的指导，请参阅《多账户环境最佳实践》和《使用多个账户组织您的 AWS 环境》白皮书。

分层弹性策略

并非所有工作负载都值得相同的弹性投资。根据您的业务影响分析，实施分层弹性策略。例如，关键任务应用程序可能设定更严格的恢复目标（如 RTO < 15 分钟，RPO < 5 分钟，可用性 99.99%），并进行全面的季度混沌实验；而业务关键应用程序可能设定中等目标（如 RTO < 1 小时，RPO < 15 分钟，可用性 99.9%），并进行月度验证；而非关键应用程序可能接受更长的恢复窗口，并进行季度评估。这种分层策略通过将弹性投资集中在影响最大的工作负载上，从而优化成本。

安全与合规

根据 AWS 共享责任模型，AWS 负责云的安全（基础设施），而您负责云中的安全（您的配置、数据和访问管理）。以下描述的控制措施是您需要配置和维护的。使用 AWS Key Management Service（AWS KMS）和客户管理密钥对静态数据进行加密。为每个环境实施单独的加密密钥，以限制基础设施中未经授权访问的范围。对传输中的数据强制实施传输层安全协议 1.3（TLS 1.3），这是一种用于保护数据传输的加密协议。AWS CloudTrail 提供您弹性操作的完整审计跟踪。通过 AWS Security Hub 进行的自动化合规监控（该服务持续评估资源是否符合包括 CIS AWS 基础架构基准、PCI DSS 和 AWS 基础安全最佳实践在内的标准），结合 AWS Config 合规性包，可简化 Service Organization Control 2 Type II（SOC 2 Type II）、国际标准化组织 27001（ISO 27001）、支付卡行业数据安全标准（PCI DSS）和数字运营弹性法案（DORA）（一项要求金融机构测试运营弹性的欧盟法规）的证据收集。

AI 代理安全性：Amazon Bedrock AgentCore 托管的代理遵循最小权限原则，使用具有作用域的 IAM 角色进行操作。AgentCore 运行时的 MicroVM 会话隔离确保每个发现会话在专用的、短暂的环境中运行，不会发生跨会话的数据泄露。在发现过程中，代理对基础设施的访问仅限于只读，无法修改资源。Amazon Bedrock 交互发生在您的 AWS 账户边界内，且不会使用客户数据进行训练。为了进一步加强防护，您可以配置 Amazon Bedrock 防护措施，以过滤代理输出并执行负责任的 AI 策略。

注意：此框架有助于您满足合规性要求，但不能保证符合任何法规框架。合规性是共同的责任。请咨询您的法律和合规团队以及合格的审计师，以验证您的实施是否符合特定的法规义务。

解决常见问题

逐步扩展范围和自动停止条件有助于您验证实验，揭示弱点，而不会在环境中造成中断。从您资源的 1% 开始，可以将潜在影响限制在统计上不显著的流量范围内。组织已通过逐步扩展范围和自动停止条件验证了此策略。

自动化场景消除了专业知识障碍。AI 驱动的分析会检查您的特定架构，以开发有针对性的实验，而不是要求您手动设计测试。AWS CloudTrail 提供了对您的混沌实验的全面审计跟踪，这有助于支持弹性测试的尽职调查文档。这些证据可以用于您的 SOC 2、ISO 27001 以及与您的组织相关的其他框架的合规性文档。对于金融服务，该框架支持 DORA 场景测试要求。

清理

为了避免持续产生费用，请删除实施过程中创建的资源：

• 删除您的 AWS 故障注入服务实验模板。警告：这将永久删除实验历史和结果。如果需要保留这些信息以用于合规性或分析目的，请在删除前导出实验数据。

• 删除您的 Amazon Bedrock AgentCore 代理部署、运行时端点和相关配置。

• 删除您的 AWS Systems Manager 自动化文档。警告：这将永久删除您的自动化运行手册。请备份您可能希望在未来实施中再次使用的任何自定义运行手册。

• 删除为停止条件创建的 Amazon CloudWatch 警报。

• 删除为审批工作流程创建的任何 AWS Step Functions 状态机。

• 删除为 IaC 验证部署的 Open Policy Agent 配置。

• 删除为弹性跟踪创建的 Amazon QuickSight 仪表板（如适用）。警告：这将删除弹性趋势数据和运营洞察。在删除前导出仪表板数据或保存分析快照。

• 删除为通知创建的 Amazon EventBridge 规则和 Amazon SNS 主题（如适用）。

您的 AWS Resilience Hub 和 AWS Config 仍会产生少量费用。请考虑保留它们以进行持续的弹性验证。

结论

在本文中，我向您展示了如何构建一个五层的 AI 驱动的弹性框架，该框架可以自动发现依赖项、生成有针对性的实验，并与您的 CI/CD 管道集成。基于下一代 AWS Resilience Hub 的原生依赖项发现和生成式 AI 驱动的故障模式分析，该框架通过 Amazon Bedrock AgentCore 实现了自动实验生成，通过 AWS Fault Injection Service 实现了受控执行，并通过 AWS Systems Manager 实现了持续的 CI/CD 验证，从而创建了一个从发现到预防的端到端弹性管道。

下一步的前沿是更早地进行检测，即在任何资源部署之前，扫描您的基础设施即代码（IaC）和应用程序代码中的弹性反模式。当您的 CI/CD 管道可以在拉取请求阶段标记出缺少断路器或单可用区依赖项时，预防就真正变得具有前瞻性。

渐进式策略（从单个应用程序试点开始，扩展到多个应用程序，然后在整个组织范围内进行扩展）在每个阶段都能建立信心并展示价值。组织通常通过防止事件和减少平均故障恢复时间（MTTR）实现积极的投资回报。

该框架使弹性测试对您来说更加容易，消除了传统上阻碍采用的专家门槛。从前面概述的试点阶段开始，随着信心的增强，逐步扩展到您的关键任务系统。

准备好开始了吗？从您的产品组合中选择一个非关键的应用程序，部署发现代理，并在本周内运行您的首次评估。然后分享您的发现。我们很乐意听到您的团队发现了哪些隐藏的依赖项。

您在组织中实施了混沌工程吗？您遇到了哪些挑战？请在下方评论中分享您的经验。

下一步

如需了解最新的 Resilience Hub 功能，包括原生依赖项发现和生成式 AI 驱动的故障模式分析，请参阅《介绍下一代 AWS Resilience Hub》和下一代文档。

从与您当前弹性旅程阶段最相关的资源开始：

如果您刚开始：

• 如需了解有关弹性策略和评估能力的更多信息，请参阅《AWS Resilience Hub 文档》。

• 如需实际操作混沌工程的体验，请参阅《AWS Fault Injection Service 工作坊》。

如果您准备开始构建：

• 如需了解如何通过 Amazon Bedrock 使用自然语言创建故障注入实验，请参阅《明确混沌工程：通过 Amazon Bedrock 使用自然语言生成 AWS FIS 实验》。

• 如需了解如何使用 AWS Resilience Hub 和 AWS CodePipeline 评估应用程序弹性，请参阅《通过 AWS Resilience Hub 和 AWS CodePipeline 持续评估应用程序弹性》。

• 如需获取更多故障注入实验模板，请参阅《AWS Fault Injection Service 模板库》。

如果您正在扩展到生产环境：

• 如需了解如何大规模托管生产 AI 代理，请参阅《Amazon Bedrock AgentCore》。

• 如需获取代理代码和部署模板的示例，请参阅《Amazon Bedrock AgentCore 启动工具包》。

系统将面临故障。通过将弹性测试从被动响应转变为积极预防，可以在客户体验到问题之前发现并修复弱点。

如果您在使用该框架时有任何问题或需要指导，请联系 AWS 或与您的 AWS 解决方案架构师联系。

关于作者

'"`