如何基于 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 对话中，以便在执行前完善拟议的修复方案。

在接下来的章节中，我们将逐步介绍实现细节，包括 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 会读取仓库中的项目规则，设置虚拟环境，安装依赖，并在部署前展示计划创建的资源。它会在执行前确认每一项基础设施变更，遵循与修复方案本身相同的人机协同模式。如需手动部署，请按照以下步骤操作。

1. Clone the AWS CDK code hosted on GitHub:

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

2. Navigate to the directory sample-automate-remediation-post-devops-agent-investigation:

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

3. 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

4. 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 被授予对 devops-agent-trigger 函数的 lambda:InvokeFunction 权限。该堆栈向 devops-agent-trigger 函数授予 aidevops:ListJournalRecords 权限，使其能够从 AWS DevOps Agent journal 获取调查摘要。同时，它还向 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 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 会以正确的顺序删除资源，并在执行每个破坏性操作之前进行确认。如需手动清理，请按照以下步骤操作。

1. Delete the AWS CDK resources:

   $ cdk destroy

2. Manually delete the devops-agent-timeout function that simulates the incident:

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

3. 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 完成工作的基础上更进一步，将调查摘要转化为可执行的修复步骤，并在人工审批的监督下运行。这种方法缩短了平均解决时间（MTTR），因为当值班工程师介入时，系统已经完成了问题诊断、收集了当前配置，并准备好了可供批准的修复方案。安全性始终是设计的核心：允许列表将 Amazon Bedrock 限制为只能调用预先批准的工具，而人工审批环节有助于防止未经明确授权的意外变更进入生产环境。该架构还具备天然的可扩展性。添加新的修复功能只需对工具注册表进行配置更新，无需修改编排器的代码。而且由于 AWS Lambda Durable Functions 在等待审批期间会挂起且不消耗计算资源，即使审批周期长达数小时或数天，该解决方案依然保持成本高效。

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

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

关于作者