Agentowe rozwiązywanie problemów HPE Zerto wprowadza chmurową AI do lokalnego odzyskiwania danych

HPE Zerto udostępniło system agentowego rozwiązywania problemów z trzema rolami agentów, jednak jego najważniejszą cechą jest miejsce działania tych agentów. Środowisko uruchomieniowe agentowego rozwiązywania problemów HPE Zerto znajduje się w środowisku każdego klienta. Lokalnie analizuje bieżące sygnały dotyczące odtwarzania po awarii, jednocześnie wysyłając wybrane zapytania inferencyjne i dotyczące wiedzy do Amazon Web Services.

Taki podział podważa założenie, że użyteczni agenci korporacyjni muszą przenosić dane operacyjne do scentralizowanej aplikacji chmurowej. HPE Zerto umieściło natomiast orkiestrację obok badanej infrastruktury. Amazon Bedrock zapewnia dostęp do modeli, wyszukiwanie wiedzy, mechanizmy ochronne i wspierające kontrole, nie stając się miejscem realizacji całego procesu rozwiązywania problemów.

System trafił do produkcji w drugim kwartale 2026 roku. HPE i AWS podają, że później wdrożyło go ponad 20 procent klientów Zerto. Informują również o 10-procentowym spadku liczby zgłoszeń wsparcia w procesach objętych systemem. Dane te pochodzą od firm i nie zostały niezależnie zweryfikowane.

Rezultat architektoniczny ma znaczenie wykraczające poza jeden produkt do odzyskiwania danych. Środowiska odtwarzania po awarii łączą wrażliwe logi, zmieniające się konfiguracje, ścisłą kontrolę dostępu i silną presję czasu. Asystent, który nie widzi bieżących warunków, oferuje jedynie ogólne porady. Agent z nieograniczonym dostępem stwarza inne ryzyko operacyjne.

HPE Zerto próbuje zająć wąską przestrzeń między tymi rezultatami. Jego agenci otrzymują ustrukturyzowany dostęp do lokalnych informacji, dzielą dochodzenia według domen technicznych i przekazują skróconą odpowiedź za pośrednictwem jednego kontrolującego orkiestratora. Kluczowe pytanie brzmi, czy ta architektura może zachować kontekst, bezpieczeństwo i przewidywalne zachowanie, gdy rzeczywiste środowiska stają się bardziej złożone.

Agentowe rozwiązywanie problemów HPE Zerto zaczyna się w środowisku klienta

Decydującą zmianą nie jest interfejs czatu. Jest nią umieszczenie środowiska uruchomieniowego agenta obok systemów i dowodów, które musi badać.

HPE Zerto Software wspiera odtwarzanie po awarii, ciągłą ochronę danych i cyberodporność w infrastrukturze hybrydowej oraz wielochmurowej. Operatorzy używają produktu do monitorowania chronionych obciążeń, gotowości do odtwarzania, stanu replikacji i ryzyka naruszenia umów o poziomie usług.

Rozwiązywanie problemów w takim środowisku tradycyjnie wymaga informacji z kilku miejsc. Administrator może sprawdzić alert, przeanalizować log komponentu, przejrzeć dane konfiguracyjne, przeszukać dokumentację produktu i porównać ustalenia z procedurą operacyjną. Podczas awarii każde przejście między tymi źródłami wydłuża proces i zwiększa prawdopodobieństwo pominięcia istotnych dowodów.

Nowy system umieszcza środowisko czatu w istniejącym interfejsie zarządzania Zerto. Operatorzy mogą pytać o stan grup ochrony, ostatnie alerty, praktyki konfiguracyjne, opóźnienia replikacji, błędy aktualizacji lub aktywne problemy systemowe. Asystent może również wskazywać problemy ze stanem systemu i prowadzić użytkownika przez działania ograniczające skutki.

Według wspólnego opisu architektury HPE wdraża warstwę agentową jako pod w lokalnym środowisku klienta. Pod to wdrażalna grupa kontenerów działająca jako jedna jednostka aplikacyjna. W tym projekcie zawiera lokalne środowisko uruchomieniowe agentów.

Środowisko uruchomieniowe korzysta ze Strands Agents, tworzonego przez AWS otwartoźródłowego frameworka do budowania agentów sterowanych modelami. Historia sesji pozostaje przechowywana lokalnie, a agenci uzyskują dostęp do bieżących informacji Zerto za pośrednictwem lokalnego serwera Model Context Protocol.

Model Context Protocol, czyli MCP, definiuje standardowy sposób wywoływania narzędzi i pozyskiwania danych kontekstowych przez aplikację AI. HPE opakowało istniejące API Zerto Manager w serwer MCP, zapewniając agentom ustrukturyzowany dostęp do aktualnych informacji o środowisku.

To istotnie różni się od kopiowania każdego logu i rekordu konfiguracji do zdalnego chatbota. Agenci Zerto mogą żądać lokalnych faktów potrzebnych do dochodzenia, podczas gdy środowisko uruchomieniowe pozostaje wewnątrz urządzenia. HPE twierdzi, że poza lokalną sieć przez HTTPS trafiają wyłącznie żądania inferencyjne modeli oraz zapytania do Amazon Bedrock Knowledge Bases.

To rozróżnienie wymaga ostrożnego sformułowania. System nie jest całkowicie odłączony od chmury ani nie stanowi wdrożenia modelu działającego offline. Amazon Bedrock nadal przetwarza żądania modeli, a zarządzana usługa wiedzy wyszukuje istotne informacje o produkcie. Lokalny projekt kontroluje orkiestrację i dostęp operacyjny, zamiast eliminować przetwarzanie zewnętrzne.

Ta granica tworzy centralne napięcie artykułu. Agent działający lokalnie może pozostawać blisko wrażliwych danych, lecz jego rozumowanie nadal zależy od zdalnych usług modelowych i starannie projektowanych żądań wychodzących. Użyteczność systemu zależy zatem od tego, jaki kontekst przekracza tę granicę, jak jest filtrowany oraz czy zwracane wskazówki pozostają oparte na faktach.

Wydanie wprowadza także pomoc AI głębiej do procesu odtwarzania. Nie ogranicza się ona już do objaśniania dokumentacji. System może analizować bieżące warunki i tworzyć dochodzenie dopasowane do konkretnego problemu, co zwiększa zarówno jego wartość operacyjną, jak i koszt błędnego wniosku.

Projekt typu hub-and-spoke utrzymuje jednego agenta pod kontrolą

HPE Zerto podzieliło rozwiązywanie problemów między wyspecjalizowanych agentów, zachowując jednego orkiestratora jako punkt kontroli delegowania zadań i końcowych odpowiedzi.

Architektura wykorzystuje agenta orkiestratora i co najmniej dwóch wyspecjalizowanych podagentów. Orkiestrator obsługuje rutynowe pytania bezpośrednio i deleguje bardziej szczegółowe dochodzenia, gdy problem wymaga specjalistycznej analizy.

Jeden podagent koncentruje się na Zerto Manager, określanym również jako ZVM. Bada obszary takie jak awarie usług, problemy sieciowe i błędy aktualizacji. Jego narzędzia zapewniają dostęp do istotnych danych środowiskowych, a umiejętności domenowe wskazują wiedzę techniczną i rozpoznawalne wzorce logów.

Kolejny podagent koncentruje się na Zerto Replication Engine, czyli VRA. Obsługuje problemy z replikacją, siecią między lokalizacjami, błędy instalacji i opóźnienia. Otrzymuje własne narzędzia, instrukcje, wiedzę domenową i kontekst roboczy.

Ten podział odzwierciedla istotny wybór inżynieryjny. Przekazanie jednemu ogólnemu agentowi każdego logu, narzędzia, instrukcji i szczegółu rozmowy może stworzyć nadmiernie rozbudowany kontekst z konkurującymi sygnałami. Utrudnia także izolowanie błędów, ponieważ ten sam komponent realizuje routing, analizę i generowanie odpowiedzi.

HPE wykorzystuje zamiast tego strukturę hub-and-spoke. Orkiestrator znajduje się w centrum, a wyspecjalizowani agenci działają jako odgałęzienia. Podagenci raportują do agenta nadrzędnego, zamiast wywoływać się nawzajem bezpośrednio.

AWS opisuje ten wzorzec wieloagentowy jako agents-as-tools, w którym koordynujący agent wywołuje specjalistów za pośrednictwem ograniczonych interfejsów. Każdy specjalista może używać osobnego promptu, kontekstu, modelu i zestawu narzędzi.

W przypadku Zerto rozdzielenie to przynosi trzy praktyczne korzyści. Po pierwsze, dochodzenie intensywnie wykorzystujące logi nie wypełnia kontekstu orkiestratora surowym materiałem diagnostycznym. Specjalista zwraca krótszy raport z ustaleniami, a nie cały przebieg swojej pracy.

Po drugie, każdy agent staje się niezależnie testowalny. Inżynierowie mogą ocenić, czy specjalista VRA wybiera właściwe narzędzia, bez konieczności przechodzenia w każdym teście przez niepowiązane zachowanie ZVM. Takie rozdzielenie może ułatwić lokalizowanie regresji.

Po trzecie, orkiestrator pozostaje odpowiedzialny za końcową odpowiedź. HPE twierdzi, że usuwa sekrety i surowe logi przed zaprezentowaniem wyników użytkownikowi. Jedna ścieżka wyjściowa daje również produktowi jedno miejsce do stosowania reguł odpowiedzi.

Struktura hub-and-spoke ogranicza autonomię poziomą. Jeśli specjalista odkryje, że inny komponent jest źródłem problemu, przekazuje tę obserwację orkiestratorowi. Nie wywołuje samodzielnie innego agenta.

To ograniczenie zmniejsza ryzyko, że rekurencyjne rozmowy agentów będą zużywać tokeny bez osiągnięcia decyzji. Tworzy też możliwą do prześledzenia sekwencję na potrzeby obserwowalności. Każde delegowanie rozpoczyna się i kończy w tym samym punkcie kontroli.

Kompromisem jest potencjalne tarcie w routingu. Orkiestrator musi poprawnie rozpoznać, kiedy pytanie wymaga specjalizacji, i wybrać odpowiedniego agenta. Specjalista musi również skondensować swoje ustalenia bez usuwania dowodów kluczowych dla końcowej diagnozy.

HPE wykorzystuje różne profile modeli dla tych obowiązków. Rutynowe zadania mogą pozostać po stronie orkiestratora, podczas gdy dochodzenia wymagające intensywnego rozumowania mogą korzystać z silniejszego modelu. Firma podaje, że początkowo oceniała większe modele, aby ustalić wykonalność, a następnie porównała alternatywy pod kątem jakości odpowiedzi, opóźnień i kosztów.

To podejście wielomodelowe pozwala uniknąć traktowania każdego żądania jako zadania o jednakowym poziomie trudności. Sprawdzenie stanu grupy ochrony nie wymaga takiego samego budżetu rozumowania jak interpretacja rozbudowanej sekwencji awarii obejmującej logi i stan sieci.

Przenosi ono również wybór modelu z jednorazowej decyzji zakupowej do ciągłego procesu inżynieryjnego. Wraz ze zmianami modeli bazowych HPE może ponownie oceniać, który model odpowiada każdemu agentowi, bez przebudowy całego produktu wokół procesu zależnego od jednego dostawcy.

Bieżące dane o odzyskiwaniu są zarówno przewagą, jak i ryzykiem

System staje się użyteczny, gdy może odpytywać aktualną infrastrukturę, lecz ten sam dostęp sprawia, że kluczowe stają się ugruntowanie odpowiedzi, uprawnienia i wybór narzędzi.

Agent do rozwiązywania problemów potrzebuje czegoś więcej niż instrukcji produktu. Dokumentacja może wyjaśnić znaczenie alertu, ale nie ujawni, czy konkretny silnik replikacji jest opóźniony, która trasa sieciowa zawodzi ani czy niedawna zmiana konfiguracji wpłynęła na gotowość do odtwarzania.

HPE łączy swoich agentów z bieżącymi danymi operacyjnymi za pośrednictwem lokalnego serwera MCP. Serwer udostępnia wybrane API Zerto Manager jako ustrukturyzowane narzędzia. Zamiast prosić model językowy o interpretację surowego zrzutu danych, agent może wywołać zdefiniowaną operację i otrzymać wynik o określonym typie.

Publiczna specyfikacja MCP rozdziela narzędzia, zasoby i prompty za pośrednictwem uzgodnionego interfejsu klient-serwer. W przypadku oprogramowania korporacyjnego taka struktura może przekształcić istniejące API produktu w warstwę dostępną dla agentów bez przepisywania bazowych usług operacyjnych.

Dostęp typowany pomaga, ale nie gwarantuje poprawnej diagnozy. Agent nadal musi wybrać odpowiednie narzędzie, podać prawidłowe parametry, zinterpretować zwrócone informacje i połączyć je z właściwą dokumentacją.

HPE łączy lokalne narzędzia z Amazon Bedrock Knowledge Bases. Retrieval-augmented generation, czyli RAG, pobiera istotny materiał źródłowy, zanim model utworzy odpowiedź. Celem jest oparcie wskazówek na zatwierdzonej dokumentacji produktu i procedurach operacyjnych, a nie wyłącznie na pamięci modelu.

Usługa knowledge base Amazon zarządza wyszukiwaniem dokumentów i może zwracać materiał źródłowy istotny dla zapytania. W projekcie Zerto ta zewnętrzna wiedza uzupełnia lokalny stan środowiska pozyskiwany przez MCP.

Rozróżnienie między tymi źródłami ma znaczenie. Dokumentacja produktu opisuje oczekiwane zachowanie. Lokalne API opisują aktualny stan klienta. Wiarygodne rozwiązywanie problemów wymaga, aby agent porównywał oba źródła, nie myląc ogólnej procedury z dowodem dotyczącym aktywnego incydentu.

Rozważmy pytanie dotyczące opóźnienia replikacji. Dokumentacja może wymieniać ograniczenia przepustowości, przerwy w sieci, zmienność obciążenia lub stan urządzenia jako możliwe przyczyny. Lokalne narzędzia muszą ustalić, które z tych warunków występują w środowisku klienta. Użyteczna odpowiedź powinna zawężać możliwości, zamiast powtarzać całą listę.

HPE twierdzi, że wyspecjalizowani agenci wykorzystują również umiejętności domenowe zawierające znane wzorce logów. Umiejętności te dostarczają modelowi ustrukturyzowanych wskazówek do rozpoznawania sygnałów związanych z konkretnymi komponentami i awariami.

System musi następnie wewnętrznie zachować pochodzenie informacji. Inżynierowie powinni móc odróżnić ustalenie poparte danymi na żywo od hipotezy wywnioskowanej przez model. Opublikowany opis rozwiązania AWS wspomina o telemetrii, ewaluacjach i ustrukturyzowanych wynikach, lecz nie ujawnia pełnego sposobu prezentowania cytowań administratorom.

Kontrola dostępu stanowi kolejny punkt presji. Szerokie narzędzie MCP może ujawniać więcej informacji operacyjnych, niż wymaga pytanie. Wąskie narzędzie ogranicza ekspozycję, ale może pomijać kontekst potrzebny do diagnozy. Projektowanie granicy narzędzia staje się zatem decyzją dotyczącą bezpieczeństwa i produktu, a nie jedynie zadaniem integracyjnym.

Tagowanie żądań dla poszczególnych tenantów dodaje kolejną warstwę kontroli. Architektura wykorzystuje znaczniki ról AWS Identity and Access Management powiązane z każdym tenantem. CloudWatch, DynamoDB i Lambda wspierają monitorowanie użycia oraz egzekwowanie limitów tenantów.

Amazon Bedrock Guardrails sprawdza prompty i wyniki wokół procesu wnioskowania modelu. Dokumentacja AWS podaje, że jego mechanizmy Guardrails mogą filtrować wybrane treści, wykrywać ataki na prompty, ograniczać niedozwolone tematy i maskować informacje wrażliwe.

Filtry te ograniczają konkretne zagrożenia, ale nie mogą zweryfikować każdego wniosku operacyjnego. Odpowiedź może pozostawać w ramach zatwierdzonego tematu, a mimo to rekomendować niewłaściwe działania naprawcze. Guardrails zarządza granicami treści, podczas gdy ewaluacja i logika produktu muszą zapewniać poprawność techniczną.

Dlatego lokalnej architektury HPE nie należy odczytywać jako prostego twierdzenia o prywatności. Lokalna orkiestracja ogranicza scentralizowane zbieranie danych i utrzymuje wykonywanie narzędzi blisko środowiska. Nie eliminuje jednak potrzeby kontroli danych wychodzących, projektowania autoryzacji, testowania ryzyka modeli ani ludzkiego osądu podczas incydentów o dużym wpływie.

Testowane odpowiedzi HPE Zerto, ścieżki narzędzi, opóźnienia i tokeny

HPE potraktowało ewaluację jako system operacyjny, a nie pojedynczy test dokładności wykonywany przed wydaniem.

Ewaluacja agentów jest trudna, ponieważ końcowa odpowiedź jest tylko jednym obserwowalnym wynikiem. Agent może stworzyć wiarygodnie brzmiącą odpowiedź po wybraniu niewłaściwego narzędzia, użyciu nieistotnych dowodów lub obraniu nadmiernie kosztownej ścieżki. Takie zachowanie może zawieść w nieco innych warunkach.

HPE zbudowało testy z wykorzystaniem PyTest oraz zestawu SDK do ewaluacji Strands Agents. Utworzyło zadania, które wielokrotnie uruchamiają szerszy zestaw testów wraz ze zmianami agentów, modeli i promptów.

Pierwsza kategoria testów obejmuje podstawowe zapytania. Każdy test dostarcza pojedyncze żądanie i ocenia odpowiedź. To podejście pasuje do stabilnych pytań z jasno oczekiwanym wynikiem lub zdefiniowanymi kryteriami punktacji.

Druga kategoria ocenia rozmowy wieloturowe. Model symulujący użytkownika wchodzi w interakcję z agentem po początkowym zapytaniu, a ocenie podlega cała rozmowa. Ten format sprawdza, czy system prosi o brakujące informacje i utrzymuje kontekst w kolejnych wymianach.

Trzecia kategoria generuje dynamiczne testy. Generator eksperymentów Strands tworzy przypadki na podstawie wybranych kryteriów, dając HPE sposób na badanie scenariuszy nieobecnych w stałym zestawie testowym. Dynamiczne generowanie poszerza zakres pokrycia, choć wygenerowane testy nadal wymagają sensownych kryteriów i przeglądu.

Każdy test może stosować cztery ewaluatory. Ewaluator odpowiedzi ocenia ją względem zdefiniowanych wcześniej wymagań. Ewaluator trajektorii sprawdza, czy agent wybrał odpowiednie narzędzia i podążał akceptowalną ścieżką.

Ewaluator opóźnień sprawdza czas ukończenia względem progu. Ewaluator tokenów sprawdza, czy wykorzystanie pozostaje w określonych granicach. Razem miary te odzwierciedlają produkcyjowy kompromis między jakością diagnostyki, czasem odpowiedzi i zużyciem zasobów wnioskowania.

Ewaluacja trajektorii jest szczególnie istotna dla agenta operacyjnego. Końcowe sformułowanie może wyglądać poprawnie, nawet gdy system doszedł do niego przez niebezpieczną lub niewiarygodną sekwencję. Testowanie ścieżki może ujawnić, że agent pominął weryfikację danych na żywo, wywołał niepowiązane API lub polegał na dokumentacji mimo dostępności aktualnych danych.

Zestaw ewaluacyjny wspiera również projekt wielomodelowy. HPE może porównać mniejszy model z większym, korzystając z tych samych kryteriów odpowiedzi, trajektorii, opóźnień i tokenów. Dzięki temu wymiana modelu staje się decyzją empiryczną, a nie ogólnym założeniem, że większy model zawsze działa lepiej.

System przesyła postęp dochodzenia do interfejsu za pomocą Server-Sent Events. SSE to mechanizm internetowy, który pozwala serwerowi stale wysyłać aktualizacje do przeglądarki przez jedno połączenie. Użytkownicy mogą obserwować postęp, gdy specjalista analizuje problem.

HPE twierdzi, że strumieniowanie poprawiło doświadczenie użytkownika, ponieważ operatorzy nie muszą już czekać bez informacji zwrotnej. W odzyskiwaniu po awarii widoczny postęp pomaga również odróżnić trwające dochodzenie od zawieszonego interfejsu.

Jednak aktywność przesyłana strumieniowo może tworzyć fałszywe poczucie pewności, jeśli pokazuje kroki bez wyjaśnienia ich wartości dowodowej. Lista wywołań narzędzi nie jest tym samym co zweryfikowana diagnoza. Interfejs musi przedstawiać wystarczający postęp, by budować zaufanie, nie zamieniając wewnętrznego rozumowania w przedstawienie.

Ta sama ostrożność dotyczy twierdzeń HPE o wdrożeniu rozwiązania. Firma informuje, że ponad 20 procent klientów aktywnie korzysta z systemu, a liczba kwalifikujących się zgłoszeń wsparcia spadła o 10 procent. Wyniki te sugerują rzeczywiste wykorzystanie produktu, lecz publiczny wpis nie definiuje aktywnego użycia, okresu pomiarowego ani populacji objętych procesów.

Spadek liczby zgłoszeń wsparcia może mieć również kilka możliwych wyjaśnień. Agent może skutecznie rozwiązywać problemy, kierować użytkowników do istniejącej dokumentacji, zmieniać sposób klasyfikacji zgłoszeń lub zniechęcać do części eskalacji. Niezależne dane dotyczące wskaźnika rozwiązania i wyników zapewniłyby jaśniejszy obraz.

Dla zespołów inżynieryjnych rozważających podobny projekt wniosek nie jest taki, że cztery ewaluatory rozstrzygają kwestię niezawodności. Wniosek jest taki, że agenci produkcyjni potrzebują mierzalnego zachowania na kilku warstwach. Jakość odpowiedzi, wybór narzędzi, responsywność i wykorzystanie zasobów mogą zawodzić niezależnie.

Przeszukiwalna inżynieryjna baza wiedzy opiera się na podobnej zasadzie. Wyszukiwanie staje się bardziej użyteczne, gdy dokumenty pozostają uporządkowane, aktualne i połączone z pracą wykonywaną przez inżynierów.

Platformy odzyskiwania w chmurze stają dziś przed pytaniem o interfejs

Presja konkurencyjna przesuwa się z samych funkcji replikacji w stronę tego, kto potrafi zinterpretować stan odzyskiwania i poprowadzić operatora podczas incydentu.

HPE Zerto konkuruje na rynku, który już obejmuje natywne dla chmury usługi odzyskiwania. Amazon Elastic Disaster Recovery replikuje obsługiwane obciążenia lokalne i chmurowe do obszaru przejściowego na koncie AWS. Operatorzy mogą uruchamiać instancje odzyskiwania na potrzeby ćwiczeń lub rzeczywistych incydentów.

Usługa odzyskiwania AWS kładzie nacisk na ciągłą replikację, odzyskiwanie do punktu w czasie, niezakłócające testowanie i failback. Jest ściśle zintegrowana z infrastrukturą AWS i ukierunkowana na odzyskiwanie do Amazon EC2.

Microsoft Azure Site Recovery zarządza replikacją, przełączeniem awaryjnym i failbackiem obsługiwanych maszyn wirtualnych oraz serwerów fizycznych. Jego platforma odzyskiwania obejmuje replikację Azure-do-Azure oraz kilka scenariuszy lokalnych, w których Azure jest celem odzyskiwania.

Usługi te nie odpowiadają bezpośrednio każdemu wdrożeniu Zerto. HPE Zerto obsługuje szersze hybrydowe wzorce działania i utrzymuje własną architekturę produktu. Istotnym porównaniem nie jest tutaj lista kontrolna funkcji replikacji.

Nowa presja dotyczy interfejsu operacyjnego ponad tymi funkcjami. Systemy odzyskiwania generują alerty, stany konfiguracji, metryki replikacji i wyniki ćwiczeń. Agent może potencjalnie przełożyć te informacje na prowadzone dochodzenie, bez wymagania od każdego administratora wiedzy o tym, gdzie znajduje się każdy sygnał.

Wczesny ruch HPE daje firmie szansę na ukształtowanie zachowania agenta wokół jej zastrzeżonego kontekstu operacyjnego. Jej specjaliści mogą kodować wzorce logów właściwe dla komponentów i używać API już powiązanych z Zerto Manager oraz silnikami replikacji.

Dostawcy chmury mają inną przewagę. Kontrolują infrastrukturę, telemetrię, usługi tożsamości, API odzyskiwania i zarządzane platformy AI w swoich chmurach. Mogą potencjalnie budować agentów z bezpośrednim dostępem do szerszego zbioru natywnych sygnałów.

To tworzy głównego przeciwnika dla podejścia HPE Zerto: lokalnie kontrolowane rozwiązywanie problemów kontra operacyjna inteligencja skupiona w chmurze. Rywalizacja nie sprowadza się po prostu do HPE przeciwko AWS czy Microsoft, ponieważ AWS dostarcza modele stojące za systemem Zerto. Jest to rywalizacja między architektonicznymi lokalizacjami kontroli i kontekstu.

Lokalna kontrola utrzymuje orkiestrację blisko chronionej infrastruktury i może wspierać środowiska o restrykcyjnych zasadach rezydencji danych. Systemy skoncentrowane na chmurze mogą korzystać ze zintegrowanej telemetrii i usług zarządzanych bez utrzymywania środowiska uruchomieniowego agenta w urządzeniu każdego klienta.

Architektura HPE łączy oba podejścia. Agenci i narzędzia operacyjne pozostają lokalne, podczas gdy wnioskowanie modelu i wyszukiwanie dokumentów korzystają z AWS. Ten hybrydowy układ próbuje utrzymać najbardziej wrażliwą granicę wykonywania lokalnie, bez rezygnacji z zarządzanych modeli podstawowych.

Podejście to nakłada również na HPE obowiązki wdrożeniowe, których może uniknąć w pełni zarządzana usługa chmurowa. Lokalny pod musi zachować zgodność z wydaniami produktu, politykami sieciowymi klientów, systemami uwierzytelniania i ograniczonymi połączeniami wychodzącymi. Rozwiązywanie problemów agenta do rozwiązywania problemów staje się częścią obciążenia operacyjnego.

Środowiska odizolowane od sieci stanowią największe ograniczenie. HPE twierdzi, że infrastruktura odzyskiwania po awarii jest często odizolowana, wrażliwa na opóźnienia lub objęta wymaganiami dotyczącymi rezydencji danych. Opisany system nadal potrzebuje jednak dostępu HTTPS do wnioskowania modelu i zapytań do bazy wiedzy.

Ściśle odłączone instalacje nie mogą zatem korzystać z architektury dokładnie w opisanej postaci. Inni klienci mogą zezwolić na ściśle kontrolowany ruch wychodzący, lecz zespoły bezpieczeństwa nadal będą musiały sprawdzić miejsca docelowe, zawartość żądań, mechanizmy kontroli tożsamości, zachowanie danych oraz tryby awarii.

Opóźnienie również obejmuje dwie lokalizacje. Wywołania narzędzi względem Zerto pozostają lokalne, podczas gdy żądania rozumowania trafiają do AWS. Złożone dochodzenie może wymagać kilku cykli między decyzjami modelu a lokalnymi wynikami narzędzi. Strumieniowanie może uwidocznić to oczekiwanie, ale nie eliminuje zależności od sieci.

Strategiczna wartość architektury zależy od tego, czy ten hybrydowy kompromis działa lepiej niż alternatywy. Jeśli zapewnia wiarygodne, oparte na dowodach wskazówki bez centralizowania surowych danych operacyjnych, oferuje dostawcom oprogramowania dla przedsiębiorstw wzorzec możliwy do ponownego wykorzystania. Jeśli dominują ograniczenia sieciowe lub błędy uziemienia w danych, nabywcy mogą preferować prostszą pomoc albo w pełni zarządzane operacje chmurowe.

Kolejnym testem będzie to, czy prowadzona diagnoza stanie się zaufaną działalnością operacyjną

Trzy sygnały pokażą, czy agentowe rozwiązywanie problemów HPE Zerto staje się niezawodną infrastrukturą, a nie atrakcyjnym interfejsem wsparcia.

Pierwszym sygnałem są dane o jakości rozwiązywania problemów. Liczba wdrożeń i zgłoszeń do wsparcia to użyteczne punkty wyjścia, ale nie pokazują, czy użytkownicy wybierali bezpieczne środki zaradcze ani czy szybciej rozwiązywali incydenty.

HPE powinno z czasem publikować miary rezultatów dla obsługiwanych procesów. Przydatne wskaźniki obejmują skuteczne samodzielne rozwiązanie problemu, eskalację po interakcji z agentem, powtarzające się incydenty, akceptację przez administratora oraz błędy wykryte podczas przeglądu. Porównywalne okresy pomiarowe nadałyby tym wynikom większe znaczenie.

Jeśli niezależnie zweryfikowane wyniki wykażą trafną diagnozę w zróżnicowanych środowiskach klientów, argument za lokalnymi operacjami agentowymi stanie się silniejszy. Jeśli ograniczenie obciążenia działu wsparcia nastąpi bez wiarygodnych danych o rozwiązywaniu problemów, przedstawiona historia wyników pozostanie niepełna.

Drugim sygnałem jest rozszerzenie poza zadania doradcze. HPE wymienia wykonywanie zadań dla użytkowników jako jeden z celów systemu. Publicznie opisana architektura skupia się głównie na pomocy, analizie problemów, alertach dotyczących kondycji oraz wskazówkach dotyczących ograniczania skutków.

Przejście od rekomendacji do działań zmienia model ryzyka. Błędne wyjaśnienie pochłania czas, podczas gdy błędna zmiana konfiguracji może wpłynąć na gotowość ochrony lub odzyskiwania danych. Agenci podejmujący działania potrzebują wąskich uprawnień, zatwierdzeń, pełnych ścieżek audytu, idempotentnych operacji oraz niezawodnych ścieżek wycofania zmian.

Każde wydanie, które pozwala systemowi modyfikować konfigurację, powinno być więc uważnie obserwowane. Ograniczone, odwracalne działania z wyraźnym potwierdzeniem wzmocniłyby architekturę HPE. Szerokie autonomiczne usuwanie problemów bez opublikowanych szczegółów dotyczących kontroli zwiększyłoby niepewność.

Trzecim sygnałem jest zachowanie agenta podczas pogorszonej łączności i poważnych incydentów. Zwykłe pytanie do wsparcia zakłada stabilny dostęp do sieci i umiarkowaną pilność. Atak ransomware lub awaria infrastruktury mogą zakłócić te same ścieżki tożsamości, sieci lub chmury, z których korzysta agent.

HPE potrzebuje jasnego opisu zachowania systemu, gdy Amazon Bedrock staje się niedostępny, zapytanie do bazy wiedzy przekracza limit czasu, lokalne narzędzie zwraca nieaktualne dane lub orkiestrator nie może ukończyć analizy. Bezpieczne działanie w trybie ograniczonym powinno odróżniać brakujące dowody od sprawnej infrastruktury i kierować operatorów do ustalonych procedur odzyskiwania.

Wewnętrzne wykorzystanie systemu przez firmę stanowi kolejne pole testowe. HPE twierdzi, że jej inżynierowie używają systemu do badania typowych problemów, a zespół zapewnienia jakości integruje go z procesami testowymi. Tacy użytkownicy mogą ujawnić wzorce awarii, zanim klienci będą zależni od tego samego zachowania w czasie kryzysu.

Architektura już zawiera kilka rozsądnych ograniczeń. Wyspecjalizowani agenci otrzymują jasno ograniczone obowiązki. Rekursja peer-to-peer jest zabroniona. Orkiestrator kontroluje końcowy wynik. Lokalne API dostarczają aktualne dane, a powtarzane ewaluacje analizują odpowiedzi i trajektorie użycia narzędzi.

Żadna z tych kontroli nie czyni rozumowania modelu językowego deterministycznym. System nadal działa w środowisku zmieniających się wersji oprogramowania, topologii klientów, formatów logów, wydań modeli i dokumentacji. Ciągła ewaluacja musi zatem towarzyszyć produktowi również po wdrożeniu.

Dla nabywców korporacyjnych właściwe pytanie nie brzmi, czy agent potrafi podsumować alert. Chodzi o to, czy system pokazuje źródło swojej odpowiedzi, respektuje uprawnienia operacyjne, rozpoznaje brakujące dowody i eskaluje sprawę, zanim niepewność przerodzi się w działanie.

Programiści powinni obserwować granicę narzędzi. Dobrze zaprojektowany serwer MCP może umożliwić agentom korzystanie z istniejących API, ale każda udostępniona operacja rozszerza uprawnienia systemu. Zespoły produktowe powinny traktować projektowanie narzędzi z taką samą starannością, jaką stosują wobec publicznych API i ról administracyjnych.

Pracownicy wiedzy mogą wyciągnąć z tego wdrożenia szerszą lekcję. AI staje się bardziej użyteczna, gdy może łączyć zaufane materiały referencyjne z bieżącym kontekstem pracy. Ta korzyść zależy od jakości źródeł, granic dostępu oraz jasnego rozróżnienia między pozyskanymi faktami a wygenerowanym osądem.

HPE Zerto przeniosło tę ideę do jednego z najmniej wybaczających błędy środowisk w informatyce korporacyjnej. System łączy lokalną orkiestrację, bieżące dane o odzyskiwaniu po awarii, wyspecjalizowanych agentów i zarządzane wnioskowanie chmurowe w jednej ścieżce operacyjnej.

Teraz dowody muszą wyjść poza poziom wdrożenia. Warto obserwować, czy HPE publikuje wyniki rozwiązywania problemów, wprowadza kontrolowane działania oraz dokumentuje zachowanie w trybie ograniczonym. Te sygnały zdecydują, czy model agentowego rozwiązywania problemów HPE Zerto stanie się wzorcem, za którym powinni podążać inni dostawcy infrastruktury.