YCDBWYCID

Toen ik begon te werken met HP NonStop-systemen hingen er overal posters met de afkorting YCDBWYCID – oftewel ‘you can’t do business when your computer is down’. Dat was in 1985! Voor sommige toepassingen klopte het toen en nu hebben we de meeste processen zo efficiënt (lean) gemaakt, dat handmatige workarounds niet meer mogelijk zijn. Klanten accepteren geen downtime en kunnen bovendien vaak gemakkelijk overstappen naar de concurrentie. Hoewel de betrouwbaarheid van hardware sterk is verbeterd, is tegelijkertijd de complexiteit van software, het aantal transacties en de hoeveelheid data flink toegenomen. Naast verstoringen in hardware en fouten in applicaties hebben we nu ook te maken met partijen die de data willen stelen en/of onklaar maken. Ook het feit dat veel IT-verwerking bij derde partijen en in de cloud plaatsvindt, maakt het ingewikkelder.

Door Michael Crooymans, Resilience professional

Het uitgangspunt is niet de IT-systemen, maar de kritische bedrijfsprocessen, geïdentificeerd middels een Business Impact Analyse als onderdeel van BCM. Voor deze processen moeten de eisen aan IT worden bepaald, de hersteltijd en het maximale acceptabele dataverlies (RTO en RPO). Vervolgens is het nodig om de benodigde IT-resources in kaart te brengen – denk aan de IT-keten en zaken als hardware, middleware, applicatie, data en koppelingen. Al deze componenten moeten optimaal beschikbaar zijn om het proces te kunnen uitvoeren.

Voor elk component moet worden bepaald ‘Wat gebeurt er als dit uitvalt?’ en ‘Hoe kan ik dit herstellen binnen het RTO?’ Voor lokale hardware-storingen, bijvoorbeeld stroom, schijven, netwerken en processoren, kan veel worden opgevangen door lokale redundantie, maar denk ook aan uitval van een geheel datacenter.

Voor data is het gemakkelijk om remote near-realtime kopieën te maken van alle mutaties. Besef dan wel dat fouten ook meteen gerepliceerd worden. Naast een kopie van de belangrijkste data voor het geval van een storing moeten organisaties ook een datarecovery-strategie hebben voor het geval dat de data, inclusief back-ups, versleuteld zijn door een derde partij (ransomware).

Een point-in-time recovery is dan vaak niet meer mogelijk en bovendien gaan mogelijk te veel transacties verloren. Denk aan extra back-ups, op verschillende manieren gemaakt en afdoende beveiligd, met de benodigde informatie om de kritische processen te kunnen uitvoeren. Voor applicaties in de cloud is beschikbaarheid niet altijd standaard, dus moet je je goed verdiepen in de beschikbaarheid van de diensten en de opties om dit op het vereiste niveau te krijgen. Het hebben van een hoog beschikbare infrastructuur, met de gevalideerde en geoefende herstelplannen is essentieel, maar niet voldoende. Monitoren en incidentdetectie zijn essentieel en zijn ook onderdeel van IT-Continuity evenals adequate reactie, van simpele fix tot escalatie naar een crisis. Het efficiënt en effectief uitvoeren van Crisismanagement, IT Continuity en Business Continuity.

Kwaliteit en zekerheid

Na veel te hebben geïnvesteerd in IT-Continuity en Disaster Recovery strategieën is het belangrijk om zeker te zijn dat deze zullen werken indien nodig. Hiervoor is een goed test- en oefenprogramma noodzakelijk. Testen om de technische werking te controleren en oefeningen om ervaring op te doen met de procedures en samenwerking. Bouw de testen op, neem geen onnodige risico’s, maar zorg voor realistische tests. Doe geen ‘geplande shutdown’ tijdens een uitwijktest, maar ga meteen de ‘stekker eruit trekken’, zoals bij een echt incident. Zorg ook voor validatie van de IT Continuity van uitbestedingsleveranciers (cloud diensten), hun maatregelen en dat deze overeenkomen met jullie eisen. En ga liefst samen met hen testen en oefenen. IT Service continuity is een specialisme dat een groter artikel verdient, maar ik hoop hiermee de hoofdlijnen te hebben gedeeld.