Trex Pi
En undtagelse bliver logget, en alarm udløses, nogen retter det. Den løkke fungerer - for fejl, der er højlydte nok til at gøre opmærksom på sig selv. De fejl, der koster vores kunder rigtige penge, er de stille: leverandøren udskiftede lydløst en SFTP-nøgle, den natlige eksport producerede en gyldig fil med nul rækker, kø-forbrugeren "kører" men behandler ingenting.
Intet fejlede. Alt stoppede.
Flow-målinger frem for helbredstjek
Et helbredstjek besvarer "er processen i live?" Det spørgsmål, der betyder noget, er "skete arbejdet?" Så det primære signal på hver integration, vi drifter, er en flow-måling - poster pr. interval, sammenlignet med hvad det interval normalt bærer:
- Ordrer synkroniseret pr. time, med baselines for hverdag/weekend - en stille søndag er normalt; en stille tirsdag klokken 10:00 er en hændelse.
- Filankomster som deadlines, ikke hændelser: "partner X's prisfil skal foreligge senest kl. 06:30" - alarmen udløses, når den ikke ankommer.
- End-to-end-forsinkelse, målt fra kildens tidsstempel til destinationens commit, ikke fra kø-indgang.
Nul-rækker-problemet
Særlig omtale til den mest almindelige stille fejl, vi ser: et planlagt job, der lykkes med tomt output. Upstream ændrede et filter, en adgangskode mistede læserettighed til én tabel, en fejl i datointervallet ekskluderede alt - og jobbet afsluttes med 0, grønt over hele linjen.
Hver eneste udtræk, vi leverer, har en sandsynlighedsgrænse: den mindste outputstørrelse, der nogensinde har været legitim for det job og den kalenderkontekst. Under grænsen holdes kørslen tilbage, og et menneske bliver spurgt: "dette producerede 0 rækker; de sidste 90 tirsdage gav i gennemsnit 4.200 - fortsæt?" Den ene sikring har fanget flere reelle hændelser end al vores undtagelsesalarmering tilsammen.
Stilhed er et signal. Instrumenter bevidst for det, for det vil aldrig gøre opmærksom på sig selv.