HPE Zerto Agentic Troubleshooting bringt Cloud-AI in die lokale Wiederherstellung
HPE Zerto hat ein agentisches Troubleshooting-System mit drei Agentenrollen veröffentlicht. Seine wichtigste Eigenschaft ist jedoch der Ort, an dem diese Agenten arbeiten. Die Laufzeitumgebung von HPE Zerto agentic troubleshooting befindet sich innerhalb der Umgebung jedes Kunden. Sie untersucht laufende Disaster-Recovery-Signale lokal und sendet ausgewählte Inferenz- und Wissensanfragen an Amazon Web Services.
Diese Aufteilung stellt die Annahme infrage, dass nützliche Enterprise-Agenten Betriebsdaten in eine zentralisierte Cloud-Anwendung übertragen müssen. HPE Zerto hat die Orchestrierung stattdessen neben der Infrastruktur platziert, die untersucht wird. Amazon Bedrock stellt Modellzugriff, Wissensabruf, Guardrails und unterstützende Kontrollen bereit, ohne zum Zuhause des vollständigen Troubleshooting-Workflows zu werden.
Das System ging im zweiten Quartal 2026 in Produktion. HPE und AWS geben an, dass es anschließend von mehr als 20 Prozent der Zerto-Kunden übernommen wurde. Sie berichten zudem von einem Rückgang der Supportfälle um 10 Prozent in den vom System abgedeckten Workflows. Diese Zahlen stammen von den Unternehmen und wurden nicht unabhängig validiert.
Das architektonische Ergebnis ist über ein einzelnes Recovery-Produkt hinaus relevant. Disaster-Recovery-Umgebungen vereinen sensible Logs, sich verändernde Konfigurationen, strikte Zugriffskontrollen und hohen Zeitdruck. Ein Assistent, der die aktuellen Bedingungen nicht sehen kann, bietet nur allgemeine Ratschläge. Ein Agent mit uneingeschränktem Zugriff schafft ein anderes operatives Risiko.
HPE Zerto versucht, den schmalen Raum zwischen diesen Ergebnissen einzunehmen. Seine Agenten erhalten strukturierten Zugriff auf lokale Informationen, teilen Untersuchungen nach technischen Domänen auf und liefern über einen steuernden Orchestrator eine verdichtete Antwort zurück. Die zentrale Frage lautet, ob diese Architektur Kontext, Sicherheit und vorhersehbares Verhalten bewahren kann, wenn reale Umgebungen komplexer werden.
HPE Zerto Agentic Troubleshooting beginnt in der Kundenumgebung
Die entscheidende Veränderung ist nicht die Chat-Oberfläche. Sie liegt in der Platzierung der Agentenlaufzeit neben den Systemen und Belegen, die sie untersuchen muss.
HPE Zerto Software unterstützt Disaster Recovery, kontinuierlichen Datenschutz und Cyberresilienz über hybride und Multi-Cloud-Infrastrukturen hinweg. Betreiber nutzen das Produkt, um geschützte Workloads, Wiederherstellungsbereitschaft, Replikationszustand und die Gefährdung durch Service-Level-Agreements zu überwachen.
Das Troubleshooting dieser Umgebung erfordert traditionell Informationen aus mehreren Quellen. Ein Administrator könnte einen Alarm prüfen, ein Komponentenlog untersuchen, Konfigurationsdaten einsehen, Produktdokumentation durchsuchen und die Ergebnisse mit einem Runbook vergleichen. Während eines Ausfalls verursacht jeder Wechsel zwischen diesen Quellen Verzögerungen und erhöht die Wahrscheinlichkeit, relevante Belege zu übersehen.
Das neue System integriert eine Chat-Erfahrung in die bestehende Zerto-Verwaltungsoberfläche. Betreiber können nach dem Status von Protection Groups, aktuellen Warnungen, Konfigurationspraktiken, Replikationsverzögerungen, Upgrade-Fehlern oder aktiven Systemproblemen fragen. Der Assistent kann zudem Zustandsprobleme hervorheben und bei Gegenmaßnahmen unterstützen.
Laut dem gemeinsamen Architekturbericht stellt HPE die agentische Schicht als Pod innerhalb der On-Premises-Umgebung des Kunden bereit. Ein Pod ist eine bereitstellbare Gruppe von Containern, die als eine Anwendungseinheit ausgeführt wird. In diesem Design enthält er die lokale Agentenlaufzeit.
Die Laufzeit nutzt Strands Agents, ein von AWS entwickeltes Open-Source-Framework zum Aufbau modellgesteuerter Agenten. Der Sitzungsverlauf bleibt lokal gespeichert, und die Agenten greifen über einen lokalen Model Context Protocol Server auf aktuelle Zerto-Informationen zu.
Model Context Protocol, kurz MCP, definiert einen Standardweg, über den eine AI-Anwendung Tools aufrufen und Kontextdaten beziehen kann. HPE hat bestehende Zerto Manager APIs in einen MCP-Server eingebunden und den Agenten damit strukturierten Zugriff auf aktuelle Umgebungsinformationen gegeben.
Das unterscheidet sich wesentlich davon, jedes Log und jeden Konfigurationsdatensatz in einen entfernten Chatbot zu kopieren. Die Zerto-Agenten können die lokalen Fakten anfordern, die für eine Untersuchung erforderlich sind, während die Laufzeit innerhalb der Appliance bleibt. HPE sagt, dass lediglich Modellinferenzanfragen und Abfragen an Amazon Bedrock Knowledge Bases das lokale Netzwerk über HTTPS verlassen.
Diese Unterscheidung erfordert eine sorgfältige Formulierung. Das System ist weder vollständig von der Cloud getrennt noch eine Offline-Modellbereitstellung. Amazon Bedrock verarbeitet weiterhin Modellanfragen, während sein verwalteter Wissensdienst relevante Produktinformationen abruft. Das lokale Design steuert Orchestrierung und operativen Zugriff, statt externe Verarbeitung vollständig auszuschließen.
Diese Grenze schafft die zentrale Spannung des Artikels. Ein lokal betriebener Agent kann nahe an sensiblen Belegen bleiben, doch seine Schlussfolgerungen hängen weiterhin von entfernten Modelldiensten und sorgfältig gestalteten ausgehenden Anfragen ab. Der Nutzen des Systems hängt daher davon ab, welcher Kontext diese Grenze überschreitet, wie er gefiltert wird und ob die zurückgegebene Anleitung fundiert bleibt.
Die Veröffentlichung verlagert AI-Unterstützung zudem tiefer in den Recovery-Workflow. Sie beschränkt sich nicht mehr auf das Erläutern von Dokumentation. Das System kann aktuelle Bedingungen untersuchen und eine problemspezifische Untersuchung zusammenstellen, was sowohl seinen operativen Wert als auch die Kosten einer falschen Schlussfolgerung erhöht.
Ein Hub-and-Spoke-Design behält einen Agenten unter Kontrolle
HPE Zerto hat das Troubleshooting auf spezialisierte Agenten verteilt, behält jedoch einen einzelnen Orchestrator als Kontrollpunkt für Delegierung und finale Antworten.
Die Architektur nutzt einen Orchestrator-Agenten und mindestens zwei spezialisierte Sub-Agenten. Der Orchestrator bearbeitet Routinefragen direkt und delegiert tiefergehende Untersuchungen, wenn ein Problem spezialisierte Analyse erfordert.
Ein Sub-Agent konzentriert sich auf Zerto Manager, auch ZVM genannt. Er untersucht Bereiche wie Service-Abstürze, Netzwerkprobleme und Upgrade-Fehler. Seine Tools bieten Zugriff auf relevante Umgebungsdaten, während Domänenfähigkeiten technisches Wissen und erkennbare Log-Muster identifizieren.
Ein weiterer Sub-Agent konzentriert sich auf die Zerto Replication Engine oder VRA. Er bearbeitet Replikationsprobleme, standortübergreifende Netzwerke, Installationsfehler und Verzögerungen. Er erhält eigene Tools, Anweisungen, Domänenwissen und Arbeitskontext.
Diese Aufteilung spiegelt eine wichtige technische Entscheidung wider. Einem allgemeinen Agenten jedes Log, Tool, jede Anweisung und jedes Gesprächsdetail zu geben, kann zu einem übergroßen Kontext mit konkurrierenden Signalen führen. Außerdem lassen sich Fehler schwer isolieren, weil dieselbe Komponente Routing, Analyse und Antwortgenerierung übernimmt.
HPE setzt stattdessen auf eine Hub-and-Spoke-Struktur. Der Orchestrator befindet sich im Hub, spezialisierte Agenten arbeiten als Speichen. Sub-Agenten berichten an den übergeordneten Agenten zurück, statt einander direkt aufzurufen.
AWS beschreibt dieses Multi-Agent-Muster als agents-as-tools, bei dem ein koordinierender Agent Spezialisten über begrenzte Schnittstellen aufruft. Jeder Spezialist kann einen separaten Prompt, Kontext, ein Modell und einen Tool-Satz verwenden.
Für Zerto bietet diese Trennung drei praktische Vorteile. Erstens füllt eine logintensive Untersuchung den Kontext des Orchestrators nicht mit rohem Diagnosematerial. Der Spezialist liefert einen kürzeren Bericht mit seinen Erkenntnissen zurück, statt seinen vollständigen Arbeitsprozess.
Zweitens wird jeder Agent unabhängig testbar. Entwickler können prüfen, ob der VRA-Spezialist die richtigen Tools auswählt, ohne dass jeder Test nicht zusammenhängendes ZVM-Verhalten durchlaufen muss. Diese Trennung kann Regressionen leichter auffindbar machen.
Drittens bleibt der Orchestrator für die finale Antwort verantwortlich. HPE gibt an, Geheimnisse und rohe Logs zu entfernen, bevor Ergebnisse dem Nutzer präsentiert werden. Ein einziger Ausgabepfad gibt dem Produkt außerdem einen Ort, an dem Antwortregeln angewendet werden können.
Die Hub-and-Spoke-Struktur beschränkt laterale Autonomie. Wenn ein Spezialist feststellt, dass eine andere Komponente für das Problem zuständig ist, gibt er diese Beobachtung an den Orchestrator zurück. Er ruft keinen anderen Agenten eigenständig auf.
Diese Einschränkung reduziert die Wahrscheinlichkeit, dass rekursive Agentengespräche Tokens verbrauchen, ohne zu einer Entscheidung zu gelangen. Sie schafft außerdem eine nachvollziehbare Abfolge für die Beobachtbarkeit. Jede Delegierung beginnt und endet am selben Kontrollpunkt.
Der Kompromiss besteht in möglicher Reibung beim Routing. Der Orchestrator muss korrekt erkennen, wann eine Frage Spezialisierung benötigt, und den passenden Agenten auswählen. Ein Spezialist muss seine Erkenntnisse zudem verdichten, ohne für die endgültige Diagnose wesentliche Belege zu entfernen.
HPE verwendet für diese Aufgaben unterschiedliche Modellprofile. Routinearbeit kann beim Orchestrator verbleiben, während untersuchungsintensive Analysen ein leistungsfähigeres Modell einsetzen können. Das Unternehmen sagt, es habe zunächst größere Modelle bewertet, um die Machbarkeit festzustellen, und anschließend Alternativen hinsichtlich Antwortqualität, Latenz und Kosten verglichen.
Dieser Multi-Modell-Ansatz vermeidet es, jede Anfrage als gleich schwierige Aufgabe zu behandeln. Die Prüfung des Status einer Protection Group benötigt nicht dasselbe Schlussfolgerungsbudget wie die Interpretation einer längeren Fehlersequenz über Logs und Netzwerkzustand hinweg.
Er verlagert die Modellauswahl außerdem von einer einmaligen Beschaffungsentscheidung in einen fortlaufenden Engineering-Prozess. Wenn sich Foundation Models verändern, kann HPE neu bewerten, welches Modell zu jedem Agenten passt, ohne das gesamte Produkt um einen anbieterspezifischen Workflow neu aufzubauen.
Live-Recovery-Daten sind Vorteil und Risiko
Das System wird nützlich, wenn es aktuelle Infrastruktur abfragen kann, doch genau dieser Zugriff macht Fundierung, Berechtigungen und Tool-Auswahl entscheidend.
Ein Troubleshooting-Agent benötigt mehr als Produkthandbücher. Dokumentation kann erklären, was eine Warnung bedeutet, aber sie kann nicht aufzeigen, ob eine bestimmte Replication Engine verzögert ist, welche Netzwerkroute ausfällt oder ob eine kürzliche Konfigurationsänderung die Wiederherstellungsbereitschaft beeinflusst hat.
HPE verbindet seine Agenten über einen lokalen MCP-Server mit operativen Live-Daten. Der Server stellt ausgewählte Zerto Manager APIs als strukturierte Tools bereit. Statt ein Sprachmodell zu bitten, einen Rohdaten-Dump zu interpretieren, kann der Agent eine definierte Operation aufrufen und ein typisiertes Ergebnis erhalten.
Die öffentliche MCP-Spezifikation trennt Tools, Ressourcen und Prompts über eine vereinbarte Client-Server-Schnittstelle. Für Enterprise-Software kann diese Struktur eine bestehende Produkt-API in eine für Agenten zugängliche Schicht verwandeln, ohne die zugrunde liegenden operativen Dienste neu zu schreiben.
Typisierter Zugriff hilft, garantiert jedoch keine korrekte Diagnose. Der Agent muss weiterhin das passende Tool auswählen, gültige Parameter angeben, die zurückgegebenen Informationen interpretieren und sie mit relevanter Dokumentation verknüpfen.
HPE kombiniert lokale Tools mit Amazon Bedrock Knowledge Bases. Retrieval-augmented generation, kurz RAG, ruft relevantes Quellmaterial ab, bevor das Modell eine Antwort erstellt. Ziel ist es, Empfehlungen in freigegebener Produktdokumentation und Runbooks zu verankern, statt sich allein auf den Modellspeicher zu stützen.
Der Knowledge-Base-Service von Amazon verwaltet den Dokumentenabruf und kann für eine Anfrage relevantes Quellmaterial zurückgeben. Im Zerto-Design ergänzt dieses externe Wissen den über MCP gewonnenen lokalen Umgebungszustand.
Die Unterscheidung zwischen diesen Quellen ist wichtig. Produktdokumentation beschreibt erwartetes Verhalten. Lokale APIs beschreiben den aktuellen Zustand des Kunden. Zuverlässiges Troubleshooting erfordert, dass der Agent beides vergleicht, ohne eine allgemeine Vorgehensweise mit Belegen zum aktiven Vorfall zu verwechseln.
Betrachten wir eine Frage zu Replikationsverzögerungen. Die Dokumentation könnte Bandbreitenbeschränkungen, Netzunterbrechungen, Workload-Änderungen oder den Zustand der Appliance als mögliche Ursachen aufführen. Die lokalen Tools müssen ermitteln, welche Bedingungen in der Umgebung des Kunden tatsächlich vorliegen. Eine hilfreiche Antwort sollte die Möglichkeiten eingrenzen, statt die gesamte Liste zu wiederholen.
HPE zufolge nutzen die spezialisierten Agents außerdem Domänen-Skills, die bekannte Log-Muster enthalten. Diese Skills geben dem Modell strukturierte Orientierung, um Signale zu erkennen, die mit bestimmten Komponenten und Fehlern verbunden sind.
Das System muss anschließend die Herkunft der Informationen intern bewahren. Ingenieure sollten zwischen einer durch Live-Daten gestützten Erkenntnis und einer vom Modell abgeleiteten Hypothese unterscheiden können. Die veröffentlichte AWS-Darstellung beschreibt Telemetrie, Evaluierungen und strukturierte Ausgaben, legt jedoch nicht das vollständige Zitierverhalten offen, das Administratoren angezeigt wird.
Auch die Zugriffskontrolle stellt einen weiteren kritischen Punkt dar. Ein breit angelegtes MCP-Tool kann mehr Betriebsinformationen offenlegen, als eine Frage erfordert. Ein eng gefasstes Tool reduziert die Offenlegung, könnte jedoch für die Diagnose notwendige Zusammenhänge auslassen. Die Gestaltung der Tool-Grenze wird damit zu einer Sicherheits- und Produktentscheidung, nicht nur zu einer Integrationsaufgabe.
Die Kennzeichnung von Anfragen pro Mandant fügt eine weitere Kontrollinstanz hinzu. Die Architektur verwendet mit jedem Mandanten verknüpfte AWS Identity and Access Management-Rollen-Tags. CloudWatch, DynamoDB und Lambda unterstützen die Nutzungsüberwachung und die Durchsetzung von Mandantenlimits.
Amazon Bedrock Guardrails prüft Prompts und Ausgaben rund um die Modellausführung. Laut AWS-Dokumentation können seine Guardrail-Kontrollen ausgewählte Inhalte filtern, Prompt-Angriffe erkennen, untersagte Themen einschränken und sensible Informationen maskieren.
Diese Filter verringern spezifische Risiken, können jedoch nicht jede operative Schlussfolgerung verifizieren. Eine Antwort kann innerhalb eines zulässigen Themenbereichs bleiben und dennoch die falsche Behebung empfehlen. Guardrails regeln Inhaltsgrenzen, während Evaluierung und Produktlogik die technische Korrektheit sicherstellen müssen.
Deshalb sollte HPEs lokale Architektur nicht als bloßes Datenschutzversprechen verstanden werden. Die lokale Orchestrierung reduziert zentralisierte Datensammlung und hält die Tool-Ausführung nah an der Umgebung. Sie beseitigt jedoch nicht den Bedarf an Kontrollen für ausgehende Daten, Autorisierungsdesign, Tests von Modellrisiken oder menschlichem Urteilsvermögen bei Vorfällen mit hoher Auswirkung.
HPE Zerto testete Antworten, Tool-Pfade, Latenz und Tokens
HPE behandelte die Evaluierung als operatives System und nicht als einzelnen Genauigkeitstest vor der Veröffentlichung.
Die Evaluierung von Agents ist schwierig, weil die endgültige Antwort nur ein beobachtbares Ergebnis ist. Ein Agent kann eine plausibel wirkende Antwort erzeugen, nachdem er das falsche Tool ausgewählt, irrelevante Belege verwendet oder einen übermäßig kostspieligen Pfad eingeschlagen hat. Dieses Verhalten könnte unter leicht veränderten Bedingungen scheitern.
HPE entwickelte seine Tests mit PyTest und dem Software Development Kit zur Evaluierung von Strands Agents. Das Unternehmen erstellte Jobs, die bei Änderungen an Agents, Modellen und Prompts wiederholt eine umfassendere Testsuite ausführen.
Die erste Testkategorie deckt grundlegende Anfragen ab. Jeder Test liefert eine einzelne Anfrage und bewertet die Antwort. Dieser Ansatz eignet sich für stabile Fragen mit einem klar erwarteten Ergebnis oder definierten Bewertungskriterien.
Die zweite Kategorie bewertet mehrteilige Gespräche. Ein Nutzersimulator-Modell interagiert nach der ursprünglichen Anfrage mit dem Agent, und das vollständige Gespräch wird bewertet. Dieses Format prüft, ob das System fehlende Informationen anfordert und den Kontext über mehrere Interaktionen hinweg beibehält.
Die dritte Kategorie erzeugt dynamische Tests. Der Strands-Experimentgenerator erstellt Fälle anhand ausgewählter Kriterien und gibt HPE damit eine Möglichkeit, Szenarien zu erkunden, die nicht in einem festen Testsatz vertreten sind. Dynamische Generierung erweitert die Abdeckung, auch wenn generierte Tests weiterhin aussagekräftige Kriterien und Überprüfung benötigen.
Jeder Test kann vier Evaluatoren anwenden. Ein Antwort-Evaluator bewertet die Antwort anhand vorab definierter Anforderungen. Ein Trajektorien-Evaluator untersucht, ob der Agent geeignete Tools ausgewählt und einen akzeptablen Pfad verfolgt hat.
Ein Latenz-Evaluator prüft die Abschlusszeit anhand eines Schwellenwerts. Ein Token-Evaluator überprüft, ob die Nutzung innerhalb definierter Grenzen bleibt. Zusammen spiegeln diese Messgrößen den Produktionskonflikt zwischen Diagnosequalität, Antwortzeit und Inferenzverbrauch wider.
Die Trajektorien-Evaluierung ist für einen operativen Agent besonders wichtig. Die endgültige Formulierung kann korrekt wirken, selbst wenn das System über eine unsichere oder unzuverlässige Abfolge dorthin gelangt ist. Die Prüfung des Pfads kann aufdecken, dass ein Agent eine Live-Verifizierung übersprungen, eine nicht zugehörige API aufgerufen oder sich auf Dokumentation gestützt hat, obwohl aktuelle Daten verfügbar waren.
Die Evaluierungssuite unterstützt außerdem das Multi-Modell-Design. HPE kann ein kleineres Modell anhand derselben Kriterien für Antwort, Trajektorie, Latenz und Tokens mit einem größeren vergleichen. Dadurch wird ein Modellwechsel zu einer empirischen Entscheidung statt zu der allgemeinen Annahme, dass ein größeres Modell stets besser abschneidet.
Das System überträgt den Fortschritt der Untersuchung über Server-Sent Events an die Oberfläche. SSE ist ein Webmechanismus, mit dem ein Server über eine Verbindung kontinuierlich Aktualisierungen an einen Browser senden kann. Nutzer können den Fortschritt sehen, während ein Spezialist ein Problem untersucht.
HPE zufolge verbesserte Streaming die Nutzererfahrung, weil Operatoren nicht länger ohne Rückmeldung warten. Bei der Notfallwiederherstellung hilft sichtbarer Fortschritt außerdem dabei, zwischen einer fortlaufenden Untersuchung und einer eingefrorenen Oberfläche zu unterscheiden.
Gestreamte Aktivität kann jedoch falsches Vertrauen schaffen, wenn sie Schritte anzeigt, ohne deren Beweiswert zu erklären. Eine Liste von Tool-Aufrufen ist nicht dasselbe wie eine verifizierte Diagnose. Die Oberfläche muss ausreichend Fortschritt vermitteln, um Vertrauen aufzubauen, ohne internes Denken in bloßes Theater zu verwandeln.
Dieselbe Vorsicht gilt für HPEs Behauptungen zur Akzeptanz. Das Unternehmen berichtet, dass mehr als 20 Prozent der Kunden das System aktiv nutzen und die Zahl anwendbarer Supportfälle um 10 Prozent sank. Diese Ergebnisse deuten auf tatsächliche Produktnutzung hin, doch der öffentliche Beitrag definiert weder aktive Nutzung noch Messzeitraum oder die abgedeckte Workflow-Population.
Ein Rückgang von Supportfällen kann zudem mehrere Ursachen haben. Der Agent könnte Probleme erfolgreich lösen, Nutzer auf bestehende Dokumentation verweisen, die Klassifizierung von Fällen verändern oder manche Eskalationen abschrecken. Unabhängige Daten zu Lösungsquoten und Ergebnissen würden ein klareres Bild liefern.
Für Engineering-Teams, die ein ähnliches Design erwägen, lautet die Erkenntnis nicht, dass vier Evaluatoren die Zuverlässigkeit abschließend klären. Die Erkenntnis ist, dass Produktions-Agents auf mehreren Ebenen messbares Verhalten benötigen. Antwortqualität, Tool-Auswahl, Reaktionsfähigkeit und Ressourcennutzung können unabhängig voneinander versagen.
Eine durchsuchbare Engineering-Wissensdatenbank folgt einem verwandten Prinzip. Retrieval wird nützlicher, wenn Dokumente organisiert, aktuell und mit der Arbeit verbunden bleiben, die Ingenieure ausführen.
Cloud-Recovery-Plattformen stehen nun vor einer Schnittstellenfrage
Der Wettbewerbsdruck verlagert sich von reinen Replikationsfunktionen hin zu der Frage, wer den Wiederherstellungsstatus interpretieren und einen Operator während eines Vorfalls anleiten kann.
HPE Zerto konkurriert in einem Markt, der bereits cloudnative Recovery-Services umfasst. Amazon Elastic Disaster Recovery repliziert unterstützte lokale und Cloud-Workloads in einen Staging-Bereich innerhalb eines AWS-Kontos. Operatoren können Wiederherstellungsinstanzen für Übungen oder reale Vorfälle starten.
Der AWS-Recovery-Service betont kontinuierliche Replikation, Point-in-Time-Recovery, unterbrechungsfreie Tests und Failback. Er ist eng in die AWS-Infrastruktur integriert und auf die Wiederherstellung in Amazon EC2 ausgerichtet.
Microsoft Azure Site Recovery verwaltet Replikation, Failover und Failback für unterstützte virtuelle Maschinen und physische Server. Seine Recovery-Plattform deckt Azure-zu-Azure-Replikation sowie mehrere lokale Szenarien mit Azure als Wiederherstellungsziel ab.
Diese Services entsprechen nicht unmittelbar jeder Zerto-Bereitstellung. HPE Zerto unterstützt breitere hybride Betriebsmodelle und unterhält eine eigene Produktarchitektur. Der relevante Vergleich ist hier keine Checkliste von Replikationsfunktionen.
Der neue Druck betrifft die operative Schnittstelle oberhalb dieser Funktionen. Recovery-Systeme erzeugen Warnungen, Konfigurationszustände, Replikationsmetriken und Ergebnisse von Tests. Ein Agent kann diese Informationen potenziell in eine geführte Untersuchung übersetzen, ohne dass jeder Administrator wissen muss, wo sich jedes Signal befindet.
HPEs früher Schritt gibt dem Unternehmen die Möglichkeit, das Verhalten von Agents rund um seinen proprietären operativen Kontext zu etablieren. Seine Spezialisten können komponentenspezifische Log-Muster kodieren und APIs verwenden, die bereits mit dem Zerto Manager und den Replikationsengines verbunden sind.
Cloud-Anbieter verfügen über einen anderen Vorteil. Sie kontrollieren Infrastruktur, Telemetrie, Identitätsdienste, Recovery-APIs und verwaltete KI-Plattformen innerhalb ihrer jeweiligen Clouds. Sie können potenziell Agents mit direktem Zugriff auf eine breitere Sammlung nativer Signale entwickeln.
Daraus entsteht der zentrale Gegenspieler für HPE Zertos Ansatz: lokal kontrollierte Fehlerbehebung gegenüber cloudzentrierter operativer Intelligenz. Der Wettbewerb ist nicht einfach HPE gegen AWS oder Microsoft, denn AWS liefert die Modelle hinter Zertos System. Es ist ein Wettbewerb zwischen architektonischen Standorten für Kontrolle und Kontext.
Lokale Kontrolle hält die Orchestrierung nah an geschützter Infrastruktur und kann Umgebungen mit strengen Residenzrichtlinien unterstützen. Cloudzentrierte Systeme können auf integrierte Telemetrie und verwaltete Dienste zurückgreifen, ohne in der Appliance jedes Kunden eine Agent-Laufzeitumgebung pflegen zu müssen.
HPEs Architektur kombiniert beide Wege. Die Agents und operativen Tools bleiben lokal, während Modellausführung und Dokumentenabruf AWS nutzen. Diese hybride Anordnung versucht, die sensibelste Ausführungsgrenze lokal zu halten, ohne auf verwaltete Foundation-Modelle zu verzichten.
Der Ansatz überträgt HPE zudem Bereitstellungsverantwortlichkeiten, die ein vollständig verwalteter Cloud-Service vermeiden kann. Der lokale Pod muss mit Produkt-Releases, Kundennetzwerkrichtlinien, Authentifizierungssystemen und eingeschränkten ausgehenden Verbindungen kompatibel bleiben. Die Fehlerbehebung für den Fehlerbehebungs-Agent wird Teil der operativen Belastung.
Air-Gap-Umgebungen stellen die deutlichste Einschränkung dar. HPE erklärt, dass Infrastruktur zur Notfallwiederherstellung häufig air-gapped, latenzeempfindlich oder Anforderungen an die Datenresidenz unterworfen ist. Das beschriebene System benötigt jedoch weiterhin HTTPS-Zugriff für Modellausführung und Wissensabfragen.
Strikt getrennte Installationen können die Architektur daher nicht genau wie beschrieben verwenden. Andere Kunden könnten eng kontrollierten ausgehenden Datenverkehr zulassen, doch Sicherheitsteams müssen weiterhin Ziele, Anfrageinhalte, Identitätskontrollen, Aufbewahrungsverhalten und Fehlermodi prüfen.
Auch die Latenz erstreckt sich über zwei Standorte. Tool-Aufrufe gegen Zerto bleiben lokal, während Reasoning-Anfragen zu AWS gelangen. Eine komplexe Untersuchung kann mehrere Zyklen zwischen Modellentscheidungen und lokalen Tool-Ergebnissen erfordern. Streaming kann diese Wartezeit sichtbar machen, aber die Netzwerkabhängigkeit nicht beseitigen.
Der strategische Wert der Architektur hängt davon ab, ob dieser hybride Kompromiss besser funktioniert als die Alternativen. Wenn er zuverlässige, evidenzbasierte Anleitung bietet, ohne rohe Betriebsdaten zu zentralisieren, liefert er Anbietern von Unternehmenssoftware ein wiederverwendbares Muster. Wenn Netzbeschränkungen oder Grounding-Fehler überwiegen, bevorzugen Käufer möglicherweise einfachere Unterstützung oder vollständig verwaltete Cloud-Betriebsmodelle.
Der nächste Test lautet, ob geführte Diagnose zu vertrauenswürdigem Betrieb wird
Drei Signale werden zeigen, ob die agentische Fehlerbehebung von HPE Zerto zu verlässlicher Infrastruktur wird statt zu einer attraktiven Support-Oberfläche.
Das erste Signal betrifft die Qualität der Problemlösung. Nutzungs- und Supportfallzahlen sind nützliche Ausgangspunkte, zeigen jedoch nicht, ob Nutzer sichere Abhilfemaßnahmen ausgewählt oder Vorfälle schneller gelöst haben.
HPE sollte letztlich Ergebniskennzahlen für unterstützte Workflows veröffentlichen. Sinnvolle Signale wären erfolgreiche Selbsthilfe-Lösungen, Eskalationen nach einer Agenteninteraktion, wiederkehrende Vorfälle, die Akzeptanz durch Administratoren und bei Prüfungen entdeckte Fehler. Vergleichbare Messzeiträume würden diese Ergebnisse aussagekräftiger machen.
Wenn unabhängig überprüfte Ergebnisse eine präzise Diagnose in unterschiedlichen Kundenumgebungen belegen, wird das Argument für lokale agentische Abläufe stärker. Wenn der Supportaufwand sinkt, ohne dass verlässliche Daten zur Problemlösung vorliegen, bleibt die veröffentlichte Leistungsgeschichte unvollständig.
Das zweite Signal ist die Ausweitung über beratende Aufgaben hinaus. HPE nennt die Ausführung von Aufgaben für Nutzer als eines der Ziele des Systems. Die öffentliche Architektur erläutert vor allem Unterstützung, Untersuchung, Zustandswarnungen und Empfehlungen zur Risikominderung.
Der Schritt von Empfehlungen zu Aktionen verändert das Risikomodell. Eine falsche Erklärung kostet Zeit, während eine fehlerhafte Konfigurationsänderung Schutz oder Wiederherstellungsbereitschaft beeinträchtigen kann. Handlungsfähige Agenten benötigen eng begrenzte Berechtigungen, Genehmigungen, vollständige Prüfprotokolle, idempotente Vorgänge und zuverlässige Rollback-Wege.
Jede Veröffentlichung, die dem System Konfigurationsänderungen erlaubt, sollte daher genau beobachtet werden. Begrenzte, reversible Aktionen mit ausdrücklicher Bestätigung würden HPEs Architektur stärken. Eine weitreichende autonome Fehlerbehebung ohne veröffentlichte Details zu den Kontrollmechanismen würde die Unsicherheit erhöhen.
Das dritte Signal ist das Verhalten des Agenten bei eingeschränkter Konnektivität und größeren Vorfällen. Eine alltägliche Supportfrage bietet stabilen Netzwerkzugang und moderate Dringlichkeit. Ein Ransomware-Ereignis oder ein Infrastrukturausfall kann dieselben Identitäts-, Netzwerk- oder Cloud-Pfade beeinträchtigen, die der Agent nutzt.
HPE benötigt ein klares Verhalten für den Fall, dass Amazon Bedrock nicht verfügbar ist, eine Wissensabfrage eine Zeitüberschreitung verursacht, ein lokales Tool veraltete Daten zurückgibt oder der Orchestrator eine Untersuchung nicht abschließen kann. Eine sichere Degradierung sollte fehlende Belege von einer gesunden Infrastruktur unterscheiden und Betreiber auf etablierte Wiederherstellungsverfahren verweisen.
Die interne Nutzung des Unternehmens bietet ein weiteres Testfeld. HPE erklärt, dass seine Ingenieure das System zur Untersuchung häufiger Probleme verwenden, während das Qualitätssicherungsteam es in Test-Workflows integriert. Diese Nutzer können Fehlermuster aufdecken, bevor Kunden während einer Krise auf dasselbe Verhalten angewiesen sind.
Die Architektur enthält bereits mehrere sinnvolle Einschränkungen. Spezialagenten erhalten begrenzte Verantwortungsbereiche. Peer-to-Peer-Rekursion ist untersagt. Der Orchestrator kontrolliert die endgültige Ausgabe. Lokale APIs liefern aktuelle Daten, während wiederholte Bewertungen Antworten und Tool-Trajektorien untersuchen.
Keine dieser Kontrollen macht das Schlussfolgern von Sprachmodellen deterministisch. Das System arbeitet weiterhin über sich verändernde Softwareversionen, Kundentopologien, Log-Formate, Modell-Releases und Dokumentationen hinweg. Die kontinuierliche Bewertung muss dem Produkt daher auch nach der Bereitstellung folgen.
Für Unternehmenskäufer lautet die entscheidende Frage nicht, ob ein Agent eine Warnung zusammenfassen kann. Entscheidend ist, ob das System zeigt, woher seine Antwort stammt, operative Berechtigungen respektiert, fehlende Belege erkennt und eskaliert, bevor Unsicherheit zu einer Handlung wird.
Entwickler sollten die Tool-Grenze im Blick behalten. Ein gut konzipierter MCP-Server kann bestehende APIs für Agenten nutzbar machen, doch jeder freigelegte Vorgang erweitert die Autorität des Systems. Produktteams sollten das Tool-Design mit derselben Sorgfalt behandeln wie öffentliche APIs und administrative Rollen.
Wissensarbeiter können aus dem Einsatz eine allgemeinere Lehre ziehen. KI wird nützlicher, wenn sie vertrauenswürdige Referenzmaterialien mit dem aktuellen Arbeitskontext verbinden kann. Dieser Nutzen hängt von der Qualität der Quellen, Zugriffsgrenzen und einer klaren Unterscheidung zwischen abgerufenen Fakten und generiertem Urteil ab.
HPE Zerto hat diese Idee in eine der anspruchsvollsten Umgebungen der Unternehmens-IT übertragen. Das System verbindet lokale Orchestrierung, Live-Daten zur Notfallwiederherstellung, spezialisierte Agenten und verwaltete Cloud-Inferenz innerhalb eines einzigen operativen Pfads.
Nun müssen die Belege über die Nutzung hinausgehen. Beobachten Sie, ob HPE Ergebnisse zur Problemlösung veröffentlicht, kontrollierte Aktionen einführt und das Verhalten im Degradierungsmodus dokumentiert. Diese Signale werden bestimmen, ob das agentische Troubleshooting-Modell von HPE Zerto zu einem Muster wird, dem andere Infrastrukturanbieter folgen sollten.
