AWS 演示 DevOps Agent 自动化修复方案

缩短从事件检测、调查到修复的时间，对于在 AWS 上运行生产工作负载的组织而言是一项关键优先事项。当出现问题时，值班工程师通常需要在深夜快速诊断跨应用组件的问题、确定根本原因并实施修复。

AWS DevOps Agent 是一款由 AI 驱动的代理，能够基于关联的指标、日志和应用拓扑全天候自主对事件进行分类处理。它通过提供根本原因分析（RCA）和推荐的解决操作，解决了上述优先事项中的第一部分。然而，为了保留控制权并防止意外变更，组织通常会将包括 AWS DevOps Agent 在内的可观测性代理保持在“观察与报告”模式，即代理仅诊断问题而不直接修改生产资源。在本文中，我们将演示如何利用 AWS Lambda Durable Functions（AWS Lambda 的一项功能）、Amazon EventBridge 和 Amazon Bedrock 创建一个自动化的修复工作流，以补充 AWS DevOps Agent 并完成问题解决步骤。该工作流将调查摘要转化为经过预验证的修复方案，只需单次审批即可执行，从而帮助您降低平均恢复时间（MTTR），并将值班工程师从重复性的诊断工作中解放出来。

解决方案概述

借助 AWS Lambda Durable Functions，您可以构建具有弹性的多步骤应用程序和 AI 工作流，这些工作流最长可运行一年，而无需您管理额外的基础设施或编写自定义的状态管理和错误处理代码。这些函数会自动检查点保存进度，在长时间运行的任务期间挂起执行，并在发生故障后恢复，即使在出现中断的情况下也能保持可靠的进度。

下图展示了该解决方案的架构。

图 1：从 AWS DevOps Agent 发起的调查到通过 Amazon EventBridge、AWS Lambda 和 Amazon Bedrock 实现的自动化修复工作流，在变更触及基础设施之前包含可选的人工审批环节

该工作流包含以下步骤：

1. AWS DevOps Agent 完成事件调查，并发出一个包含症状、发现及根本原因分析的事件。
2. Amazon EventBridge 接收调查完成事件，并使用调查内容触发 devops-agent-trigger 函数。
3. Lambda 函数打包调查摘要，并调用 devops-agent-remediation-durable 持久函数。
4. 持久函数将调查上下文发送给 Amazon Bedrock，由后者分析发现结果并寻找适用的修复方案。
5. Amazon Bedrock 从已批准的 Lambda 函数白名单 devops-agent-lambda-tool 中识别并列出可用的修复工具。
6. Amazon Bedrock 根据调查结果和可用工具提出具体的修复操作建议。
7. 对于只读操作，持久函数自主运行修复工具。对于基础设施变更，工作流会暂停并等待 人工审批 后再继续执行。
8. 获得批准后，持久函数使用选定的工具将修复操作应用到基础设施上。

该持久化函数以 智能体循环 的形式运行，迭代调用 Amazon Bedrock、执行已批准的工具，并将结果反馈到对话中，直到修复完成。为确保自动化操作的安全性和可审计性，编排器强制实施一个经过精心筛选的修复工具白名单。每个工具都是一个专门构建的 Lambda 函数，用于执行特定且范围明确的操作，例如读取 Lambda 函数配置或更新 AWS Identity and Access Management (IAM) 策略声明。Amazon Bedrock 只能从这一组已批准的工具中选择并调用，从而将自动化操作的范围控制在可控范围内。工作流进一步区分只读操作和变更操作。只读工具可在无需人工干预的情况下自主运行。而会修改基础设施状态的变更操作会导致持久化函数暂停执行，并等待人工审批。这正是 AWS Lambda Durable Functions 提供关键优势的地方。该函数对其进度进行 检查点保存，并在不消耗计算资源的情况下暂停数分钟、数小时甚至数天，然后在收到审批信号后从中断处精确恢复执行。当值班工程师介入时，系统已经收集了相关配置，将根本原因与可用的修复措施进行了关联，并准备了一组预先验证过的变更，只需一键即可批准。当前实现使用批准或拒绝信号。由于回调接受任意 JSON 载荷，你可以扩展审批流程以携带参数覆盖值或审核者意见。这些信息可以反馈到 Bedrock 对话中，在执行前优化所提议的修复方案。

前提条件

在部署此解决方案之前，请确认你满足以下前提条件：

• 已安装并配置 AWS Command Line Interface（AWS CLI）。
• Python 3.14 或更高版本。
• 已安装 AWS CDK。
• 一个有效的 AWS DevOps Agent space。
• （可选）Kiro 及 Agent Toolkit for AWS。Agent Toolkit 通过带有基于 IAM 访问控制的托管 MCP Server，为 Kiro 提供对 AWS API 的安全访问。如果你使用 Kiro，本文中的故障模拟、部署和清理步骤可以通过自然语言提示完成，而无需手动运行 CLI 命令。要设置它，请将 AWS MCP Server 添加到 ~/.kiro/settings/mcp.json（设置说明）。代码仓库中包含一个 Kiro rules and agents 文件，可自动为 Kiro 提供项目上下文、部署顺序和安全规范。

模拟故障

为了演示端到端的工作流，我们模拟一个常见场景：Lambda 函数超出其配置的超时时间。这为 AWS DevOps Agent 提供了一个真实的故障以供调查，并启动修复工作流。

为了将重点放在修复解决方案本身，创建和调用此测试函数的步骤保留在 代码仓库 中。它包含一个可直接使用的 devops-agent-timeout 函数，以及部署该函数、调用该函数并在 Amazon CloudWatch Logs 中确认超时错误的分步说明。有关完整指南，请参阅 README 中的 “Simulate the incident” 部分。

函数部署完成并产生至少一次超时错误后，你就可以开始使用 AWS DevOps Agent 进行调查了。

使用 AWS CDK 部署解决方案

请完成以下步骤以部署剩余的解决方案资源：

Kiro： 如果你已配置了带有 AWS Agent Toolkit 的 Kiro（参见先决条件），请在 Kiro 中打开克隆后的仓库，并提问：“设置 Python 环境并部署 CDK 堆栈。在部署前向我展示将创建哪些资源。” Kiro 会从仓库读取项目规则，设置虚拟环境，安装依赖项，并在部署前向你展示计划创建的资源。它在执行前会确认每一项基础设施变更，遵循与修复解决方案本身相同的人机协同（human-in-the-loop）模式。若要手动部署，请按照以下步骤操作。

1. 克隆托管在 GitHub 上的 AWS CDK 代码：

$ git clone https://github.com/aws-samples/sample-automate-remediation-post-devops-agent-investigation.git

2. 进入目录 sample-automate-remediation-post-devops-agent-investigation：

$ cd sample-automate-remediation-post-devops-agent-investigation

3. 引导（Bootstrap）AWS CDK。首次在任何特定的 AWS 环境（即 AWS 账户和 AWS 区域的组合）中使用 AWS CDK 时，此步骤是必需的。

$ cdk bootstrap

4. 部署堆栈：

$ cdk deploy

AWS CDK 会自动预配并配置以下资源：

• 三个 Lambda 函数：

• devops-agent-trigger.

• devops-agent-remediation-durable.

• devops-agent-lambda-tool.

• Amazon EventBridge 规则。

AWS CDK 会根据最小权限原则和 AWS 安全最佳实践自动处理 IAM 权限。例如，Amazon EventBridge 被授予对 devops-agent-trigger 函数的 lambda:InvokeFunction 权限。该堆栈授予 devops-agent-trigger 函数 aidevops:ListJournalRecords 权限，以便它可以从 AWS DevOps Agent 日志中获取调查摘要。它还授予 devops-agent-remediation-durable 函数 bedrock:InvokeModel 权限，以便它可以调用 Amazon Bedrock。

验证解决方案

随着修复堆栈部署完成且 devops-agent-timeout 函数因超时错误而失败，我们现在可以梳理端到端的工作流程。

使用 AWS DevOps Agent 启动调查

打开 AWS DevOps Agent 控制台，导航到你的代理空间，并提问：“devops-agent-timeout 函数发生了什么问题？”

图 2：从 AWS DevOps Agent 控制台启动调查

调查随即开始，需要几分钟才能完成。在此期间，AWS DevOps Agent 会自动关联 CloudWatch 指标、日志以及函数配置，以确定根本原因。

图 3：AWS DevOps Agent 在调查期间关联信号

调查完成后，AWS DevOps Agent 会呈现根本原因分析结果，指出函数超时设置对于该工作负载而言不足。

图 4：根本原因分析指出函数超时设置不足

验证触发器 Lambda 执行

调查完成时，会向 Amazon EventBridge 发出一个 Investigation Completed（调查完成）事件。

规则触发 devops-agent-trigger Lambda 函数，该函数从 AWS DevOps Agent 日志中获取调查摘要。在 /aws/lambda/devops-agent-trigger CloudWatch 日志组中，你可以看到发送给 devops-agent-remediation-durable 持久函数的已解析摘要，其中包括症状、根本原因、促成原因以及调查缺口。

图 5：触发器函数 CloudWatch 日志组中的已解析调查摘要

监控持久函数执行

前往 Lambda 控制台，打开 devops-agent-remediation-durable 函数，并选择 Durable executions（持久化执行）选项卡。选择新的执行以检查其已保存的检查点步骤。

图 6：Lambda 控制台中显示的持久化函数执行及其检查点步骤

持久化编排器通过向 Amazon Bedrock 发送调查上下文来启动其智能体循环。在第一次调用 Bedrock 时，模型分析调查摘要，并确定在提出修复方案之前需要检查当前的函数配置。它从允许列表中选择 lambda_get_function_configuration 工具。由于这是一个只读操作，因此无需人工批准即可自主运行。该步骤的结果显示了 devops-agent-timeout 函数的当前配置，确认超时值为 3 秒。

图 7：返回当前 3 秒超时配置的只读工具调用结果

Amazon Bedrock 提出修复方案

在确认当前配置后，Amazon Bedrock 进入下一次迭代。它推理得出 3 秒的超时是导致失败的根本原因，并建议将其增加到 30 秒。Amazon Bedrock 的响应包含推理过程和工具调用：

{
  ....
  },
  "output": {
    "message": {
      "role": "assistant",
      "content": [
        {
          "text": "现在我可以确认当前配置证实了该问题——函数的超时时间为 3 秒。鉴于这似乎是一个用于测试超时场景的函数（基于名称 \"devops-agent-timeout\" 及其与 \"DevOps Agent Test Infrastructure\" 的关联），我将把超时时间增加到一个合理的值，以确保函数能够成功完成执行。我会将其设置为 30 秒，这是需要更多执行时间的 Lambda 函数的常见超时设置。"
        },
        {
          "toolUse": {
            "toolUseId": "tooluse_lcGHbWDxng5HiLpmhWagDS",
            "name": "lambda_update_function_configuration",
            "input": {
              "FunctionName": "devops-agent-timeout",
              "Timeout": 30
            },
            "type": "tool_use"
          }
        }
        ...
      }

由于 lambda_update_function_configuration 是一项变更操作，持久化函数会暂停执行并等待人工批准。

图 8：Lambda 持久化函数审批请求的 CloudWatch 日志输出

重要提示： 发送给 Amazon Bedrock 的 investigation_summary 以及其提出的修复方案均由 AI 生成，在批准前务必进行审查。人工审批关卡是安全控制措施：审批人必须检查完整的工具参数（例如，在 lambda_update_function_configuration 调用中确切的 FunctionName 和 Timeout），并确认更改是正确的。

使用 AWS CLI：

$ aws lambda send-durable-execution-callback-success \
    --callback-id <callback-id> \
    --cli-binary-format raw-in-base64-out \
    --result '{"approved": true}'

使用 AWS Console：

导航至持久化执行，选择待处理的回调，然后选择 Send success 以确认：

图 9：在 Lambda 控制台中选择 Send success 以批准修复操作

在输入字段中输入 {'approved': true} 并确认。

图 10：输入批准载荷以确认回调

验证修复结果

批准后，持久函数恢复运行，调用工具 Lambda 以更新配置，Amazon Bedrock 确认修复已完成。更新后的 devops-agent-timeout 函数现在显示新的超时值：

图 11：devops-agent-timeout 函数配置已更新为 30 秒超时

最终步骤输出（bedrock-call-4）确认修复成功：

{
  "EventType": "StepSucceeded",
  "Name": "bedrock-call-4",
  ....
  },
  "output": {
    "message": {
      "role": "assistant",
      "content": [
        {
          "text": "## Remediation Complete
          **Issue Identified:** The Lambda function `devops-agent-timeout` in eu-west-1 was configured with a 3-second timeout that was insufficient for its execution time, causing timeout errors at exactly 3000ms.
          **Action Taken:** Successfully updated the Lambda function configuration to increase the timeout from 3 seconds to 30 seconds.
          **Verification:** Confirmed the configuration change was applied successfully. The function now has:
          - **Timeout:** 30 seconds (increased from 3 seconds)
          - **Status:** Successful update completion
          - **LastModified:** 2026-05-22T11:11:28.000+0000
          This remediation should resolve the timeout errors by providing the function with adequate time to complete its execution. The 30-second timeout provides a 10x increase from the original 3-second limit, which should be sufficient for most operations while still maintaining reasonable execution bounds for a Lambda function."
        }
      ]
    }
  },
  "stopReason": "end_turn",
  ...
}

整个周期，从故障检测到自动修复，仅需工程师执行一次审批操作。系统自主完成了诊断、配置检索、修复方案提议及执行。

清理资源

通过完成以下步骤来清理你创建的资源：

Kiro： 如果你使用 Kiro 配合 AWS Agent Toolkit，可以询问：“清理 DevOps Agent 修复演示中的所有资源：销毁 CDK stack，删除 devops-agent-timeout 测试函数、其 IAM role 以及其 CloudWatch log group。” Kiro 会按正确顺序移除资源，并在继续之前确认每个破坏性操作。如需手动清理，请遵循以下步骤。

1. 删除 AWS CDK 资源：

$ cdk destroy

2. 手动删除模拟故障的 devops-agent-timeout 函数：

$ aws lambda delete-function --function-name devops-agent-timeout

3. 手动删除 devops-agent-timeout 函数的 IAM role 和 CloudWatch log group：

$ aws iam detach-role-policy \
    --role-name devops-agent-timeout-role \
    --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
$ aws iam delete-role --role-name devops-agent-timeout-role
$ aws logs delete-log-group --log-group-name /aws/lambda/devops-agent-timeout

结论

本文演示了如何结合使用 Lambda Durable Functions、Amazon EventBridge 和 Bedrock，配合 DevOps Agent 来实现问题修复的自动化。该方案承接 AWS DevOps Agent 的工作成果，将调查摘要转化为可执行的修复步骤，并在人工审批（human-in-the-loop）的控制下运行。这种方法缩短了平均解决时间（MTTR），因为在值班工程师介入之前，系统已经完成了问题诊断、当前配置收集以及待审批修复方案的准备。安全性始终是设计的核心：允许列表限制 Amazon Bedrock 仅调用预先批准的工具，而人工审批关卡则有助于防止未经明确授权的意外变更进入生产环境。此外，该架构具有天然的扩展性。添加新的修复能力只需更新工具注册表的配置，无需修改编排器的代码。而且，由于 AWS Lambda Durable Functions 在等待审批期间会挂起且不消耗计算资源，即使审批周期长达数小时或数天，该方案依然保持成本效益。

要开始使用此解决方案，请从 GitHub 仓库下载完整的 AWS CDK 模板，并按照本文中的步骤在你的环境中部署该解决方案。

我们非常期待听到你的反馈。欢迎在评论区分享你实施此解决方案的经验、提出问题或建议改进。你也可以加入 AWS Community Builders 计划，与其他开发者建立联系并分享你的无服务器架构模式。