Eén datacenter eruit. Hoeveel van jouw organisatie blijft overeind?

Hoe betrouwbaar is jouw cloud eigenlijk?

Een brand in een datacenter. Zes dagen gedoe. Eerst de brand zelf. Daarna het herstel van de stroomvoorziening. En vervolgens begint voor klanten pas het echte werk: systemen controleren, verbindingen herstellen, diensten opnieuw opstarten, schade inschatten, data nalopen, gebruikers weer aan de praat krijgen.

De brand bij NorthC in Almere laat iets zien waar veel organisaties liever niet te lang naar kijken. Cloud, hosting en colocatie voelen vaak abstract. Netjes geregeld. Professioneel beheerd. Contract erbij. SLA erop. Klaar.

Tot de stroom eraf moet.

Dan blijkt hoe fysiek digitaal nog steeds is. Achter elke cloudomgeving zitten gebouwen, kabels, verdeelkasten, noodstroom, koeling, routers, racks en mensen die onder druk de juiste beslissingen moeten nemen. Dat is geen kritiek op NorthC. Calamiteiten gebeuren. Brand, water, stroomstoringen, kabelbreuken, menselijke fouten en digitale aanvallen horen bij de realiteit van IT.

De vraag is dus niet of een datacenter ooit geraakt kan worden. De vraag is wat er met jouw organisatie gebeurt als dat gebeurt.

Bij de brand in Almere lagen meerdere organisaties direct stil. Niet een beetje traag. Niet een paar applicaties minder beschikbaar. Gewoon: geen IT, dus niet werken. En als je digitale systemen plat liggen, gaat er meer mee onderuit dan je serverpark. Telefonie. Toegangssystemen. Werkplekken. Klantcontact. Interne processen. Soms zelfs dienstverlening aan burgers, studenten, patiënten of reizigers.

Dat is het pijnlijke punt.

In 2026 zou een brand in één datacenter niet automatisch mogen betekenen dat je hele operatie omvalt. Zeker niet voor je kernsystemen. Redundantie, uitwijk, gescheiden verbindingen, back-ups, failover en herstelprocedures zijn geen luxe meer. Ze zijn onderdeel van bedrijfscontinuïteit.

Want Almere had erger kunnen aflopen. Als klantapparatuur wél zwaar beschadigd was geraakt, praat je niet over dagen. Dan praat je al snel over weken.

Deze brand is daarom geen incident om snel weg te klikken. Het is een testvraag.

Hoe betrouwbaar is jouw cloud eigenlijk, als de plek waar hij draait morgen uitvalt?

De gevaarlijkste SPOF staat zelden op je architectuurplaat

Redundantie klinkt geruststellend. Twee systemen. Twee verbindingen. Twee leveranciers. Twee locaties. Klaar, zou je denken. Tot de praktijk laat zien dat dubbel uitvoeren iets anders is dan echt onafhankelijk ontwerpen.

Ik had ooit een klant die dacht volledig redundant te zijn met twee storage arrays. De data was keurig over beide arrays verdeeld. Op papier zag dat er prima uit. Tot een technicus van de leverancier een fout maakte op één van die arrays. Toen bleek dat alle bootvolumes op precies dat ene systeem stonden. De data was verdeeld, maar het vermogen om op te starten niet. Het resultaat: geen snelle failover, maar een tijdrovende restore vanaf tape.

Een andere klant had de verbindingen tussen twee locaties redundant laten uitvoeren. Verschillende ingangen in het gebouw. Twee telecomleveranciers. Alles leek netjes gescheiden. Tot een graafmachine de kabels raakte op de ene plek waar beide leveranciers toch door dezelfde buis bleken te lopen.

Dat is het probleem met redundantie. De zwakke plek zit vaak niet in het onderdeel dat je bewust dubbel hebt uitgevoerd, maar in de afhankelijkheid die niemand heeft gezien. Een gedeelde stroomvoorziening. Een gemeenschappelijke route. Eén beheeraccount. Eén configuratiefout. Eén procedure die alleen op papier bestaat.

Kun je je hiertegen beschermen? In 99,999% van de gevallen wel. Maar dan moet je redundantie niet zien als een vinkje. Je moet de hele keten gedetailleerd in beeld hebben.

De snelheid van herstel bepaalt de echte schade

RTO en RPO klinken als termen voor de technische bijlage. Dat zijn ze niet. Ze bepalen hoeveel schade je organisatie accepteert als er iets misgaat.

Recovery Time Objective betekent simpel gezegd: hoe lang mag je maximaal uit de lucht zijn? Recovery Point Objective betekent: hoeveel data mag je maximaal verliezen? Twee vragen die iedere directie zou moeten kunnen beantwoorden. Niet in theorie, maar per systeem, per proces en per calamiteit.

Bij een kapotte schijf lijken RTO en RPO vaak nul. Zeker als je RAID gebruikt. De schijf valt uit, de omgeving draait door, iemand vervangt de disk en klaar. Maar wat als de backplane faalt? Of de controller? Of als er een firmwarefout zit in alle schijven uit dezelfde productieserie? Dan ben je ineens veel meer kwijt dan één disk. Eerst wacht je op hardwareherstel. Daarna moet je alsnog een restore uitvoeren. Je RTO is dan geen nul, maar bijvoorbeeld zes uur. Je RPO hangt af van de leeftijd van je laatste bruikbare back-up.

En dan die tweede storage in het tweede datacenter. Mooi idee. Tot blijkt dat daar dezelfde productieserie hardware draait, met dezelfde fout.

Ook software en configuratie bepalen hoe snel je kunt schakelen. Failover is geen magische knop. De snelheid hangt af van je inrichting, afhankelijkheden, datareplicatie, netwerkpaden, authenticatie en beheer. Als jouw failover afhankelijk is van een resource uit het datacenter dat net is uitgevallen, heb is je uitwijk een dure wachtruimte.

Echter weerbaarheid begint bij een goed ontwerp en een regelmatige test.

Resilience vraagt meer dan het volgen van leveranciersadvies

Houden best practices rekening met resilience?

Best practices zijn waardevol. Ze voorkomen dat je telkens opnieuw het wiel moet uitvinden. Ze bundelen ervaring, kennis en fouten die anderen al voor je hebben gemaakt. Maar een best practice is geen wet. En zeker geen vervanging voor nadenken.

Juist bij resilience moet je scherp blijven.

De vraag is niet: wat adviseert de leverancier? De vraag is: past dit advies bij jouw omgeving, jouw risico’s en jouw hersteldoelen?

Een leverancier kijkt logischerwijs vanuit zijn eigen technologie. Dat maakt zijn advies niet verkeerd. Maar het maakt het ook niet automatisch het beste advies voor jouw situatie. De beste oplossing die een leverancier kan leveren, is niet altijd de beste oplossing voor jouw organisatie.

Een PAPA-cluster van Oracle kan een veel hogere mate van resilience bieden dan een HA-cluster van Microsoft SQL Server. Een PostgreSQL-installatie met regiogebonden sharding kan weer mogelijkheden bieden die je bij Oracle of Microsoft niet op dezelfde manier vindt. Het punt is niet welke technologie “beter” is. Het punt is dat context alles bepaalt.

Daarom moet je best practices toetsen. Aan je architectuur. Aan je afhankelijkheden. Aan je RTO en RPO. Aan je budget. Aan je beheerorganisatie. Aan de schade als het misgaat.

Hoe robuust is jouw IT als het spannend wordt?

Je IT blijft niet vanzelf draaien als er iets misgaat. Daar is technische architectuur voor nodig. Niet als mooie tekening voor in een document, maar als praktisch ontwerp dat rekening houdt met brand, stroomuitval, kabelbreuken, firmwarefouten, menselijke fouten en leveranciersafhankelijkheden.

Resilience begint met inzicht. Welke systemen zijn echt kritisch? Welke afhankelijkheden zitten ertussen? Waar zitten de single points of failure? Hoe snel moet je kunnen herstellen? En hoeveel dataverlies kun je dragen zonder dat je operatie schade oploopt?

Dat zijn geen vragen voor na een incident. Dan ben je te laat.

Wil je weten hoe robuust jouw omgeving werkelijk is? Maak een vrijblijvende afspraak met mij. Dan kijken we samen waar jouw kwetsbaarheden zitten en welke technische keuzes nodig zijn om onder druk door te kunnen draaien.