HPE Zerto 如何基于 Amazon Bedrock 构建 Agentic 故障排除系统
- 作者
- 姓名
- Nino
- 职业
- Senior Tech Editor
在企业级灾难恢复（Disaster Recovery, DR）领域，系统可用性要求极高。当持续数据保护（CDP）复制中断，或虚拟保护组（VPG）进入错误状态时，存储与基础设施管理员必须在严格的恢复时间目标（RTO）内，迅速对复杂的遥测数据、网络拓扑和存储日志进行诊断。然而，传统基于规则的告警系统往往只能提供表面症状，无法直击问题根源。
为解决这一难题，HPE Zerto 基于 Amazon Bedrock 与 Strands Agents 框架，构建了一套自主的 Agentic（智能代理）故障排除系统。该系统运行在客户敏感的本地环境（On-Premises）中，能够将非结构化的日志流和复杂的系统状态图转化为可执行的修复路径。本文将深入剖析 HPE Zerto 的架构设计、在实时灾备数据中落地大语言模型（LLM）的工程挑战，以及开发者如何通过 n1n.ai 等统一 API 网关构建企业级高可用 AI 系统。
架构痛点：本地灾备环境与生成式 AI 的结合挑战
灾难恢复系统在运行环境上面临极为苛刻的限制，这给标准的云原生 LLM 接入带来了诸多挑战：
- 数据隐私与主权：企业客户严禁将原始系统遥测、IP 地址或虚拟机元数据传输至公有云多租户 AI 节点。
- 状态极其复杂：单个 Zerto Virtual Manager (ZVM) 需要管理数百个并发复制管道。分析特定 VPG 快照失败的原因，需要跨多个 Hypervisor 检查 VSS 写入程序、存储 I/O 队列以及 WAN 延迟指标。
- 确定性执行要求：AI 模型绝对不能基于幻觉触发具有破坏性的操作（例如误启动灾备切换或擦除日志文件）。
为了应对这些挑战，HPE Zerto 选择了本地部署与云端推理结合的 Agentic 架构。系统并没有采用单 Prompt 检索增强生成（Single-Prompt RAG），而是通过 Strands Agents 将任务拆分给多个独立的 Agent 协作完成，底层 LLM 推理则通过安全的 Amazon Bedrock 端点提供。
+-----------------------------------------------------------------------------------+
| 客户本地环境 (On-Premises) |
| |
| +-----------------------+ +-----------------------+ +-------------------+ |
| | HPE Zerto VVM/ZVM | | 遥测数据采集组件 | | Strands Agent | |
| | (复制日志与指标) | | (Log Streams & VPG) | | 协同调度器 | |
| +-----------+-----------+ +-----------+-----------+ +---------+---------+ |
| | | | |
+--------------|----------------------------|----------------------|----------------+
| | |
+----------------------------+ |
HTTPS / PrivateLink
|
v
+---------------------------------+
| Amazon Bedrock / API 网关 |
| (Claude 3.5 Sonnet / Haiku) |
+---------------------------------+
架构详解：多 Agent 协作模式（Supervisor-Worker Pattern）
Zerto 架构的核心在于主控-工作代理模式（Supervisor-Worker Agent Pattern）。与其依赖单一基座模型完成日志解析、根因分析和方案生成，不如将工作流合理拆分：
1. 诊断调度 Agent（Supervisor）
主控 Agent 接收初始故障报告（例如 VPG_BITMAP_SYNC_FAILED）。它维护整体上下文图谱，将诊断流程分解为多个子任务，并决定何时调用哪个工具或子 Agent。
2. 日志与遥测解析 Agent
该工作 Agent 直接与本地 Zerto API 和日志文件交互。它能够过滤干扰噪声，归一化分布式 Zerto 虚拟组件（ZVA）的时间戳，并提取结构化的 JSON 上下文。
3. 知识对齐 Agent (RAG)
知识 Agent 负责查询索引化的知识库，其中包含 Zerto 技术文档、已知问题数据库和排错 Runbook。它能根据解析出的错误参数匹配最恰当的解决方案。
4. 安全与校验 Agent
在提出或执行任何诊断脚本前，该 Agent 会根据系统策略检查预设操作，确保对系统延迟的影响 < 50ms，且不包含破坏性命令。
架构对比：故障排除范式演进
| 特性 | 传统脚本 / 规则告警 | 单 Prompt RAG | HPE Zerto Agentic (Amazon Bedrock) |
|---|---|---|---|
| 上下文适应力 | 僵硬（静态 IF-THEN 逻辑） | 中等（受限于上下文窗口长度） | 极高（多步工具调用与动态调整） |
| 根因诊断准确率 | 低（仅报告表面症状） | 中（容易遗漏深层关联上下文） | 极高（多 Agent 交叉验证闭环） |
| 数据主权保障 | 完全本地（无 AI 能力） | 参差不齐（通常需同步大量数据到云端） | 混合模式（本地逻辑执行，安全云端端点） |
| 执行安全性 | 确定但脆弱 | 低（存在 Prompt 漂移风险） | 高（由确定性安全 Agent 严格把关） |
| 扩展性 | 需要修改硬编码 | 需要不断修改 System Prompt | 模块化添加 Tool 与 Agent |
技术实现：基于 Python 的 Agent 工具调用实践
以下代码示例展示了开发者如何参考 HPE Zerto 的模式，利用 Python 和 Amazon Bedrock 模型构建一个多 Agent 诊断节点。在需要跨多云（如 Amazon Bedrock、OpenAI 与 Anthropic）维持系统高可用时，借助 n1n.ai 统一接入层，可以非常简便地实现多模型容灾与路由调度。
import json
import boto3
from typing import Dict, Any, List
# 初始化 Amazon Bedrock Runtime 客户端
# 技术建议：生产环境中可接入 https://n1n.ai 实现多模型供应商自动容灾
bedrock_client = boto3.client(
service_name="bedrock-runtime