如何用 AWS Lambda Durable Functions 自动执行 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 规则和代理文件，可自动为 Kiro 提供项目上下文、部署顺序和安全约定。

模拟事件

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

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

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

使用 AWS CDK 部署解决方案

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

Kiro：如果你已配置了带有 Agent Toolkit for AWS 的 Kiro（请参阅先决条件），请在 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 权限。例如，为 devops-agent-trigger 函数授予 Amazon EventBridge 的 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 发出一个调查已完成事件。

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

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

监控持久函数的执行

导航到Lambda 控制台，打开 devops-agent-remediation-durable 函数，然后选择持久执行选项卡。选择新的执行以检查其已设置检查点的步骤。

图 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 Logs 输出

重要：发送到 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

结论

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

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

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

关于作者

Michele Scarimbolo

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