缩短事件检测、调查和修复之间的时间是运维 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 基于调查发现结果和可用工具提出具体的修复措施。
- 对于只读操作，持久化函数会自主运行修复工具。对于基础设施更改，工作流会挂起并等待 人工批准 后再继续。
- 批准后，持久化函数使用所选工具将修复措施应用到基础设施。
该持久化函数作为一个 代理循环（agentic loop）运行，迭代调用 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 会从仓库中读取项目规则，设置虚拟环境，安装依赖项，并在部署前向您展示计划创建的资源。它在执行之前会确认每一项基础设施更改，遵循与该修复解决方案本身相同的人工在环（human-in-the-loop）模式。要手动部署，请按照以下步骤操作。
- 克隆托管在 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 - 引导（bootstrap）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 被授予 lambda:InvokeFunction 函数的 devops-agent-trigger 权限。该堆栈向 aidevops:ListJournalRecords 函数授予 devops-agent-trigger 权限，使其能够从 AWS DevOps Agent journal 获取调查摘要。它还向 bedrock:InvokeModel 函数授予 devops-agent-remediation-durable 权限，使其能够调用 Amazon Bedrock。
验证解决方案
在修复堆栈已部署且 devops-agent-timeout 函数因超时错误而失败的情况下，我们现在可以完整走一遍端到端工作流程。
使用 AWS DevOps Agent 启动调查
打开 AWS DevOps Agent 控制台，导航到您的 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 生成的，在批准之前应始终进行审查。人工批准关卡是安全控制点：批准者必须检查完整的工具参数（例如， FunctionName 调用中确切的 Timeout 和 lambda_update_function_configuration ），并确认更改是正确的。
使用 AWS CLI：
$ aws lambda send-durable-execution-callback-success \
--callback-id <callback-id> \
--cli-binary-format raw-in-base64-out \
--result '{"approved": true}'使用 AWS 控制台：
导航到持久执行（durable execution），选择待处理的回调（pending callback），然后选择 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 停止之处继续工作，将调查摘要转化为可执行的修复步骤，并在人工在环批准的情况下运行。这种方法缩短了平均解决时间（MTTR），因为当值班工程师介入时，系统已经诊断出问题、收集了当前配置，并准备好了可供批准的修复方案。安全性仍然是设计的核心：允许列表将 Amazon Bedrock 限制为只能调用预先批准的工具，而人工批准关卡有助于防止未经明确授权的意外更改进入生产环境。该架构本身也具备良好的可扩展性。添加新的修复功能只需要更新工具注册表的配置，无需修改编排器的代码。而且，由于 AWS Lambda Durable Functions 在等待批准期间会挂起而不消耗计算资源，即使批准周期长达数小时或数天，该方案仍能保持成本效益。
要开始使用此方案，请从 GitHub 仓库下载完整的 AWS CDK 模板，并按照本文中的步骤在您的环境中部署该方案。
我们非常期待您的反馈。欢迎在评论区分享您实施该解决方案的经验、提出问题或建议改进。您还可以加入 AWS Community Builders 计划，与其他构建者交流并分享您的无服务器架构模式。