Kundcase · Detaljhandel

Felsökningen är klar innan någon loggat in

Så blev ett laddningsfel en granskning i stället för en brandsläckning.

Den nattliga laddningen går fel kvart över två. Klockan sex startar en agent som läser loggarna, hittar den verkliga orsaken och avgör var felet hör hemma. Klockan åtta kommer en utvecklare in till en färdig rättning att granska eller en rapport som pekar ut rätt ägare. Gick allt bra har ingenting hänt.

Kund: Internationellt detaljhandelsföretag, avidentifierat
Bransch: Detaljhandel
Uppdrag: AI-driven automatisering inom dataplattformsförvaltning
Omfattning: Daglig körning före arbetsdagens start, deterministisk feldetektering
Roller: Senior data engineer med AI-inriktning
Teknikstack: BigQuery, dbt, git-baserat repo
Leverans: Agent för felsökning av nattliga laddningar, i drift dagligen
Metod: RAID

Utmaningen

Det verkliga priset är att någon rycks ur sitt arbete

Frågar man ett utvecklingsteam vad en trasig nattkörning kostar svarar de antal timmar av felsökning, och det är en underskattning. Det verkliga priset är att någon rycks ur det den höll på med. Arbetet som var planerat pausas och blir därmed försenat.

Ovanpå det är uppgiften personberoende. För att läsa en dbt-logg och förstå vad som gick sönder krävs kunskap om koden, plattformen och affärsdomänen. Det är sällan mer än ett par personer som har den, och det är samma personer som behövs någon annanstans. Avgränsad, återkommande och impopulär, alltså ett bra problem att automatisera.

Lösningen

Ett vanligt skript avgör om något gått fel

Agenten kör varje morgon, efter nattkörningen och före arbetsdagen. Den avgör inte själv om laddningen misslyckats, det gör ett vanligt Python-skript som frågar körningsmiljön och returnerar ett strukturerat svar.

Skillnaden är avgörande, eftersom den vanligaste anledningen till att sådan här automatik inte fungerar är att en språkmodell tycker att något ser trasigt ut. Sex utfall är definierade och fem av dem är fel. Bara en verkligt lyckad körning ger OK, de övriga initierar en felsökning.

Genomförandet

Spärrar som hindrar agenten från att fuska

Merparten av arbetet gick åt till att hindra agenten från att fuska, eftersom den enklaste vägen till ett grönt test nästan aldrig är att laga felet utan att dölja det.

Ingen kodändring föreslås därför utan att felet först återskapats mot riktig data och rättningen bevisats grön, och en rättning får aldrig göra oväntade rader osynliga för testet som fångade dem. I övrigt har agenten läsbehörighet, ingen automatisk merge och ingen åtkomst till test eller produktion.

Resultat

En granskning i stället för en brandsläckning

Diagnosen är gjord innan arbetsdagen börjar, och man behöver inte vara den som kan plattformen bäst för att komma vidare. Det tidsödande momentet att leta orsaken till felet är automatiserat.

De lärdomar som är återanvändbara skrivs dessutom tillbaka till den domänkunskapsbas som dokumentationsagenten håller aktuell, så att nästa person inte gör samma fel. Ett laddningsfel har blivit en granskning i stället för en brandsläckning.

I korthet

01
Diagnosen är klar innan arbetsdagen börjar, varje dag
02
Sex definierade utfall, avgjorda av ett vanligt skript i stället för av en språkmodell
03
Återanvändbara lärdomar skrivs tillbaka till den gemensamma domänkunskapsbasen

Står ni inför en liknande utmaning?