在 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 空间。
（可选）带有 Agent Toolkit for AWS 的 Kiro。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 的“Simulate the incident”部分。
在函数部署完成并产生至少一个超时错误后，您就可以开始使用 AWS DevOps Agent 进行调查了。
使用 AWS CDK 部署解决方案
完成以下步骤以部署其余解决方案资源：
Kiro：如果您已配置带有 Agent Toolkit for AWS 的 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 发送一个 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 是变更操作，持久函数会暂停执行并等待人工批准。
重要：发送到 Amazon Bedrock 的 investigation_summary 及其提出的修复方案均由 AI 生成，批准前应始终进行审查。人工批准门禁是安全控制措施：批准者必须检查完整的工具参数（例如 lambda_update_function_configuration 调用中的确切 FunctionName 和 Timeout），并确认更改是正确的。
$ aws lambda send-durable-execution-callback-success \
--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 会按正确顺序删除资源，并在继续之前确认每个破坏性操作。若要手动清理，请按照以下步骤操作。
删除 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 计划，与其他构建者建立联系并分享你的无服务器架构模式。
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文作者：Michele Scarimbolo；如有侵权，请联系管理员删除。
