Agent AI do monitorowania i klasyfikacji błędów zgłaszanych przez użytkowników

Błąd na produkcji nigdy nie zgłasza się w dogodnym momencie. Pojawia się jako wpis zagubiony w strumieniu logów, którego nikt nie ogląda na żywo, albo jako zgłoszenie wsparcia otwarte przez klienta, który opisuje objaw, nie znając technicznej przyczyny. Między tymi dwoma źródłami często nie ma żadnego automatycznego połączenia: zespół inżynierski odkrywa problem dopiero, gdy wsparcie w końcu eskaluje sprawę, czasem godziny po tym, jak spotkali się z nim pierwsi użytkownicy. Autonomiczny agent AI, który monitoruje oba strumienie jednocześnie, zamyka tę lukę.

Problem

Czas, jaki deweloperzy poświęcają na poprawianie błędów zamiast na nowy kod, pozostaje jedną z najlepiej udokumentowanych strat produktywności w inżynierii oprogramowania. Globalne badanie przeprowadzone przez Rollbar na 950 deweloperach (za pośrednictwem Propeller Insights) pokazało już wcześniej, że 32% deweloperów poświęca do 10 godzin tygodniowo na poprawianie błędów zamiast pisania kodu, a 38% przeznacza na to nawet jedną czwartą swojego czasu pracy (źródło). To badanie pochodzi z 2021 roku i warto je czytać raczej jako rząd wielkości niż aktualny pomiar, ale wniosek, który dokumentuje, znacząca część czasu inżynierii pochłaniana przez poprawianie zamiast budowania, powraca stale w nowszych badaniach nad produktywnością deweloperów.

Prawdziwym wyzwaniem jest nie tylko czas poprawy, lecz opóźnienie między pojawieniem się problemu a jego wykryciem. Raport DORA State of DevOps 2024 ustala precyzyjne punkty odniesienia w tej kwestii: zespoły o najwyższej wydajności przywracają zdegradowaną usługę w mniej niż godzinę, zespoły bardzo wydajne w mniej niż dobę, zespoły średnie od dnia do tygodnia, a zespoły najmniej wydajne mogą potrzebować od tygodnia do miesiąca (źródło). Różnica między górą a dołem tej skali liczy się więc w tygodniach, nie w godzinach, a opóźnienie to zależy bezpośrednio od tego, jak szybko anomalia zostaje wykryta i poprawnie sklasyfikowana, jeszcze zanim zostanie naprawiona.

To opóźnienie ma bezpośredni koszt, gdy problem dotyka produkcji. Badanie ITIC 2024, przeprowadzone na ponad 1000 firm na świecie między listopadem 2023 a marcem 2024, wskazuje, że średni koszt godziny niedostępności przekracza 300 000 dolarów dla ponad 90% firm średniej i dużej wielkości, a 41% dużych przedsiębiorstw szacuje ten koszt godzinowy na od 1 do 5 milionów dolarów (źródło). Te liczby dotyczą poważnych awarii i nie odnoszą się do każdego pojedynczego błędu, ale pokazują rząd wielkości stawki, gdy problem, który mógł zostać wykryty wcześnie, pozostaje niewidoczny zbyt długo, zagubiony w strumieniu logów, którego nikt nie monitoruje nieprzerwanie.

Warto wyjaśnić jedną kwestię, aby nie mylić dwóch bliskich zastosowań. Monitorowanie CI, dotyczące błędów builda i testów zanim wdrożenie dotrze na produkcję, to inny problem niż ten opisany tutaj. Ta strona dotyczy monitorowania po wdrożeniu: błędów, które rzeczywiście występują u użytkowników, oraz zgłoszeń wsparcia, które oni otwierają, aby je opisać, dwóch strumieni, które często opowiadają o tym samym incydencie, nigdy nie będąc automatycznie ze sobą powiązanymi.

Ten brak powiązania ma konkretny wpływ na priorytetyzację. Błąd, który generuje pięć dyskretnych błędów technicznych w logach, ale wywołuje dwadzieścia identycznych zgłoszeń wsparcia, zasługuje na pilne działanie, podczas gdy błąd generujący sto błędów technicznych, na który nie skarży się ani jeden klient, może zwykle poczekać do kolejnego cyklu. Bez skorelowania obu źródeł zespół inżynierski priorytetyzuje po omacku, opierając się wyłącznie na wolumenie technicznym, co nie zawsze odzwierciedla rzeczywisty wpływ odczuwany przez użytkowników.

Co robi agent, krok po kroku

Agent nieprzerwanie monitoruje strumienie błędów produkcyjnych, metryki opóźnień i logi aplikacyjne, ten sam surowy materiał co klasyczne narzędzie monitoringu. Różnica zaczyna się na kolejnym etapie: monitoruje równolegle zgłoszenia wsparcia otwarte przez użytkowników, aby wyłapać sygnały opisujące anomalię techniczną językiem potocznym, a nie stack trace'em. Następnie grupuje błędy i zgłoszenia opisujące ten sam problem, zamiast traktować każde wystąpienie osobno, jak zrobiłby to surowy system alertujący. Na podstawie tego grupowania ocenia częstotliwość, szacowany wpływ na użytkowników i krytyczność anomalii. Tworzy ustrukturyzowane issue w GitHub lub Linear z opisem problemu, stack trace'em, szacowanym wpływem i już ustalonym poziomem priorytetu. Powiadamia właściwy zespół na Slacku wraz z tym już zebranym kontekstem i eskaluje do dyżuru tylko, gdy wcześniej ustalone progi krytyczności zostają przekroczone.

Wykorzystywane integracje

Wykrywanie opiera się na Datadog albo na Sentry, dla zespołów preferujących narzędzie wyspecjalizowane w śledzeniu błędów i stack trace'ów. Korelacja z doświadczeniem użytkownika przechodzi przez Intercom, albo Zendesk, w zależności od narzędzia wsparcia już wdrożonego, aby zestawić otwarte zgłoszenia z wykrytymi błędami technicznymi po stronie monitoringu. Tworzenie issue odbywa się w GitHub lub Linear, w zależności od narzędzia śledzenia zespołu, z opisem, stack trace'em i poziomem priorytetu już wypełnionymi. Slack przenosi powiadomienia zespołowe, a eskalacja do PagerDuty może zostać wywołana dla incydentów, których krytyczność przekracza ustalony próg.

Co zostaje po stronie człowieka

Zespół inżynierski definiuje progi krytyczności i zasady eskalacji podczas konfiguracji agenta, wstępne ustalenie, które określa później, co wywołuje, a co nie, alert do dyżuru. Otrzymuje już sklasyfikowane i skontekstualizowane issue, wraz ze stack trace'em i szacowanym wpływem, i musi już tylko napisać poprawkę zamiast odtwarzać kontekst z surowych logów. Dostosowuje reguły priorytetyzacji w miarę ewolucji produktu, nowy moduł czy nowa integracja zawsze zmieniają to, co w danym momencie liczy się jako krytyczne. Sama poprawka, decyzja, co zasługuje na natychmiastowy hotfix, a co na zaplanowaną korektę, pozostaje w całości decyzją człowieka.

Wynik mierzalny

Najbardziej bezpośrednią korzyścią jest skrócony czas między pojawieniem się problemu na produkcji a jego zgłoszeniem w formie gotowego do działania issue, zamiast zagubienia w strumieniu logów albo rozproszenia między kilka zgłoszeń wsparcia opisujących ten sam objaw bez powiązania. Biorąc pod uwagę różnicę udokumentowaną w raporcie DORA między przywróceniem usługi w mniej niż godzinę dla zespołów najbardziej wydajnych a kilkoma dniami dla zespołów średnich, skrócenie czasu wykrycia i klasyfikacji bezpośrednio wpływa na zdolność zespołu do zbliżenia się do góry tej skali, zamiast pozostawania w przeciętnej. Druga korzyść to mniej szumu dla dyżuru: przekazując dalej tylko anomalie, których krytyczność przekracza ustalony próg, agent ogranicza niepotrzebne przerwania z powodu drobnych błędów, punkt szczególnie istotny dla małych zespołów bez rozbudowanej rotacji dyżurowej, gdzie każde nocne wybudzenie bezpośrednio odbija się na dostępności i koncentracji następnego dnia, z efektem kumulacyjnym w ciągu kilku tygodni, jeśli szum pozostaje słabo filtrowany.