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 的自动化修复工作流，在变更到达基础设施之前可选择人工批准

该工作流包含以下步骤：

AWS DevOps Agent 完成事件调查，并发出包含症状、调查结果和根本原因分析的事件。
Amazon EventBridge 接收调查完成事件，并使用调查内容触发 devops-agent-trigger 函数。
该 Lambda 函数打包调查摘要并调用 devops-agent-remediation-durable 持久函数。
持久函数将调查上下文发送到 Amazon Bedrock，由其分析调查结果并查找适用的修复措施。
Amazon Bedrock 从经过精心整理的已批准 Lambda 函数允许列表中识别并列出可用的修复工具：devops-agent-lambda-tool。
Amazon Bedrock 根据调查结果和可用工具提出具体的修复操作。
对于只读操作，持久函数会自主运行修复工具。对于基础设施变更，工作流会暂停并等待人工批准后再继续。
获得批准后，持久函数使用所选工具将修复操作应用到基础设施。

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

在以下各节中，我们将逐步介绍实现细节，包括 Amazon EventBridge 规则配置以及持久函数的编排逻辑。然后，我们使用 AWS Cloud Development Kit（AWS CDK）部署该解决方案。

先决条件

在部署此解决方案之前，请确认你具备以下先决条件：

已安装并配置 AWS Command Line Interface（AWS CLI）。
Python 3.14 或更高版本。
已安装 AWS CDK。
一个处于活动状态的 AWS DevOps Agent 空间。
（可选）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：如果你已配置带有 Agent Toolkit for AWS 的 Kiro（参见 Prerequisites），请在 Kiro 中打开克隆的仓库并提问：“设置 Python 环境并部署 CDK 堆栈。在部署前向我展示将要创建的资源。”Kiro 会从仓库中读取项目规则，设置虚拟环境，安装依赖项，并在部署前向你展示计划创建的资源。它会在执行每一项基础设施变更前进行确认，遵循与修复方案本身相同的人在回路模式。若要手动部署，请按照以下步骤操作。

Clone the AWS CDK code hosted on GitHub:

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

Navigate to the directory sample-automate-remediation-post-devops-agent-investigation:
```
$ cd sample-automate-remediation-post-devops-agent-investigation
```
Bootstrap the AWS CDK. This is required the first time you use the AWS CDK in a specific AWS environment (a combination of an AWS account and AWS Region).
```
$ cdk bootstrap
```
Deploy the stack:
```
$ cdk deploy
```

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

Three Lambda functions:
- devops-agent-trigger.
- devops-agent-remediation-durable.
- devops-agent-lambda-tool.
Amazon EventBridge 规则。

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

验证该方案

在修复堆栈已部署且 devops-agent-timeout 函数因超时错误而失败后，我们现在可以逐步演练端到端工作流。

使用 AWS DevOps Agent 开始调查

打开 AWS DevOps Agent 控制台，进入你的 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 journal 获取调查摘要。在 /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": "Now I can see the current configuration confirms the issue - the function has a 3-second timeout. Given that this appears to be a test function for timeout scenarios (based on the name \"devops-agent-timeout\" and its association with \"DevOps Agent Test Infrastructure\"), I'll increase the timeout to a reasonable value that should allow the function to complete successfully. I'll set it to 30 seconds, which is a common timeout for Lambda functions that need more execution time."
        },
        {
          "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 控制台：

导航到持久执行，选择待处理的回调，然后选择 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 与 Agent Toolkit for AWS 一起使用，请询问：“清理 DevOps Agent 补救演示中的所有资源：销毁 CDK 堆栈，删除 devops-agent-timeout 测试函数、其 IAM 角色及其 CloudWatch 日志组。” Kiro 会按正确顺序移除资源，并在继续之前确认每个破坏性操作。要手动清理，请按照以下步骤操作。

Delete the AWS CDK resources:
```
$ cdk destroy
```
Manually delete the devops-agent-timeout function that simulates the incident:
```
$ aws lambda delete-function --function-name devops-agent-timeout
```

Manually delete the IAM role and the CloudWatch log group of the devops-agent-timeout function:

$ 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

结论

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

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

我们很乐意听到您的反馈。请在评论中分享您实施此解决方案的经验、提出问题或建议改进。您也可以加入 AWS Community Builders 计划，与其他构建者交流并分享您的无服务器架构模式。

关于作者

Michele Scarimbolo

Michele 是 AWS 的技术客户经理。他的职业生涯始于 Web 和移动开发，现在帮助客户构建无服务器解决方案。工作之余，他喜欢和团队一起游泳，以及旅行品尝新美食。