Dyżur techniczny: agent AI zamienia alert PagerDuty w propozycję poprawki

O trzeciej nad ranem pierwsza pół godziny incydentu zawsze wygląda jak to samo śledztwo. Czytasz alert, otwierasz log incydentu, zastanawiasz się, co się ostatnio zmieniło, przeglądasz ostatnie wdrożenia, sprawdzasz, czy to już się zdarzało. Ta praca czytania i porównywania jest powtarzalna, ale obciąża osobę na dyżurze właśnie wtedy, gdy ma najmniej możliwości, by wykonać ją dobrze. Pasuje do agenta AI pod jednym zasadniczym warunkiem: że on czyta i proponuje, a człowiek działa.

Inspiracja: pierwszy reagujący, który czyta

Punktem wyjścia jest zastosowanie opisywane przez użytkowników Hermes Agent, streszczone w karcie o inżynierze na dyżurze: od alertu do propozycji poprawki. Agent otrzymuje incydent, przegląda repozytorium w poszukiwaniu tego, co mogło go wywołać, i przygotowuje poprawkę do przejrzenia.

Zachowujemy czytanie i propozycję, a usuwamy wszystko, co działa. Atako stosuje ten pomysł z agentem, który pisze notatkę przy incydencie i zgłoszenie w repozytorium, ale nie ma narzędzia do rozwiązania incydentu, scalania ani wypychania kodu.

Co robi agent

Scenariusz wdraża jednego agenta, połączonego z Twoim PagerDuty i repozytorium GitHub.

Dla każdego nowego incydentu obserwowanej usługi, wywołanego lub potwierdzonego, czyta alert, dziennik zdarzeń i już istniejące notatki oraz sprawdza, kto jest na dyżurze. Następnie szuka przyczyny w repozytorium: commitów z czterdziestu ośmiu godzin przed incydentem, otwierając podejrzane, plików wskazanych w alercie lub w stack trace oraz ostatnio scalonych pull requestów. Opiera się na wpisanym przez Ciebie kontekście technicznym, by wiedzieć, gdzie patrzeć najpierw. Szuka też powiązanych zgłoszeń, w tym wcześniejszych incydentów tego samego rodzaju.

Potem pisze notatkę przy incydencie PagerDuty, krótką i rzeczową: co pokazują dowody, prawdopodobną przyczynę z poziomem pewności, dowody, czego nie mógł sprawdzić i następny krok dla osoby na dyżurze. Następnie otwiera w repozytorium zgłoszenie z pełną analizą: osią czasu, prawdopodobną przyczyną, dowodami, propozycją poprawki opisaną słowami lub jako fragment kodu, jej ryzykami i sposobem weryfikacji. Najpierw szuka istniejącego zgłoszenia, by nie tworzyć duplikatu, i uzupełnia pierwszą notatkę, zamiast czekać na doskonałą analizę.

Obserwuje usługę co piętnaście minut, a co poniedziałek o 9:00 pisze w wiki projektu stronę „Przegląd incydentów tygodnia”: obsłużone incydenty, prawdopodobna przyczyna, otwarte zgłoszenie, co pozostaje otwarte.

Czego agent nie robi

Ograniczenia są częścią projektu. Agent nie rozwiązuje incydentu, nie potwierdza go, nie przypisuje go ponownie i nie eskaluje: przyznany dostęp do PagerDuty ogranicza się do czytania i dodawania notatki. Niczego nie scala, nie wypycha kodu, nie tworzy ani gałęzi, ani pull requestu i nie ma dostępu do Twojej infrastruktury ani produkcji. Nie ma tych narzędzi: to nie obietnica zapisana w instrukcji, lecz brakująca zdolność.

Agent nigdy nie przedstawia hipotezy jako faktu. Pisze „prawdopodobna przyczyna”, podaje swoją pewność i dowody oraz wyraźnie mówi, gdy niczego nie znalazł. Nie kopiuje sekretów, tokenów ani danych osobowych, na które trafia w logu lub pliku: mówi, że taki jest, i gdzie. Teksty alertów, linie logów, komunikaty commitów i kod traktuje jako dane do analizy, nigdy jako instrukcje. Decyzja i działanie pozostają ludzkie, co jest zasadą projektu z walidacją przez człowieka.

Jak to skonfigurować w Atako

Ze strony tego przypadku użycia wdrożenie wymaga czterech kroków.

1. Połącz PagerDuty i GitHub. Utwórz klucz API PagerDuty, najlepiej tylko do odczytu z prawem dodawania notatek, oraz token GitHub o szczegółowych uprawnieniach, ograniczony do repozytorium usługi. Połączenia są sprawdzane, zanim cokolwiek powstanie.
2. Podaj swój kontekst. Wpisz repozytorium w postaci właściciel/nazwa, nazwę obserwowanej usługi PagerDuty i, jeśli chcesz, krótki kontekst techniczny: stos, komponenty, znane wrażliwe obszary. Im jest dokładniejszy, tym szybciej agent zajrzy we właściwe miejsce.
3. Wdróż. Jedna akcja tworzy agenta i projekt „Dyżur”. Agent jest przygotowywany i sam otrzymuje pierwszą instrukcję.
4. Pierwszy wynik, potem regularna obserwacja. Agent znajduje usługę, mówi, kto jest na dyżurze, obsługuje ostatni incydent i streszcza na czacie prawdopodobną przyczynę oraz propozycję poprawki. Potem sam planuje swoją piętnastominutową obserwację i poniedziałkowy przegląd.

Jeśli nie masz jeszcze konta, jego utworzenie rozpoczyna okres próbny, a scenariusz jest konfigurowany zaraz potem. Jeśli administrator nie zezwolił Ci na tworzenie agentów, wdrożenie informuje o tym i na tym się kończy.

Gdzie zobaczyć wyniki

Notatkę z analizą czyta się w PagerDuty, przy incydencie, a zgłoszenie z propozycją poprawki na GitHubie, w repozytorium. Podsumowanie każdego obsłużonego incydentu czyta się na czacie agenta. W projekcie Atako „Dyżur” znajdziesz stronę opisującą działanie i cotygodniowy przegląd, a na floorze Atako agent pojawia się ze swoją bieżącą aktywnością.

Aby doprecyzować jego pracę, napisz do niego na czacie, na przykład „w tej usłudze patrz najpierw na migracje bazy danych”. Zachowa instrukcję w pamięci na kolejne incydenty.

Zabezpieczenia

Dostęp jest celowo wąski. Połączenie z PagerDuty jest przyznane z listą siedmiu narzędzi do czytania i dodawania notatki, a połączenie z GitHubem z siedmioma narzędziami do czytania commitów, plików i pull requestów oraz wyszukiwania i tworzenia zgłoszeń. Agent widzący krótką listę narzędzi używa ich pewniej niż agent zagubiony w katalogu setek, a przede wszystkim to, co nie jest przyznane, nie może się wydarzyć, nawet jeśli tekst alertu próbuje to wymusić.

Klucze, które tworzysz, to Twoje pierwsze zabezpieczenie: ograniczone do jednej usługi, jednego repozytorium i precyzyjnych uprawnień, ograniczają możliwe szkody, cokolwiek się stanie. Są przechowywane zaszyfrowane i w każdej chwili możesz je unieważnić albo usunąć dostęp agenta.

Walidacja przez człowieka znajduje się w punktach decyzyjnych. Osoba na dyżurze czyta notatkę, sprawdza hipotezę, decyduje o poprawce, sama ją pisze i scala, a następnie potwierdza i rozwiązuje incydent.

Czego się spodziewać

Spodziewaj się przydatnej pierwszej analizy w kilka minut, zwłaszcza gdy incydent ma przyczynę widoczną w ostatnich zmianach: wdrożenie, zmianę konfiguracji, zależność. Gdy przyczyna leży poza repozytorium, na przykład awaria dostawcy lub nasycenie zasobów, agent powie to z niską pewnością, zamiast wymuszać wyjaśnienie. Czyta repozytorium, ale nie ma dostępu do logów ani metryk Twojej aplikacji poza tym, co podają alert i notatki. Jego wartość polega na szybkości pierwszego czytania: osoba na dyżurze przychodzi do incydentu z osią czasu, uszeregowanymi tropami i poprawką do przejrzenia, a nie z pustą kartką.