Eén tik op de betaalterminal, en klaar. In de milliseconden daarna controleren, autoriseren en verwerken tientallen systemen die betaling, zonder dat iemand het merkt. Via de Nederlandse betaalinfrastructuur gaat dat ruim zes miljard keer per jaar goed, met een beschikbaarheid die jarenlang bijna 99,9 procent haalt. Goede infrastructuur maakt zichzelf onzichtbaar, en daarmee vanzelfsprekend.
Achter een systeem dat nooit lijkt te haperen, gaat vaak een complexe keten schuil. Hoe minder een systeem mag haperen – omdat de impact ervan direct merkbaar is – hoe meer techniek er nodig is om het in de lucht te houden. En al die techniek is niet gratis.
Elke negen levert minder op
Beschikbaarheid wordt vaak uitgedrukt in negens. Van 99,9 procent naar 99,99 procent klinkt als een marginale verbetering, maar in de praktijk maakt dit verschil uit: van bijna negen uur uitval per jaar naar minder dan een uur. Five nines, 99,999 procent, laat nog een handvol minuten per jaar over.
Die eerste stap wint acht uur, de volgende nog geen uur. De opbrengst wordt dus steeds kleiner, terwijl de investering steeds groter wordt. Elke extra negen kan vragen om dubbel uitgevoerde componenten, extra locaties, een complexere failover en meer beheerlast.
Wat die extra negen kost, verschilt enorm. Een component beveiligen is iets anders dan een complexe keten beveiligen. Belangrijker dan wat maximale beschikbaarheid kost, is wat een maatregel oplevert: hoeveel risico’s neem je ermee weg, en hoeveel is dat waard in gemiste omzet of reputatieschade? Voorbij een bepaald punt draait het niet langer om hoe je uitval voorkomt, maar hoe je ermee omgaat.
Wat mag er uitvallen?
Honderd procent uptime bestaat niet. Er blijft altijd risico op uitval. Dan wil je vooral weten hoeveel uitval je kunt dragen, op welk vlak en voor hoe lang.
Tijdens het ontwerpen van systemen maak je keuzes. Een organisatie die niet van tevoren bepaalt wat er mag falen, accepteert nog steeds risico, alleen ongestuurd en verspreid over talloze losse beslissingen. Door bewust vast te stellen welke processen een uur stil mogen liggen, en welke geen seconde, maak je het verschil tussen een architectuur met prioriteiten en een architectuur waarin alles even kritiek zou zijn. Dat laatste betekent in de praktijk vaak dat niets echt goed beschermd is.
Redundantie beschermt niet tegen gedeelde afhankelijkheid
De grootste verstoringen komen zelden voort uit gebrekkige betrouwbaarheid van individuele systemen, maar uit afhankelijkheden die veel partijen delen zonder het te beseffen. Toen in mei 2026 brand uitbrak in een datacenter in Almere, bleven de servers grotendeels intact, maar werd op last van de brandweer de stroom van het hele complex afgesloten. Ruim honderd organisaties maakten gebruik van dat datacenter. Een universiteit sloot omdat toegangspassen en het netwerk niet werkten, zorgverleners konden niet bij patiëntgegevens. Bij sommige partijen duurde het herstel meer dan een week.
Dit is concentratierisico. Wie zijn plan B op één locatie, achter dezelfde stroomvoorziening of bij dezelfde leverancier heeft ondergebracht, heeft geen uitwijkmogelijkheid.
Zekerheid is weten wat er gebeurt als het misgaat
Een systeem ontwerpen voor de gemiddelde dag is niet moeilijk. Ontwerpen voor de slechtste dag betekent accepteren dat de volgende negen steeds duurder wordt en minder oplevert, en dat een uitwijk geen uitwijk is wanneer die op hetzelfde punt steunt als het origineel. De winst zit niet in meer uptime, maar in gecontroleerd herstel: hoe snel je weer draait en hoeveel je onderweg kwijtraakt.
Wanneer je kritieke systemen bouwt, bepaal je daarmee wat anderen op een doodgewone dag nog kunnen doen. Dat verdient een eerlijker belofte dan een percentage achter de komma. Zekerheid is niet dat alles blijft draaien. Zekerheid is weten wat er gebeurt als het misgaat en hoe volledig je herstelt.
Dit is een ingezonden bijdrage van Conclusion Mission Critical. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.