Uptimepercentages begrijpen: wat de "nines" écht betekenen
Kort antwoord
Beschikbaarheid wordt meestal geschreven als een percentage van een jaar, maar het getal dat er echt toe doet is de downtime die daarachter schuilgaat. 99% klinkt bijna perfect en laat toch nog zo'n 3,65 dagen downtime per jaar toe. 99.9% ("drie nines") brengt dat terug tot ongeveer 8,76 uur. 99.99% ("vier nines") brengt het nog verder terug tot ongeveer 52,6 minuten. Elke extra nine levert ruwweg een tienvoudige afname van de downtime op, en elke nine kost onevenredig meer moeite om te bereiken.
Een percentage omzetten naar een aantal minuten
Een jaar heeft 525.600 minuten. Een uptime-percentage is niets anders dan een claim over hoeveel van die minuten een systeem bereikbaar hoort te zijn. Draai het percentage om en vermenigvuldig het met het aantal minuten in een jaar, en je krijgt het downtime-budget dat het eigenlijk vertegenwoordigt.
| Beschikbaarheid | Gangbare naam | Downtime per jaar | Downtime per maand |
|---|---|---|---|
| 99% | Twee nines | ~3,65 dagen | ~7,3 uur |
| 99.9% | Drie nines | ~8,76 uur | ~43,8 minuten |
| 99.99% | Vier nines | ~52,6 minuten | ~4,4 minuten |
| 99.999% | Vijf nines | ~5,26 minuten | ~26 seconden |
Het patroon is wat dit de moeite waard maakt om te begrijpen: elke extra nine haalt niet een beetje van de downtime af, maar deelt hem door ruwweg tien. Daarom lijkt "99% versus 99.9%" op papier een verschil van afronding, maar is het in de praktijk het verschil tussen een systeem dat het grootste deel van een werkweek per jaar plat kan liggen, en een systeem dat minder dan één werkdag per jaar niet bereikbaar is.
Waarom de stap van drie naar vier nines zoveel lastiger is dan hij lijkt
De stap van 99% naar 99.9% betekent vooral het wegnemen van de slordige, makkelijk te verhelpen oorzaken van downtime: ongepatchte software die crasht, één service zonder restart-beleid, een deploy die de hele site tien minuten platlegt. Het grootste deel daarvan is haalbaar met redelijke operationele discipline en zonder exotische architectuur.
De stap van 99.9% naar 99.99%, en verder naar 99.999%, is een ander soort probleem. Op dat niveau zijn de resterende oorzaken van downtime precies de oorzaken die één goed beheerde server niet in zijn eentje kan oplossen: een stroomstoring die een hele faciliteit platlegt, een netwerkpad dat uitvalt op precies de verkeerde laag, hardware die uitvalt zonder standby die direct overneemt. Om dat gat te dichten is meestal redundantie nodig op elke laag die kan uitvallen (stroom, netwerk, compute en vaak ook geografie), automatische failover die niet op een mens wacht, en genoeg testen van de faalpaden zelf om erop te kunnen vertrouwen dat ze werken wanneer het nodig is. Elk van die dingen brengt echte kosten en echte complexiteit met zich mee, en dat is precies waarom beschikbaarheidscijfers exponentieel moeilijker worden naarmate ze stijgen, niet lineair.
Welk beschikbaarheidsdoel heeft een bepaalde workload echt nodig
Niet elk systeem hoeft hetzelfde getal na te jagen, en "meer nines" als onvoorwaardelijk doel behandelen betekent meestal dat je iets over-engineert dat het niet nodig had. De juiste vraag is wat een uur downtime de workload erachter daadwerkelijk kost: in geld, in reputatie, of doordat er iets verderop in de keten kapotgaat.
- Een persoonlijke blog of intern tool. Een incidentele storing van een paar uur is vervelend, geen crisis. Vier of vijf nines najagen levert hier vooral complexiteit op die niemand nodig had.
- Een zakelijke website of SaaS-product waar klanten tijdens werkuren op vertrouwen. Downtime heeft hier een directe, zichtbare kostenpost. Drie nines is een redelijke basis om naartoe te ontwerpen, met redundantie waar die goedkoop toe te voegen is.
- Een payment gateway, handelssysteem, of iets anders waarbij downtime geldstromen stopzet of een contractuele verplichting breekt. Hier kunnen de kosten van een storing die van preventie ver overtreffen, en dat rechtvaardigt het ontwerpen voor vier of vijf nines: redundante infrastructuur, geautomatiseerde failover, en een architectuur die ervan uitgaat dat elk los onderdeel kan uitvallen.
In de praktijk kiezen de meeste organisaties niet één getal voor alles wat ze draaien. Ze leggen de lat hoger voor de systemen waar downtime duur is, en accepteren een lagere, goedkopere lat voor de systemen waar dat niet zo is.