Zolang het goed gaat, gaat het goed. Maar als je ICT systeem ‘down’ is, dan begin je pas te merken hoe afhankelijk je bent van je systeem en digitale gegevens. Voor de ene ondernemer is deze downtime echter (veel) schadelijker dan voor de ander. Het is daarom verstandig om hier vooraf over na te denken en dit kenbaar te maken richting je IT dienstverlener.
Dit doe je het beste via de zogenaamde RPO en RTO. De watte? Ja, dat zal de meeste ondernemers niet zeggen, daarom tekst en uitleg over deze twee termen.
RPO en RTO
RPO staat voor Recovery Point Objective. Dit houdt in dat je een bepaalde mate van dataverlies accepteert bij een grootschalige storing. RTO staat voor Recovery Time Objective. Dit betreft de tijd dat het systeem na de storing weer beschikbaar moet zijn.
Zowel RPO als RTO zijn dus tijdsintervallen. Het opvallende is dat de RPO en RTO per bedrijfssector (of bedrijf) enorm kan verschillen. Ik zal een aantal voorbeelden geven.
Enkele voorbeelden…
Stel, je hebt een administratiekantoor en je verzorgt de boekhoudingen van ZZP’ers. Je hoeft de administraties van je klanten niet dagelijks bij te werken, eens per week of zelfs één keer per maand is voldoende. Dan is een langere Recovery Point Objective (RPO) geen probleem. Als je wat verder terug in de tijd moet om bijvoorbeeld een back-up terug te zetten, dan ben je relatief weinig werk kwijt. Je moet hooguit enkele mutaties van de tussenliggende periode opnieuw invoeren. Vervelend maar overkomelijk. De Recovery Time Objective is echter wel korter: je wilt wel weer snel toegang krijgen tot de systemen. Hier zou een RPO van 2 of 3 dagen geen probleem zijn maar is een kortere RTO gewenst. Je wilt binnen een dag wel weer in je administraties kunnen inloggen.
Je hebt echter geen administratiekantoor maar een webshop. Je krijgt veel orders binnen via internet. Je bent hard aan de slag om deze orders te verwerken, totdat je server crasht. Een ramp! Er komen gelijk geen orders meer binnen en je bent volledig onthand. Uiteraard is een zeer korte RTO hier van belang. Je wilt dat het systeem snel weer werkt. Een korte RPO is hier echter ook heel belangrijk: het is geen optie om een back-up van 24 uur geleden terug te zetten. Dat zou inhouden dat je alle bestellingen van de afgelopen 24 uur kwijt bent.
Kortom: probeer voor jezelf eens een worst-case scenario te schetsen en projecteer dat op jouw bedrijf. Wat is de impact op jouw bedrijfsvoering als je ICT systeem er compleet uitligt. Wat kun je dan niet meer? Wat is de directe schade qua productiviteitsverlies? Kunnen je medewerkers dan wat anders doen of moet je iedereen naar huis sturen? Hoe lang kun je zonder computersysteem? Oftewel: wat is een acceptabele Recovery Time Objective (RTO)?
En punt 2 is eveneens zeer belangrijk. Je IT dienstverlener is genoodzaakt een back-up terug te zetten. Hoe oud mag die back-up zijn? Is het voldoende dat deze 24 uur oud is, is langer ook geen probleem of is het al een ramp als je alle werkzaamheden van het laatste uur kwijt bent? Oftewel: wat is voor jou een acceptabele Recovery Point Objective (RPO) waarbij de schade te overzien is?
Zoek de balans
OK, nu zal iedere ondernemer roepen: doe maar een zo kort mogelijke RTO en RPO. Beide van een paar minuten maximaal. Hehe, uiteraard geen probleem. Maarrrrr…. (er is altijd een maar) daar hangt natuurlijk een prijskaartje aan. Hoe korter de hersteltijd moet zijn, hoe duurder de oplossing. Als een maximale ‘downtime’ van je server hooguit enkele minuten moet zijn, dan kun je dat oplossen met bijvoorbeeld een servercluster. Je server wordt dan dubbel uitgevoerd. De servers ‘spiegelen’ elkaar waarbij de ‘reserve-server’ automatisch de taken overneemt van de primaire server bij storing. Technisch een prachtige oplossing en iets wat we ook al vaak gerealiseerd hebben voor klanten maar natuurlijk ook een stukje prijziger dan een enkele server. Echter: als de schade van uren of dagen downtime groter is dan de prijs van een extra server + toebehoren die nodig zijn om dit risico af te dekken, dan is het al snel een no-brainer. Voor veel bedrijven is een dag downtime simpelweg veel duurder dan een extra server. De ICT is bij deze bedrijven dusdanig bedrijf kritisch dat (bijna) alle ‘single point of failures’ (onderdelen in je ICT die enkelvoudig zijn uitgevoerd en bij storing dus veel overlast kunnen veroorzaken) zijn uitgebannen.
Het is dus goed om naast de RTO en RPO ook een globale schatting te maken van de bedrijfsschade bij langere downtime. Als de voorzorgsmaatregelen (zoals het dubbel uitvoeren van servers) duurder uitpakt dan de schade van langere downtime, dan is het uiteraard de moeite niet om hierin te investeren. Dat zijn echter zaken die je als ondernemer zelf moet inschatten.
Stel jezelf dus de volgende vragen:
- Wat is een acceptabele Recovery Time Objective? Oftewel: hoe lang ‘mag’ mijn systeem down zijn zonder dat de bedrijfsvoering al te zeer wordt benadeeld?
- Wat kost ‘downtime’ mijn organisatie ruwweg per dag?
- Wat is de mate van dataverlies (RPO) die nog acceptabel? Is een dag werk kwijt acceptabel? Of is een uur werk kwijt al een ramp?
Ga met deze vragen en de antwoorden daarop in gesprek met je ICT partner. Een goede ICT partij kan de oplossingen die ze aanbieden afstemmen op de voor jou acceptabele RTO’s en RPO’s. Zo kom je gezamenlijk tot een oplossing waarbij dit soort verrassingen aan de voorkant worden voorkomen.
