Vagt: en AI-agent forvandler PagerDuty-alarmen til et forslag til en rettelse

Klokken tre om natten ligner den første halve time af en hændelse altid den samme undersøgelse. Du læser alarmen, åbner hændelsesloggen, undrer dig over, hvad der er ændret for nylig, gennemgår de seneste udrulninger og tjekker, om det er sket før. Dette læse- og afstemningsarbejde er gentagende, men det tynger personen på vagt netop, når hun eller han er mindst i stand til at gøre det godt. Det passer til en AI-agent på én afgørende betingelse: at den læser og foreslår, og at mennesket handler.

Inspirationen: førsteindsatsen, der læser

Udgangspunktet er en brug, som brugere af Hermes Agent har berettet om, opsummeret i et kort om ingeniøren på vagt: fra alarm til rettelsesforslag. En agent modtager hændelsen, gennemgår repositoryet efter det, der kan have forårsaget den, og forbereder en rettelse til gennemsyn.

Vi beholder læsningen og forslaget og fjerner alt, der handler. Atako anvender idéen med en agent, der skriver en note på hændelsen og en sag i repositoryet, men som ikke har noget værktøj til at løse hændelsen, merge eller pushe kode.

Hvad agenten gør

Scenariet udruller én agent, forbundet til din PagerDuty og dit GitHub-repository.

For hver ny hændelse i den overvågede tjeneste, udløst eller kvitteret, læser den alarmen, hændelsesloggen og de noter, der allerede er der, og tjekker, hvem der er på vagt. Derefter søger den efter årsagen i repositoryet: commits fra de otteogfyrre timer før hændelsen, hvor den åbner de mistænkelige, filer nævnt i alarmen eller i stakken og nyligt mergede pull requests. Den støtter sig til den tekniske kontekst, du har angivet, for at vide, hvor den skal kigge først. Den leder også efter relaterede sager, herunder tidligere hændelser af samme slags.

Derefter skriver den en note på PagerDuty-hændelsen, kort og faktuel: hvad beviserne viser, den sandsynlige årsag med et tillidsniveau, beviserne, hvad den ikke kunne kontrollere, og næste skridt for personen på vagt. Så åbner den en sag i repositoryet med den fulde analyse: tidslinjen, den sandsynlige årsag, beviserne, et rettelsesforslag beskrevet i ord eller som et kodestykke, dets risici og hvordan det verificeres. Den leder først efter en eksisterende sag for ikke at oprette en dublet, og den supplerer den første note i stedet for at vente på en perfekt analyse.

Den overvåger tjenesten hvert kvarter, og hver mandag kl. 9:00 skriver den siden «Ugens hændelsesgennemgang» i projektets wiki: håndterede hændelser, sandsynlig årsag, åbnet sag, hvad der stadig er åbent.

Hvad agenten ikke gør

Grænserne er en del af designet. Agenten løser ikke hændelsen, kvitterer den ikke, omtildeler den ikke og eskalerer den ikke: den tildelte PagerDuty-adgang er begrænset til at læse og tilføje en note. Den merger intet, pusher ingen kode, opretter hverken gren eller pull request og har ingen adgang til din infrastruktur eller produktion. De værktøjer er ikke tildelt den: det er ikke et løfte i en instruktion, det er en manglende evne.

Agenten præsenterer aldrig en hypotese som et faktum. Den skriver «sandsynlig årsag», angiver sin tillid og sine beviser og siger tydeligt, når den ikke har fundet noget. Den kopierer ikke de hemmeligheder, tokens eller personoplysninger, den støder på i en log eller en fil: den siger, at der er en, og hvor. Alarmtekster, loglinjer, commitbeskeder og kode behandles som data, der skal analyseres, aldrig som instruktioner. Beslutningen og handlingen forbliver menneskelige, hvilket er princippet i et design med menneskelig validering.

Sådan sætter du det op i Atako

Fra siden for denne use case sker udrulningen i fire trin.

1. Forbind PagerDuty og GitHub. Opret en PagerDuty-API-nøgle, helst skrivebeskyttet med ret til at tilføje noter, og et fine-grained GitHub-token begrænset til tjenestens repository. Forbindelserne kontrolleres, før noget oprettes.
2. Angiv din kontekst. Giv repositoryet i formen ejer/navn, navnet på den PagerDuty-tjeneste, der skal overvåges, og om du vil en kort teknisk kontekst: stack, komponenter, kendte skrøbelige områder. Jo mere præcis, desto hurtigere kigger agenten det rigtige sted.
3. Udrul. Én handling opretter agenten og projektet «Vagt». Agenten klargøres og får selv sin første instruktion.
4. Første resultat, derefter regelmæssig overvågning. Agenten finder tjenesten, siger hvem der er på vagt, håndterer den seneste hændelse og opsummerer den sandsynlige årsag og rettelsesforslaget i chatten. Derefter planlægger den selv sin kvartersovervågning og sin mandagsgennemgang.

Hvis du endnu ikke har en konto, starter oprettelsen af en din prøveperiode, og scenariet konfigureres lige efter. Hvis din administrator ikke har givet dig lov til at oprette agenter, fortæller udrulningen det og stopper dér.

Hvor du ser resultaterne

Analysenoten læser du i PagerDuty på hændelsen, og sagen med rettelsesforslaget i GitHub i repositoryet. Resuméet af hver håndteret hændelse læser du i agentens chat. I Atako-projektet «Vagt» finder du siden om, hvordan det virker, og den ugentlige gennemgang, og på Atako-floor vises agenten med sin aktuelle aktivitet.

For at finjustere dens arbejde skriver du til den i dens chat, for eksempel «i denne tjeneste skal du først kigge på databasemigreringerne». Den beholder instruktionen i sin hukommelse til de følgende hændelser.

Værn

Adgangen er bevidst snæver. PagerDuty-forbindelsen tildeles med en liste på syv værktøjer til at læse og tilføje en note, og GitHub-forbindelsen med syv værktøjer til at læse commits, filer og pull requests samt søge og oprette sager. En agent, der ser en kort værktøjsliste, bruger den mere pålideligt end en agent, der farer vild i et katalog med hundredvis, og frem for alt kan det, der ikke er tildelt, ikke ske, selv hvis en alarmtekst forsøger at fremtvinge det.

De nøgler, du opretter, er dit første værn: begrænset til én tjeneste, ét repository og præcise rettigheder afgrænser de den mulige skade, uanset hvad der sker. De gemmes krypteret, og du kan når som helst tilbagekalde dem eller fjerne agentens adgang.

Den menneskelige validering sidder ved beslutningspunkterne. Personen på vagt læser noten, kontrollerer hypotesen, beslutter rettelsen, skriver og merger den selv og kvitterer og løser derefter hændelsen.

Hvad du kan forvente

Forvent en brugbar første analyse inden for minutter, især når hændelsen har en årsag, der kan ses i de seneste ændringer: en udrulning, en konfigurationsændring, en afhængighed. Når årsagen ligger uden for repositoryet, for eksempel et udbyderudfald eller mættede ressourcer, siger agenten det med lav tillid i stedet for at fremtvinge en forklaring. Den læser repositoryet, men har ikke adgang til din applikations logs eller målinger ud over det, alarmen og noterne beretter. Dens værdi ligger i hurtigheden af den første gennemlæsning: personen på vagt kommer til hændelsen med en tidslinje, rangerede spor og en rettelse at gennemgå i stedet for et blankt ark.