Een disaster recovery plan: bedrijfsproces voor techniek

• Door
• Kristian de Bruijn (BIT)
• geplaatst op
• 5 juli 2016 10:00 uur

Een calamiteitenplan is er in alle vormen en maten. Middels een calamiteitenplan kan invulling worden gegeven aan issuemanagement, gebouwontruiming, omgaan met milieurampen, noem maar op. Zo werd onlangs in de NRC.next nog de noodzaak van een calamiteitenplan voor de schilderijen van Karel Appel aangekaart. Als het gaat om het opstellen van een calamiteitenplan voor de IT-infrastructuur, oftewel een disaster recovery plan, dan zien we daar in de praktijk nog weleens iets misgaan. Zo wordt bij het opstellen van een disaster recovery plan nog te vaak vanuit de techniek gedacht en te weinig vanuit de business. Dit kan grote gevolgen hebben voor de bedrijfscontinuïteit. Daarom bespreek ik in deze blog graag vijf stappen die als leidraad dienen voor het opstellen van een dergelijk plan.

Stap 1 – Vitale bedrijfsprocessen
Om de bedrijfscontinuïteit te garanderen is de eerste stap cruciaal: breng de meest vitale bedrijfsprocessen in kaart. Welke processen zijn essentieel voor de bedrijfsvoering? Dit lijkt wellicht voor de hand liggend, maar in veel gevallen wordt deze stap overgeslagen. Vaker wordt er gedacht vanuit de technologie (heb ik een goede back-up oplossing?) of vanuit de calamiteit zelf. Bij BIT hebben we dit omgedraaid: niet de calamiteit, maar de bedrijfsprocessen zijn leidend. Als dienst x niet beschikbaar is, wat moet er dan gedaan worden om de dienstverlening weer te laten werken en welke middelen heb ik daarvoor nodig? Dit zorgt naast een focus op de bedrijfsvoering ook voor dat er geen tijd verspild wordt met het zinloos zoeken naar een specifieke calamiteit in het plan. Want, wat doe je als een calamiteit zich voordoet waar je nooit eerder aan gedacht hebt?

Stap 2 – Business impact
Vandaag de dag is always-on beschikbaarheid van groot belang. We moeten 24/7 bij onze data kunnen en deze data moet ook continu gewaarborgd worden. Toch blijkt uit recent onderzoek van Veeam dat het aantal ongeplande downtime-gevallen de afgelopen 12 maanden gestegen is van 13 naar 15. Deze downtime-gevallen duren bovendien langer en het kost meer tijd om te herstellen. Stap 2 luidt dan ook als volgt: bepaal per bedrijfsproces wat acceptabel is qua downtime en dataverlies. Een Business Impact Analyse biedt hiervoor uitkomst. Wat is de impact als een proces uitvalt en hoe snel is de schade voelbaar? We hebben het hier niet alleen over financiële schade, maar zeker ook over reputatieschade en schade op juridisch en sociaal vlak. De impact moet dus over de hele linie geanalyseerd worden.

Vervolgens is het zaak om in kaart te brengen welke middelen er zijn om schade te beperken of te voorkomen en wat er nog mist. Dit kunnen technische oplossingen zijn, maar bijvoorbeeld ook kennis en locaties (denk aan een uitwijklocatie). Op basis van de verzamelde informatie kan er voor ieder proces een Recovery Time Objective (RTO) worden vastgelegd en de Recovery Point Objective (RPO) vastgesteld worden. Op basis hiervan kiest u de juiste oplossingen.*

Stap 3 – Afhankelijkheden
Breng de afhankelijkheden in kaart, met andere woorden de relatie tussen de diverse bedrijfsprocessen. Wanneer er twee processen gelijktijdig uitvallen kan dit veel meer schade aanrichten dan wanneer alleen proces 1 verstoord wordt. Stel je voor dat proces 1 uitvalt. Hiervoor is geïnventariseerd dat de organisatie zonder risico nog twee dagen kan functioneren, maar wanneer proces 2 tegelijkertijd uitvalt dan kan de maximaal acceptabele downtime van proces 1 zo veranderen in slechts een halve dag. Denk bijvoorbeeld aan een internetverbinding die wegvalt en tegelijkertijd ook de customer care afdeling die niet te bereiken is. Een andere afhankelijkheid kan zijn dat proces 3 gebruikmaakt van proces 4. Wanneer proces 4 onderbroken wordt, heeft dat als gevolg dat ook proces 3 uitvalt.

Stap 4 – Maak mensen verantwoordelijk
Stel de juiste personen verantwoordelijk voor de disaster recovery uitvoering. Dit doe je op basis van expertise, maar bijvoorbeeld ook op reisafstand. In het geval van calamiteiten is het prettig als hulp niet twee uur onderweg is. Het hoeft dus niet altijd de IT-manager te zijn. Door van tevoren na te denken over taken en verantwoordelijkheden, voorkom je dat medewerkers tegelijk aan hetzelfde probleem werken. Vergeet dan ook niet om het disaster recovery plan bij te werken wanneer er organisatorische veranderingen plaatsvinden die ook betrekking hebben op het plan.

Stap 5 – Communiceer het disaster recovery plan
Breng iedereen op de hoogte van het disaster recovery plan. Dit lijkt misschien heel logisch, maar het komt nog genoeg voor dat medewerkers met hun handen in het haar zitten bij een calamiteit en geen idee hebben van het bestaan van een disaster recovery plan.

Last but not least wil ik u graag meegeven dat welke maatregelen er ook bedacht zijn om op calamiteiten te reageren, ze moeten wel werken. Testen is daarom essentieel, vooral ook wanneer er geen calamiteiten zijn. Als er bijvoorbeeld dagelijks een back-up wordt gemaakt, controleer dan ook of er daadwerkelijk iets is opgeslagen. Het zou toch zonde zijn als er een mooi disaster recovery plan op tafel ligt en de tapes leeg blijken te zijn. Daar is geen plan tegen opgewassen…

* RTO is de maximaal toegestane downtime van een computer, systeem, netwerk of applicatie na een calamiteit. RPO staat voor het feit dat het voorval leidt tot een bepaalde mate van dataverlies. Oftewel: wat is de hoeveelheid data die je accepteert te verliezen?

Geschreven door Kristian de Bruijn (BIT)

Stuur ook uw blog, achtergrond artikel of andere bijdrage in!