HPE Zerto 如何用 Amazon Bedrock 构建智能体排障系统
HPE Zerto 把排障智能体以 Pod 部署在本地 ZVM 中,只把推理和知识库查询送到 Amazon Bedrock。生产使用中,相关工作流的支持案例减少了 10%。

目录
#HPE Zerto 如何用 Amazon Bedrock 构建智能体排障系统
本文由 AWS 与 HPE Zerto 团队合写。
如果你管理混合云和多云基础设施,你可能已经在借助 AI 系统评估健康状况、调查问题,并更快地处理问题。HPE Zerto 应对这一挑战的方式,是构建一套由 Amazon Bedrock 驱动的智能体排障系统。
HPE Zerto Software 帮助你加强网络韧性、灾难恢复和持续数据保护。你可以用这些能力大幅减少数据丢失和停机,同时支持从勒索软件事件、中断和其他干扰中快速恢复。
本文描述我们在开发由 Amazon Bedrock 驱动的智能体排障系统时所选择的系统架构,以及遇到的挑战。我们把它部署在本地环境中,并对运行信号、环境上下文和产品知识保持受控且安全的访问。
该系统提供自然语言体验,帮助你快速从问题走到可执行的洞察,从而支持更快、更有依据的恢复决策。
业务挑战
数据保护和灾难恢复团队所处的环境,在规模、复杂性和业务关键性上都在增长。他们必须持续监控保护健康状况、校验服务级别协议(service level agreement,SLA)合规、解读告警、调查故障,并为恢复事件做准备。这项工作常常跨越多个站点和大量受保护工作负载。
- 回答运维问题所需的信息,常常分散在产品告警、事件和文档之中,迫使团队在行动之前手工收集上下文。
- 操作人员在仪表盘、报告和知识来源之间来回切换,才能弄清正在发生什么以及下一步做什么,从而损失时间。
- 经验较少的管理员可能难以解读症状,或判断最安全的补救路径。
- 管理者可能缺少对风险、SLA 暴露或恢复就绪程度的清晰摘要的快速访问。
- 在中断或网络事件期间,这些延迟变得更加显著,因为不确定性的代价很高,团队需要清晰、可信的指导,而且要快。
因此,我们的客户需要一种办法,把复杂的韧性数据变成可执行的答案,同时不增加更多运维负担,并且能部署在不同环境中。
方案概览
从根本上说,我们把系统设计为:
- 充当支持助手,帮助你解决配置问题,并在不需要创建支持工单的情况下走短路完成排障。
- 就系统健康问题向你告警,并协助缓解。
- 代表你执行任务,以加快搭建时间和功能采用。
我们把该系统作为 Zerto 产品中的一个 Pod 部署在你的本地环境里,你可以从日常运维已经在用的同一套用户界面(user interface,UI)直接访问。你可以以自然语言交互,系统被设计为能够推理、行动,并给出扎根于你环境实时状态的、有上下文且可执行的回答。
我们选择 Amazon Bedrock,是因为它能够支持安全的企业部署、模型灵活性和运维控制。
关键考虑包括:
- 安全与治理:Amazon Bedrock 支持对基础模型的受控访问,帮助我们把 AI 使用与企业安全、合规和数据保护要求对齐。
- 模型灵活性:该服务使我们可以访问并评估多个基础模型,并按质量、延迟和成本选择最合适的。
- 运维集成:Amazon Bedrock 与用于护栏(guardrails)、可观测性和知识检索的 AWS 服务集成,从而支持更易管理的生产架构。
我们使用 Amazon Bedrock Guardrails 强制执行内容安全,以确保你的提示和系统输出与公司政策、合规和安全要求一致。
下图展示架构的关键组件:
- UI 层:你通过嵌入现有 Zerto UI 的聊天界面与系统交互。使用服务器发送事件(Server-Sent Events,SSE)的实时流式传输会在调查进行时展示进度,从而提供更好的用户体验。
- 智能体层:使用 Strands Agents 框架构建的智能体,作为 Pod 运行在你的本地环境中,并可访问下列内容:
- 会话历史:本地存储的历史聊天对话和上下文。
- 内部工具:本地模型上下文协议(Model Context Protocol,MCP)服务器,暴露智能体可以调用的 ZVM(Zerto Manager)API,以便结构化访问实时环境数据。
- 外部工具:使用 Amazon Bedrock Knowledge Bases 智能获取公开文档、相关运行手册(runbook)和运维知识。这是一种集中式、全托管的检索增强生成(Retrieval Augmented Generation,RAG)能力,带有用于上下文检索的内部语义搜索。
- 智能层:由三个主要组件构成:
- 推理:请求被发送到 Amazon Bedrock,由其路由到所选基础模型。按租户的请求标记,使用每个租户所扮演的 AWS Identity and Access Management(IAM)角色标签完成。
- 安全:在推理之前和之后应用 Amazon Bedrock Guardrails,以强制内容边界,并帮助验证响应仍限定在运维话题之内。
- 限额与配额:把 Amazon CloudWatch、Amazon DynamoDB 和 AWS Lambda 组合起来,强制执行按租户的配额和限额,并维持一个成本可控的系统。
- 可观测性层:从系统发送到 Amazon CloudWatch 的遥测数据,提供对智能体性能、错误率和使用模式的可见性。
图 1:方案架构
下图展示嵌入 Zerto 产品中的智能体系统。
图 2:嵌入 HPE Zerto 管理控制台的智能体系统
智能体流程
该系统由多个子智能体组成,由一个编排智能体控制。编排智能体可以根据手头任务把每个子智能体当作工具来使用。反过来,每个子智能体拥有自己的一套工具和单独的上下文,以处理其子任务。图 3 展示智能体之间的流程和层级。
编排智能体决定何时委派工作。常规问题直接回答,而深入的、日志量大的调查会被路由到限定在相关组件上的专门子智能体。每个子智能体以自己全新的上下文、专用系统提示和自己的工具运行,并对推理负担重的工作使用更强的模型。它的最终响应是一份紧凑、提炼过的报告,不会让原始日志和调查草稿纸污染或膨胀父级上下文。
- 编排智能体:承担两个用途。你可以用它检查保护组状态、查看近期告警,或询问配置最佳实践。当系统中当前存在某个问题时,该智能体在子智能体之间编排排障流程。它在从响应中剥离密钥或原始日志之后,把最终答案转达给你。
- ZVM 智能体:负责排查与 ZVM 相关的问题,例如服务崩溃、网络问题和升级失败。它使用提供领域知识和特定日志模式的专用技能,分析日志,并通过 MCP 补充环境数据。这为手头问题及其可能原因提供彻底分析。
- VRA 智能体:负责排查与 VRA(Zerto Replication Engine,Zerto 复制引擎)相关的问题,例如复制问题和延迟、站点之间的网络以及安装。它同样拥有领域知识技能,为智能体提供结构化日志模式上下文,以便对照日志和通过 MCP 可得的环境数据进行匹配。
图 3:智能体流程
挑战
构建 HPE Zerto 智能体排障系统,需要处理若干关键工程决策,包括模型选择、评估方法,以及本地部署的约束。
模型选择
作为开发过程的一部分,我们比较并随后组合了若干模型用于推理,权衡质量、性能和成本。
我们首先评估更大、更强的模型,用于最初的概念验证(proof of concept,POC),以证明可行性;后来实现了智能体评估机制(见下一节),并比较了其他模型,其中一些更快、更小、更便宜。最终选择了前文所述的多模型架构。随着更新的模型可用,我们会继续评估。
关于按 AWS 区域划分的模型可用性,请参阅 Amazon Bedrock 中的《按 AWS 区域划分的受支持模型》(Supported models by AWS Region)。
智能体评估
我们使用 PyTest 和 Strands Agents Evals SDK,在持续升级系统的过程中系统地、持续地评估智能体。我们还创建了作业来运行完整评估套件,以查看智能体行为中的回归和改进。
创建了三类评估:
- 基本查询评估:单轮查询—响应评估。智能体被给予一条查询作为测试,然后评估响应。
- 多轮评估:完整对话评估。智能体被给予一条初始查询作为测试,智能体作出响应,一个用户模拟器大语言模型(large language model,LLM)扮演真实用户。这一技术使用 Strands Agents ActorSimulators。完整对话在结束时被评估。
- 动态测试评估:为了评估尚未覆盖的动态用例,我们使用 Strands Agents Experiment Generator 创建了一套完全动态的测试套件,它会基于特定标准创建一套唯一的测试。对每个测试有四个评估器:
- 响应评估器:基于特定的预定义标准评估智能体响应,并使用可以解析以提取相关数据的结构化输出。
- 轨迹评估器:基于特定的预定义标准评估智能体的工具选择。该评估器也使用结构化输出。
- 延迟评估器:评估智能体延迟,并检查它是否处于所定义的阈值之内。
- 令牌评估器:评估智能体的令牌用量,并检查它是否保持在边界之内。
“Strands Agents 消除了构建 AI 智能体的复杂工作——没有僵硬的工作流定义,没有样板式的工具串联代码,只需要一个模型、一条提示,以及你需要的工具。借助内置的评估和可观测性,我的团队构建、测试和迭代智能体的速度,比我们试过的任何框架都快。它覆盖完整的开发生命周期,因此我们可以专注于解决真实问题,而不是编写胶水代码。”
—— Shahak Gabay,HPE Zerto 高级软件工程师
本地部署模型
围绕我们的智能体排障系统部署的一项约束是:它必须运行在你自己的环境内部。灾难恢复(disaster recovery,DR)基础设施常常是气隙隔离的、对延迟敏感的,或受严格数据驻留要求约束。我们使用 Strands Agents SDK 实现智能体运行时,它完全在 ZVM 设备内部的本地运行。只有模型推理请求和知识库查询通过 HTTPS 出去到 AWS。
业务结果
借助 HPE Zerto 智能体系统,你可以在加强恢复就绪程度的同时提高运维效率。通过把响应扎根于实时环境数据和可信的产品文档,该系统帮助你回答运维问题、调查问题、识别可能的根因,并排列需要行动的风险的优先级。
自 2026 年第二季度发布以来,已有超过 20% 的 HPE Zerto 客户采用并在积极使用该智能体系统。这显示出对 AI 辅助灾难恢复运维的强需求。在生产使用中,我们观察到由该智能体系统支持的工作流,其支持案例减少了 10%。你现在可以通过引导式自助,在产品内部直接调查并解决更多常见运维问题。
影响不止于支持案例的减少。通过减少重复的数据收集和手工调查,该系统帮助加快你的排障和根因识别,同时提高管理员生产率。你可以更快地生成运维摘要,更早识别 SLA 和保护风险,并在日常运维和事件响应中都作出更有依据的决策。
随着采用继续增长,这些能力可以帮助你减少运维摩擦、改善恢复就绪程度,并更有效地扩展灾难恢复运维,而不需要同比例增加专门技能。
在内部,我们的工程师已经开始使用该智能体系统的排障能力来调查并解决常见运维问题。此外,我们的质量保证(quality assurance,QA)自动化团队已把该智能体系统集成进他们的工作流,现在能更快、更准确地调查并解决测试中发现的问题。
经验
构建和部署这一方案浮现出若干洞察,塑造了我们对待智能体架构的方式。这些洞察集中在本地约束、智能体分解和实时用户反馈上。
- 本地部署从根本上改变架构。 把传出客户环境的数据减到最少,并防止敏感客户信息被发送出去,这一要求塑造了每一项架构决策——从我们选择 Strands Agents SDK 做本地编排,到为本地数据访问而设计的 MCP 服务器。
- MCP 服务器是把智能体扎根于实时运维数据的有效模式。 把现有产品 API 包进 MCP 服务器,给智能体提供对实时环境数据的结构化、带类型的访问,并显著加快了我们的智能体开发。
- 多智能体分解提高复杂任务的可靠性。 把工作流拆成多个专门智能体,每个都有边界清楚的职责,使每个组件可以独立测试,也使整个系统更容易调试。我们把子智能体接成轮毂—辐条拓扑。每一次委派都流经父级;发现问题属于别处的子智能体向父级报告,而不是直接调用对等方。这一设计为安全规则和最终答案保留单一控制点,并使流程保持线性,便于在遥测中追踪。它也有助于防止失控的智能体对智能体递归耗尽令牌预算。结果是在复杂问题上得到更好的答案,同时不牺牲日常聊天的速度和可预测性。
- 流式传输关系到用户信任。 通过 SSE 实时展示调查进度,显著改善了用户体验。用户看到每一步正在发生,而不是在没有可见性的情况下等待。
结论
HPE Zerto Software 把可信的韧性专业知识、运维数据和 AI 驱动的协助,与 Amazon Bedrock 生成式 AI 服务结合在一起,帮助你更有信心地保护、恢复和运营。通过把智能指导嵌入日常保护和恢复工作流,我们帮助你把复杂的韧性信号变成清晰、可执行的洞察,从而支持更快的决策和更强的 SLA 就绪程度。
借助 HPE Zerto,你可以超越时间点式的恢复就绪,建立一种更智能、更有韧性的持续业务保护方式。
PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/how-hpe-zerto-built-an-agentic-troubleshooting-system-with-amazon-bedrock
- #案例拆解
- #灾难恢复
- #Bedrock
- #本地部署
- #智能体评估


