Automate remediation post AWS DevOps Agent investigation

自动化AWS DevOps Agent调查后的问题修复 | 人工智能

自动化AWS DevOps Agent调查后的问题修复

缩短从事件检测、调查到修复的时间间隔，是运行AWS生产工作负载的组织的首要任务。当出现问题时，值班工程师通常需要快速跨应用组件诊断问题，确定根本原因并应用修复措施，而这往往发生在深夜。

AWS DevOps Agent 是一个基于人工智能的代理，全天候通过关联指标、日志和应用拓扑自主对事件进行分类处理。它通过提供根本原因分析（RCA）和推荐的解决措施，解决了上述优先事项的第一部分。然而，为了保持控制并帮助防止意外更改，组织通常会将观察代理（包括AWS DevOps Agent）保持在"观察-报告"模式，即代理诊断问题但不直接修改生产资源。在本文中，我们将演示如何使用AWS Lambda Durable Functions（AWS Lambda、Amazon EventBridge和Amazon Bedrock的功能），创建一个自动化修复工作流程，与AWS DevOps Agent形成互补，完成问题解决步骤。该工作流程将调查摘要转换为预先验证的修复方案，仅需单次批准操作即可执行，帮助您减少平均修复时间（MTTR），并让值班工程师摆脱重复的诊断工作。

解决方案概述

通过AWS Lambda Durable Functions，您可以构建具有弹性的多步骤应用和AI工作流，这些流程可持续运行长达一年，无需管理额外基础设施或编写自定义状态管理和错误处理代码。这些函数会自动检查进度，在长时间任务期间暂停执行，并在发生故障时恢复，同时在中断情况下保持可靠进度。

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

Figure 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 身份和访问管理 (IAM) 策略语句。Amazon Bedrock 只能从该批准工具集中选择和调用工具，这确保了自动化操作的范围可控。工作流进一步区分只读操作和变更操作。只读工具无需人工干预即可自主运行。任何可能修改基础设施状态的变更操作都会导致持久函数暂停执行并等待人工批准。这正是 AWS Lambda 持久函数的关键优势所在。该函数会检查点保存进度，并在数分钟、数小时甚至数天内暂停执行而无需消耗计算资源，收到批准信号后会从暂停处精确恢复执行。当值班工程师介入时，系统已提前收集了相关配置，将根本原因与可用修复操作相关联，并准备好了预验证的更改集供一键批准。当前实现使用了批准或拒绝信号。由于回调接受任意 JSON 载荷，可以将参数覆盖或审核员观察结果扩展到批准流程中。这些信息可以反馈到 Bedrock 对话中，在执行前优化拟议的修复方案。

在以下章节中，我们将逐步讲解实现细节，包括 Amazon EventBridge 规则配置和持久函数编排逻辑。然后使用 AWS 云开发工具包 (AWS CDK) 部署该解决方案。

先决条件

部署此解决方案前，请确认已满足以下先决条件：

• 已安装并配置 AWS 命令行界面 (AWS CLI)
• Python 3.14 或更高版本
• 已安装 AWS CDK
• 活动的 AWS DevOps Agent 空间
• (可选) 安装 Kiro 及 AWS 代理工具包。代理工具包通过基于 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 的“模拟事件”章节。

函数部署并产生至少一个超时错误后，即可使用 AWS DevOps Agent 开始调查。

使用 AWS CDK 部署解决方案

按照以下步骤部署剩余的解决方案资源：

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

• 克隆 GitHub 上的 AWS CDK 代码：$ git clone https://github.com/aws-samples/sample-automate-remediation-post-devops-agent-investigation.git

• 进入目录 sample-automate-remediation-post-devops-agent-investigation：$ cd sample-automate-remediation-post-devops-agent-investigation

• 初始化 AWS CDK。首次在特定 AWS 环境（AWS 账户和 AWS 区域的组合）使用 AWS CDK 时需要此操作：$ cdk bootstrap

• 部署堆栈：$ 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 发出"调查完成"事件。

该规则会触发 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 执行选项卡。选择新的执行项以检查其检查点步骤。

图 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 控制台：

导航到持久化执行，选择待处理的回调，然后选择发送成功以确认：

图 9：在 Lambda 控制台选择“发送成功”以批准修复

在输入字段中，输入 {'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": "## 修复完成
          **识别的问题：** 在 eu-west-1 区域中，Lambda 函数 `devops-agent-timeout` 配置了 3 秒的超时时间，该时间不足以完成其执行时间，导致在正好 3000ms 时出现超时错误。
          **采取的措施：** 成功更新 Lambda 函数配置，将超时时间从 3 秒增加到 30 秒。
          **验证：** 确认配置更改已成功应用。现在函数具有：
          - **超时时间：** 30 秒（从 3 秒增加）
          - **状态：** 成功完成更新
          - **LastModified：** 2026-05-22T11:11:28.000+0000
          此修复应通过为函数提供充足的时间完成执行来解决超时错误。30 秒的超时时间相比原始 3 秒限制增加了 10 倍，这应足以满足大多数操作需求，同时仍保持 Lambda 函数的合理执行限制。"
        }
      ]
    }
  },
  "stopReason": "end_turn",
  ...
}

从事件检测到自动修复的整个周期，仅需要工程师进行一次批准操作。系统自主处理了诊断、配置检索、修复方案提出和执行等所有步骤。

资源清理

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

Kiro：如果您使用 Kiro 和 AWS Agent Toolkit，询问：“清理 DevOps Agent 修复演示中的所有资源：销毁 CDK 堆栈，删除 devops-agent-timeout 测试函数、其 IAM 角色及其 CloudWatch 日志组。” Kiro 会按照正确顺序删除资源，并在继续前确认每个破坏性操作。要手动清理，请按照以下步骤操作。

• 删除 AWS CDK 资源：$ cdk destroy

• 手动删除模拟事件的 devops-agent-timeout 函数：$ aws lambda delete-function --function-name devops-agent-timeout

• 手动删除 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 Durable Functions、Amazon EventBridge 和 Bedrock 以及 DevOps Agent 来实现问题修复的自动化。该解决方案在 AWS DevOps Agent 的基础上进一步推进，将调查摘要转化为需要人工审批的可操作修复步骤。这种方案能够降低平均故障恢复时间，因为当值班工程师介入时，系统已经完成了问题诊断、收集了当前配置，并准备好了待审批的修复方案。安全性始终是设计的核心：白名单限制 Amazon Bedrock 仅调用预先批准的工具，人工审批环节则有助于防止未经明确授权的更改进入生产环境。该架构本身也具有高度可扩展性。添加新的修复功能只需更新工具注册表的配置，而无需修改编排器的代码。而且由于 AWS Lambda Durable Functions 在等待审批期间会挂起且不消耗计算资源，即使审批周期跨越数小时或数天，该方案仍能保持成本效率。

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

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

作者简介

'"`