AgentSRE: Składalne agenty AI do autonomicznej naprawy incydentów w AWS

Pętla incydentów, która pochłania dzień inżyniera SRE

Znaczna część dnia inżyniera odpowiedzialnego za niezawodność serwisu upływa na powtarzający się cykl. Wybucha alert, ktoś zajmuje się sprawą, ustala przyczynę problemu, wdraża naprawę i zamknie ticket. Każdy krok wymaga czasu, a średni czas rozwiązania problemu (MTTR) może wynosić od minut do godzin. W miarę rozwoju chmurowych infrastruktur ta ręczna rutyna staje się wąskim gardłem.

AgentSRE to autonomiczna platforma do zarządzania incydentami w AWS, stworzona właśnie po to, by rozwiązać to problem. Pozwala ona przeprowadzić incydent od jego wykrycia aż po rozwiązanie za pomocą składalnych agentów AI, z których każdy specjalizuje się w innym rodzaju zadania naprawczego. Projekt traktuje proces naprawczy jako zbiór małych, współpracujących agentów, a nie jako jeden monolityczny skrypt automatyzacji – powody tego rozwiązania są przedstawione poniżej.

Jak wygląda typowy incydent

Wyobraź sobie alarm w CloudWatch, który sygnalizuje wysoką opóźnioność odczytu z bazy danych. Inżynier na zmianie otrzymuje powiadomienie, otwiera panel sterowania, sprawdza wskaźniki oraz analizuje logi wolnych zapytań, aż w końcu odkrywa, że brakujący indeks zmusza do pełnego skanowania tabeli. Następnie pisze i uruchamia polecenie CREATE INDEX, potwierdza, że naprawa zadziałała, i aktualizuje ticket.

Wszystkie te kroki są konieczne, ale większość z nich ma charakter rutynowy. Inżynier nie rozwiązuje nowej zagadki – postępuje zgodnie z dobrze znanym schematem diagnostyki i naprawy, a koszty tego są rzeczywiste. Zmiana kontekstu, przeglądanie paneli sterowania oraz ręczne wykonywanie zapytań powiększają nakłady, gdy incydent trwa dłużej, niż powinien.

Jeśli wzorzec diagnostyczny jest zrozumiały, a rozwiązanie dobrze określone, cały cykl może zostać zautomatyzowany, przy czym osoba nadal musi zatwierdzić zmianę. AgentSRE obejmuje cały cykl życia incydentu w pięciu etapach: wykrycie, dochodzenie, podjęcie decyzji, wykonanie i zamknięcie.

Cechą wyróżniającą jest sposób organizacji procesu wykonania. Zamiast jednego rozbudowanego skryptu, który próbuje każdego możliwego rozwiązania, używa się specjalistycznych agentów – po jednym na każdą kategorię: agenta bazy danych do naprawy problemów w SQL oraz agenta kolejki do obsługi komunikacji. Każdy agent to odrębna maszyna stanów, dzięki czemu można go budować, testować i wdrażać oddzielnie, a nowe typy agentów mogą być dodawane bez konieczności edytowania istniejących. Zasadniczą zasadą projektu jest kompozytywność – odzwierciedla ona sposób, w jaki prawdziwy zespół operacyjny dzieli zadania między specjalistów, oraz umożliwia rozwój platformy wraz z pojawianiem się nowych metod naprawczych.

Architektura w pigułce

Platforma działa wyłącznie przy użyciu usług zarządzanych przez AWS, co zapewnia niskie koszty operacyjne oraz automatyczne skalowanie.

Na diagramie architektury wszystko zaczyna się po lewej stronie – alarm CloudWatch dostarcza dane do pipeline’u opartego na zdarzeniach. Tematy SNS rozpowszechniają powiadomienia, funkcja Lambda odpowiada za otwieranie incydentów w ServiceNow, a agent AWS DevOps rozpoczyna samodzielne badanie. Wyniki znajdują się w interfejsie React, podzielonym na sekcje Chat, Incydenty i Raporty. U dołu znajdują się trzy widoki topologiczne, które pokazują operatorom, jak wygląda każdy incydent wizualnie. Jedna grafika obejmuje więc całą ścieżkę od wykrycia do wizualizacji, a żaden etap nie wymaga ręcznego przekazania informacji.

Wykrywanie

Pierwszym sygnałem jest alarm CloudWatch dotyczący anomalii, na przykład wysokiego opóźnienia odczytu, wyczerpanych połączeń lub stale rosnącej kolejki wiadomości nieodebranych. Alarm ten jest publikowany w temacie SNS, co uruchamia funkcję Lambda odpowiedzialną za powiadamianie, która natychmiast tworzy incydent w ServiceNow i rozpoczyna dochodzenie przez agenta AWS DevOps. Na tym etapie w ogóle nie jest potrzebna interwencja człowieka.

Dochodzenie

Agent AWS DevOps to usługa zarządzana, która samodzielnie przeprowadza dochodzenie. Analizuje metryki CloudWatch, dane z RDS Performance Insights oraz logi wolnych zapytań i sama decyduje, które dane są istotne w kontekście alarmu. Asynchroniczna funkcja Lambda zbiera uzyskane informacje i zapisuje je w DynamoDB.

Amazon Bedrock, uruchamiając Claude, sprowadza wyniki analizy do krótkiego stwierdzenia dotyczącego podstawowej przyczyny problemu, oceny wpływu oraz zalecanych działań naprawczych. Ten streszczenie znajduje się na górze widoku dochodzenia, a pełna analiza jest dostępna poniżej.

Zdjęcie ekranu pokazuje widok wyników dochodzenia – najpierw streszczenie, a poniżej szczegóły.

Decyzje i zarządzanie

Przed zastosowaniem jakiejkolwiek zmiany przeprowadzane są sprawdzenia bezpieczeństwa. Narzędzia typu Guardrails analizują każde zdanie SQL i odrzucają te destruktywne, takie jak usuwanie tabeli lub wierszy bez klauzuli WHERE. Działanie otrzymuje poziom ryzyka i trafia do osoby ludzkiej w celu zatwierdzenia. Okno potwierdzenia przedstawia dokładny rozkaz, docelowy zasób oraz sposób cofnięcia zmian.

Krok realizowany przez osobę ludzką jest celowy. Pełna autonomia jest potężna, ale zmiany w środowisku produkcyjnym wymagają chwili ludzkiego osądu, szczególnie przy operacjach o wyższym ryzyku.

Widok przedstawiony powyżej to to, co widzi operator, gdy prosi się go o potwierdzenie naprawy.

Kierowanie naprawy do odpowiedniego agenta

Gdy naprawa zostanie zatwierdzona, system klasyfikuje kategorię naprawy i wysyła żądanie do odpowiedniego agenta. Wtedy właśnie przydaje się zastosowanie koncepcji kompozowalności.

Diagramat szczegółowo przedstawia proces naprawy. Gdy ktoś zatwierdza rozwiązanie, orkiestrator przejmuje kontrolę i wykonywa trzy zadania: klasyfikuje przyczynę podstawową, wdraża zabezpieczenia bezpieczeństwa SQL oraz przekazuje żądanie odpowiedniemu specjaliście, jednocześnie rejestrując operację w DynamoDB. Dalej istnieją dwa kierunki działania. Po stronie bazy danych maszyna stanowa LangGraph w Amazon Bedrock AgentCore wraz z analitykiem AI weryfikuje kod SQL, uruchamia go w bazie danych za pośrednictwem bramy Lambda w VPC i zapisuje wynik do Jira razem z wpisem audytowym. Po stronie kolejki zadania są realizowane w ten sam sposób – np. przy opróżnianiu kolejki wiadomości błędnych lub odsyłaniu komunikatów tam, skąd pochodziły.

Żaden agent nie dostępuje bezpośrednio do zasobu. Każdy z nich korzysta z narzędzi bramy: funkcja bramy łącząca się z RDS dla agenta bazy danych oraz narzędzie realizujące operacje SQS dla agenta kolejki. Taka architektura sprawia, że agenci są małe, a dostęp do zasobów jest kontrolowany i śledzalny. Po zakończeniu pracy którejkolwiek z gałęzi, wspólny pipeline wyników przechowuje rezultat w DynamoDB, dodaje notatkę do ServiceNow, zamknie ticket i odświeży topologię, dzięki czemu każdy incydent kończy się w ten sam sposób, niezależnie od tego, który agent nim zajmował się.

Jak działa klasyfikacja

Inteligencja umożliwiająca to funkcjonowanie znajduje się w orkiestratorze. Gdy agent AWS DevOps kończy pracę, generuje analizę przyczyn źródłowych w języku naturalnym, a orkiestrator ją odczytuje i przypisuje kategorię naprawczą, zanim uruchomiony zostanie jakikolwiek agent.

Klasyfikacja odbywa się w dwóch krokach. Strukturyzowany parser najpierw przeszukuje wyniki analizy w poszukiwaniu z góry zdefiniowanego bloku naprawczego, który określa typ korekty, docelowy zasób oraz planowaną akcję. Jeśli taki blok nie istnieje, system kieruje się na model językowy do klasyfikacji w Amazon Bedrock, który analizuje opis przyczyny w formie swobodnej wraz z oryginalnym kontekstem alarmu i określa kategorię. Kontekst alarmu pomaga powiązać objaw z odpowiednią korektą. Wysoka opóźniona szybkość odczytu wskazuje na konieczność dodania indeksu bazy danych, wyczerpane połączenia sugerują zakończenie zapytania blokującego, a rosnąca kolej wiadomości bez odpowiedzi wymaga ich usunięcia lub ponownego przesłania.

Kierowanie ruchem jest deterministyczne po ustaleniu kategorii: dane trafiają do agenta bazy danych, a kolejki do agenta kolejek. Oddzielenie klasyfikacji od wykonywania zadań ułatwia dodawanie nowych elementów, ponieważ nowa kategoria po prostu jest przypisywana do nowego agenta, a logika kierowania ruchem się nie zmienia.

Dwa agenty produkcyjne

AgentSRE zawiera dwa agenty produkcyjne, z których każdy jest przeznaczony do obsługi innej kategorii działań naprawczych. Oba działają jako zaimplementowane w kontenerach środowiska wykonawcze na platformie Amazon Bedrock AgentCore i mają wspólny projekt: maszynę stanów LangGraph z kilkoma dobrze zdefiniowanymi węzłami, z których każdy jest wyposażony w mechanizmy rejestrujące czas wykonywania i wynik działań.

Agent bazy danych

Ten agent obsługuje wszystkie naprawy oparte na SQL. Jego projekt odpowiada rzeczywistemu procesowi operacji w bazie danych, zorganizowanemu jako maszyna stanów z warstwą kierowania ruchem, która wybiera kolejny krok na podstawie obecnego stanu.

Gdy przychodzi żądanie, agent najpierw wybiera docelową bazę danych oraz zalecony SQL z opisu incydentu. Następnie następuje weryfikacja, podczas której analityk AI działający na Bedrocku bada zapytanie, aby upewnić się, że jest dobrze sformułowane i bezpieczne. Ta semantyczna kontrola jest dodawana do już zastosowanych przez orkiestratora mechanizmów ochronnych, dzięki czemu błędne lub niebezpieczne zapytania napotykają dodatkową barierę.

Gdy weryfikacja zostanie przeprowadzona pomyślnie, agent wykonuje zapytanie, choć nie bezpośrednio. Wywołuje wtedy Lambda umieszczone w VPC, które łączy się z docelową instancją RDS przy użyciu autoryzacji IAM. Dzięki temu dane dostępu do bazy danych oraz możliwości sieciowe pozostają zamknięte w jednym kontrolowanym komponencie, a agent pozostaje lekki, nie mając bezpośredniego połączenia z bazą danych.

Jeden pipeline służy do realizacji różnych działań korygujących. Agent może utworzyć brakujący indeks w celu skrócenia czasu odczytu, zakończyć zapytanie blokujące, które utrzymuje zamki i wyczerpuje połączenia, lub uruchomić inne instrukcje korygujące w razie potrzeby. Następnie rejestruje wynik, w tym liczbie wpływających wierszy oraz czas wykonywania, a także tworzy odpowiadający temu wpis w Jira oraz pełny zapis audytowy. Ponieważ ten sam pipeline do walidacji, wykonywania i audytu obsługuje każdą operację SQL, wprowadzanie nowych sposobów naprawy błędów w bazie danych nie wymaga zmiany struktury agenta.

Agent kolejki

Agent kolejki zajmuje się problemami z przesyłaniem wiadomości, najczęściej takimi jak kolejka wiadomości nieudanych, w której gromadzą się nieudane komunikaty. Działa według tej samej trójetapowej procedury: walidacja, wykonywanie i audyt, ale z logiką specyficzną dla kolejek.

Weryfikacja pokazuje, dlaczego bezpieczeństwo jest najważniejsze dla autonomicznego agenta kolejki. Zanim ten dokona czegokolwiek destruktywnego, upewnia się najpierw, że docelowa kolejka rzeczywiście jest kolejką wiadomości nieudanych, sprawdzając format ARN, a następnie pytając narzędzie bramkowe o atrybuty tej kolejki. Kolejka, która nie jest kolejką wiadomości nieudanych, powstrzymuje agenta od dalszych działań, zgłaszając awarię bezpieczeństwa, zamiast ryzykować pracą z aktywną kolejką produkcyjną. Usunięcie niewłaściwej kolejki zniszczyłoby wiadomości w trakcie przesyłania, a taka cena uzasadnia specjalną weryfikację.

Gdy walidacja się powiedzie, następuje jedna z dwóch akcji. Operacja usuwania wymazuje wszystkie zgromadzone wiadomości z kolejki dead letter, która zawiera wiadomości uznane za nieodzyskwalne. Operacja ponownego wysłania odsyła je z powrotem do źródłowej kolejki w celu ponownej próby, przy czym stosuje konfigurowalne ograniczenie szybkości, aby uniknąć przepełnienia odbiorców poniżej w łańcuchu. Dostępna jest również kontrola stanu, umożliwiająca monitorowanie trwającej operacji ponownego wysłania.

Tak jak agent bazy danych, agent kolejki przekazuje każdą operację przez własną funkcję bramy, która wykonywa połączenia boto3 SQS i rejestruje wszystkie działania w celach audytu. Przyjmuje on albo zapytanie strukturyzowane, albo tekst prosty, i wyodrębnia z nich odpowiednią akcję oraz ARN kolejki.

Niezależność z założenia

Żaden z agentów nie ma żadnej wiedzy o drugim. Każdy posiada własną maszynę stanową, narzędzie bramy oraz mechanizm walidacji dostosowane do swojej dziedziny. Tylko orkiestrator widzi oba i nie robi nic poza klasyfikacją oraz kierowaniem ruchem.

To właśnie ta niezależność oznacza w praktyce koncepcję kompozytowości. Trzeci agent, który miałby za zadanie ponowne uruchomienie kontenera, rotację uprawnień lub zmianę polityki skalowania, stosowałby tę samą metodologię – z maszyną stanową LangGraph przeprowadzającą kroki walidacji, wykonywania i audytu oraz własnym narzędziem bramy. Rejestruje się on w nowej kategorii u orkiestratora, a starsze agenty pozostają nienaruszone. Rozwój następuje poprzez dodawanie nowych elementów, a nie ich edycję.

Raportowanie i zamykanie

Gdy praca zostanie zakończona, agent zgłasza, czy udało się to osiągnąć, ile wierszy zostało zmienionych oraz jak długo to trwało. Wynik jest zapisywany w DynamoDB i dodawany do incydentu w ServiceNow jako notatka dotycząca wykonywanych działań, a udane zakończenie rozwiązuje problem bez dodatkowych działań. Wszystkie kroki są rejestrowane, co zapewnia pełny ślad audytowy od pierwszego alarmu aż do rozwiązania problemu.

Interfejs operacyjny

Automatyzacja wykonywa pracę, ale operatorzy nadal potrzebują miejsca, z którego mogliby ją monitorować, kierować nią i ją rozumieć. AgentSRE posiada spersonalizowany interfejs internetowy stworzony przy użyciu React i hostowany na AWS Amplify – stanowi on jednolite narzędzie do obsługi całego cyklu życia incydentu. Dostęp odbywa się poprzez Microsoft Entra ID Single Sign-On, dzięki czemu dostawca tożsamości organizacji decyduje o tym, kto może korzystać z funkcji kontrolnych. Interfejs składa się z trzech obszarów, z których każdy służy innym celom.

Czat

Chat stanowi interfejs konwersacyjny do AWS DevOps Agent. Operatorzy zadają proste pytania dotyczące stanu określonej bazy danych, tego, czy aktywne są jakieś alarmy, lub jak przebiega dochodzenie. Wpisanie numeru incydentu uruchamia pełne dochodzenie bezpośrednio z czatu. Interfejs przechowuje kontekst rozmowy pomiędzy wiadomościami i radzi sobie z wolnymi odpowiedziami poprzez ponowne próby w tle, dzięki czemu operatorzy otrzymują odpowiedź, a nie błąd.

Zdjęcie ekranu pokazuje widok czatu.

Incydenty

Sekcja Incydenty to panel sterowania dla codziennych operacji. Każdy incydent jest wyświetlany wraz ze swoim stanem, informacją o tym, czy ktoś już go badał oraz czy zastosowano naprawę. Operator może stamtąd rozpocząć dochodzenie, przeczytać przyczynę podstawową, przejrzeć topologię i rozpocząć działania naprawcze. Naprawa wymaga jednego kliknięcia, a następnie dialogu potwierdzającego, który pokazuje dokładną zmianę przed jej wykonaniem.

To jest panel incydentów.

Raporty

Raporty dostarczają analiz dotyczących wszystkich incydentów: liczba dochodzeń, wskaźniki rozwiązania problemów, MTTR oraz podział według priorytetu i zasobów. Przekształcają one dane dotyczące pojedynczych incydentów w wgląd operacyjny w czasie.

Widok raportów pojawia się powyżej. W widoku dochodzeń interfejs oferuje również wizualizację topologii, opisaną poniżej, która przekształca złożone analizy w interaktywne wykresy umożliwiające szybkie zrozumienie sytuacji.

Integracja z ServiceNow

Autonomiczna platforma, która ignoruje istniejące systemy zarządzania usługami IT, stworzyłaby więcej problemów, niż rozwiązałaby. Dlatego AgentSRE integruje się bezpośrednio z ServiceNow, co oznacza, że każdy obsłużony przez niego incydent jest odzwierciedlany w systemie danych, od którego już korzystają zespoły operacyjne.

Informacje przepływają w obu kierunkach przez cały cykl życia. Gdy uruchomi się alarm CloudWatch, funkcja Lambda odpowiedzialna za powiadamiania automatycznie tworzy incydent w ServiceNow, z góry wypełniony szczegółami alarmu, priorytetem i kategorią, najpierw szukając istniejącego otwartego incydentu, aby uniknąć duplikatu. Dzięki temu ticket istnieje od samego początku, bez konieczności jego ręcznego tworzenia.

W miarę postępów w rozwiązywaniu incydentu, AgentSRE publikuje aktualizacje w tym ticketu. Wyniki dochodzenia są dodawane jako notatki robocze, dzięki czemu każdy, kto przegląda ticket, może zobaczyć pełną analizę przyczyn w odpowiednim kontekście. Gdy zostanie zastosowane rozwiązanie, jego rezultat – obejmujący podjęte działania, wynik oraz datę i godzinę – trafia jako kolejna notatka robocza. Po udanym rozwiązaniu platforma przenosi ticket do statusu „rozwiązany” i dołącza notatki z opisem rozwiązania.

W rezultacie powstaje kompletny, sprawdzalny zapis w ServiceNow, który odzwierciedla cały zautomatyzowany proces pracy. Zespoły mogą dalej pracować w narzędziu, które znają, podczas gdy automatyzacja zajmuje się ciężką pracą, a przestrzeganie istniejącego procesu ułatwia wdrożenie platformy w przedsiębiorstwie, zamiast tworzenia systemu równoległego, którego ludzie musieliby się osobno uczyć.

To jest ticket w ServiceNow po jego aktualizacji przez platformę.

Zobaczenie tego, co się stało: widoki topologiczne

Znajomość tego, co wydarzyło się podczas incydentu, jest niemal tak ważna jak jego naprawa, a obraz przekazuje więcej informacji niż gęsty tekst. AgentSRE oferuje trzy widoki topologiczne, z których każdy jest prezentowany jako interaktywny graf.

Topologia dochodzenia

To widok pokazuje promień wybuchu: jakie zasoby są dotknięte i w jaki sposób się ze sobą łączą. Zasób będący przyczyną główną jest wyraźnie wyróżniony, a animowane krawędzie pokazują ścieżkę awarii w miarę jej rozprzestrzeniania się. Wykres jest generowany dynamicznie na podstawie ustaleń z dochodzenia, więc różne incydenty tworzą różne topologie, ponieważ każdy wykres odzwierciedla to, co agent faktycznie odkrył.

Powyższy widok przedstawia topologię dochodzenia.

Topologia infrastruktury

Ta mapa pokazuje pełną architekturę: każdą bramkę API, funkcję Lambda, agenta, bazę danych, kolejkę oraz elementy monitoringu oraz połączenia między nimi. Daje to operatorom pełny obraz zainstalowanej infrastruktury oraz ścieżkę, którą podążają żądania.

Mapa infrastruktury pokazuje ten sam system.

Topologia agenta komponowalnego

To widok pokazuje krok po kroku ścieżkę naprawy: akcję użytkownika, klasyfikację przez orkiestratora, wywołanie agenta, wezwanie narzędzia bramy, zmianę zasobu oraz ostateczny wynik umieszczony w ServiceNow. Każdy węzeł reprezentuje rzeczywisty komponent wywoływany podczas naprawy, dzięki czemu architektura kompozytowa przestaje być abstrakcyjną koncepcją i staje się czymś, co operatorzy mogą zobaczyć i zweryfikować.

Topologia agenta pokazuje jedną sesję naprawy.

Topologię wydobywa się za pomocą metody hybrydowej. Wydobywacz oparty na regułach buduje graf natychmiast i bezpłatnie, gdy incydent odpowiada znanemu wzorcowi. W przypadku czegoś nieznajomego system prosi Bedrock Claude o wydobycie topologii z tekstu dochodzenia. Przypadki typowe są rozwiązywane szybko, a te nietypowe również otrzymują odpowiednie traktowanie.

Dlaczego kompozytywność się opłaca

Budowa mechanizmów korygujących jako agentów komponowalnych, a nie jako monolitu, przynosi kilka praktycznych korzyści.

• Rozszerzalność. Nowa kategoria działań korygujących, takich jak ponowne uruchomienie kontenera, dostosowanie polityki skalowania lub rotacja uprawnień, oznacza konieczność stworzenia jednego agenta i jego zarejestrowania w orkiestratorze, przy czym istniejące agenty pozostają nietknięte.
• Możliwość testowania. Jedną maszynę stanów z określonymi danymi wejściowymi i wyjściowymi można testować oddzielnie, dzięki czemu zmiana w jednym agencie rzadziej powoduje awarie w innym.
• Obserwowalność. Każdy agent podąża za zdefiniowaną maszyną stanów, więc jego działanie można śledzić i wizualizować, a widok topologii agentów komponowalnych pochodzi bezpośrednio z tego projektu.
• Możliwość ponownego użycia. Jeden agent może obsługiwać wiele incydentów. Na przykład agent bazy danych zajmuje się tworzeniem indeksów, zamykaniem zapytań oraz innymi naprawami w SQL bez żadnych zmian.

Stack technologiczny

Pliattaforma łączy te usługi AWS oraz frameworki otwartego oprogramowania, ugrupowane według funkcji:

• Monitorowanie i alarmy pochodzą z Amazon CloudWatch, a orkiestracja oparta na zdarzeniach – z Amazon SNS w połączeniu z AWS Lambda.
• Rozbieranie problemów jest realizowane za pomocą AWS DevOps Agent, natomiast Amazon Bedrock z Claude zajmuje się rozumowaniem, tworzeniem streszczeń oraz wyodrębnianiem topologii.
• Amazon Bedrock AgentCore hostuje agenty, a LangGraph dostarcza ich maszyny stanowe.
• Amazon DynamoDB przechowuje dane stanu i audytowe, a ServiceNow zarządza cyklem życia ticketów.
• Część front-end wykorzystuje React wraz z React Flow do tworzenia interfejsu i grafów topologicznych, hostowanych na AWS Amplify.

Wpływ pomierzony

Automatyzacja tego procesu przynosi wyraźne korzyści. Ręczna analiza i naprawa mogą trwać od jednej do czterech godzin, natomiast AgentSRE rozwiązuje problem w mniej niż dziesięć minut od wykrycia alarmu. Samo badanie zwykle zajmuje od trzech do pięciu minut, a zatwierdzona naprawa jest realizowana w mniej niż trzydzieści sekund.

Poprawia się zarówno szybkość, jak i spójność działań. Wszystkie incydenty podlegają takiej samej dokładnej analizie, weryfikacjom bezpieczeństwa oraz rejestracji działań, dzięki czemu lista osób na dyżurze nie decyduje o jakości reakcji.

Kierunki dalszego rozwoju

Fundament komponowalny otwiera kilka możliwości. Więcej agentów mogłoby zajmować się naprawami na poziomie infrastruktury za pomocą Systems Manager lub Terraform. Procesy zatwierdzania mogłyby być przekierowywane przez narzędzia współpracy, takie jak Microsoft Teams. Warstwa wiedzy mogłaby wykorzystywać lekcje z wcześniejszych incydentów, aby udoskonalić przyszłe rekomendacje. A ponieważ wzorzec agenta nie jest powiązany z jednym chmurą, ten sam podejście mogłoby zostać zastosowane w środowiskach multi-cloud.

Główne wnioski architektoniczne

Zarządzanie incydentami w sposób autonomiczny okazuje się praktyczne i wykonalne, gdy opiera się na właściwych zasadach: autonomiczne dochodzenie, komponowalne agenty naprawcze, ludzkie zatwierdzenie oraz szczegółowe widoki topologii. Wspólnie znacznie skracają one średni czas rozwiązania problemu, jednocześnie zapewniając bezpieczeństwo i pełną śledzalność.

Główna lekcja dotyczy architektury. Podział procesów korygujących na specjalistyczne, komponowalne agenty zamiast jednej automatyzacji odpowiada rzeczywistym metodom pracy zespołów operacyjnych, utrzymuje system otwarty na rozbudowę i sprawia, że każda akcja jest widoczna. W miarę jak środowiska chmurowe stają się coraz bardziej złożone, jest to skalowalna droga do operacji napędzanych sztuczną inteligencją.