De incidenten die ik het meest verhelderend vind, zijn niet de storingen die van buiten komen. Een server die crasht, een leverancier die uitvalt, een aanval van buitenaf: vervelend, maar begrijpelijk. Veel leerzamer zijn de storingen die je automatisering helemaal zelf veroorzaakt. Systemen die keurig deden wat ik ze had opgedragen, en juist daardoor iets sloopten. Dit zijn er twee, uit de praktijk, met de bredere les eronder.

Incident één: wedstrijden die permanent gemist werden door één dag verschil#

Op footballoracle.nl, mijn hobby-voorspelsite voor voetbal, haalt een automatisch proces de uitslagen van gespeelde wedstrijden binnen en koppelt ze aan de vooraf ingeplande wedstrijden. Dat koppelen ging op de meest voor de hand liggende manier: zoek de geplande wedstrijd waarvan de datum gelijk is aan de datum van de uitslag. Simpel, logisch, en jarenlang geen probleem.

Tot er een wedstrijd was tussen Australië en Turkije. Die stond in mijn systeem ingepland op 13 juni, de lokale datum. Maar de aftrap was om vier uur ‘s nachts in wereldtijd, wat betekent dat de externe bron waar ik de uitslag vandaan haalde, het evenement had gelabeld op 14 juni. Dertien is niet veertien. Dus zocht mijn koppeling naar een geplande wedstrijd op 14 juni, vond die niet, en concludeerde: geen match. De uitslag werd niet gekoppeld. Niet vertraagd, maar permanent gemist, want elke volgende poging deed exact dezelfde vergelijking en faalde op exact dezelfde manier.

De oorzaak is een klassieker die vrijwel iedereen die met tijd en automatisering werkt een keer treft: verschillende bronnen hanteren verschillende tijdzones. De ene rekent in lokale tijd, de andere in wereldtijd, en rond middernacht schuift dat een hele kalenderdag op. Wie dan matcht op exacte datumgelijkheid, mist stelselmatig alles wat ‘s avonds laat of ‘s nachts speelt.

De oplossing was om niet meer op één exacte datum te matchen, maar op de teamnamen in combinatie met een datum die zowel de lokale als de wereldtijd-dag accepteert. Beide kalenderdagen tellen als geldig. Zodra ik dat aanpaste, werden de gemiste wedstrijden alsnog netjes verwerkt.

De gouden regel die ik eruit haalde: match nooit op exacte datumgelijkheid bij bronnen die gevoelig zijn voor tijdzones. Accepteer een dag speling, of vergelijk op het precieze tijdstip in plaats van op de kale datum. Een verschil van één dag dat nooit optreedt in je testjes, treft je gegarandeerd op het moment dat het telt.

Incident twee: de klantsite die zichzelf uitzette#

Het tweede incident kostte een echte klant echte bereikbaarheid, en dat maakt het scherper. Om kosten te besparen had ik een hostingopzet gekozen waarin een site zichzelf uitzet als er even geen bezoekers zijn, en vanzelf weer opstart zodra er iemand langskomt. Op papier een elegante manier om niet te betalen voor stilstand. Voor een simpel testomgevinkje is dat prima.

Maar deze stond voor een levende klantsite. En bij het weer opstarten ging het mis. De site moest bij het wakker worden een interne verbinding opzetten, en de informatie die hij nodig had om die verbinding te vinden, was verouderd. Het adres klopte niet meer. Dus kon de site niet volledig opstarten, waarna het systeem concludeerde “blijkbaar geen verkeer” en de site opnieuw uitzette. Een vicieuze cirkel: uit omdat er geen verkeer is, geen verkeer omdat de site uit is. Zonder ingrijpen van buitenaf zou die site nooit meer vanzelf omhoogkomen.

Het gevolg was dat een klantsite urenlang onbereikbaar was. Niet door een storing bij de hostingpartij, niet door een aanval, maar door mijn eigen zuinigheid: ik had een besparingstruc aangezet op een plek waar bereikbaarheid heilig hoort te zijn.

Twee lessen kwamen daaruit. De eerste: zet een levende klantsite nooit op “uit bij geen verkeer”. Die paar centen besparing zijn het niet waard tegenover een site die zichzelf niet meer kan wekken. Voor een echte, publieke dienst mag de bereikbaarheid nooit afhangen van of er toevallig net iemand langskwam.

De tweede les gaat over hoe ik erachter kwam, of eigenlijk hoe traag. Mijn interne bewaking zag geen probleem, want intern klopte alles. Dat een klant van buitenaf tegen een dode site aankeek, merkte ik veel te laat. Sindsdien geldt: controleer je diensten van buitenaf, zoals een klant ze ervaart, niet alleen van binnenuit. Een externe bereikbaarheidscontrole vanaf een plek buiten je eigen systeem had dit binnen minuten gezien in plaats van uren.

De rode draad: automatisering faalt op de aannames die je nooit uitsprak#

Wat deze twee incidenten delen, is dat er geen enkele component “kapot” was. De koppeling deed netjes wat ik had gevraagd: match op datum. De hosting deed netjes wat ik had gevraagd: bespaar geld door uit te schakelen. Ze faalden allebei op een aanname die ik nooit expliciet had gemaakt: dat datums altijd in dezelfde tijdzone staan, en dat een klantsite altijd wel iemand heeft die hem wakker houdt.

Dat is het patroon bij zelfveroorzaakte incidenten. Ze ontstaan niet omdat iets stuk is, maar omdat de werkelijkheid net iets rijker is dan de aanname waarop je het bouwde. En je ontdekt die aanname pas op het moment dat hij breekt.

Wat betekent dit voor jouw bedrijf?#

Je hoeft geen voorspelsite of hosting te draaien om hier last van te krijgen. Elk automatisch proces in je bedrijf leunt op aannames die niemand ooit hardop maakte. Een facturatiesysteem dat aanneemt dat elke maand even lang is. Een voorraadkoppeling die aanneemt dat leveringen op werkdagen komen. Een herinneringsmail die aanneemt dat iedereen in dezelfde tijdzone zit.

Drie dingen om mee te nemen:

  1. Wees extra achterdochtig rond tijd en tijdzones. Alles wat met datums, deadlines of tijdstippen werkt, is een klassieke bron van stille fouten. Vergelijk nooit op exacte datumgelijkheid als er meerdere tijdzones in het spel zijn.
  2. Zet besparingstrucs nooit op je kritieke, klantgerichte diensten. Wat handig is voor een testomgeving kan gif zijn voor een levende site. Bereikbaarheid voor de klant weegt zwaarder dan een paar centen besparing.
  3. Controleer altijd ook van buitenaf. Wat jij intern ziet, is niet wat je klant ervaart. Een simpele controle vanaf buiten je eigen systeem vangt precies de storingen die je van binnenuit mist.

De storingen die je automatisering zelf veroorzaakt, zijn ongemakkelijk, want er is niemand anders om naar te wijzen. Maar ze zijn ook het meest leerzaam, want ze laten haarscherp zien welke stilzwijgende aanname je bouwwerk droeg. Wie leert om die aannames op te sporen voordat ze breken, bouwt automatisering die je vertrouwt in plaats van vreest.

Wil je uitzoeken welke stilzwijgende aannames onder de automatisering in jouw bedrijf schuilgaan? Bekijk mijn gratis downloads of neem via de consulting-pagina contact op.