基于 Amazon Bedrock 构建 Agentic 灾难恢复助手:Intuit 的 DevOps 实践
- 作者

- 姓名
- Nino
- 职业
- Senior Tech Editor
在现代企业级云计算架构中,系统停机不仅意味着巨大的直接经济损失,还会引发严重的合规风险。对于管理着 TurboTax、QuickBooks 和 Credit Karma 等知名金融科技产品的 Intuit 而言,灾难恢复(Disaster Recovery, DR)是保障系统 99.99% 以上高可用性的核心命脉。
在突发故障或基础设施异地灾备场景下,执行生产环境的跨区域故障切换(Multi-Region Failover)是一项极其复杂的系统工程。传统的 DR 机制高度依赖静态的操作手册(Runbooks)、复杂的 Shell 脚本以及运维人员在几十个监控仪表板之间的手动排查。当高压故障发生时,值班的站点可靠性工程师(SRE)必须阅读成百上千行的文档,手动比对指标,并一步一步触发基础设施变更。这种人工决策模式极易导致平均恢复时间(MTTR)拉长,并在紧急关头引入人为操作失误。
为解决这一瓶颈,Intuit 基于 Amazon Bedrock 设计并实现了 EWOK Agent(Emergency Workflow Operations Kit,紧急工作流操作工具包)——一个基于 Agentic AI 架构的智能灾难恢复助手。EWOK Agent 允许 SRE 和值班工程师通过自然的语言指令启动、跟踪和完成跨区域故障切换,同时全流程保证策略合规、可审计性以及严格的底层安全屏障。
灾难恢复的演进:从静态手册到 Agentic AI 智能体
企业级灾难恢复系统的演进经历了三个关键阶段:
- 静态文档与手动操作阶段:工程师依靠 Wiki 文档中的步骤,在命令行中手动敲入指令。该模式响应慢、易出错,且文档极其容易与实际生产环境脱节。
- 脚本化 ChatOps 阶段:基于规则的 Slack/Teams 机器人,触发预先编写好的 Jenkins 或 AWS Systems Manager 自动化脚本。虽然提高了执行速度,但缺乏动态应变能力,无法处理复杂的组合型故障。
- Agentic AI 自主决策阶段:由大语言模型(LLM)驱动的自适应智能体。Agent 能够理解人类自然语言意图,自主检索实时监控指标与架构拓扑,规划执行路径,调用 API 接口,并在人工授权下完成闭环操作与效果校验。
Intuit 选择 Amazon Bedrock 作为 EWOK Agent 的核心基础设施,主要归功于 Bedrock 提供的企业级数据隔离、对 Anthropic Claude 3.5 Sonnet 等高阶模型的无缝支持、原生的 Action Groups 扩展能力、 Knowledge Bases 知识库以及严密的 Guardrails 安全防护屏障。
EWOK Agent 架构深度拆解
构建一个面向生产环境的 DR AI Agent,必须满足三大核心原则:动作的确定性(Determinism)、上下文感知(Contextual Intelligence) 以及 零信任安全(Zero-Trust Security)。
下图展示了 EWOK Agent 如何与 AWS 基础设施及 Amazon Bedrock 协同工作:
+-----------------------------------+
| 值班工程师 (Slack / CLI) |
+-----------------------------------+
|
[自然语言故障处理请求]
v
+-----------------------------------+
| Intuit 内部 API 网关 / 路由 |
+-----------------------------------+
|
v
+-----------------------------------------------------------------------------------+
| Amazon Bedrock Agent 运行时环境 |
| |
| +------------------------+ +-----------------------+ +------------------+ |
| | Bedrock Guardrails | | LLM 推理引擎 | | Knowledge Base | |
| | (策略与安全过滤防护屏障) | -> | (Claude 3.5 Sonnet) | -> | (DR Runbook 文档, | |
| +------------------------+ +-----------------------+ | 拓扑结构知识库) | |
| | +------------------+ |
| v |
| +-----------------------+ |
| | Action Group 动作分发 | |
| +-----------------------+ |
+--------------------------------------------|--------------------------------------+
|
v
+-----------------------------------+
| Human-in-the-Loop (HITL) 审批门禁 |
| (影响面评估与人工确认面板) |
+-----------------------------------+
|
[人工确认授权]
v
+-----------------------------------+
| AWS Lambda / 执行微服务层 |
+-----------------------------------+
|
+-------------------------+-------------------------+
| |
v v
+---------------------------+ +---------------------------+
| Amazon Route 53 / 全局 | | Kubernetes 集群 (EKS) |
| 流量路由控制 | | 双活应用副本弹性伸缩 |
+---------------------------+ +---------------------------+
架构核心组件说明
- 推理与规划引擎:采用 Amazon Bedrock 托管的 Anthropic Claude 3.5 Sonnet 模型。模型将高层级的自然语言指令(例如:“由于 us-east-1 延迟飙升,请将支付服务的 50% 流量切往 us-west-2”)拆解为按顺序执行的具体步骤。
- Action Groups 与 OpenAPI 规范:Bedrock Action Groups 将 LLM 的推理意图转化为格式化的 API 调用。Intuit 编写了标准的 OpenAPI 规范,映射 Route 53 域名解析权重修改、AWS EKS Pod 伸缩以及 Kafka 消息队列路由调整等底层操作。
- Knowledge Bases 向量知识库:通过向量化索引,将 Intuit 内部的架构文档、服务依赖拓扑和标准 DR 流程注入 Bedrock 知识库。Agent 在执行规划前,会自动检索相关服务的上下文中最新拓扑,防止盲目操作。
- Guardrails 防护屏障:Bedrock Guardrails 实时扫描输入 Prompt 与输出内容,屏蔽违规指令,拦截幻觉生成的无效参数,并对敏感信息进行脱敏处理。
代码实战:构建 Bedrock DR Action Group 处理器
为了展示 EWOK Agent 如何安全执行底层基础设施变更,以下展示基于 Python boto3 开发的后端 Lambda 处理逻辑示例。
1. 定义 Action Group 接口处理函数
当 Bedrock 完成推理并决定触发故障切换动作时,会将结构化的 JSON 数据传递给绑定的 AWS Lambda 函数。
import json
import boto3
import os
import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
route53_client = boto3.client('route53')
# 安全策略约束配置
MAX_ALLOWED_TRAFFIC_SHIFT_PERCENT = 100
CRITICAL_SERVICES = ["payment-gateway