Wat doe ik na een IT-crash?
Overstromingen, aardbevingen, WTC-torens of andere rampspoed. Business continuity wordt al snel geassocieerd met rampen en grote bedrijven. onterecht vaak, want meestal is een ordinaire IT-crash de oorzaak.
Bovendien blijkt business continuity een zaak van kleinere organisaties te zijn, aldus enkele sprekers op het Business Meets IT-seminarie over dit thema. We noteerden enkele bevindingen uit de praktijk.
Eerst even een misvatting de wereld uithelpen, vermits business continuity en disaster recovery vaak in één woord – of soms zelfs als synoniem – worden gebruikt. Disaster recovery is eigenlijk een relatief klein onderdeel van business continuity. Bij disaster recovery staat volgende vraag centraal: hoe krijg ik mijn infrastructuur zo snel mogelijk weer overeind na een catastrofe zoals een natuurramp, een terreurdaad of IT-falen?
Zo’n ramp is overigens niet zo uitzonderlijk. Uit onderzoek van het bureau McGladrey & Pullen blijkt dat 1 datacenter op 500 jaarlijks met een ernstige ramp te maken heeft. Bij business continuity staat een heel andere vraag centraal, namelijk: hoe houd ik mijn bedrijf draaiende, zelfs in tijden van catastrofes?
Business continuity is dus niet iets dat op het moment van een of andere ramp de kop op steekt. Wim De Keyser, director ICT Infrastructure & Support bij Smals voegt daar nog twee verwante termen aan toe: availability en back-up. Availability of beschikbaarheid is het deel van de tijd dat een ICT-infrastructuur of -applicatie functioneert, terwijl back-up refereert naar het kopiëren van data met als doel een extra kopie te hebben van de originele bron.
“Het zijn allemaal ICT-strategieën om operaties te herstarten indien nodig“, vat De Keyser samen. En allemaal zijn ze noodzakelijk.
“Uit onderzoek van het IT Governance Instituut blijkt dat de meeste bedrijven zich niet meer dan vier uur downtime kunnen permitteren zonder een ernstige impact te ondervinden.” Maar naast de puur zakelijke redenen, zoals productiviteit, minder inkomsten of imagoschade is er een toenemend aantal regelgevingen en bepalingen rond compliance waar bedrijven zich aan moeten houden.
Keuzes maken
Cruciaal bij dit alles zijn twee drieletterwoorden: RPO en RTO. Het eerste (Recovery Point Objective of RPO) beschrijft de aanvaardbare hoeveelheid dataverlies bij een ramp, gemeten over een bepaalde periode. Het is het punt in de tijd tot waar we moeten kunnen terugkeren bij het terugzetten van gegevens.
RTO of Recovery Time Objective is dan weer de tijd en het serviceniveau waarop een bepaald bedrijfsproces is hersteld. Hoe korter de RTO die u oplegt, hoe hoger de operationele kosten die hierbij komen kijken. Ander onderscheid hierbij is dat tussen een koude, warme en hete herstart.
“Bij een koude start is er bijvoorbeeld geen hardware aanwezig. Bij een warme wel, maar in tegenstelling tot bij een hot start is die niet geconfigureerd”, aldus Wim De Keyser. Deze vooropgestelde strategie maakt vaak onderwerp uit van de vooraf besproken SLA’s of Service Level Agreements waarin, afhankelijk van de toepassing, telkens een RTO of RPO wordt vastgelegd .
In uw distasterrecoveryaanpak gaat het dus om het maken van keuzes. Bij het Belgisch leger stelt men bijvoorbeeld een RPO van 24 uur en een RTO van 48 uur voorop. “Wij hebben hier duidelijke vereisten rond vooropgesteld en er een actieplan voor opgesteld”, vertelt Pascal Brasseur, datacentermanager bij het Belgisch leger. “Al zijn wij tegelijk ook geen bank of e-commercesite die altijd beschikbaar moet zijn. Zo ver willen we ook niet gaan.”
Maar zoals het cliché zegt: voorkomen is beter dan genezen. “De meest succesvolle disaster recovery strategy is om nooit het disaster-recoveryplan te moeten uitvoeren, wat heet risk avoidance”, benadrukt Wim De Keyser van Smals. Of zoals een andere spreker het op het Business Meets IT-seminarie met een boutade omschreef: "Denial is not a river in Egypt."
