Vijf essentiële onderdelen van een DR-plan

Sean Masters, Zerto

Als het afgelopen jaar ons iets kunnen leren, is het wel dat disaster recovery-maatregelen niet alleen mogen leunen op technologie. DR in het geval van een crisis heeft alleen zin wanneer deze software ingebed is in een groter plan. Crisis is uiteraard een relatief begrip, dat kan variëren van natuurrampen, eenvoudige maar veelvoorkomende stroomuitval tot door de mens veroorzaakte problemen - fouten of criminele activiteiten zoals ransomware. Het advies in deze situaties is altijd hetzelfde: "organisaties hebben een volledig DR-plan nodig om downtime te minimaliseren". Maar wat betekent dit eigenlijk? Hoe moet een DR-plan eruitzien? En... Waar begint zo'n plan?

Wij hebben een uitgebreide evaluatie gedaan van een aantal cases in verschillende sectoren van over de hele wereld, waarbij onze klantenservice-afdeling ondersteuning heeft geleverd. Op basis van deze analyse komen wij tot deze top vijf met essentiële componenten voor een effectieve planning en implementatie van disaster recovery.

Maak een risicoprofiel - ken de triggerpoints

In het geval van uitval van IT-middelen is er een moment waarop een bedrijf besluit om zijn disaster recovery-processen op te starten. Hoewel, zoals eerder opgemerkt, de oorzaken kunnen verschillen, zou er een consistente benchmark moeten zijn om dit moment te bepalen. Deze benchmark is idealiter lang voordat een crisis zich voordoet, vastgesteld.

Het moment waarop een bedrijf zijn DR-plan activeert, is afgestemd op zijn eigen criteria. Om hun specifieke triggerpoints vast te stellen, moet elke organisatie een risico- en business impact-analyse uitvoeren. De resultaten van deze analyse bepalen de impact van elk systeem of elke applicatie die offline gaat op het bedrijf als geheel en in welke fase de herstelprocessen gestart moeten worden.

Documentatie en autoriteitsbeheer

Wat vaak duidelijk wordt in het geval van een storing is dat een organisatie uitsluitend vertrouwt op de kennis van één persoon om het DR-plan te leiden. Het is duidelijk dat dit een risicovolle aanpak is, gezien er een single point of failure ontstaat. Als de deskundige niet beschikbaar is vanwege ontslag, ziekte, vakantie of anderszins onbereikbaar is in het geval van een crisis, neemt de impact potentieel aanzienlijk toe.

Om deze afhankelijkheid tijdens een crisis te vermijden is grondige documentatie nodig, die de volgende zaken omvat:

• Wat de triggerpoints zijn.
• De diensten die onder het DR-plan vallen en hun hiërarchie.
• Autoriteitsbeheer - wie is verantwoordelijk voor wat tijdens de implementatie van het DR-plan, inclusief personeel en relevante leveranciers.
• Stap-voor-stap instructies voor het herstelproces.

Het volledige IT-team moet verplicht worden de procedures in de documentatie door te nemen en kunnen volgen om een onderbreking tot een minimum te beperken.

De omvang en het bereik van degenen die betrokken zijn bij het DR-plan zullen sterk variëren, afhankelijk van de bedrijfsomvangen de vertical waarin ze actief zijn. Veel Fortune 100-bedrijven hebben bijvoorbeeld experts in dienst die puur zijn toegewijd aan bedrijfscontinuïteit en DR-planning.

Ongeacht de grootte van het bedrijf, moeten namen, titels en contactinformatie voor alle werknemers met een rol bij een calamiteit en/of een mandaat bij disaster management worden gedocumenteerd, evenals de te volgen 'chain of command' tijdens een calamiteit.

Wat krijgt voorrang?

Het is een veel voorkomende misvatting dat de personen die het hardst over hun IT-problemen schreeuwen, voorrang moeten krijgen in geval van downtime. Een volledig gestructureerd DR-plan schetst de juiste prioritering van IT-gerelateerde diensten op basis van wat de financiële of reputationele impact heeft op het bedrijf.

Het documenteren van deze priorisering is uiterst belangrijk, omdat geen enkele organisatie over oneindig veel middelen beschikt. Er moeten criteria worden ingesteld om te bepalen in welke volgorde de beschikbare resources moeten worden toegewezen. Dit moet onderdeel zijn van het identificatieproces voor triggerpoints, als resultaat van de risicoanalyse. Systemen en applicaties moeten worden geclassificeerd als kritiek, belangrijk en niet-essentieel. Vaker wel dan niet zullen de systemen die een hoge prioriteit hebben, een domino-effect sorteren op de andere.

Regelmatige beoordeling en testen

Het testen van het DR-plan is nog steeds geen prioriteit voor alle bedrijven, ook al is dit het meest kritieke onderdeel van het hele plan. Wat heeft het voor zin om een plan te hebben als je niet zeker weet dat het werkt?

Een bedrijf test idealiter zijn plan eenmaal per kwartaal. Dit is niet voor iedere organisatie haalbaar, maar twee keer per jaar zou het absolute minimum moeten zijn. Bij sterk gereguleerde sectoren, zoals de gezondheidszorg of financiën waar naleving een prioriteit is, moeten de tests maandelijks worden uitgevoerd. Bij toevoeging van een nieuwe software- of hardware-leverancier of wanneer andere grote veranderingen worden doorgevoerd op de IT-infrastructuur verdient een DR-test eveneens aanbeveling.

De sleutel tot een goede DR-test is dat de hele IT-infrastructuur erbij betrokken is. Wanneer alleen kleine, onsamenhangende elementen worden getest, is dit niet noodzakelijkerwijs representatief voor een échte uitval waar de hele omgeving mogelijk door wordt beïnvloed.

Netflix is een perfect voorbeeld van een bedrijf dat zich geen downtime kan veroorloven, en dat DR-tests serieus neemt. Het bedrijf test voortdurend zijn productieomgeving via zijn Simian Army om ervoor te zorgen dat de systemen veelvoorkomende problemen kunnen doorstaan zonder enige impact op de klant. De Chaos Monkey-tool van Netflix termineert willekeurig servers in productie tijdens kantooruren om het IT-team scherp te houden en voortdurend te leren. Zo weet het team wat de zwakke punten van de systemen van het bedrijf zijn en hoe deze aan te pakken, waardoor ze in staat zijn om applicaties en infrastructuur duurzaam veerkrachtiger te maken.

Evalueer altijd

Misschien wel het allerbelangrijkste van alles is dat een DR-plan een dynamische en 'levende' strategie moet zijn, waarin voortdurende verbetering en evaluatie geborgd zijn, op een vergelijkbare manier als waarop Netflix zijn Chaos Monkey gebruikt.

Als er een onfortuinlijke voorval plaatsvindt en het DR-plan in werking treedt, organiseer dan altijd een post-mortem-evaluatie. Dit biedt het team dat het plan uitvoert een kans om te evalueren wat wel én wat niet werkte, wat kan worden verbeterd en hoe downtime in de toekomst kan worden voorkomen.

In de huidige datacentrische wereld is continue beschikbaarheid van belangrijke applicaties en data de enige echte manier voor bedrijven om hun concurrentievermogen te behouden of zelfs te vergroten, terwijl klanten centraal blijven staan in hun operationele focus.