Selvreparerende AI-konsol

Da vi først satte konsollen i drift, var målet enkelt: enhver fejlet agentkørsel skulle udløse en rød markering, så et menneske kunne gribe ind eller lade systemet selv forsøge en reparation. Problemet opstod, da en enkelt fejlende komponent begyndte at generere en ny incident, hver gang den fejlede, selvom det reelt var samme rodårsag, der blev ved med at trigge. Resultatet var en konsol, der konstant råbte op, men hvor godt over en tredjedel af alarmerne var duplikater. Når et overvågningssystem crier ulv for ofte, holder operatørerne op med at reagere med den hast, som reelle fejl kræver. Det er præcis den dynamik, der gør falske alarmer farligere end ingen alarmer overhovedet.

Den mest lærerige del af historien lå ikke i de seks falske alarmer, men i en syvende fejl, der næsten blev overset. Incident-titlerne i konsollen blev trunkeret ved et bestemt antal tegn for at holde overbliksvisningen læsbar. Det virkede fint, indtil en fejlbesked med en lang, teknisk stack-reference blev klippet af midt i den vigtigste del af beskeden. Det, der så ud som en harmløs, gentagen timeout-fejl, var i virkeligheden en fejlkonfigureret retry-mekanisme, der havde forårsaget 25 fejlede kørsler over flere dage, uden at nogen havde reageret, fordi den korte titel aldrig afslørede alvoren. Fejlen lå altså ikke i logikken bag alarmerne, men i den måde information blev præsenteret på. En konsol, der skjuler den vigtigste del af en fejlbesked for at spare plads, er lige så farlig som en konsol, der slet ikke alarmerer.

Løsningen på duplikat-problemet var at indføre fingerprinting af incidents. I stedet for at behandle hver fejlet kørsel som en isoleret hændelse, genererer systemet nu et fingeraftryk baseret på fejltype, den komponent der fejlede, og et normaliseret uddrag af fejlbeskeden, hvor variable elementer som tidsstempler og kørsels-id'er er fjernet. Hvis et nyt fingeraftryk matcher et eksisterende, åbnet incident, bliver den nye hændelse tilføjet som en opdatering til den eksisterende sag i stedet for at oprette en ny. Det betyder, at seks separate røde markeringer nu bliver til én incident med en tæller, der viser, hvor mange gange fejlen er gentaget. Det giver et langt mere ærligt billede: en enkelt, alvorlig, tilbagevendende fejl frem for et virvar af tilsyneladende usammenhængende problemer.

Fingerprinting løste duplikat-problemet, men rejste et nyt spørgsmål: hvornår er en incident egentlig løst? Den adskillelse alene reducerede den daglige mængde af røde markeringer markant, uden at en eneste reel fejl blev skjult.

Det grundlæggende problem var aldrig, at systemet fejlede for ofte. Det var, at overvågningen ikke kunne skelne mellem én fejl, der gentog sig, og ti forskellige fejl. Enhver, der bygger eller driver autonome AI-agenter, bør forvente det samme mønster: fejl clusters, og et overvågningssystem uden fingerprinting vil systematisk overvurdere antallet af reelle problemer. Samtidig er det værd at huske, at brugerflade-beslutninger som titel-trunkering ikke er kosmetiske detaljer. De afgør, om et menneske reagerer på en fejl i tide eller lader den køre i baggrunden i flere dage. Den vigtigste indsigt fra denne uge var derfor ikke teknisk kompleks: alarmtræthed og skjulte fejlbeskeder er to sider af samme problem, og begge løses ved at gøre overvågningen ærlig om, hvad der faktisk sker, hverken mere eller mindre støjende end virkeligheden.