Het is maandagochtend negen uur. Je primaire verbinding valt weg. De back-up springt in, zoals afgesproken. Maar even later valt ook die weg. Niet door een tweede storing, maar omdat beide verbindingen al die tijd via hetzelfde glasvezeltracé liepen. Twee contractuele paden, één fysieke route.
Dit is geen fictie. Het is een patroon dat zich keer op keer herhaalt, ook in omgevingen die op papier goed zijn ingericht.
De kern van het probleem is niet de storing zelf. Het is de aanname die eraan voorafging: dat een SLA gelijk staat aan weerbaarheid. Dat wie de contracten op orde heeft, ook de infrastructuur op orde heeft. Die aanname klopt niet, en de gevolgen daarvan komen altijd op het slechtst mogelijke moment aan het licht.
Wat een SLA wel en niet doet
Een SLA beschrijft wat er gebeurt nadat het misgaat: welke hersteltijd geldt, hoe credits worden berekend, wie je kunt bellen. Dat is waardevol. Maar een SLA voorkomt geen uitval. Het beschrijft alleen de afhandeling ervan.
Wie vooral op contracten vertrouwt, gaat er ook vanuit dat de techniek daarachter klopt. En juist daar klopt de aanname vaak niet. De vraag is niet: wat staat er in de SLA? De vraag is: hoe is de omgeving gebouwd?
Schijnredundantie is gevaarlijker dan geen redundantie
Redundantie die het eigenlijk niet is, geeft een vals gevoel van veiligheid. Wie denkt twee onafhankelijke paden te hebben, test die aanname misschien nooit.
Schijnredundantie kent meerdere vormen:
- Twee providers die allebei dezelfde stadsentree gebruiken.
- Twee datacenters die op papier gescheiden zijn, maar gevoed worden vanuit hetzelfde trafostation.
- Back-upverbindingen die over hetzelfde netwerk lopen als de primaire verbinding, omdat dat goedkoper was.
- Of een back-uppad dat wel actief is, maar niet de capaciteit heeft om de primaire verbinding volledig te vervangen.
Echte fysieke scheiding vraagt om transparantie. Niet alleen in contracten, maar in tracékaarten en technische tekeningen. Als een leverancier niet kan laten zien waar het glasvezel precies loopt, is dat een signaal om op te letten.
Bouw voor uitval, niet voor beschikbaarheid
De meeste IT-omgevingen zijn ontworpen met beschikbaarheid als doel: zo hoog mogelijke uptime, zo weinig mogelijk geplande uitval. En dat is op zich logisch. Maar wie alleen op beschikbaarheid stuurt, denkt niet na over wat er precies misgaat als iets wegvalt, en hoe lang dat acceptabel is.
Een weerbare omgeving wordt gebouwd met uitval als vertrekpunt. Dat begint bij concrete vragen voor elke kritieke applicatie: wat is de maximale uitvalduur? Hoeveel dataverlies is acceptabel? Wat als een cloudregio onbereikbaar is? Zijn opslag en back-ups onafhankelijk van het publieke internet, of valt de back-upverbinding precies weg op het moment dat je hem nodig hebt?
Die vragen klinken technisch, maar zijn ook bestuurlijk van aard. Wetgeving zoals NIS2, DORA en GDPR maakt dit steeds explicieter: beschikbaarheid, herstel en naleving van regels moeten aantoonbaar zijn, niet alleen op papier, maar in de architectuur zelf.
Ketenregie: van glasvezel tot cloud
In een hybride IT-omgeving bewegen data voortdurend tussen eigen locaties, datacenters en cloudplatforms. Die flexibiliteit is waardevol, maar vergroot ook de risico's, zeker als netwerk, opslag en cloudverbindingen niet als één geheel zijn ontworpen.
Wat dat in de praktijk betekent: gebruik private verbindingen met vaste capaciteit en voorspelbare snelheid. Zorg dat dataopslag en replicatie binnen de eigen landgrenzen blijven. En zorg dat je bij een incident direct kunt ingrijpen, zonder eerst meerdere partijen te moeten bellen. Wie de regie heeft over de hele keten, van glasvezel tot cloudkoppeling, kan uitval sneller beheersen en de impact beperken.
Testen, testen en nog eens testen
Een herstelplan dat nooit getest is, is geen zekerheid. Het is een aanname. Periodiek testen kost tijd, maar het is de enige manier om aan te tonen dat de weerbaarheid van een omgeving ook echt werkt.
Kan het back-uppad de primaire verbinding volledig vervangen, in capaciteit én snelheid? Zijn data binnen de afgesproken tijd terug te zetten? Wat gebeurt er met applicaties als een cloudregio wegvalt? Wat je bij die tests tegenkomt, stelt zelden gerust. Maar je kunt het dan nog oplossen. Hoe vaker je test, hoe kleiner de verrassing als het er echt op aankomt.
Organisaties die storingen het snelst achter zich laten, zijn niet die met de beste SLA. Het zijn organisaties die hun omgeving zo hebben gebouwd dat uitval voorspelbaar is en herstel snel op gang komt, omdat de architectuur dat mogelijk maakt.
Wil je weten waar jouw omgeving staat? In de whitepaper '10 bouwstenen voor digitale weerbaarheid' lees je welke keuzes het verschil maken, van fysieke redundantie en ketenregie tot testen en compliance.
