AI-agent til overvågning og triage af bugs indrapporteret af brugere

En bug i produktion melder sig aldrig på det rette tidspunkt. Den dukker op som en fejl gemt i en logstrøm, ingen kigger på i realtid, eller som en supportsag åbnet af en kunde, der beskriver symptomet uden at kende den tekniske årsag. Mellem de to er der ofte ingen automatisk forbindelse: engineering-teamet opdager først problemet, når support til sidst eskalerer, nogle gange timer efter de første brugere stødte på det. En autonom AI-agent, der overvåger begge strømme samtidig, lukker dette hul.

Problemet

Den tid, udviklere bruger på at rette bugs frem for at skrive ny kode, er stadig et af de bedst dokumenterede produktivitetstab i softwareudvikling. En global undersøgelse fra Rollbar blandt 950 udviklere (via Propeller Insights) viste allerede, at 32 procent af udviklerne bruger op til 10 timer om ugen på at rette bugs frem for at skrive kode, og at 38 procent bruger op til en fjerdedel af deres samlede arbejdstid på det (kilde). Denne undersøgelse er fra 2021 og bør læses som en størrelsesorden snarere end et opdateret mål, men konklusionen den dokumenterer, en betydelig del af udviklingstiden opsluges af rettelser frem for opbygning, går igen konsekvent i nyere undersøgelser om udvikleres produktivitet.

Den reelle udfordring er ikke kun rettetiden, det er tiden mellem et problems opståen og dets opdagelse. DORA State of DevOps 2024-rapporten sætter præcise mærker på dette punkt: de bedst præsterende teams genopretter en forringet tjeneste på under en time, de meget velfungerende teams på under en dag, de mellemliggende teams mellem en dag og en uge, og de dårligst præsterende teams kan bruge mellem en uge og en måned (kilde). Afstanden mellem toppen og bunden af denne skala måles altså i uger, ikke i timer, og denne ventetid afhænger direkte af, hvor hurtigt en anomali bliver opdaget og korrekt prioriteret, endnu før den bliver rettet.

Denne ventetid har en direkte omkostning, når problemet rammer produktionen. ITIC 2024-undersøgelsen, gennemført blandt over 1.000 virksomheder verden over mellem november 2023 og marts 2024, viser, at den gennemsnitlige omkostning ved en times nedetid overstiger 300.000 dollars for over 90 procent af mellemstore og store virksomheder, og at 41 procent af de store virksomheder vurderer denne timeomkostning til mellem 1 og 5 millioner dollars (kilde). Disse tal gælder store nedbrud og gælder ikke hver enkelt isoleret bug, men de viser størrelsesordenen af, hvad der står på spil, når et problem, der kunne være opdaget tidligt, forbliver usynligt for længe, druknet i en logstrøm, ingen overvåger løbende.

Et punkt fortjener at blive afklaret, så to beslægtede anvendelser ikke forveksles. CI-opfølgning, der handler om build- og testfejl, før et deployment når produktionen, er et andet problem end det, denne side dækker. Denne side handler om overvågning efter deployment: fejl der reelt opstår hos brugerne, og supportsager de opretter for at beskrive dem, to strømme der ofte fortæller om samme hændelse uden nogensinde at blive krydstjekket automatisk.

Dette manglende krydstjek har en konkret effekt på prioriteringen. En bug, der genererer fem diskrete tekniske fejl i loggene, men udløser tyve identiske supportsager, fortjener en hastende behandling, mens en bug der genererer hundrede tekniske fejl uden en eneste kundeklage ofte kan vente til næste cyklus. Uden at korrelere de to kilder prioriterer et engineering-team blindt, ud fra det rene tekniske volumen, hvilket ikke altid afspejler den reelle effekt, brugerne oplever.

Hvad agenten gør, trin for trin

Agenten overvåger løbende strømme af produktionsfejl, latensmålinger og applikationslogs, samme rå materiale som et klassisk overvågningsværktøj. Forskellen begynder ved næste trin: den overvåger samtidig de supportsager, brugerne åbner, for at finde indrapporteringer, der beskriver en teknisk anomali i almindeligt sprog frem for en stack trace. Den samler derefter fejl og sager, der beskriver det samme problem, i stedet for at behandle hver forekomst isoleret, som et rent alarmeringssystem ville gøre. Ud fra denne samling vurderer den frekvensen, den anslåede brugereffekt og anomaliens kritikalitet. Den opretter en struktureret issue i GitHub eller Linear med beskrivelse af problemet, stack trace, en anslået effekt og et prioritetsniveau allerede fastsat. Den underretter det relevante team i Slack med denne kontekst allerede samlet, og eskalerer kun til vagtholdet, hvis de på forhånd definerede kritikalitetstærskler overskrides.

Integrationerne i spil

Detektionen bygger på Datadog, eller på Sentry for teams, der foretrækker et værktøj specialiseret i fejlsporing og stack traces. Korrelationen med brugeroplevelsen sker via Intercom, eller Zendesk afhængigt af hvilket supportværktøj der allerede er på plads, for at krydstjekke åbne sager med de tekniske fejl, der er opdaget i overvågningen. Oprettelsen af issues sker i GitHub eller Linear afhængigt af teamets opfølgningsværktøj, med beskrivelse, stack trace og prioritetsniveau allerede udfyldt. Slack bærer teamunderretningerne, og en eskalering til PagerDuty kan udløses for hændelser, hvis kritikalitet overstiger den definerede tærskel.

Det, der stadig er op til mennesket

Engineering-teamet definerer kritikalitetstærskler og eskaleringsregler ved opsætning af agenten, en indledende afstemning der derefter afgør, hvad der udløser eller ikke udløser en alarm til vagtholdet. Det modtager allerede trierede og kontekstualiserede issues, stack trace og anslået effekt inklusive, og skal blot skrive rettelsen frem for at genskabe konteksten ud fra rå logs. Det justerer prioriteringsreglerne, efterhånden som produktet udvikler sig, et nyt modul eller en ny integration ændrer nødvendigvis, hvad der tæller som kritisk på et givet tidspunkt. Selve rettelsen, afgørelsen om, hvad der fortjener en øjeblikkelig hotfix frem for en planlagt rettelse, forbliver fuldt ud en menneskelig beslutning.

Målbart resultat

Den mest direkte gevinst er en kortere ventetid mellem et problems opståen i produktion og dets fremkomst som en brugbar issue, frem for druknet i en logstrøm eller spredt ud over flere supportsager, der beskriver samme symptom uden at være koblet sammen. I lyset af den forskel, DORA-rapporten dokumenterer mellem en gendannelse af tjenesten på under en time for de bedst præsterende teams og flere dage for de mellemliggende teams, påvirker en kortere detektions- og triage-tid direkte et teams evne til at nærme sig toppen af denne skala frem for at forblive fastlåst i middelklassen. Den anden gevinst er mindre støj for vagtholdet: ved kun at eskalere anomalier, hvis kritikalitet overstiger en defineret tærskel, reducerer agenten unødvendige afbrydelser for mindre fejl, et punkt der er særligt følsomt for små teams uden et udvidet vagtsystem, hvor hver nattevækning direkte påvirker næste dags tilgængelighed og koncentration, med en kumulativ effekt over flere uger, hvis støjen forbliver dårligt filtreret.