AI-agent til triage af CI-fejl og incidenthåndtering

Et deployment, der fejler midt om natten, bør ikke længere vække nogen. Alligevel er det stadig en vagthavende ingeniør, der i mange teams åbner de kolde logs, leder efter den skyldige commit og skriver Slack-beskeden, der advarer de andre. En autonom AI-agent kan tage sig af dette første trin, uden nogensinde at erstatte den menneskelige vurdering af rodårsag eller rettelse.

Problemet

Tallene for CI/CD-pipelinernes pålidelighed er ikke gode. Ifølge CircleCIs rapport 2026 State of Software Delivery er andelen af succesfulde builds på hovedgrenen faldet til 70,8 procent, det laveste niveau i fem år og et godt stykke under de 90 procent, som udbyderen selv anbefaler (CircleCI, 2026). Konkret fejler omkring tre ud af ti merge-forsøg, før de overhovedet når produktion.

På incidentsiden konstaterer Runframes State of Incident Management-rapport, udgivet primo 2026, at andelen af udviklingstid, der går til rutinemæssigt driftsarbejde (besvare alarmer, triere fejl, eskalere information), er steget til 30 procent, en stigning for første gang i fem år på trods af investeringer i AI (Runframe, 2026). Samme rapport anslår, at omkring to tredjedele af de daglige alarmer ignoreres, fordi der ikke er tid til at triere dem ordentligt. Det er et størrelsesordensestimat, der skal tages med forbehold: rapporten samler flere eksterne studier og kvalitative interviews, det er ikke en enkelt, direkte måling.

DORA-rapporten 2025 om AI-assisteret softwareudvikling peger i samme retning på et centralt punkt: AI forstærker det, der allerede findes i en organisation, den retter ikke op på en dårlig triage-proces, den gør den blot mere synlig, hurtigere (DORA, 2025). En dårligt overvåget pipeline forbliver dårligt overvåget, med eller uden AI, så længe ingen holder øje med fejlene løbende.

Det sidste punkt betyder særligt meget for teams, der kører med et reduceret vagthold, hvor én enkelt person overvåger flere services på samme tid. En byggefejl, der opstår klokken tre om natten, venter som regel ikke på, at nogen vågner for at blive klassificeret: enten forbliver den ignoreret til morgenen, eller også vækker den nogen for et problem, der efter triage viser sig at være mindre alvorligt. Begge udfald koster dyrt, det ene i forlænget løsningstid, det andet i akkumuleret vagttræthed over tid.

Hvad agenten gør, trin for trin

Hos Atako udløses denne agent ikke bare én gang for derefter at stoppe, den kører kontinuerligt i sit eget isolerede miljø. To indgangsmekanismer nærer den: et indgående webhook, som teamet konfigurerer til at modtage CI/CD-hændelser, og en cron-opgave, som agenten selv planlægger for periodisk at tjekke workflowstatus, hvis webhooket skulle overse en hændelse.

Når en fejl opstår, læser agenten job-loggen og stack trace for at klassificere problemtypen (kompilering, test, afhængighed, deployment), og korrelerer derefter fejlen med de seneste commits og pull requests for at identificere den sandsynlige ophavsmand og den mistænkelige ændring. Den poster derefter et struktureret resumé på Slack i vagtkanalen, med direkte links til jobbet og den ansvarlige commit, og opretter samtidig en Jira-sag knyttet til buildet. Hvis alvorligheden overstiger en tærskel, som teamet har defineret (blokeret deployment, flere berørte services), sendes en yderligere eskalering til de rette personer. Til sidst udarbejder den en første version af incidentrapporten: tidslinje, berørte services, relevante logs, mistænkt årsag, bevidst holdt åben for menneskelig gennemgang frem for præsenteret som en endelig konklusion.

Integrationerne i spil

Hver integration gives via et præcist grant, der afgrænser nøjagtigt, hvad agenten må gøre, aldrig generel adgang til hele værktøjet.

GitHub og GitLab leverer læseadgang til pipelines, jobs og commits, med valgfri skriveadgang til at oprette eller kommentere på en issue, hvis grantet dækker det scope. På GitHub er de konkrete handlinger list_workflow_runs og get_job_logs_download_url på læsesiden, create_issue og add_issue_comment på skrivesiden.

Slack modtager triage-resuméerne via post_message, i den kanal teamet vælger, med mulighed for at planlægge en påmindelse via schedule_message, hvis en incident forbliver åben for længe.

Jira fører selve incidentsagen: create_issue ved oprettelsen, update_issue og transition_issue undervejs i løsningen, indtil den lukkes.

Datadog gør det, når teamet har forbundet det, muligt for agenten at krydse performance-metrikker og applikationstraces med CI-fejlen for at kvalificere hypotesen om rodårsagen. PagerDuty har ingen dedikeret integrationsside på Atako lige nu, men kan stadig bruges som alarmmål via et udgående webhook konfigureret i Jira eller Slack.

Det, der stadig er op til mennesket

Agenten beslutter aldrig alene at merge en rettelse, og det er ikke en designdetalje, det er selve måden, Atako strukturerer autonomi på. Hver handling, agenten kan udføre på GitHub, GitLab, Jira eller Slack, afhænger af et eksplicit grant: hvilke præcise handlinger der er tilladt, med hvilket omfang (kun læsning, eller læsning og skrivning). Dette omfang gælder, selv hvis en skrivehandling ved en fejl skulle optræde i en liste over handlinger, der ellers er godkendt til læsning, og intet gives nogensinde som standard blot ved at forbinde et værktøj.

Det efterlader tre ting klart hos mennesket. Først undersøgelsen af rodårsagen og den tekniske beslutning om rettelsen: agenten giver et udgangspunkt (logs, mistænkelig commit, historik), ikke en endelig diagnose. Dernæst skrivning og merging af koden, en handling der pr. natur forbliver menneskelig, uden for det, agenten kan gøre. Til sidst post-mortemet: justering af alvorlighedstærskler, gennemgang af runbooken, forbedring af triage-reglerne, et teamarbejde agenten ikke erstatter.

Denne opdeling hører under det, man kalder human-in-the-loop: agenten tager sig af den gentagne og tidskrævende del af triagen, mennesket beholder kontrollen over de beslutninger, der virkelig betyder noget. For at kunne verificere, hvad agenten reelt har gjort, logges hvert integrationskald med den pågældende agent, handlingen, status (godkendt og udført, afvist af en grant-kontrol, eller fejlet hos udbyderen) og latens. Dette spor er synligt i agentens aktivitetstidslinje og, for en administrator, i hele virksomhedens integrationslog, som kan eksporteres til CSV.

Målbart resultat

Den mest direkte gevinst er tiden mellem buildets fejl og det øjeblik, hvor den rette person har den fulde information til at handle. Ingen grund til at vente på, at et menneske bemærker alarmen, åbner loggene og manuelt sammenholder med de seneste commits: agenten gør det kontinuerligt, også klokken tre om natten, uden nogensinde at sove eller ændre humør efter ugens arbejdsbyrde. Det erstatter ikke de klassiske DORA-metrikker som deployment-frekvens eller genoprettelsestid efter fejl, men det reducerer den del af disse metrikker, der udelukkende afhænger af menneskelig tilgængelighed på et givet tidspunkt.

Prisen følger Atakos Standard-plan: 20 euro om måneden per agent-slot, med 1000 credits inkluderet hver måned til at dække de modelkald, der bruges til ræsonnement, klassificering og skrivning. For at regne på afkastet, før du går i gang, findes detaljerne på siden om priser.