Woensdag 31 maart is World Backup Day. Dat herinnert ons aan de nood om bestanden veilig te bewaren. Maar als de boel letterlijk in brand staat, komt het Disaster Recovery Plan in actie. Een onzichtbaar en onsexy onderdeel. Maar wel een dat je bedrijf zal redden.
‘We raden aan uw Disaster Recovery Plan te activeren’, klonk het in de tweet van Octave Klaba, hoofd van de het Franse hostingbedrijf OVH nadat op 10 maart brand uitbrak in een van zijn datacenters. Zo’n brand is zeldzaam, dat een volledig datacenter (één van de vier op die locatie) volledig in de vlammen opgaat is bijna ongezien.
Het herinnert ons eraan dat rampen gebeuren. Een brand, overstroming, een aanslag, maar evenzeer een banale kabelbreuk of ransomware kunnen een bedrijf in geen tijd stilleggen. In een wereld vol digitale diensten is snel kunnen uitwijken of herstellen de belangrijkste strohalm wanneer het fout loopt. Dat geheel valt onder de term Disaster Recovery Planning of DRP. Het plan dat je moét maken om het hopelijk nooit nodig te hebben.
Het is een omniumverzekering. Je bent er pas blij mee als het fout loopt.
DRP is meer dan een vinkje in een servicecontract. Hoe begin je eraan? Zijn er regels? En vallen alle meubels te redden? We vroegen het aan enkele experts en daar klinkt het unisono dat het een zeer individueel plan is, met voor elk bedrijf een ander zwaartepunt en kostenplaatje. ‘De basis is vrij standaard, de uitwerking is in elke organisatie anders’, zegt Johan Van Grieken, partner bij Deloitte en gespecialiseerd in digitaal risicobeheer.
‘Het lastigste deel is om het management te overtuigen om erin te investeren’, zegt Peter Witsenburg, onafhankelijk information security auditor en oprichter van Belgium Cloud. Het is een omniumverzekering, je bent er pas blij mee als het fout loopt.’
De inventaris
DRP begint met weten hoe je bedrijfsprocessen werken, waar welke data zitten en hoe alles met elkaar interageert. Naast je IT-architectuur hoor je ook de verschillende rollen en verantwoordelijkheden aan te wijzen. Werk een aantal mogelijke incidenten uit, schat in hoe groot de kans is dat ze voorvallen en wat hun impact is op je bedrijf.
Ook weten wannéér je je rampenplan activeert is belangrijk. ‘Een klant stelde zich enkele maanden geleden de vraag of ze voor een bepaald incident niet in disaster recovery modus moesten gaan’, vertelt Andy Van Der Eeken, Head of Customer Service Management bij Fujitsu. ‘Gezien de relatief beperkte impact en zicht op een oplossing op korte termijn leek mij dat toen overbodig, want bij het overschakelen naar een disaster recovery scenario komt toch een en ander kijken. Dit moet enkel indien echt noodzakelijk. Op dat moment werd duidelijk dat er niet was omschreven vanaf wanneer je een failover moet doen. Bij een brand weet je dat. Maar er zijn genoeg situaties die minder duidelijk zijn. Hetzelfde geldt voor wie de beslissing mag nemen.’
Het einddoel is dat je bij een reeks scenario’s snel kan terugvallen op een plan dat stelt wat er moet gebeuren, hoe dat moet gebeuren en welke keuzes je daarbij maakt.
Witsenburg: ‘Je moet bij het begin kijken naar de kroonjuwelen. Wat is je core business? Vervolgens kijk je op applicatieniveau wat er gebeurt als een toepassing niet meer beschikbaar is, en daar is de eerste vraag: hoe lang kan je zonder?’.
‘Wij kijken meer vanuit de data’, zegt Van Der Eeken (Fujitsu). ‘Welke gegevens zijn het meest kritiek voor je bedrijf. Welke data jagen je bedrijf kopje onder als ze er niet meer zijn? Maar je moet ook kijken naar alles er omheen. Bij OVH ging het om een datacenter, maar er zijn bij zware incidenten misschien ook mensen met bepaalde kennis die niet meteen beschikbaar zijn.’
‘Bij veel van onze klanten zit disaster recovery mee in het pakket. Zeker bij outsourcing krijgen we vereisten rond RPO en RTO (Recovery Time Objective en Recovery Point Objective). Maar vaak blijft het vrij algemeen. Vragen we naar meer details, bijvoorbeeld rond prestaties, dan is daar niet altijd een antwoord op.’
Witsenburg: ‘Je kan veel Service Level Agreements (SLA, nvdr) afvinken, maar je moet ze ook kunnen toetsen in de praktijk. Wanneer je cloudprovider 99,999 procent uptime belooft, is dat bijvoorbeeld op jaar- of maandbasis? Want dat scheelt heel wat in praktijk’.
Een SLA kan mooi zijn op papier, maar daar heb je weinig aan wanneer je je Disaster Recovery Plan moet starten.
‘En wat zijn de boetes als het misgaat? Veel contracten beperken zich dan tot 10 à 15 procent van wat je hen betaalt, soms nog afgemeten op hoe ver je in de maand zit. Daar heb je niets aan, want je gaat zelf veel meer kosten hebben. Maar weinig spelers betalen je voor honderd procent terug. Een SLA kan mooi zijn op papier, maar daar heb je weinig aan wanneer je je Disaster Recovery Plan moet starten.’
Ook Marnix Vrambout, Technical Sales Manager bij Westpole wijst naar RTO en RPO. ‘Het eerste bepaalt hoe snel je weer up and running bent. Het tweede hoeveel data je mag verliezen. Maak je elke 24 uur een back-up, dan ben je hooguit voor 24 uur aan data kwijt. Voor veel bedrijven of applicaties is dat meer dan voldoende. Maar als een speler als Bol.com of Coolblue voor 24 uur aan bestellingen verliest, dan hebben ze een groot probleem.’
Als zaken niet duidelijk zijn bij het opstellen van je plan, dan gaat het nog moeilijker zijn in tijden van crisis.
‘Hier is een goede enterprise architect zijn geld waard’, stelt Koen Magnus, ook partner bij Deloitte en gespecialiseerd in crisismanagement en business continuity. ‘Bij de identificatie van bedrijfsprocessen, maar ook bij het identificeren van de kroonjuwelen, de link maken naar het IT-technische luik, enzovoort. Vaak is het bijvoorbeeld niet duidelijk wiens verantwoordelijkheid een bepaald onderdeel is. Loopt dat via derde partijen, dan kan het zijn dat een bedrijf niet ver genoeg gaat in hun SLA’s. Als die zaken niet duidelijk zijn bij het opstellen van je plan, dan gaat het nog moeilijker zijn in tijden van crisis.’
Tot slot moet je plan ook zodanig zijn opgesteld dat anderen er mee verder kunnen. Van Grieken (Deloitte): ‘Zorg dat het plan zelf ook op meerdere locaties ligt. Het zou bovendien niet de eerste keer zijn dat de verantwoordelijke voor DRP intussen niet meer voor het bedrijf werkt. Je plan mag wel geschreven zijn voor mensen met een IT-kennis, maar zorg dat ook iemand zonder doorgewinterde kennis van je omgeving ermee aan de slag kan.’
Hoe ver mag het gaan?
Vragen we de specialisten hoe breed een Disaster Recovery Plan moet gaan, dan horen we twee zaken telkens opnieuw: het is voor iedereen anders en je moet keuzes maken. DRP draait overigens ook over zaken als werkplekken en communicatie naar klanten, partners of personeel toe. Maar voor dit artikel focussen we hoofdzakelijk op IT.
In een bouwbedrijf kan je misschien een paar dagen verder zonder bepaalde digitale processen. Bij een online retailer is een dag onbeschikbaarheid van een tool soms veel ernstiger.
‘Er zijn geen richtlijnen voor’, zegt Johan Van Grieken (Deloitte). ‘Het hangt ook fel af per sector. In een bouwbedrijf kan je misschien een paar dagen verder zonder bepaalde digitale processen. Bij een online retailer is een dag onbeschikbaarheid van een tool soms veel ernstiger.’
‘Wij kijken vooral naar de processen die rechtstreeks impact hebben op klanten. Als het je service degradeert dan moet het vooraan staan. Meer naar achteren kan bijvoorbeeld de leveranciersboekhouding staan. Tegelijk zijn er ook bedrijven die meteen zonder leveringen vallen en ernstig in de problemen komen als de leveranciersboekhouding wegvalt.’
‘Het brengt soms interessante discussies naar boven. Een werkgever zal het een ramp vinden als honderd mensen een paar dagen niet kunnen werken. Maar is dat belangrijker dan een dag geen bestellingen kunnen ontvangen?’
Er is evenwel meer dan het rechtstreekse financiële plaatje. ‘Denk ook aan reputationele impact. Misschien gebeurt er iets met weinig impact op je bedrijfsprocessen, maar kan het wel je reputatie schaden en riskeer je er daardoor negatief in de media te komen. Ook met die impact moet je rekening houden’, Vult Koen Magnus (Deloitte) aan.
Zelfs met een identieke setup in twee datacenters is alles weer in de lucht krijgen niet altijd eenvoudig.
Ook technisch: volstaat een cloudprovider die infrastructuur op meerdere locaties heeft, of kies je ook daar voor een tweede aanbieder? Van Der Eeken (Fujitsu): ‘De meeste grote spelers bieden daar wel voldoende redundantie. Onthoud dat het ook nog moet werken. De manier waarop een bepaalde functionaliteit wordt ingevuld, kan verschillen per oplossing of cloudomgeving. Zelfs met een identieke setup in twee datacenters is alles weer in de lucht krijgen niet altijd eenvoudig’.
Risico’s accepteren
Los van keuzes om iets als prioriteit (of net niet) te bestempelen, zijn er ook zaken die je niet kan aanpakken. ‘Er is een Belgisch datacenter dat onder de aanvliegroute van Brussels Airport ligt. Als ooit een vliegtuig te vroeg neerkomt dan is het daar afgelopen’, zegt Witsenburg. ‘Toen we daar de oefening maakten hebben we dat risico aanvaard, simpelweg omdat de kosten om je datacenter te verplaatsen te hoog liggen. Soms moet je het gewoon accepteren.’
Voor sommige zaken moet je gewoon aanvaarden dat het kan gebeuren.
‘Soms moet het’, vult Van Der Eeken (Fujitsu) aan. ‘Je kijkt naar de kans dat het kan gebeuren, de kost om de impact te beperken en dan moet je voor sommige zaken gewoon aanvaarden dat het kan gebeuren.’
Hoe ver je daarin gaat is opnieuw zeer individueel en een afweging van kost en waarschijnlijkheid. Vrambout (Westpole): ‘Als we een klant vragen welke RPO en RTO ze willen, dan is het antwoord vaak ‘nul’, ze willen continu blijven draaien. Dat kan technologisch, tot je rekent hoeveel moeite dat kost, welke middelen en kosten eraan verbonden zijn en hoe die op maandbasis oplopen. In praktijk gaan bedrijven dan kijken naar welke impact een incident of een oplossing biedt en waar je de afweging gaat maken. Al zien we wel dat klanten vaak voor hun bedrijfskritische toepassingen dezelfde RPO en RTO willen.’
Testen
Er is een plan, er zijn keuzes en investeringen gemaakt, dan is het ook tijd om ze te testen. Maar doe je dat in stapjes, of zoals in het echte leven: de motor van je bedrijf stilleggen en kijken of de plannen het overnemen?
‘Er zijn bedrijven die dat doen. Maar de meesten houden het op een dry run‘, zegt Vrambout (Westpole). ‘Ze laten de omgeving en hun applicaties wel draaien, maar niet geconnecteerd met het internet of met actieve uitwisseling aan data.’
‘Bouw dat testen op’, zegt Magnus (Deloitte). ‘We adviseren niet om je uitgeschreven plan te testen door de stekker eruit te trekken. Faseer een aantal zaken, hevel ze over van de ene omgeving naar de andere en spreek ook af met je gebruikers en je derde partijen dat je met een aantal IT-testen begint vooraleer end-to-end na te gaan of alles werkt. Als je dat voor elk stuk van de ketting doet, kan je overwegen om alles helemaal te testen.’
‘In de praktijk zien we dat zeer weinig, maar er zijn bedrijven die daar zeer ver in gaan en zo goed als volledig op hun disaster recovery terugvallen. Sommigen communiceren daar zelfs proactief over en informeren klanten over een noodoefening en dat dat tijdelijk impact kan hebben op de dienstverlening. Dat is soms sterker dan de oefening op een willekeurig tijdstip houden, maar dat verschilt van bedrijf tot bedrijf.’
Vaak gebeurt zo’n gesimuleerde failover in het weekend, wanneer je bedrijf niet op volledige capaciteit draait. Alle kleine obstakels komen dan pas naar boven op maandag.
‘Als je nooit test is de kans klein dat het naadloos verloopt’, vult Van Grieken (Deloitte) aan. ‘Door te testen leer je wat nog niet in orde is. De realiteit is dat de meeste systemen niet op zichzelf staan. Ook een cloudoplossing bestaat uit verschillende integraties met andere onderdelen. Dus moet je plots wisselen van cloudomgeving, dan bestaat de kans dat er iets wegvalt.’
Bij Fujitsu raden ze aan om net wel iets uitgebreider te testen. Van Der Eeken: ‘Als je een uitwijktest doet, probeer dan toch een paar dagen of weken op die tweede omgeving te draaien. Vaak gebeurt zo’n gesimuleerde failover in het weekend, wanneer je bedrijf niet op volledige capaciteit draait. Alle kleine obstakels komen dan pas naar boven op maandag.’
Terug naar de tekentafel
Het plan is er, alle procedures zijn getest, iedereen weet wat te doen, maar hoe lang blijft dat plan actueel? Hier speelt de technologische vooruitgang in het nadeel. ‘Het nadeel van virtualisatie is dat je IT-omgeving vandaag veel sneller evolueert. Niet enkel met virtualisatie, maar ook met containerisatie maak je snel nieuwe workloads. Als die erbij komen dan moet je ook de Disaster Recovery planning bijwerken. Het maakt dat je vandaag sneller je servers moet opkuisen en aan lifecycle management moet doen’, zegt Vrambout (Westpole)
Makkelijker of moeilijker dan vroeger?
De technologisch evolutie maakt dat disaster recovery vandaag op een andere manier kan of moet. Als we onze experts vragen of het nu makkelijker of moeilijker is dan vroeger, dan horen we meestal dat het beiden is.
Vrambout (Westpole): ‘Sommige dingen zijn verbeterd. Vroeger was disaster recovery een exacte kopie van je actieve omgeving. Dat was complex, vroeg veel middelen en was bijgevolg ook duur. Vandaag kan je met virtualisatie het meeste op bijna eender welk platform terugbrengen. Identieke hardware is veel minder nodig en de communicatielijnen zijn beter waardoor data in realtime op een tweede locatie wordt bewaard’.
‘Er zijn ook gespecialiseerde diensten die je legacytoepassingen of iets op de mainframe kunnen ontdubbelen, maar dat is een stuk kostelijker dan een virtuele x86-gebaseerde omgeving. Waar het haalbaar is, merken we gelukkig wel dat de meeste toepassingen vandaag op standaard hardware draaien en dat maakt het makkelijker.’
Vrambout merkt daarbij op dat SaaS-diensten doorgaans ook hun gegevens op meerdere fysieke locaties bewaren. ‘Maak wel een onderscheid tussen IaaS (een virtuele server huren) en SaaS (een online softwarepakket). Huur je één virtuele machine bij AWS of Google dan is het aan jou om die omgeving terug te brengen wanneer er iets foutloopt. Maar ook daar kan je voor iets meer geld dat ontdubbelen op een tweede locatie.’
Hou het eenvoudig
Witsenburg is minder enthousiast: ‘Vijftien jaar geleden was het eenvoudiger want er was minder keuze. Vandaag zijn er zoveel speler op de markt dat alleen al je RFP een stuk moeilijker is’.
Van Der Eeken (Fujitsu): ‘Er is vandaag veel meer mogelijk, maar er komt een laag complexiteit bij waardoor het niet vereenvoudigt. Als klanten, bewust of onbewust, een multicloud-omgeving hebben on premise, bij AWS, bij Azure en dergelijke, dan is het puzzelen om dat bij elkaar te houden. Keep it simple is nog steeds een principe dat veel waard is, zeker naar disaster recovery toe.’
De cartoon bovenaan dit artikel is met toestemming van KC Green herbruikt. In ruil verwijzen we graag door naar zijn webshop met meer ‘this is fine’ merchandising.
Fout opgemerkt of meer nieuws? Meld het hier