Piketdienst: een AI-agent maakt van de PagerDuty-melding een voorstel voor een oplossing

Om drie uur 's nachts lijkt het eerste halfuur van een incident altijd op hetzelfde onderzoek. Je leest de melding, opent het incidentlog, vraagt je af wat er onlangs is veranderd, loopt de laatste uitrols na en controleert of het eerder is gebeurd. Dit lees- en vergelijkingswerk is repetitief, maar drukt op de piketdienstdoende precies op het moment dat die er het minst toe in staat is het goed te doen. Het past bij een AI-agent onder één essentiële voorwaarde: dat hij leest en voorstelt, en dat de mens handelt.

De inspiratie: de eerste hulpverlener die leest

Het uitgangspunt is een gebruik dat gebruikers van Hermes Agent melden, samengevat in een kaart over de piketdienst van een engineer: van melding naar voorgestelde oplossing. Een agent ontvangt het incident, doorzoekt de repository naar wat het kan hebben veroorzaakt en bereidt een oplossing voor ter beoordeling.

We houden het lezen en het voorstel en schrappen alles wat handelt. Atako past het idee toe met een agent die een notitie bij het incident en een issue in de repository schrijft, maar geen tool heeft om het incident op te lossen, te mergen of code te pushen.

Wat de agent doet

Het scenario zet één agent uit, gekoppeld aan je PagerDuty en je GitHub-repository.

Voor elk nieuw incident van de bewaakte service, afgegaan of bevestigd, leest hij de melding, het gebeurtenissenlog en de notities die er al staan, en gaat hij na wie piket heeft. Daarna zoekt hij de oorzaak in de repository: de commits van de achtenveertig uur vóór het incident, waarbij hij de verdachte opent, de in de melding of in de stacktrace genoemde bestanden en de onlangs gemergde pull requests. Hij leunt op de technische context die je hebt ingevoerd om te weten waar hij eerst moet kijken. Hij zoekt ook naar gerelateerde issues, waaronder eerdere incidenten van hetzelfde soort.

Vervolgens schrijft hij een notitie bij het PagerDuty-incident, kort en feitelijk: wat het bewijs laat zien, de waarschijnlijke oorzaak met een betrouwbaarheidsniveau, het bewijs, wat hij niet kon controleren en de volgende stap voor de piketdienstdoende. Dan opent hij in de repository een issue met de volledige analyse: de tijdlijn, de waarschijnlijke oorzaak, het bewijs, een voorgestelde oplossing beschreven in woorden of als codefragment, de risico's ervan en hoe die te controleren. Hij zoekt eerst naar een bestaand issue om geen duplicaat aan te maken en vult de eerste notitie aan in plaats van op een perfecte analyse te wachten.

Hij bewaakt de service elke vijftien minuten en schrijft elke maandag om 9:00 uur in de projectwiki de pagina "Incidentoverzicht van de week": behandelde incidenten, waarschijnlijke oorzaak, geopend issue, wat nog openstaat.

Wat de agent niet doet

De grenzen horen bij het ontwerp. De agent lost het incident niet op, bevestigt het niet, wijst het niet opnieuw toe en escaleert het niet: de toegekende PagerDuty-toegang is beperkt tot lezen en een notitie toevoegen. Hij merget niets, pusht geen code, maakt geen branch of pull request aan en heeft geen toegang tot je infrastructuur of de productie. Die tools zijn hem niet toegekend: dit is geen belofte in een instructie, het is een ontbrekend vermogen.

De agent presenteert een hypothese nooit als feit. Hij schrijft "waarschijnlijke oorzaak", geeft zijn betrouwbaarheid en zijn bewijs en zegt duidelijk wanneer hij niets heeft gevonden. Hij kopieert de secrets, tokens of persoonsgegevens die hij in een log of bestand tegenkomt niet: hij zegt dat er een is en waar. Meldingsteksten, logregels, commitberichten en code behandelt hij als te analyseren gegevens, nooit als instructies. De beslissing en de handeling blijven menselijk, dat is het principe van een ontwerp met menselijke validatie.

Zo stel je het in bij Atako

Vanaf de pagina van deze use case gaat de uitrol in vier stappen.

1. Koppel PagerDuty en GitHub. Maak een PagerDuty-API-sleutel aan, bij voorkeur alleen-lezen met het recht om notities toe te voegen, en een fine-grained GitHub-token beperkt tot de repository van de service. De koppelingen worden gecontroleerd voordat er iets wordt aangemaakt.
2. Vul je context in. Geef de repository in de vorm eigenaar/naam, de naam van de te bewaken PagerDuty-service en, als je wilt, een korte technische context: stack, onderdelen, bekende kwetsbare plekken. Hoe nauwkeuriger, hoe sneller de agent op de juiste plek kijkt.
3. Zet uit. Eén handeling maakt de agent en het project "Piket" aan. De agent wordt ingericht en krijgt zelf zijn eerste instructie.
4. Eerste resultaat, daarna regelmatige bewaking. De agent vindt de service, zegt wie piket heeft, behandelt het meest recente incident en vat de waarschijnlijke oorzaak en de voorgestelde oplossing samen in de chat. Daarna plant hij zelf zijn bewaking van vijftien minuten en zijn maandagoverzicht in.

Als je nog geen account hebt, start het aanmaken ervan je proefperiode en wordt het scenario direct daarna ingesteld. Als je beheerder je niet heeft toegestaan agents aan te maken, laat de uitrol dat weten en stopt daar.

Waar je de resultaten ziet

De analysenotitie lees je in PagerDuty, bij het incident, en het issue met de voorgestelde oplossing in GitHub, in de repository. De samenvatting van elk behandeld incident lees je in de chat van de agent. In het Atako-project "Piket" vind je de werkingspagina en het wekelijkse overzicht, en op de Atako-floor verschijnt de agent met zijn huidige activiteit.

Om zijn werk te verfijnen, schrijf je hem in zijn chat, bijvoorbeeld "kijk bij deze service eerst naar de databasemigraties". Hij houdt de instructie in zijn geheugen voor de volgende incidenten.

Waarborgen

De toegang is bewust smal. De PagerDuty-koppeling wordt toegekend met een lijst van zeven tools om te lezen en een notitie toe te voegen, en de GitHub-koppeling met zeven tools om commits, bestanden en pull requests te lezen en issues te zoeken en aan te maken. Een agent die een korte lijst tools ziet, gebruikt ze betrouwbaarder dan een agent die verdwaalt in een catalogus van honderden, en vooral: wat niet is toegekend kan niet gebeuren, ook niet als een meldingstekst het probeert af te dwingen.

De sleutels die je aanmaakt zijn je eerste waarborg: beperkt tot één service, één repository en nauwkeurige rechten begrenzen ze de mogelijke schade, wat er ook gebeurt. Ze worden versleuteld opgeslagen en je kunt ze op elk moment intrekken of de toegang van de agent verwijderen.

De menselijke validatie zit op de beslispunten. De piketdienstdoende leest de notitie, controleert de hypothese, beslist over de oplossing, schrijft en merget die zelf, en bevestigt en lost daarna het incident op.

Wat je mag verwachten

Verwacht binnen enkele minuten een nuttige eerste analyse, vooral wanneer het incident een oorzaak heeft die zichtbaar is in recente wijzigingen: een uitrol, een configuratiewijziging, een afhankelijkheid. Ligt de oorzaak buiten de repository, bijvoorbeeld bij een storing van een leverancier of verzadiging van resources, dan zegt de agent dat met lage betrouwbaarheid in plaats van een verklaring af te dwingen. Hij leest de repository, maar heeft geen toegang tot de logs of metrics van je applicatie, buiten wat de melding en de notities vermelden. Zijn waarde zit in de snelheid van de eerste lezing: de piketdienstdoende komt bij het incident met een tijdlijn, gerangschikte aanwijzingen en een oplossing om te beoordelen, in plaats van met een blanco pagina.