HPE Zerto 在 Amazon Bedrock 上打造內部部署的代理式故障排除系統

HPE Zerto 已打造出一套代理式故障排除系統，該系統在客戶的內部部署環境中運作，同時使用 Amazon Bedrock 來驅動其推理層。這套系統把自然語言介面與即時災難復原資料、產品文件以及營運工具連接起來，目標是在不必手動在儀表板與支援資料之間切換的情況下，協助韌性團隊排查問題。

這個架構在 AWS Machine Learning Blog 的文章中有詳細說明，也反映了企業級 AI 的一項實務限制：模型服務可以在雲端，但敏感的營運脈絡與工具執行需要盡可能靠近客戶基礎設施。HPE Zerto 表示，其系統以 pod 形式部署在 Zerto 產品內，並透過既有的營運介面進行存取。

對 AI 開發者與企業技術團隊而言，重點與其說是一個新的聊天機器人，不如說是 HPE Zerto 圍繞它所劃出的邊界。代理可以根據目前環境狀態進行推理並擷取相關知識，但其存取會透過本機 API、檢索系統與安全控制來中介。這種設計旨在讓 AI 助手在停機與設定問題期間發揮作用，同時避免把通用模型變成不受限制的操作員。

連接即時復原資料的多代理層

根據 AWS Machine Learning Blog，這套系統使用以 Strands Agents 建構的代理。這些代理以內部部署的 pod 執行，並可利用三個主要資訊來源：本機儲存的對話歷史、內部工具，以及外部知識檢索。

內部工具路徑是透過本機的 Model Context Protocol 伺服器公開。該伺服器可結構化存取 Zerto Manager APIs，讓代理能檢視客戶環境中的即時資訊，而不只是依賴靜態文件或使用者對事件的描述。

外部路徑則使用 Amazon Bedrock Knowledge Bases 來擷取公開文件、runbooks 以及其他營運資料。這種組合很重要，因為災難復原系統的故障排除通常同時需要目前狀態與程序脈絡。警示可以顯示哪裡發生故障，而 runbook 或產品指南則說明安全的檢查或修正順序。

介面整合在既有的 Zerto 使用體驗中。HPE Zerto 表示，它使用 Server-Sent Events 將調查進度串流給使用者，讓中間活動可見，而不是等待單一最終回覆。其列出的使用案例包括回答設定問題、協助緩解健康問題、協助設定與功能採用，以及摘要風險、服務等級協議曝險或復原準備狀態。

這並不表示模型能獨立控制整個復原環境。來源描述的是一個設計為透過可用工具進行推理、行動與回應的系統。因此，部署的實際安全性取決於圍繞這些工具所實作的權限、驗證邏輯與行動邊界——AWS 文章在架構層面有討論，但並未完全量化為生產績效報告。

為什麼內部部署模式很重要

HPE Zerto 的目標使用者負責在混合雲或多雲環境中管理網路韌性、持續資料保護與災難復原。在這類環境中，營運資料可能包括受保護工作負載的健康狀態、複寫狀態、警示、事件、站點關係以及復原準備狀況。該公司所描述的挑戰是，這些資訊分散在不同介面與文件中，因而在停機或網路事件期間拖慢決策速度。

把代理層放在客戶環境內執行，能解決其中一部分問題。助理可以部署在它需要檢查的系統旁邊，而工作階段歷史則在本機保存，產品仍可透過熟悉的管理 UI 存取。對企業而言，這可能簡化部署，並減少把營運脈絡移到另一個外部應用程式的需求。

模型層仍然依賴 Amazon Bedrock。AWS 表示，HPE Zerto 選擇該服務，是因為它能受控地存取 foundation models、可以評估不同模型，並能與 guardrails、可觀測性與檢索服務整合。HPE Zerto 也使用 Amazon Bedrock Guardrails，將政策、合規與安全控制套用到提示詞與生成輸出。

這種混合式配置說明了一種對企業 AI 越來越重要的部署模式：讓資料存取與執行靠近記錄系統，同時使用受管理的模型平台進行推論與模型選擇。它可以提供彈性，但也在本機產品、連往模型服務的網路路徑、檢索品質，以及分配給每個代理的權限之間建立依賴關係。

證據與主張仍來自供應商報導

目前可得的證據是一篇圍繞 HPE Zerto 架構撰寫的 AWS Machine Learning Blog 案例研究。它確認了所描述的元件與部署方式，但沒有提供對故障排除準確度、回應延遲、客戶採用率、支援工單量下降，或復原時間可量化改善的獨立驗證。

因此，有關更快、更有資訊基礎的復原決策以及降低營運負擔的說法，應視為系統預期成果，而非經獨立驗證的結果。來源也未說明生產環境中使用哪些 foundation models、模型路由如何管理，或代理有多頻繁被允許直接採取行動，而不是只回傳建議給操作員。

另一篇關於 Intuit EWOK Agent 的 AWS Machine Learning Blog 文章提供了相關參考點，但不是針對 HPE Zerto 的額外證據。Intuit 描述了一個把口語化 failover 請求轉換成經驗證工作流程的代理，而確定性的執行系統則負責基礎設施變更。Intuit 表示，團隊已使用該系統八個月，並報告支援的復原工作流程可在約 20 分鐘內完成，但那是 Intuit 對其另一個平台的自述。

這兩個案例共享一項更廣泛的設計原則：讓 AI 模型解讀意圖並從受限能力中選擇，而由確定性系統執行政策與高影響操作。這種模式比任何特定基準更具可移植性，但組織仍應以自身的資料品質、失敗模式與變更控管需求來進行測試。

對開發者與企業買家的啟示

對開發者而言，HPE Zerto 的做法凸顯了 grounding 是一個整合問題，而不是單純的提示詞撰寫練習。代理需要可靠地存取目前產品狀態、明確定義的工具規格、相關文件，以及足夠的工作階段脈絡，以避免反覆詢問對話中已可取得的資訊。本機 MCP 伺服器可以提供結構化介面，但也會成為驗證、授權、記錄與 API 相容性的關鍵控制點。

對企業買家來說，關鍵評估問題在於營運面。系統能否區分過時警示與目前狀況？它會引用或揭露建議的來源嗎？管理員能否依角色與環境限制工具？當模型不可用、檢索結果不完整，或要求的修復可能提高資料遺失風險時會發生什麼事？AWS 文章建立了架構，但沒有回答所有採購與治理問題。

這套系統的價值，可能在資訊密度高、操作人員經驗不一的團隊中最為顯著。自然語言層可以減少蒐集脈絡與解釋症狀所需的時間，特別是對經驗較少的管理員而言。但在災難復原中，有用的解釋不等於安全的執行。從診斷到修復的任何轉換，都需要明確權限、確認步驟、稽核軌跡，以及能可靠回退到人工操作員的機制。

下一步值得觀察什麼

接下來真正有意義的訊號，將是超越架構描述的部署證據。HPE Zerto 可能會說明這個助理是否已正式一般 उपलब्ध、哪些產品版本與環境支援它，以及客戶是否能設定模型選擇或工具權限。

開發者也應關注是否有公開的量化指標，涵蓋回覆準確度、檢索品質、錯誤建議、事故調查節省時間，以及使用者接受或拒絕建議行動的比例。這些指標能顯示系統是否真的改善營運工作，而不只是加入一個對話介面。

在平台面，模型彈性仍將是重要考驗。HPE Zerto 表示，Amazon Bedrock 可根據品質、延遲與成本來評估 foundation models。若能看到真實世界比較、部署指引，以及有關資料駐留與網路故障行為更清楚的細節，將有助於企業判斷這種彈性是否帶來實際優勢。

Creati.ai 觀點

HPE Zerto 的系統是企業代理式 AI 正在變得具體的有用例子：它位於既有的營運產品內，連接即時狀態，並受限於既有管理該環境的 API 與控制機制。這個設計最強的部分，是把對話式推理層與產品底層的營運介面分離開來。

更困難的問題是證明。在災難復原中，評價代理不該只看它能否解釋警示，還要看它的指引是否即時、可稽核，並能在壓力下安全執行。除非 HPE Zerto 或其客戶公布成果資料，否則這項公告最好被理解為一種可信的部署模式與值得評估的架構——還不是代理已經解決復原作業的證據。