Det kan du nu med event sourcing. I hvert fald i dine systemer.
Det lyder som en reklame, og jeg ved det godt. Men prøv at tænke på, hvor tit spørgsmålet egentlig bliver stillet i en virksomhed. En prisregel har været forkert i tre uger. Hvor mange ordrer blev ramt, og hvad skulle de have kostet? Revisoren vil vide, hvad I vidste den 4. marts, og ikke hvad I ved i dag. Eller en AI-agent traf en mærkelig beslutning i går, og nu vil I se den ske igen, langsomt.
I de fleste systemer er svaret det samme: Det kan vi ikke. Databasen ved, hvordan tingene ser ud nu. Hvordan de kom til at se sådan ud, er skrevet over.
Kassekladden igen
I det forrige indlæg beskrev jeg loggen som den tredje måde at bygge et AI-system på. Man gemmer ikke tilstanden. Man gemmer hændelserne: Ordre modtaget, pris beregnet, rabat givet, godkendt af Mette, sendt til kunden. Hver hændelse skrives én gang og ændres aldrig. Tilstanden lige nu regnes ud ved at gennemgå dem forfra.
En regnskabsmedarbejder vil kende princippet med det samme. Man retter ikke en postering med viskelæder. Man laver en modpostering. Saldoen er bare summen af det hele.
Det er den regel, der gør tidsrejsen mulig. Når intet bliver skrevet over, ligger fortiden der stadig.
Et replay er at spille båndet om
Et replay betyder, at man tager hændelserne og kører dem igennem igen. Det lyder banalt. Det kan fire ting, som et almindeligt system ikke kan.
Se fortiden, som den var
Stop afspilningen ved den 4. marts klokken 14, og du har systemets tilstand præcis dér. Ikke en rekonstruktion ud fra hukommelse og mails, men det, systemet faktisk vidste. Tager tilsynet, kunden eller bestyrelsen fat i en afgørelse, kan man vise, hvad den blev truffet på.
Ret en fejl bagud
Prisreglen var forkert i tre uger. Ret reglen, og spil de tre ugers hændelser igennem med den nye version. Nu har du en liste over hver ordre, der blev ramt, og hvad forskellen var. I et almindeligt system ville det samme spørgsmål kræve en uges gravearbejde i logfiler og regneark, og svaret ville stadig være et skøn.
Stil nye spørgsmål til gamle data
Ledelsen vil gerne se, hvor lang tid der går fra et tilbud sendes, til kunden svarer. Ingen tænkte på det, da systemet blev bygget, så der er intet felt til det. Med en hændelseslog betyder det ingenting. Hændelserne «tilbud sendt» og «svar modtaget» ligger der i forvejen med tidsstempel, og en ny rapport kan bygges på to års historik fra første dag.
Det er den gevinst, jeg synes er mest undervurderet. De spørgsmål, man kommer til at stille om et år, kender man ikke i dag. En log gemmer svaret på dem alligevel.
Test i morgen på i går
Den her er særligt relevant for AI. Vil I skifte til en ny sprogmodel eller en ny prompt, er det store spørgsmål, om den opfører sig bedre på jeres egne sager. Med en log kan I tage sidste måneds rigtige henvendelser og spille dem igennem den nye version, side om side med den gamle. Så sammenligner I på virkeligheden og ikke på leverandørens demo.
Hvor jeg selv har brugt det
Min lille godkendelsesapp, janus, har ingen tabel med spørgsmål. Den har en strøm af hændelser og en funktion på omkring 70 linjer, der folder dem til en tilstand. Jeg kan smide hele cachen ud, genstarte og få præcis det samme tilbage, fordi cachen aldrig var sandheden. Det var loggen.
Og da kæden fra telefonen til udgivelsen på Folkets holdt op med at virke, kunne jeg se præcis, hvilket led der knækkede. Svaret fra telefonen lå der. Det nåede bare aldrig videre. Uden loggen havde jeg gættet på, om nogen overhovedet havde trykket.
Tre ting, der går galt, hvis man ikke passer på
Tidsmaskinen har nogle regler, og de er ikke valgfrie.
Et replay må ikke gøre noget igen. Spiller man ordrerne igennem for at finde fejlen i prisreglen, skal systemet ikke sende tre ugers ordrebekræftelser til kunderne en gang til. Det betyder, at der skal være et skarpt skel mellem den del af systemet, der regner på hændelserne, og den del, der handler ud af huset. Den første må køres om så tit, man vil. Den anden må kun reagere på nye hændelser. Det skel skal bygges fra starten, og det er det, der oftest bliver glemt.
Fortiden kan ikke ændres, heller ikke når man gerne vil. En hændelse fra i fjor blev skrevet med den struktur, systemet havde dengang. Kommer der nye felter til, skal koden stadig kunne læse de gamle hændelser. Det er en løbende disciplin og ikke noget, man løser én gang.
En log, der aldrig glemmer, kolliderer med GDPR. Retten til at blive glemt passer dårligt til en historik, der aldrig ændres. Det almindelige greb er at kryptere personoplysningerne med en nøgle pr. person og slette nøglen, når personen skal glemmes. Hændelserne står der stadig, men navnet kan ikke længere læses. Det skal besluttes, før den første kunde er skrevet ind, ikke når den første anmodning kommer. Mere om det i Sikkerhed.
Skal I så bygge alt sådan?
Nej. Et system, der hver morgen trækker fakturaer ind i et regneark, har ingen fortid, der er værd at spole tilbage til. Der er en log bare en ekstra ting, den næste udvikler skal forstå.
Men stil to spørgsmål, før I bygger noget, hvor en AI træffer beslutninger:
Kommer nogen til at spørge, hvorfor systemet gjorde, som det gjorde?
Kommer I til at ville ændre en regel og se, hvad den ville have betydet bagud?
Er svaret ja til bare ét af dem, skal hændelserne gemmes fra første dag. Man kan nemlig spole tilbage i tiden med event sourcing, men kun til det øjeblik, man begyndte at optage.