Agent AI do klasyfikacji błędów CI i reagowania na incydenty

Wdrożenie, które psuje się w środku nocy, nie powinno już nikogo budzić. Mimo to w wielu zespołach to wciąż dyżurny inżynier na zimno otwiera logi, szuka winnego commitu i pisze wiadomość na Slacku ostrzegającą innych. Autonomiczny agent AI może przejąć ten pierwszy krok, nigdy nie zastępując ludzkiego osądu w sprawie przyczyny źródłowej czy poprawki.

Problem

Liczby dotyczące niezawodności pipeline'ów CI/CD nie napawają optymizmem. Według raportu State of Software Delivery 2026 firmy CircleCI wskaźnik powodzenia buildów na głównej gałęzi spadł do 70,8%, najniższego poziomu odnotowanego od pięciu lat i wyraźnie poniżej progu 90%, który rekomenduje dostawca (CircleCI, 2026). W praktyce około trzy próby merge'a na dziesięć kończą się niepowodzeniem, zanim jeszcze trafią na produkcję.

Po stronie incydentów raport State of Incident Management firmy Runframe, opublikowany na początku 2026 roku, stwierdza, że udział czasu inżynieryjnego pochłanianego przez rutynową pracę operacyjną (odpowiadanie na alerty, klasyfikowanie błędów, przekazywanie informacji) ponownie wzrósł do 30%, po raz pierwszy od pięciu lat, mimo inwestycji w AI (Runframe, 2026). Ten sam raport podaje, że około dwie trzecie alertów generowanych każdego dnia jest ignorowanych z braku czasu na ich poprawną klasyfikację. To rząd wielkości, który warto traktować z ostrożnością: raport agreguje kilka zewnętrznych badań i wywiady jakościowe, to nie jest jeden bezpośredni pomiar.

Raport DORA 2025 na temat rozwoju oprogramowania wspieranego przez AI idzie w tym samym kierunku w jednej istotnej kwestii: AI wzmacnia to, co już istnieje w organizacji, nie naprawia chwiejnego procesu klasyfikacji, po prostu czyni go bardziej widocznym i szybszym (DORA, 2025). Źle monitorowany pipeline pozostaje źle monitorowany, z AI czy bez, dopóki nikt nie obserwuje błędów nieprzerwanie.

Ten ostatni punkt liczy się szczególnie dla zespołów działających z ograniczonym dyżurem, gdzie jedna zaangażowana osoba pilnuje kilku usług jednocześnie. Błąd builda, który pojawia się o 3 nad ranem, zwykle nie czeka, aż ktoś się obudzi, by go sklasyfikować: albo zostaje zignorowany do rana, albo budzi kogoś dla problemu, który po klasyfikacji okazuje się drobny. Oba scenariusze kosztują, jeden w postaci czasu rozwiązania, drugi w postaci zmęczenia dyżurem narastającego z czasem.

Co robi agent, krok po kroku

W Atako ten agent nie uruchamia się raz i nie zatrzymuje, działa nieprzerwanie we własnym, izolowanym środowisku. Zasilają go dwa mechanizmy wejściowe: przychodzący webhook, który zespół konfiguruje do odbierania zdarzeń CI/CD, oraz zadanie cron, które agent sam planuje, aby okresowo sprawdzać stan workflowów, gdyby webhook przeoczył zdarzenie.

Gdy pojawia się błąd, agent odczytuje logi i stack trace zadania, aby sklasyfikować typ problemu (kompilacja, test, zależność, wdrożenie), a następnie koreluje ten błąd z ostatnimi commitami i pull requestami, aby zidentyfikować prawdopodobnego autora i podejrzaną zmianę. Następnie publikuje strukturalne podsumowanie na Slacku na kanale dyżurnym, z bezpośrednimi linkami do zadania i winnego commitu, a równolegle otwiera zgłoszenie w Jirze powiązane z buildem. Jeśli poziom krytyczności przekracza próg zdefiniowany przez zespół (zablokowane wdrożenie, kilka dotkniętych usług), do właściwych osób trafia dodatkowa eskalacja. Na koniec przygotowuje pierwszą wersję raportu incydentu: chronologię, dotknięte usługi, istotne logi, podejrzewaną przyczynę, celowo pozostawioną otwartą do weryfikacji przez człowieka, a nie prezentowaną jako ostateczny wniosek.

Wykorzystywane integracje

Każda integracja jest przyznawana przez precyzyjny grant, który dokładnie ogranicza, co agent może zrobić, nigdy poprzez ogólny dostęp do całego narzędzia.

GitHub i GitLab dostarczają odczyt pipeline'ów, zadań i commitów, z opcjonalnym zapisem umożliwiającym utworzenie lub skomentowanie issue, jeśli grant obejmuje ten zakres. W GitHub konkretnymi działaniami są list_workflow_runs i get_job_logs_download_url po stronie odczytu, create_issue i add_issue_comment po stronie zapisu.

Slack otrzymuje podsumowania klasyfikacji przez post_message, na kanale wybranym przez zespół, z możliwością zaplanowania przypomnienia przez schedule_message, jeśli incydent pozostaje otwarty zbyt długo.

Jira prowadzi samo zgłoszenie incydentu: create_issue przy otwarciu, update_issue i transition_issue w trakcie rozwiązywania, aż do zamknięcia.

Datadog, gdy zespół je podłączył, pozwala agentowi zestawiać metryki wydajności i trace'y aplikacyjne z błędem CI, aby doprecyzować hipotezę przyczyny źródłowej. PagerDuty nie ma obecnie dedykowanej strony integracji w Atako, ale pozostaje użyteczny jako cel alertu przez wychodzący webhook skonfigurowany po stronie Jiry lub Slacka.

Co zostaje po stronie człowieka

Agent nigdy sam nie decyduje o scaleniu poprawki, i to nie jest szczegół konstrukcyjny, to sposób, w jaki Atako strukturyzuje autonomię. Każde działanie, które agent może wykonać w GitHub, GitLab, Jirze czy Slacku, zależy od jawnego grantu: jakie dokładnie działania są dozwolone, z jakim zakresem (tylko odczyt albo odczyt i zapis). Ten zakres obowiązuje nawet gdyby działanie zapisu przez pomyłkę znalazło się na liście działań dozwolonych w odczycie, a nic nigdy nie jest przyznawane domyślnie przez samo podłączenie narzędzia.

To zostawia trzy rzeczy wyraźnie po stronie człowieka. Po pierwsze, badanie przyczyny źródłowej i decyzję techniczną o poprawce: agent dostarcza punkt wyjścia (logi, podejrzany commit, historię), a nie ostateczną diagnozę. Po drugie, napisanie i scalenie kodu, działanie z natury ludzkie, poza zakresem tego, co agent może zrobić. Po trzecie, post-mortem: dostosowanie progów krytyczności, przegląd runbooka, poprawa reguł klasyfikacji, praca zespołowa, której agent nie zastępuje.

Ten podział odpowiada temu, co nazywa się human-in-the-loop: agent przejmuje powtarzalną, czasochłonną część klasyfikacji, człowiek zachowuje kontrolę nad decyzjami, które naprawdę się liczą. Aby sprawdzić, co agent faktycznie zrobił, każde wywołanie integracji jest rejestrowane, wraz z danym agentem, działaniem, statusem (autoryzowane i wykonane, odrzucone przez kontrolę grantu, lub nieudane po stronie dostawcy) i opóźnieniem. Ten ślad jest widoczny w osi czasu aktywności agenta oraz, dla administratora, w dzienniku integracji całej firmy, eksportowalnym do CSV.

Wynik mierzalny

Najbardziej bezpośrednią korzyścią jest czas między błędem builda a momentem, w którym właściwa osoba ma pełną informację potrzebną do działania. Nie trzeba już czekać, aż człowiek zauważy alert, otworzy logi i ręcznie zestawi je z ostatnimi commitami: agent robi to nieprzerwanie, także o 3 nad ranem, nigdy nie śpiąc ani nie zmieniając nastroju w zależności od obciążenia tygodnia. To nie zastępuje klasycznych metryk DORA, takich jak częstotliwość wdrożeń czy czas przywrócenia po błędzie, ale ogranicza część tych metryk, która zależy wyłącznie od ludzkiej dostępności w danym momencie.

Koszt odpowiada planowi Standard Atako: 20 euro miesięcznie za slot agenta, z 1000 kredytami wliczonymi każdego miesiąca na pokrycie wywołań modelu wykorzystywanych do wnioskowania, klasyfikacji i redagowania treści. Aby oszacować zwrot przed startem, szczegóły znajdują się na stronie cennik.