Met name in de lokale overheid zag je afgelopen jaren de trend van de ‘doe-het-zelf uitwijkvoorziening’. Een groeiend aantal gemeenten koos ervoor om zelf uitwijkvoorzieningen te exploiteren. Hetzij in eigen beheer, hetzij in een constructie met buurgemeenten. Een goed uitgewerkte business case of een wankele redenatie?
Een uitwijkvoorziening bij een professionele leverancier vraagt een jaarlijkse investering. De leverancier verzorgt voor die vergoeding de benodigde middelen en de gewenste dienstverlening bij een calamiteit. Wanneer die calamiteit echter uitblijft – en dat hopen uiteraard alle partijen – wordt het rendement van de voorziening maar moeilijk zichtbaar voor het hoger management . Het blijft dan beperkt tot ‘een zekerheidsgevoel’, een verzekering. Ingegeven door bezuinigingen lijkt de gedachte van het zelf doen op het eerste gezicht plausibel.
Kort door de bocht
‘We zetten op een andere locatie een stel schijven neer en repliceren de virtuele servers. Zo kunnen we altijd over de machines beschikken…’ Een idee dat wordt gevoed door het feit dat de benodigde investering in hardware en dataverbindingen steeds beperkter wordt en technologieën het steeds eenvoudiger maken om een kopie van de data extern veilig te stellen. Deze redenatie achter een doe-het-zelf uitwijkvoorziening is echter erg kort door de bocht.
Een uitwijkvoorziening is immers meer dan het veiligstellen van data. Die veiliggestelde data moet bijvoorbeeld ook ontsloten worden. Daar is een vervangend serverpark voor nodig dat is afgestemd op de primaire omgeving. Dat wil zeggen qua specificaties, maar ook qua versie van het operating system en de drivers. Die vervangende systemen moeten zich in een passend geconditioneerde accommodatie bevinden, op voldoende afstand van de primaire omgeving. Daarbij zijn ook vervangende werkplekken nodig, zodat de centrale medewerkers van de organisatie ook echt snel weer aan het werk kunnen.
Als er dan daadwerkelijk nood aan de man is, zijn er personen nodig – ook zaterdagnacht om twee uur – met kennis van en ervaring met het operationeel maken van de systemen. En vooral, het tackelen van de eventuele problemen die ontstaan. De applicaties worden immers geconfronteerd met totaal andere omgevingen, adresseringen, routeringen en koppelingen. Het is dan ook belangrijk om een gedegen draaiboek op te stellen en te onderhouden. Omdat de it-omgeving dynamisch is, is het ook belangrijk om de uitwijk periodiek te testen en het draaiboek te onderhouden.
Je ziet helaas maar zelden dat al deze aspecten voldoende aandacht hebben gekregen binnen de doe-het-zelf uitwijkvoorziening. Velen reiken niet verder dan het beschikbaar hebben van de technische componenten en zijn dan ook niet meer dan een wassen neus. Bij de eerste de beste ‘heat in the kitchen’ blijft er weinig van over.
Eerlijke vergelijking
De trend van de doe-het-zelf uitwijkvoorziening lijkt zich te keren. Om politieke en praktische redenen komt men vaak terug op de eerdere beweging . Ook komen veel gemeenten tot inzicht dat het realiseren van een uitwijk een specialisme is en dat de basis van de eigen voorziening te smal is. Bovendien kan een professionele leverancier de kosten verdelen over zijn klanten, waardoor de externe uitwijkregeling in een eerlijke vergelijking verrassend vaak overeind blijft.
Een eerlijke vergelijking, dat zou de basis moeten zijn voor de keuze van het zelf doen of het uitbesteden. Een vergelijking waar alle aspecten in zijn meegewogen. Of, om in lijn met de titel af te sluiten; maak van een uitwijkvoorziening geen gok!
Een typisch onderwerp waarvan de verwachtingen in veel organisaties slecht worden gemanaged.
Ik kwam een paar jaar geleden op maandagochtend bij een klant binnen waar iedereen blij was over de afhandeling van een op zaterdag opgetreden storing. De UPS had er namelijk voor gezorgd dat hun klant niets had gemerkt. Op mijn vraag of ze dit succes al hadden gedeeld met de opdrachtgever keek men mij met grote en verbaasde ogen aan. De klant had immers niets gemerkt dus “waarom zou je dat doen”? Mijn uitleg dat die UPS ook ooit een investering had gevergd die nu dus zijn waarde bewees ging het ene oor in en het andere oor weer uit.
De les voor mij was dat de effectiviteit van je werk bestaat uit 2 componenten: kwaliteit en acceptatie. “Kwaliteit” is het inhoudelijke / objectieve / meetbare (in dit voorbeeld de UPS). “Acceptatie” is in dit voorbeeld het claimen van succes.
Vergeet daarnaast niet dat je bij uitwijk ook aandacht moet besteden aan de rollback. Er komt ooit een moment dat je uitgebrande datacenter weer is opgebouwd. Hoe kom je dan terug van je uitwijklocatie?
Goed onderwerp. Mijn ervaring is dat als organisatie gaan nadenken over uitwijk, security in ieder geval onder de aandacht is en op de kaart staat. Dat is altijd stap 1. Stap 2 is dan het inrichten van security, zo ook de uitwijk. Dat gaat vaak ook nog wel voortvarend, en er wordt vaak in de praktijk ook wel (vanuit het project) getoetst op functioneren.
Maar daarna verzand het in de operationele waan van de dag. En dan komen dit soort zaken pas naar boven als er daadwerkelijk iets fout gaat. Met alle gevolgen van dien (waar is pietje die dit heeft ingericht en weet hoe het werkt). Regelmatig testen, maar ook borgen dat dit getest wordt is de operationele uitdaging. Wat zijn de praktijkervaringen van anderen..?
Ander aspect is dat er steeds meer in de cloud wordt gewerkt. En dat de cloud vaak autmatische fail-over voorzieningen bevat. Dus ondanks dat het een belangrijk onderwerp is, denk ik wel dat langzaam maar zeker de noodzaak voor het testen van uitwijk zal afnemen. Iets vergelijkbaars zou je kunnen stellen voor de eenvoudiger variant: het maken en testen van back-ups.
Leuk artikel!
Maar ik ben het helaas niet eens met je afsluiting.
Ik heb een aantal trajecten op dit gebied (BC/DR) meegemaakt. Zelfs een uitwijkomgeving voor een aantal gemeenten die een samenwerkingsverband aangingen gerealiseerd. Zoals je aangaf, het creeren van een uitwijkomgeving/oplossing is niet alleen het repliceren van je virtuele omgeving naar andere kant! Er zijn nog meer zaken die hierin opgenomen moeten worden.
Als je een goed uitwijkprocedure hebt opgesteld dan ben je zeker niet duurder uit dan je externe leverancier! Ik heb voor een klant, een test-uitwijk bij hun externe leverancier meegemaakt waarna mijn advies aan de klant heel simple en kort was: Zeg dit uitwijkcontract op!
Je bent zeker veel kwijt aan je uitwijkkosten aan je externe leverancier en ik kan je vertellen dat deze zeker niet hoger zullen zijn dan doe-het-zelf + doe-het-goed!
@Sander:
Ook als je in de cloud werkt moet je een uitwijk regelen. De optie van uitwijk is meestal in een cloudcontract anders genoemd, daar betaal je zeker een hoge prijs voor. Sterker nog, vanwege allerlei tekortkomingen en problemen in de cloud moet je aan een verschijnsel denken dat “cloud escrow” heet. Ik zou zeggen maak eerst je huiswerk af voordat je naar cloud gaat.
@Reza:
Eens dat je in de cloud ook serieus moet kijken naar uitwijk. Wel denk ik dat uitwijk steeds meer als standaard service zal worden aangeboden. Net zoals je nu met een paar klikken een virtuele servers of zelfs een virtueel serverpark configureert. Straks zal je het hokje uitwijk kunnen aanvinken en krijg je nog wat configuratie vragen daarover. Het is (nog) niet triviaal, maar ik zie dat wel gebeuren.
En ja natuurlijk moet je je huiswerk goed blijven maken: waarnaartoe zou worden uitgeweken bijvoorbeeld. Als je data opeens verplaatst wordt vanuit een datacenter in de EU naar de USA wordt je daar niet altijd blij van. Maar ook over escrow, omschakeltijd, periodiek testen en dergelijke moeten goede afspraken gemaakt worden.
Sander,
Dan is de vraag of je je uitwijk bij dezelfde cloudleverancier wil bouwen! Stel je voor dat deze leverancier failliet gaat. Wat heb je aan je uitwijk als je leverancier er niet meer is?!
Doe je dat niet dan zou je met zeer hoge kosten van je 2e leverancier te maken krijgen.
Dit soort zaken (en nog meer) zijn juist onzichtbare onderwerpen die een andere draai aan je cloud-businesscase gaan geven. Daarom zei ik maak eerst je huiswerk en je bent gelukkig het met mij eens 🙂
Cloud
De opkomst van de cloud geeft inderdaad nog weer een ander perspectief aan de uitwijkvoorziening. Je zult zeker goede afspraken moeten maken met je cloudleverancier, maar in feite heb je een multi point of failure. Wat nl. als de calamiteit niet je cloudleverancier treft, maar de eigen (primaire) locatie? Zelf zul je als organisatie dus nog steeds voorzieningen (en een plan) moeten hebben.
Business Case
De business case voor doe-het-zelf-uitwijk is uiteraard in een aantal gevallen wel te maken. Dat heeft dan vooral te maken met schaalgrootte. Wanneer die schaalgrootte bereikt wordt door een gezamelijke voorziening voor meerdere partijen, creeert men in feite zelf een ‘externe’ voorziening. De uitdaging (of zoals hier eerder genoemd het huiswerk) blijft om alle factoren mee te calculeren, ook de organisatorische, beschikbaarheidsvergoeding personeel, onderhoud op apparatuur en inrichting, accommodatie, werkplekken, oefeningen, draaiboek, …).