在 AWS DevOps Agent 调查之后自动执行修复

#在 AWS DevOps Agent 调查之后自动执行修复

缩短事故检测、调查和修复之间的时间，是在 AWS 上运行生产工作负载的组织的一项关键优先事项。出了问题，值班工程师常常要迅速跨应用组件诊断，找出根因，再施加修复，而且常常是在半夜。

AWS DevOps Agent 是一个由人工智能驱动的智能体，它整天基于相关联的指标、日志和应用拓扑，自主分拣事故。它解决这项优先事项的前半段：提供根因分析（root cause analysis，RCA）以及建议的解决动作。不过，为了保住控制、并帮助避免未经打算的变更，组织通常让包括 AWS DevOps Agent 在内的可观测性智能体停留在观察并报告（observe-and-report）模式：智能体诊断问题，但不直接修改生产资源。在这篇文章里，我们演示如何使用 AWS Lambda 持久函数（这是 AWS Lambda 的一项能力）、Amazon EventBridge 和 Amazon Bedrock，做出一条自动修复工作流，补上 AWS DevOps Agent，把问题解决这一步做完。这条工作流把调查摘要变成预先校验过的修复，只等一次批准动作，帮助你缩短平均解决时间（mean time to resolution，MTTR），并让值班工程师从重复的诊断工作里抽身。

解决方案概览

有了 AWS Lambda 持久函数，你可以构建有韧性的多步骤应用和人工智能工作流，最长可以跑一年，而不必再管额外的基础设施，也不必自己写状态管理和错误处理代码。这些函数会自动为进度做检查点（checkpoint），在长时间任务期间挂起执行，并从故障中恢复，即便被打断也能维持可靠的进展。

下图说明该解决方案的架构。

图 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 函数允许列表（allowlist）里识别并列出可用的修复工具：devops-agent-lambda-tool。
6. Amazon Bedrock 根据调查发现和可用工具，提出具体的修复动作。
7. 对只读动作，持久函数自主运行修复工具。对基础设施变更，工作流挂起，并在继续之前等待人工批准。
8. 批准之后，持久函数用选定的工具把修复动作应用到基础设施。

持久函数按智能体循环（agentic loop）运行，反复调用 Amazon Bedrock、执行已批准的工具，并把结果喂回对话，直到修复完成。为了让自动动作安全、可审计，编排器强制使用一份经过挑选的修复工具允许列表。每个工具都是一个专为目的而建的 Lambda 函数，执行一项具体、范围清楚的动作，例如读取某个 Lambda 函数的配置，或更新一条 AWS 身份与访问管理（AWS Identity and Access Management，IAM）策略语句。Amazon Bedrock 只能从这组已批准的工具里选择并调用，从而把自动动作的范围管住。工作流进一步区分只读操作和会改变状态的操作。只读工具自主运行，不需要人介入。会修改基础设施状态的变更类动作，会让持久函数挂起执行，等待人工批准。这正是 AWS Lambda 持久函数的关键好处。函数为进度做检查点，并暂停数分钟、数小时甚至数天，而不消耗计算资源，然后在收到批准信号后，正好从停下的地方继续。等到值班工程师介入时，系统已经收集了相关配置，把根因和可用的修复动作对上，并准备好一组预先校验过的变更，只等一次点击批准。当前实现使用批准或拒绝信号。因为回调接受任意 JSON 载荷，你可以把批准扩展成携带参数覆盖或审阅者的观察。这些可以喂回 Bedrock 对话，在执行前把提出的修复再收一收。

在后面各节里，我们走一遍实现细节，包括 Amazon EventBridge 规则配置和持久函数的编排逻辑。然后我们用 AWS Cloud Development Kit（AWS CDK）部署该解决方案。

先决条件

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

• 已安装并配置 AWS 命令行界面（AWS Command Line Interface，AWS CLI）。
• Python 3.14 或更高版本。
• 已安装 AWS CDK。
• 一个处于活动状态的 AWS DevOps Agent 空间。
• （可选）装有 面向 AWS 的 Agent Toolkit 的 Kiro。Agent Toolkit 通过一个带有基于 IAM 的访问控制的托管 MCP 服务器，让 Kiro 安全访问 AWS API。如果你使用 Kiro，这篇文章里的事故模拟、部署和清理步骤可以用自然语言提示完成，而不必手工跑 CLI 命令。要设置它，把 AWS MCP 服务器加进 ~/.kiro/settings/mcp.json（设置说明）。仓库里包含一份 Kiro 规则和智能体文件，会自动把项目上下文、部署顺序和安全约定交给 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 里打开克隆下来的仓库，并提问：“ _Set up the Python environment and deploy the CDK stack. Show me what resources will be created before deploying._” 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. 引导 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 权限。该堆栈把 aidevops:ListJournalRecords 权限授予 devops-agent-trigger 函数，使它能从 AWS DevOps Agent 日志里取调查摘要。它还把 bedrock:InvokeModel 权限授予 devops-agent-remediation-durable 函数，使它能调用 Amazon Bedrock。

验证该解决方案

修复堆栈已经部署，并且 devops-agent-timeout 函数正因超时错误而失败，现在我们可以走一遍端到端工作流。

用 AWS DevOps Agent 开始调查

打开 AWS DevOps Agent 控制台，进入你的智能体空间，并提问：“ _What is happening with the devops-agent-timeout function?_”

图 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": "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，以及它提出的修复，都是人工智能生成的，批准前始终应当审阅。人工批准这道门是安全控制：批准者必须检查完整的工具参数（例如一次 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\n          **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.\n          **Action Taken:** Successfully updated the Lambda function configuration to increase the timeout from 3 seconds to 30 seconds.\n          **Verification:** Confirmed the configuration change was applied successfully. The function now has:\n          - **Timeout:** 30 seconds (increased from 3 seconds)\n          - **Status:** Successful update completion\n          - **LastModified:** 2026-05-22T11:11:28.000+0000\n          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： 如果你使用带有面向 AWS 的 Agent Toolkit 的 Kiro，可以这样问：_“Clean up all resources from the DevOps Agent remediation demo: destroy the CDK stack, delete the devops-agent-timeout test function, its IAM role, and its 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 角色和 CloudWatch 日志组：

$ 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 持久函数、Amazon EventBridge 和 Bedrock 与 DevOps Agent 一起用，从而自动修复问题。该解决方案从 AWS DevOps Agent 停下的地方接上，把调查摘要变成可执行的修复步骤，并带上人工在环批准再跑。这种做法能缩短平均解决时间，因为等到值班工程师介入时，系统已经诊断了问题、收集了当前配置，并准备好一份可以批准的修复。安全仍处在设计的中心：允许列表把 Amazon Bedrock 限制为只能调用预先批准的工具，人工批准这道门帮助避免未经明确授权的变更进入生产。这个架构本身也可以扩展。增加新的修复能力只需要更新工具注册表的配置，不必改编排器的代码。而且因为 AWS Lambda 持久函数在等待批准时挂起、不消耗计算资源，即便批准周期跨越数小时或数天，该解决方案仍然省成本。

要开始使用这个解决方案，从 GitHub 仓库 下载完整的 AWS CDK 模板，并按这篇文章里的步骤在你的环境中部署。

我们很想听到你的情况。在评论里分享你实现这个解决方案的经验，提出问题，或建议改进。你也可以加入 AWS Community Builders 计划，与其他构建者联系，并分享你的无服务器架构模式。

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/automate-remediation-post-aws-devops-agent-investigation