Zeven platforms, één pieper — hoe ik storingen zie voordat gebruikers bellen

Drie manieren waarop iets kapot is

De meeste monitoring dekt maar één van de drie, en het is toevallig de onschuldigste.

Het valt om. De server is weg, het proces is gestopt, de database accepteert geen verbindingen meer. Dit is de categorie waar elke uptimecheck op is gebouwd, en het is de makkelijkste: iets antwoordt of het antwoordt niet. Het is ook de zeldzaamste. Moderne systemen vallen niet zo vaak meer om.

Het draait, maar doet niets. De P2000-ontvanger staat keurig aan, het proces gebruikt netjes zijn geheugen, de statuspagina is groen — en er is al twintig minuten geen enkele melding binnengekomen. De pijplijn is niet gecrasht, hij is blijven hangen op een socket die nooit meer iets stuurt. Dit is de gevaarlijke categorie, want alles wat je normaal meet ziet er goed uit.

Het draait, doet iets, maar het klopt niet. De stroomprijzen die binnenkomen zijn die van gisteren. De geocoding zet een halve regio in de Noordzee omdat een externe dienst een veldnaam heeft hernoemd. Er is geen fout, er is geen foutmelding, er is alleen verkeerde data die met volle overtuiging wordt geserveerd. Deze is het duurst, omdat gebruikers hem eerder zien dan jij.

Vrijwel al mijn ellende van de afgelopen jaren zit in categorie twee en drie. Daar is mijn monitoring dus op gebouwd, en dat betekent dat “is de site bereikbaar” bij mij eigenlijk geen check meer is, maar een bijvangst.

Hartslagen in plaats van pings

De omslag kwam toen ik de logica omdraaide. Vroeger vroeg ik van buitenaf of iets nog leefde; nu laat ik elk proces zelf een seintje sturen zodra het zijn werk succesvol heeft gedaan. Blijft dat seintje langer dan een afgesproken tijd uit, dan alarmeert de monitor. Een dodemansknop, precies zoals hij in een cabine zit: niet drukken is het signaal.

Dat lost categorie twee in één klap op, want een hangend proces stuurt geen hartslag. En het dwingt je om per pijplijn na te denken over wat “normaal” is, wat verrassend nuttig blijkt. Een paar van mijn drempels:

• P2000-verwerking: een venster dat meebeweegt met het tijdstip. Op een doordeweekse ochtend is tien minuten stilte verdacht; om vier uur 's nachts is dat volstrekt normaal en ligt de grens veel verder weg. Eén vaste drempel geeft je 's nachts vals alarm of overdag een blinde vlek — je mag kiezen welke.
• Dagprijzen: de day-aheadveiling sluit rond het middaguur. Staan de prijzen voor morgen om drie uur 's middags nog niet in de database, dan is er iets mis bij de bron of bij mij, en in beide gevallen wil ik dat weten vóór de avondspits van bezoekers.
• Pushmeldingen: niet of ik ze verstuur, maar of ze worden geaccepteerd. Een verlopen sleutel bij Apple of Google levert een vrolijk verstuurde melding op die nergens aankomt. Dat is categorie drie in zijn zuiverste vorm.

Daarbovenop draait een tweede laag die niet naar processen kijkt maar naar aantallen: het aantal verwerkte meldingen in dit uur, vergeleken met hetzelfde uur vorige week. Dat is geen slimme anomaliedetectie, het is een ondergrens en een bovengrens die ik met de hand heb ingesteld. Maar het heeft me al twee keer een storing bij een externe bron laten zien voordat de bron het zelf doorhad.

Eerst zelf oplossen, dan pas klagen

Een alarm is geen prestatie. Een alarm is de erkenning dat het systeem iets niet zelf kon. Dus staat er voor elke melding die mij bereikt eerst een laag die probeert het probleem weg te nemen: processen die bij een blokkade opnieuw starten, verbindingen die zichzelf opnieuw opbouwen met oplopende wachttijd, wachtrijen die achterstand inhalen zodra de bron terug is, certificaten die ruim op tijd vernieuwen.

En er is één regel die de lijst korter houdt dan hij anders zou zijn: wat ik twee keer met de hand heb opgelost, wordt de derde keer een script. Niet omdat handmatig werk zo erg is, maar omdat de tweede keer bewijst dat het geen incident was. Handmatige stappen die zich herhalen zijn uitgesteld werk met rente.

De escalatieladder

Wat overblijft, wordt ingedeeld. Niet elk probleem verdient dezelfde aandacht, en het grootste risico van monitoring is dat je er ongevoelig voor wordt. Een melding die je hebt leren negeren, is erger dan geen melding: hij geeft je het gevoel dat je het weet.

Niveau vier bestaat voor precies drie situaties: geen enkel platform is bereikbaar, de P2000-verwerking staat langer dan een half uur stil, of er gaan pushmeldingen de deur uit die niet kloppen. Dat laatste is het enige waarbij verkeerd handelen erger is dan niets doen — een foutieve alarmering bij mensen die met een pieper leven, is precies wat je nooit wilt veroorzaken.

Bouwen voor de uren dat ik er niet ben

Hier wijkt mijn situatie af van gewone bedrijfsmonitoring. Ergens tussen de tien en vijftien keer per maand gaat de pieper, en dan ben ik voor twee tot vier uur volledig onbereikbaar. Daar komt de piketdienst als informatiecoördinator bij, waarbij ik soms een hele nacht met iets heel anders bezig ben. Er is geen tweede persoon die het dan overneemt. Dus moet het systeem het uithouden.

Drie ontwerpkeuzes doen daar het meeste werk.

Degraderen in plaats van omvallen. Als de P2000-bron wegvalt, verdwijnt de kaart van 112Radar niet. Hij blijft staan met de laatst bekende meldingen en een balk erboven: laatste melding veertien minuten geleden. Dat is een gedeeltelijk werkend product in plaats van een kapot product, en het scheelt me het grootste deel van de berichten.

Alles wat kan wachten, wacht. Binnenkomende data gaat eerst in een wachtrij en wordt daarna verwerkt. Ligt de verwerking er twintig minuten uit, dan is er niets verloren — bij herstel loopt de achterstand vanzelf leeg. Dat is het verschil tussen “we missen een half uur aan meldingen” en “we liepen een half uur achter”, en dat is een groot verschil voor iets waar mensen op vertrouwen.

Een statuspagina die zichzelf bijwerkt. Dezelfde checks die mij alarmeren, voeden een publieke pagina. Een storing die zichtbaar is, is half zo erg: mensen die zien dat het bekend is, sturen geen bericht en gaan er niet van uit dat het aan hun telefoon ligt. Het kost een middag om te bouwen en het bespaart je op elke storing een uur uitleggen.

Wat er tóch misgaat

Zonder deze paragraaf zou dit een verdacht glad verhaal worden, dus: er gaat nog steeds van alles mis, en telkens in dezelfde drie hoeken.

De storing die je niet had bedacht. Je kunt alleen monitoren waarvan je weet dat het kan gebeuren. Elke echt vervelende storing die ik heb gehad, was er een waar geen check voor bestond — en het patroon in mijn werk is inmiddels dat de check pas geschreven wordt nadat het één keer is misgegaan. Dat is geen falen, dat is hoe het gaat, maar het is wel een reden om na elk incident tien minuten te reserveren voor de vraag: waaraan had ik dit eerder kunnen zien?

De derde partij die stilletjes verandert. Een externe dienst hernoemt een veld, wijzigt een limiet of gaat strenger controleren. Er komt geen foutmelding, er komt andere data. Daar helpt alleen validatie aan de poort tegen: als een binnenkomend bericht niet aan de verwachte vorm voldoet, wordt het geweigerd en gemeld in plaats van verwerkt.

Het alarm dat wel afging, maar op de verkeerde plek. Mijn pijnlijkste voorbeeld: een certificaat dat verliep terwijl de waarschuwing keurig was verstuurd — naar een mailadres dat ik al maanden niet meer las. De monitoring werkte perfect. Het kanaal niet. Sindsdien staat er een terugkerende taak in mijn agenda die één ding controleert: komt een testalarm nog steeds aan waar ik denk dat hij aankomt?

Conclusie

Storingen zien voordat gebruikers bellen is geen kwestie van meer meten. Het is een kwestie van de goede dingen meten: niet of iets aan staat, maar of het iets doet, en of wat het doet nog klopt. Laat processen zelf een hartslag geven, laat het systeem zichzelf eerst herstellen, en houd de meldingen die overblijven zo schaars dat je erop reageert zonder erover na te denken.

Bij de brandweer geldt hetzelfde principe. De pieper gaat niet vaak, en juist daarom staat iedereen op als hij gaat. Monitoring die de hele dag piept, is monitoring waar niemand meer voor uitrukt.