Een exception wordt gelogd, een alarm gaat af, iemand lost het op. Die cyclus werkt - voor storingen die luid genoeg zijn om zichzelf aan te kondigen. De storingen die onze klanten echt geld kosten zijn de stille: de leverancier roteerde stilletjes een SFTP-sleutel, de nachtelijke export produceerde een geldig bestand met nul rijen, de queue-consument "draait" maar verwerkt niets.
Er ging niets fout. Alles stopte.
Flowmetrics boven health checks
Een health check beantwoordt de vraag "leeft het proces?" De vraag die ertoe doet is "heeft het werk plaatsgevonden?" Daarom is het primaire signaal op elke integratie die wij draaien een flowmetric - records per interval, vergeleken met wat dat interval normaal gesproken bevat:
- Orders gesynchroniseerd per uur, met baselines voor doordeweeks/weekend - een rustige zondag is normaal; een rustige dinsdag om 10:00 uur is een incident.
- Bestandsaankomsten als deadlines, niet als events: "het prijsbestand van partner X moet er om 06:30 uur zijn" - het alarm gaat af wanneer het niet aankomt.
- End-to-end vertraging, gemeten vanaf de brontijdstempel tot de bestemmingscommit, niet vanaf binnenkomst in de wachtrij.
Het nul-rijenprobleem
Speciale vermelding voor de meest voorkomende stille storing die wij zien: een geplande taak die slaagt met lege output. Upstream is een filter gewijzigd, een credential verloor leestoegang tot één tabel, een bug in het datumvenster sloot alles uit - en de taak sluit af met exit-code 0, over de hele linie groen.
Elke extract die wij opleveren draagt een "aannemelijkheidsondergrens": de kleinste outputomvang die ooit legitiem is geweest voor die taak en die kalendercontext. Onder de ondergrens wordt de run vastgehouden en wordt een mens gevraagd: "dit leverde 0 rijen op; de laatste 90 dinsdagen was het gemiddelde 4.200 - doorgaan?" Die ene beveiliging heeft meer echte incidenten opgevangen dan al onze exception-alerting samen.
Stilte is een signaal. Instrumenteer er bewust voor, want het zal zichzelf nooit aankondigen.