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

Continuïteit van informatiesystemen

Bij informatiebeveiliging draait het om drie belangrijke zaken: vertrouwelijkheid, integriteit en beschikbaarheid. Alle drie moeten deze voldoende zijn gewaarborgd om van een passende informatiebeveiliging te kunnen spreken. Een van de hoofdpunten van het onderdeel beschikbaarheid is continuïteitsmanagement van de informatiesystemen en van dat onderdeel wil ik nu kort laten zien hoe ik dat sinds het begin van deze eeuw heb zien ontwikkelen. In dit artikel ga ik niet in op ontwikkelingen als ‘Sofware as a Service’ of meer recente ontwikkelingen als ‘cloud computing’, maar neem ik de eigen infrastructuur als uitgangspunt. Over die andere ontwikkelingen een andere keer vast nog wel meer.

Extra servers
Rond de eeuwwisseling, dus zo’n 10 jaar geleden, was een eerste stap het verdelen van data over meerdere servers en het dubbel uitvoeren van compenenten in de servers. Als deze maatregelen goed werden uitgevoerd, werd de beschikbaarheid wat hoger, omdat bij een probleem met een server iedereen nog wel verder kon werken. Applicaties die gebruik maakten van de andere servers, bleven dan gewoon werken. Overigens had toen elke bedrijfslocatie vaak nog z’n eigen servers en waren storingen daardoor niet zo veel omvattend. Ook werd ICT toen nog veel minder intensief gebruikt. Bij de organisatie, waar ik werk, was dit in 1999 de eerste stap toen we ons bewust werden, dat we toch wel redelijk afhankelijk aan het worden waren van computers.

Centralisatie
Eigenlijk hoort centralisatie niet thuis in het rijtje maatregelen, dat de continuïteit beter waarborgt. Door centralisatie wordt één locatie namelijk heel kritisch in de infrastructuur en worden de risico’s voor de continuïteit dus groter. Hierbij kun je denken aan de stroomvoorziening, brandveiligheid, maar ook bijv. de afhankelijkheid van de dataverbinding op de centrale locatie. Zo’n centralisatieslag heb ik zelf in 2003 uitgevoerd, omdat dit functioneel grote voordelen op ging leveren bij de implementatie van een ERP-applicatie.

Functioneel en beheerstechnisch gezien heeft centralisatie grote voordelen en door een aantal maatregelen kunnen de risico’s voor de continuïteit natuurlijk wel worden beperkt. Een praktische manier, die ik vaak zie,  is dat de centrale infrastructuur wordt verplaatst van een eigen serverruimte naar een professioneel datacenter, waardoor bijv. stroomvoorziening, brandveiligheid, koeling en dataverbindingen veel beter zijn geregeld, dan in de meeste interne serverruimtes in eigen kantoren.

Hogere beschikbaarheid bij centralisatie
In een gecentraliseerde omgeving is het wel beter mogelijk om een groot deel van de infrastructuur dubbel uit te gaan voeren en hierdoor een hogere beschikbaarheid te waarborgen. Doordat de apparatuur fysiek op
één locatie staat, is de benodigde apparatuur en/of software om hogere beschikbaarheid te regelen ook voor kleinere organisaties redelijk betaalbaar. Vaak wordt in dit stadium ook virtualisatie toegepast. De ruimte waar de apparatuur staat, blijft echter nog steeds net zo kritisch. De kans dat deze ruimte door een calamiteit wordt getroffen is misschien niet zo groot, de gevolgen zijn dat zeker wel.

In dit stadium heb ik zelf twee belangrijke trajecten uitgevoerd: in 2005 het invoeren van een databasecluster en het redundant uitvoeren van dataverbindingen. In 2007 hebben wij het grootste deel van de backend-servers gevirtualiseerd, waardoor aanzienlijk minder hardware nodig was en de beschikbaarheid toch hoger werd. Daarnaast werd door deze virtualisatieslag de recovery bij een eventuele calamiteit veel makkelijker. Na het virtualiseren van een groot deel van de servers hebben wij ook het volledige serverpark verplaatst vanuit een eigen serverruimte naar een professioneel datacenter.

Redundant datacenter of uitwijklocatie
Nog een stap verder in het waarborgen van de continuïteit is het gebruik maken van twee datacenters. Afhankelijk van de locatie van de datacenters en de beschikbare verbindingen tussen de twee datacenters zijn hiervoor twee opties.

Uitwijklocatie
De eerste optie is het opzetten van een uitwijklocatie: een ingerichte infrastructuur in een tweede datacenter, dat alleen wordt gebruikt bij een calamiteit in het eerste. Het voordel hiervan is, dat de verbinding tussen de twee locaties alleen nodig is om de data regelmatig te dupliceren. Het nadeel hiervan is dat de apparatuur op de tweede locatie in principe nooit wordt gebruikt, ofwel een erg hoge verzekeringspremie wordt betaald. Een rekenvoorbeeld: als bij uitval van de hooflocatie nog 80% van de capaciteit moet kunnen worden gebruikt, is totaal 180% nodig (100% productie plus 80% uitwijk). Daarnaast is beheertechnisch het risico best groot, dat de applicatieversies e.d. op de uitwijklocatie achterlopen op de productielocatie.

Redundant datacenter
De gunstigere optie, waarvoor wel een aanzienlijk betere verbinding tussen de datacenters nodig is, is het verdelen van de apparatuur over beide locaties, waarbij alle apparatuur actief wordt gebruikt. Bij uitval van één locatie blijft dan nog de helft van de capaciteit beschikbaar. Als dit te weinig is, hoeft in verhouding minder te worden toegevoegd dan bij de optie van de uitwijklocatie. In hetzelfde rekenvoorbeeld is dan maar 80% nodig op beide locaties, dus totaal 160%. Als beide locaties actief zijn, kan worden geprofiteerd van 160% capacteit, terwijl bij uitval van één locatie nog voldoende overblijft. Uiteraard komt er bij deze optie nog veel meer kijken, maar als ik dat allemaal ga noemen, wordt dit artikel nog drie keer zo lang. Als ik tijd en zin heb, ga ik me daar overigens nog wel een keer aan wagen in een redelijk technisch artikel.

Momenteel ben ik bezig met de uitbreiding van onze infrastructuur naar een tweede datacenter. In een bijna volledig gedigitaliseerde omgeving is dit nodig om voldoende waarborgen te hebben voor de continuïteit van de geautomatiseerde infrastructuur. Overigens zullen wij het grootste deel van de apparatuur in een active/active configuratie verdelen over de twee locaties, maar niet alles. Hoe mooi dit technisch ook mogelijk zou zijn, de kosten moeten nog steeds in redelijke verhouding staan tot de risico’s en dan is niet alles te verdedigen.

%d bloggers liken dit: