Intuit 基于 Amazon Bedrock 构建 Agentic 灾备助手 EWOK
- 作者
- 姓名
- Nino
- 职业
- Senior Tech Editor
在大规模企业级云架构中，灾难恢复（Disaster Recovery, DR）始终是系统运维中最具挑战性的环节之一。当 AWS 某个区域（Region）出现基础设施故障或数据库损坏时，值班 SRE（系统稳定性工程师）必须在极高压力下按步骤执行繁琐的 Runbook。在生产环境跨区域故障切换的过程中，任何一个手误敲错的命令都可能引发二次灾难，导致不可逆的数据损坏或更长的停机时间。
为了解决这一痛点，Intuit 构建了名为 EWOK Agent（紧急工作流操作工具包，Emergency Workflow Operator Kit）的智能灾备助手。该系统基于 Amazon Bedrock 构建，允许值班工程师通过自然语言发出指令来启动、监控和验证生产环境的故障切换，同时确保每一次基础设施变更都具备确定性、严格审计以及策略合规性。
在为关键 SRE 运维自动化系统选择底层大模型接口时，许多企业团队除了使用 Amazon Bedrock，还会配合像 n1n.ai 这样的多模型聚合 API 平台，以确保在极端故障场景下具备跨模型冗余路由能力与低延迟的高可用响应。
EWOK 系统架构：连接非确定性 LLM 与确定性基础设施安全
将大语言模型（LLM）引入 SRE 运维的核心挑战在于非确定性（Non-determinism）。生产环境的故障切换要求 100% 的准确与可预测。Intuit 的解题思路是将 LLM 视作高层级的“意图解析与工作流规划器”，而将具体的“策略校验与 API 执行”交由确定性的代码引擎处理。
+-----------------------------------------------------------------------------------+
| 用户交互界面 |
| (Slack / CLI / Web 运维控制台) |
+-----------------------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------------------+
| Amazon Bedrock Agent 智能层 |
| - 意图提取与参数解析 (基于 Claude 3.5 Sonnet) |
| - 自动生成变更计划 (Plan Generation) |
+-----------------------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------------------+
| 确定性策略与安全 Guardrail 层 |
| - OPA (Open Policy Agent) 策略引擎 |
| - IAM / RBAC 权限与角色校验 |
| - 预检查（Pre-flight Health Checks） |
+-----------------------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------------------+
| 自动化工作流执行层 |
| - AWS Step Functions / Lambda / Systems Manager |
| - 跨区域流量切换 (Route 53 / ALB) |
+-----------------------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------------------+
| 可观测性与审计管道 |
| - 不可篡改审计日志 (DynamoDB / CloudWatch) |
| - Slack 实时同步状态播报 |
+-----------------------------------------------------------------------------------+
核心模块分工拆解：
- 自然语言意图解析（Intent Parsing）：依托 Amazon Bedrock 托管的模型（如 Anthropic Claude 3.5 Sonnet），系统解析如 “由于延迟升高，请将 TurboTax 计税服务从 us-east-1 切换至 us-west-2” 的自然语言请求。
- 工具/动作组（Action Groups）：Agent 通过映射标准 OpenAPI 定义，调用对应的 AWS Lambda 代理函数（包含清空连接池、修改 DNS 记录、提升数据库从库为主库等操作）。
- 策略护栏（Policy Guardrails）：在调用任意底层 AWS API 前，系统会自动经过基于 Open Policy Agent（OPA）与 Bedrock Guardrails 的独立校验层。一旦发现违反 RTO（恢复时间目标）或未满足合规策略，系统立即终止动作。
- 人机协同授权（Human-in-the-Loop, HITL）：对于危险性极高的高危变更（如 DNS 流量全量重定向或数据库主从切换），必须由第二位值班负责人（Incident Commander）在 Slack 或管理后台进行二次加密确认。
实战代码演练：构建 Bedrock Action Group 灾备代理
在 Amazon Bedrock 中开发 Agent 时，开发者需要定义结构化的 OpenAPI Schema 供 Agent 理解，并绑定后端 Lambda 处理函数。以下展现了灾备切换 Action Group 的配置与 Python 处理逻辑：
1. 定义 Bedrock Agent 的 OpenAPI Schema
{
"openapi": "3.0.0",
"info": {
"title": "Disaster Recovery Failover API",
"version": "1.0.0"
},
"paths": {
"/failover/execute": {
"post": {
"summary": "Trigger regional service failover",
"description": "Executes traffic shift and database promotion for a target microservice.",
"operationId": "executeFailover",
"requestBody": {
"required": true,
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"service_name": {
"type": "string",
"description": "The identifier of the service, e.g., turbotax-calc"
},
"source_region": {
"type": "string",
"description": "Current primary region, e.g., us-east-1"
},
"target_region": {
"type": "string",
"description": "Destination region for failover, e.g., us-west-2"
},
"reason": {
"type": "string",
"description": "User-provided rationale for initiating failover"
}
},
"required": ["service_name", "source_region", "target_region", "reason"]
}
}
}
},
"responses": {
"200": {
"description": "Failover workflow successfully initiated"
}
}
}
}
}
}
2. 具备安全护栏校验的 Lambda 处理代码 (Python)
import json
import boto3
import os
step_functions = boto3.client('stepfunctions')
STATE_MACHINE_ARN = os.environ.get("DR_STATE_MACHINE_ARN")
ALLOWED_SERVICES = \{"turbotax-calc