Jour: en AI-agent förvandlar PagerDuty-larmet till ett förslag på åtgärd

Klockan tre på natten ser den första halvtimmen av en incident alltid ut som samma utredning. Du läser larmet, öppnar incidentloggen, undrar vad som ändrats på sistone, går igenom de senaste driftsättningarna och kollar om det har hänt förut. Det här läs- och jämförelsearbetet är repetitivt, men det tynger personen i jour just när hen är minst i stånd att göra det bra. Det passar en AI-agent på ett avgörande villkor: att den läser och föreslår, och att människan agerar.

Inspirationen: den första insatsen som läser

Utgångspunkten är ett användningsområde som användare av Hermes Agent har berättat om, sammanfattat i ett kort om ingenjören i jour: från larm till åtgärdsförslag. En agent får incidenten, går igenom repot efter det som kan ha orsakat den och förbereder en åtgärd att granska.

Vi behåller läsandet och förslaget och tar bort allt som agerar. Atako tillämpar idén med en agent som skriver en anteckning på incidenten och ett ärende i repot, men som saknar verktyg för att lösa incidenten, merga eller pusha kod.

Vad agenten gör

Scenariot driftsätter en agent, kopplad till din PagerDuty och ditt GitHub-repo.

För varje ny incident i den bevakade tjänsten, utlöst eller kvitterad, läser den larmet, händelseloggen och de anteckningar som redan finns, och kontrollerar vem som är i jour. Sedan söker den orsaken i repot: commits från de fyrtioåtta timmarna före incidenten, där den öppnar de misstänkta, filer som nämns i larmet eller i stackspårningen och nyligen mergade pull requests. Den utgår från det tekniska sammanhang du har angett för att veta var den ska titta först. Den söker också efter relaterade ärenden, inklusive tidigare incidenter av samma slag.

Sedan skriver den en anteckning på PagerDuty-incidenten, kort och saklig: vad beläggen visar, den sannolika orsaken med en konfidensnivå, beläggen, vad den inte kunde kontrollera och nästa steg för personen i jour. Därefter öppnar den ett ärende i repot med hela analysen: tidslinjen, den sannolika orsaken, beläggen, ett åtgärdsförslag beskrivet i ord eller som kodavsnitt, dess risker och hur det verifieras. Den söker först efter ett befintligt ärende för att inte skapa en dubblett, och kompletterar den första anteckningen i stället för att vänta på en perfekt analys.

Den bevakar tjänsten var femtonde minut, och varje måndag kl. 9:00 skriver den sidan "Veckans incidentgenomgång" i projektets wiki: hanterade incidenter, sannolik orsak, öppnat ärende, vad som fortfarande är öppet.

Vad agenten inte gör

Gränserna är en del av utformningen. Agenten löser inte incidenten, kvitterar den inte, tilldelar den inte om och eskalerar den inte: den beviljade PagerDuty-åtkomsten är begränsad till att läsa och lägga till en anteckning. Den mergar ingenting, pushar ingen kod, skapar varken gren eller pull request och har ingen åtkomst till din infrastruktur eller produktion. De verktygen är inte beviljade: det är inget löfte i en instruktion, det är en förmåga som saknas.

Agenten presenterar aldrig en hypotes som ett faktum. Den skriver "sannolik orsak", anger sin konfidens och sina belägg och säger tydligt när den inte hittat något. Den kopierar inte hemligheter, tokens eller personuppgifter som den stöter på i en logg eller en fil: den säger att det finns en och var. Larmtexter, loggrader, commitmeddelanden och kod behandlas som data att analysera, aldrig som instruktioner. Beslutet och handlingen förblir mänskliga, vilket är principen bakom en design med mänskligt godkännande.

Så ställer du in det i Atako

Från sidan för det här användningsfallet sker driftsättningen i fyra steg.

1. Koppla PagerDuty och GitHub. Skapa en PagerDuty-API-nyckel, helst skrivskyddad med rätt att lägga till anteckningar, och en fine-grained GitHub-token begränsad till tjänstens repo. Kopplingarna kontrolleras innan något skapas.
2. Ange ditt sammanhang. Ange repot i formen ägare/namn, namnet på PagerDuty-tjänsten som ska bevakas och, om du vill, ett kort tekniskt sammanhang: stack, komponenter, kända ömtåliga områden. Ju mer precist det är, desto snabbare tittar agenten på rätt ställe.
3. Driftsätt. En enda åtgärd skapar agenten och projektet "Jour". Agenten förbereds och får sin första instruktion på egen hand.
4. Första resultat, sedan regelbunden bevakning. Agenten hittar tjänsten, säger vem som är i jour, hanterar den senaste incidenten och sammanfattar den sannolika orsaken och åtgärdsförslaget i chatten. Därefter schemalägger den själv sin femtonminutersbevakning och sin måndagsgenomgång.

Om du ännu inte har ett konto startar skapandet av ett din provperiod, och scenariot konfigureras direkt efteråt. Om din administratör inte har tillåtit dig att skapa agenter meddelar driftsättningen det och stannar där.

Var du ser resultaten

Analysanteckningen läser du i PagerDuty, på incidenten, och ärendet med åtgärdsförslaget i GitHub, i repot. Sammanfattningen av varje hanterad incident läser du i agentens chatt. I Atako-projektet "Jour" hittar du sidan om hur det fungerar och veckogenomgången, och på Atako-floor visas agenten med sin pågående aktivitet.

För att finjustera dess arbete skriver du till den i dess chatt, till exempel "titta först på databasmigreringarna i den här tjänsten". Den behåller instruktionen i sitt minne för kommande incidenter.

Skyddsräcken

Åtkomsten är medvetet smal. PagerDuty-kopplingen beviljas med en lista på sju verktyg för att läsa och lägga till en anteckning, och GitHub-kopplingen med sju verktyg för att läsa commits, filer och pull requests samt söka och skapa ärenden. En agent som ser en kort verktygslista använder den mer pålitligt än en agent som går vilse i en katalog på hundratals, och framför allt kan det som inte är beviljat inte hända, även om en larmtext försöker tvinga fram det.

Nycklarna du skapar är ditt första skyddsräcke: begränsade till en tjänst, ett repo och precisa rättigheter avgränsar de den möjliga skadan, vad som än händer. De lagras krypterade, och du kan när som helst återkalla dem eller ta bort agentens åtkomst.

Det mänskliga godkännandet sitter vid beslutspunkterna. Personen i jour läser anteckningen, kontrollerar hypotesen, bestämmer åtgärden, skriver och mergar den själv och kvitterar och löser sedan incidenten.

Vad du kan förvänta dig

Räkna med en användbar första analys inom minuter, särskilt när incidenten har en orsak som syns i de senaste ändringarna: en driftsättning, en konfigurationsändring, ett beroende. När orsaken ligger utanför repot, till exempel ett leverantörsavbrott eller överbelastade resurser, säger agenten det med låg konfidens i stället för att tvinga fram en förklaring. Den läser repot men har ingen åtkomst till din applikations loggar eller mätvärden utöver det som larmet och anteckningarna återger. Värdet ligger i snabbheten i den första genomläsningen: personen i jour kommer till incidenten med en tidslinje, rangordnade spår och en åtgärd att granska, i stället för med ett tomt blad.