Asystent oparty na AI przejął moje dyżury on-call przez siedem dni, przetwarzając 11 alertów i skracając mój średni czas naprawy problemu z 45 do 20 minut. Eksperyment ten jest istotny, ponieważ model językowy o umiarkowanym zakresie może skrócić czas reakcji na incydenty o pół godziny, wciąż wymagając przy tym ścisłego nadzoru człowieka.

Dlaczego powierzyłem dyżur AI

Zespoły chmurowe spędzają większość zmiany na przeszukiwaniu logów, sprawdzaniu ostatnich wdrożeń i potwierdzaniu, czy żądanie skalowania jest bezpieczne. Te „nudne” zadania są powtarzalne, wymagają dużej ilości danych i są podatne na zmęczenie człowieka. Ostatnie postępy w dziedzinie dużych modeli językowych obiecywały zautomatyzowanie właśnie takiej pracy polegającej na dopasowywaniu wzorców, ale większość publicznych demonstracji odbywa się w środowiskach typu sandbox. Chciałem sprawdzić, czy ten entuzjazm utrzyma się w klastrze klasy produkcyjnej, który faktycznie obsługuje płacących klientów.

Konfiguracja testu

  • Dostęp – Agent mógł odczytywać każdą metrykę, log i definicję wdrożenia. Mógł pisać tylko do wąskiej listy uprawnień (whitelist): restartować pod, zwiększać liczbę replik lub skalować wdrożenie. Każda inna akcja wymagała mojej wyraźnej zgody.
  • Rola – Traktowałem model jak młodszego inżyniera na jego pierwszym dyżurze on-call. Otrzymywał alert, przeprowadzał analizę i publikował rekomendację na kanale incydentów.
  • Zabezpieczenia – Wszystkie akcje zapisu były blokowane i wymagały ręcznego potwierdzenia („tak/nie”). Ograniczyłem również zużycie tokenów przez model, aby koszty były przewidywalne.

Gdzie AI wypadło najlepiej

Najbardziej zauważalną korzyścią była szybkość agenta. Gdy tylko pojawiał się alert, agent pobierał odpowiednie logi, rysował wykresy ostatnich metryk i wymieniał trzy ostatnie wdrożenia. Zanim otworzyłem laptopa, wstępna praca detektywistyczna była już wykonana. Z 11 alertów:

  • 8 dotyczyło rutynowych problemów (skoki zużycia pamięci, restarty kontenerów, proste błędy konfiguracji). AI za każdym razem poprawnie identyfikowało przyczynę źródłową.
  • Zauważył stopniowy wzrost zużycia pamięci w mikroserwisie, zanim problem przerodził się w awarię o 2:00 nad ranem, dając zespołowi szansę na wcześniejszą interwencję.
  • Zużycie tokenów przez cały tydzień wyniosło około 30 USD, co mieści się w typowym budżecie na dyżur on-call przy nałożeniu limitów.

Te wyniki przekładają się na wymierną redukcję średniego czasu rozwiązania problemu (MTTR) z 45 do 20 minut, uwalniając inżynierów do pracy o większym znaczeniu.

Gdzie AI popełniło błędy

Pewność siebie nie jest równoznaczna z poprawnością. AI było pewne siebie, ale błędne w 3 z 11 alertów:

  1. Obwiniło niedawną implementację kodu za awarię połączenia z bazą danych, ale wyjaśnienie to było błędne.
  2. W obliczu nieznanej anomalii sieciowej oferowało generyczne poprawki, które nie rozwiązywały podstawowego problemu.
  3. Podczas alertu związanego z obciążeniem zasugerowało skalowanie usługi z 3 do 30 replik. Problemem nie było obciążenie, lecz błędna konfiguracja.

Ponieważ moje zabezpieczenia wymagały ręcznej zgody na każdą operację zapisu, błędy modelu zostały wykryte, zanim mogły wyrządzić szkody. Niemniej jednak, ta sytuacja uwypukliła kluczowe ryzyko: model może generować brzmiące wiarygodnie, ale nieprawdziwe rekomendacje, szczególnie w przypadku nowych problemów.

Zarządzanie kosztami i ryzykiem

Rachunek za tokeny w wysokości 30 USD pokazuje, że uruchamianie LLM w pętli produkcyjnej może być tanie, jeśli zużycie jest monitorowane. Jednak prawdziwym kosztem jest ryzyko operacyjne. Błędne skalowanie wdrożenia może prowadzić do niekontrolowanych wydatków w chmurze, a wycofanie (rollback) dobrego wydania może podważyć zaufanie klientów. Eksperyment potwierdził skuteczność dwóch zabezpieczeń:

  • Blokowanie akcji – Pozwalaj modelowi jedynie na sugerowanie zmian, a nigdy na ich wykonywanie bez kliknięcia człowieka w przypadku zmian o dużym znaczeniu.
  • Limity budżetowe – Ustal sztywne limity zużycia tokenów i informuj zespół, gdy model zbliża się do limitu.

Na co zwrócić uwagę w przyszłości

Do tego czasu zespoły powinny:

  • Śledzić proporcję sugestii wygenerowanych przez AI, które wymagają ręcznej korekty.
  • Mierzyć wpływ na MTTR w różnych kategoriach incydentów (rutynowe vs. nowe).
  • Testować model w środowisku stagingowym przy użyciu syntetycznych alertów, zanim przyzna mu się jakiekolwiek uprawnienia zapisu na produkcji.

Wnioski dla zespołów operacyjnych

  • Automatyzuj nudne 80% – Używaj AI do agregacji logów, korelacji metryk i generowania wstępnych hipotez.
  • Zastrzeż ryzykowne 20% dla ludzi – Skalowanie powyżej umiarkowanego progu, wycofywanie zmian (rollbacks) i usuwanie powinny odbywać się za zgodą człowieka.
  • Traktuj model jako partnera, a nie zastępstwo – Inżynier znający system może szybciej zweryfikować wyniki AI niż nowicjusz, zmieniając asystenta w mnożnik efektywności.

Agent AI nie może jeszcze samodzielnie zarządzać operacjami w chmurze, ale jako partner w procesie triage już teraz przynosi wymierne korzyści w postaci przyspieszenia prac. Kluczem jest kontrolowanie poziomu pewności modelu, stosowanie rygorystycznych mechanizmów kontrolnych oraz pozwolenie modelowi na wykonywanie powtarzalnej, żmudnej pracy, podczas gdy ludzka wiedza i doświadczenie kierują kluczowymi decyzjami.