Hoe lang kunnen we nog werken als de computer uitvalt?

Als je bij een organisatie werkt, die redelijk vergaand is gedigitaliseerd, zit het antwoord op deze vraag waarschijnlijk ergens in de reeks tussen de vijf minuten en een kwartier. Als het één computer is, die uitvalt, is het leed nog wel te overzien en redelijk eenvoudig op te lossen. Maar wat als de automatiseringsomgeving in een organisatie is gecentraliseerd en die centrale omgeving valt uit? Het lijkt me toch een verplichting tegenover klanten en medewerkers, om hier op een goed onderbouwde manier keuzes in maken en maatregelen nemen. Dit wil niet zeggen dat elk risico, koste wat het kost, moet worden uitgesloten, maar wel dat de risico’s op een goede manier in kaart worden gebracht en dat vervolgens passende maatregelen worden genomen.

Een voorbeeld: als bijna alle medewerkers kunnen telewerken, hoeven waarschijnlijk geen dubbel uitgevoerde verbindingen tussen de kantoorvestigingen en het datacenter met de centrale infrastructuur aanwezig te zijn. Bij uitval van de verbinding kan iedereen thuis verder werken.

Beslissingen op managementniveau en niet (alleen) door IT-afdeling
In dit artikel wil ik wat zaken noemen, waarover het management van een organisatie vooraf een beslissing moet nemen. Deze beslissingen zijn nodig om te kunnen bepalen welke maatregelen ‘passend’ zijn. De afdeling IT kan wel helpen om alle relevante informatie beschikbaar te krijgen en ook zal deze afdeling een groot deel van de uitvoering van de maatregelen, waartoe wordt besloten, voor zijn rekening nemen, maar de beslissingen horen echt op het hoogste niveau in de organisatie te worden genomen.

Maximale uitvaltijd (Recovery Time Objective)
Een van de eerste beslissingen, die moet worden genomen, betreft de maximale tijd waarbinnen de beschikbaarheid van een uitgevallen systeem moet worden hersteld (afgekort RTO). De waarde van de RTO is afhankelijk van de schade, die wordt verwacht bij uitval, in wat voor vorm dan ook, dus zowel financiële schade als bijv. imageschade moet worden beoordeeld. Dit laatste wordt o.a. beinvloed door het feit of klanten toegang hebben tot de systemen, via bijvoorbeeld een klantenportal op de website. Ook is telefonie steeds meer geïntegreerd in de datanetwerken, dus denk hierover ook goed na.

Let wel: dit betreft een beslissing over een uitgangspunt vooraf, die tijdens het maken van een ontwerp voor een passende infrastructuur of nog later mogelijk moet worden bijgesteld. Zeker als de RTO in hoofdzaak is afgeleid van de mogelijke financiële schade kan achteraf bijstellen nodig zijn als de kosten om schade te voorkomen niet in redelijke verhouding tot de schade door uitval blijken te staan.

Maximaal dataverlies (Recovery Point Objective)
Een tweede vereiste betreft het vaststellen van het maximaal toegestane dataverlies (RPO). Bij een storing kan de data, die is toegevoegd of gewijzigd sinds de laatste back-up, verloren gaan. In de wat traditionelere netwerken is deze RPO vaak 24 uur, omdat één keer per dag een back-up wordt gemaakt. Als dan aan het einde van de werkdag een systeem zou crashen, zou het werk van de hele dag verloren zijn. Dit wordt steeds minder acceptabel in moderne bedrijfsomgevingen. Het is belangrijk om de RPO per proces vast te stellen om onnodig investeren te voorkomen. Daarnaast moeten de mogelijkheden om de data na een crash te reconstrueren in overweging worden genomen: inkomende e-mail van buiten de organisatie is bijna niet te reconstrueren en tegenwoordig wel van zeer groot belang, dus mogelijk is de RPO voor e-mail één uur, terwijl die voor andere data twee of vier uur is of nog langer.

Combinatie van RTO en RPO
De combinatie van RTO en RPO moet ook worden beoordeeld. Als een storing optreedt, die binnen vier uur moet worden opgelost (RTO) en er mag maximaal vier uur data verloren gaan (RPO) is het nog steeds mogelijk om in bedrijfsprocessen een dag achterstand op te lopen (vier uur werk kwijt en vier uur niet benutte uren). Maar als medewerkers bij uitval van een proces andere werkzaamheden uit kunnen voeren, hebben we weer een heel andere situatie en telt eigenlijk alleen de RPO mee.

Maken ontwerp als infrastructuur niet aan eisen voldoet
Als (delen van) de infrastructuur niet aan de eisen voldoet, moet een ontwerp worden gemaakt voor een gewijzigde of nieuwe infrastructuur, die dat wel doet. Dit is vooral een technische aangelegenheid, waarover ik een andere keer nog wat hoop te schrijven. Aan de hand van dit ontwerp moet ook een inschatting worden gemaakt van de benodigde investeringen en kosten. Neem bij dit soort projecten ook een post ‘onvoorzien’ op, want die komt er vrijwel zeker aan. In mijn blog van 14 november heb ik kort overzicht gegeven van wat maatregelen, die ik in de loop van de jaren genomen heb zien worden bij een groeiende organisatie.

Controleren en eventueel bijstellen van RTO en RPO
Als het ontwerp gereed is, is het tijd om na te gaan of dit aan de RTO en RPO voldoet. Ook moet aan de hand van de inschatting van investeringen en kosten worden nagegaan, of de financiële component in de beslissing voor de waarden van de RTO en RPO in redelijke verhouding staat tot de investeringen en kosten. In een ‘urenfabriek’ is bijvoorbeeld de verhouding tussen enerzijds de gemiste omzet tijdens de uitval gecombineerd met het eventuele dataverlies en anderzijds de te maken kosten een goed uitgangspunt om dit te beoordelen.

Realisatie
De realisatie is, evenals het ontwerp, vooral een technische aangelegenheid. Zoals reeds genoemd, hoop ik daar een andere keer wat over te schrijven. Momenteel ben ik zelf bezig in zo’n project en als dat een stukje verder is in de uitvoering, heb ik vast weer genoeg te melden in een nieuwe blog.

Gebruik maken van ASP of Software as a Service (SaaS)
Als je gebruikt maakt van een ASP of SaaS lijkt het bovenstaande niet van toepassing, maar dat is niet helemaal het geval. Ga maar eens na of de ASP daadwerkelijk maatregelen heeft genomen om de afgeloten Service Level Agreement (SLA) na te komen. En vraag ook eens wat is geregeld voor het geval brand ontstaat in het datacenter in de vorm van een uitwijkscenario.

Tenslotte
Het bovenstaande is misschien niet het meest boeiende in een organisatie om je mee bezig te houden, maar in het kader van informatiebeveiliging wel van essentieel belang. Misschien goed om eens een IT audit uit te laten voeren op de eigen organisatie?

Advertenties

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit /  Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit /  Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit /  Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit /  Bijwerken )

Verbinden met %s

%d bloggers liken dit: