Nederlandse Spoorwegen - Wat mag uitwijk kosten?

Wat mag uitwijk kosten?

De Nederlandse Spoorwegen bestaan uit een aantal werkmaatschappijen die op het gebied van ICT samenwerken binnen een 'governance'-model. Daarbij treedt de centrale ICT-afdeling op als interne leverancier en heeft zij een sturende en adviserende rol. Bijvoorbeeld op het gebied van business continuity. "Het zal niemand ontgaan zijn dat uitwijk tegenwoordig behoorlijk hoog op de agenda van veel bedrijven staat", vertelt Pieter van der Ploeg van de afdeling Informatiemanagement & -Technologie van de NS-holding. "Het is dan ook logisch dat ook veel werkmaatschappijen van NS naar dit onderwerp kijken. Maar hoe pak je zo'n project aan?" Nu worstelt vrijwel iedere geruikersorganisatie met dit probleem, maar NS kent een extra complicerende factor: veel werkmaatschappijen zijn relatief klein, en dat heeft ook z'n weerslag op de omvang van de ICT-bemanning en de ICT-kennis.

Erg algemeen

"De opdracht die wij als centrale ICT-afdeling kregen was enigszins gechargeerd gezegd: 'We moeten iets aan uitwijk gaan doen. Maar wat?'. Doordat die opdracht erg algemeen was, hebben we eerst goed gekeken naar de vraag hoe we zo'n project zouden moeten aanpakken. De gangbare manier van werken is natuurlijk om per werkmaatschappij een inventarisatie op te stellen van de werkprocessen, vervolgens van de business duidelijkheid te verkrijgen over de vraag welke processen belangrijker zijn en welke minder, om aan de hand daarvan tenslotte tot een voorstel te komen hoe de beschikbaarheid van al die werkprocessen in het geval van incidenten kan worden geregeld." Voor die aanpak is echter niet gekozen. "Het is voor eindgebruikers lang niet altijd even eenvoudig om het belang van een toepassing voor de functioneren van de organisatie in te schatten. Dus zegt iedereen al snel dat zijn applicatie erg belangrijk is. Wie wil immers niet een applicatie hebben die altijd beschikbaar is? Onduidelijk blijft dan namelijk wat het echte belang is van de beschikbaarheid van een toepassing. Bovendien kennen we niet voor niets de uitdrukking dat risico's de neiging hebben om kleiner te worden naarmate de kosten van het oplossen ervan hoger worden. Zolang de eindgebruikers geen idee hebben van de kosten die zij moeten maken om tot die hoge beschikbaarheid te komen, kun je nauwelijks een goede discussie voeren."

Het debat wordt wél zinvoller als duidelijk is binnen welke context keuzen gemaakt moeten worden. Van der Ploeg: " Wij hebben Comparex gevraagd om een benchmark-model te ontwikkelen. Om het in wiskundige termen uit te drukken hebben we een ruimte opgespannen met drie assen. Op de eerste as staan de soorten van uitwijk die we kunnen onderscheiden. De tweede as geeft het resultaat weer dat met die vormen van uitwijk mag worden verwacht. Zeg maar: de verwachte hersteltijd na een storing of incident. Op de derde as staan tenslotte de kosten die men hiervoor moet maken. Bedrijfsapplicaties kunnen vervolgens ergens in die ruimte gepositioneerd worden."

De kosten staan echter niet absoluut vermeld, maar relatief. "Comparex ontwierp voor ons een -zeg maar- 'model-rekencentrum' waarmee we de kosten-as kunnen invullen. Doordat het om een model van een datacenter gaat, hanteren we wat kosten betreft vooral de verhoudingen tussen kosten en niet zozeer absolute bedragen. Als we eenmaal met een werkmaatschappij in discussie zijn, vullen we voor de kosten harde cijfers in die passen bij hun specifieke omstandigheden. Maar bij het model-rekencentrum gaat het in eerste instantie vooral om dat gebruikers besef krijgen van de relatie tussen vormen van uitwijk, de resulterende beschikbaarheid en hieraan verbonden kosten.

Twee model-rekencentra

"Met deze manier van werken", zegt consultant Jan-Thijs de Feijter van Comparex, "is het mogelijk de discussie over business continuity terug te brengen naar de plek waar die eigenlijk gevoerd moet worden: de business. Bij veel uitwijkprojecten komen de gesprekken al snel uit op een niveau waarbij de gebruikersorganisatie zegt: 'laat maar zien wat mogelijk is, dan kiezen we daarna wel'. Men moet zich natuurlijk wel realiseren dat aan iedere oplossing een prijskaartje hangt. Natuurlijk is ieder werkproces belangrijk en uiteraard moet iedere applicatie die door een storing wordt getroffen zo snel mogelijk weer operationeel zijn. De vraag is echter: hoe snel? En dus ook: welke kosten wil men daarvoor maken?" Het benchmark-model is dus een hulpmiddel om antwoord te krijgen op de vraag: wat mag uitwijk kosten?

Hoe zit dit model van een datacenter er nu precies uit? De Feijter: "Wat we gedaan hebben, is het beschrijven van twee rekencentra die bestaan uit een reeks van productiesystemen op een hoofd- en een tiental nevenlocaties. Het gaat niet om een uitputtende opsomming. We hebben ons gericht op de hoofdzaken die natuurlijk ook de meeste invloed hebben op de kosten die een organisatie voor de diverse uitwijkconcepten zal moeten maken."

In figuur 1 en 2 zijn deze twee rekencentra weergegeven. Beide modellen bestaan uit een reeks van systemen en opslagvoorzieningen die via een IP-VPN-verbinding met elkaar zijn verbonden. Beide model-datacenters zijn opgebouwd rond een Sun-cluster voor een op Oracle gebaseerde ERP-omgeving, een backup-server voor zowel het Sun-cluster als de NT-systemen, een DEC Alpha-server voor een aantal business applicaties, twee op NT gebaseerde Exchange-servers, twee file- en printservers (Windows NT), drie Citrix-servers, een NT-machine voor SQL Server en een Domain Controller. Een Cisco-router zorgt voor de 100 Mbps-netwerkverbindingen. Het belangrijkste verschil tussen de twee model-rekencentra is de manier waarop de storagesystemen zijn genomen.

In het ene model gebeurt dit via een op Fibre Channel gebaseerd storage area network, terwijl in het andere datacenter de opslagcapaciteit aan individuele servers is gekoppeld.
Bij de twee model-rekencentra is uitgegaan van productiesystemen, terwijl test- en acceptatiesystemen buiten beschouwing zijn gelaten. Hetzelfde geldt voor het betrokken personeel, de feitelijke keuzes van de locaties en de client-systemen (desktops, notebooks).

Vijf uitwijkconcepten

In zijn rapport heeft De Feijter verder een aantal soorten of typen uitwijk gedefinieerd. Het gaat om vijf categorieën, waarbij vervolgens weer variaties mogelijk zijn.

De eerste categorie is simpelweg niets doen. Dat lijkt wellicht niet verstandig, maar - zo schrijft De Feijter in zijn rapport - toch kan niets doen wel degelijk een oplossing zijn. Bijvoorbeeld voor die situaties waarin het systeem op eenvoudige wijze kan worden hersteld op basis van standaard producten of componenten waar je snel over kan beschikken.

De tweede en derde categorie berusten beide op het gebruik van tape-backups voor zowel de systeem- als de applicatiegegevens. Eén concept biedt een oplossing waarbij vooraf niet is voorzien in het leveren van systeemhardware en -software. In de derde categorie is hier wel rekening mee gehouden. Het voordeel van tape-backups is dat de kosten relatief laag zijn. Daar staat tegenover dat er altijd sprake is van het verlies van gegevens omdat backups periodiek worden gemaakt en er dus altijd gegevens zullen zijn die na de laatste backup zijn vastgelegd en waarvan dus nog geen kopie bestaat. Een belangrijke voorwaarde is verder dat de kwaliteit van de backup-tapes regelmatig wordt gecontroleerd.

De vierde en vijfde categorie bieden mogelijkheden om het eventuele verlies van gegevens verder terug te dringen en desnoods verlies geheel te voorkomen. Dit kan met behulp van asynchrone dan wel synchrone vormen van datacommunicatie tussen het rekencentrum en de uitwijklocatie, al vallen in het eerste geval de transmissiekosten wel lager uit. Welke data nu precies als backup wordt weggeschreven, is een keuze die een bedrijf zelf kan maken. Dit kan op applicatieniveau worden aangepakt - al komt dit weinig voor, stelt De Feijter, eigenlijk alleen bij maatwerktoepassingen. Ook kan gekozen worden voor synchronisatie op het niveau van de database, de systeemsoftware of - bijvoorbeeld via virtualisatie - op het niveau van de storage.

Kosten per component

Er zit hier wel een addertje onder het gras, waarschuwt De Feijter. "Beide synchronisatiemethoden bieden geen bescherming tegen software- of bedieningsfouten in zowel het rekencentrum als op de backup-site. Daarom blijft het noodzakelijk om ook in deze situaties tape-backups toe te passen, al behoeven die dan niet persé op een andere locatie te worden bewaard. Dit zijn relatief kostbare oplossingen, al was het maar omdat op beide locaties de nodige hard- en software geinstalleerd zal moeten worden. Maar daar staat tegenover dat je apparatuur kunt delen als vanaf meerdere locaties wordt gewerkt."

Interessant is dat op basis van deze manier van kosten berekenen nu ook kan worden vastgesteld in welke mate een specifieke component bijdraagt aan de totale kosten die voor een uitwijkvariant moeten worden gemaakt (figuur 3). Bovendien is het nu ook mogelijk om vast te stellen wat - bijvoorbeeld - de 'schade' is van het uitvallen van een switch in het netwerk. "Dat is niet zo eenvoudig", zegt Van der Ploeg. "We doen momenteel nog wel onderzoek naar de vraag hoe dit - zeg maar - logisch in elkaar zit. Neem als heel simpel voorbeeld een DHCP-server. . De diensten van dat systeem zijn alleen belangrijk op het moment dat iemand in op het netwerk aanlogt. Dan moet die server dus beschikbaar zijn. Maar we weten natuurlijk niet wanneer dat precies gebeurt. Hoe moet je nu tot een realistische inschatting komen van de kosten die je bereid bent te maken om de beschikbaarheid van die DHCP-server op het gewenste niveau te brengen?"

Zichtbaar maken

In figuur 4 is de indeling weergegeven die Gartner rond disaster recovery hanteert, waarbij tevens een ruwe indicatie van de kostenverhoudingen en de hersteltijden is gegeven. Voor de NS is Comparex echter nog een stap verder gegaan. Per uitwijkcategorie is namelijk aangegeven met welke kosten men rekening zal moeten houden. Het resultaat van alle kostenberekeningen is te zien in figuur 5. Hierin is de relatie te zien tussen de jaarlijkse kosten en de hersteltijd bij de hiervoor genoemde uitwijkcategorieën en eventuele varianten binnen deze groepen. Van der Ploeg: "Wat we met dit rapport in handen hebben is een hulpmiddel waarmee we zowel de risico's, de mogelijke hulpmiddelen als de daaraan verbonden kosten zichtbaar kunnen maken. We kunnen nu met werkmaatschappijen in gesprek gaan. Zij kunnen nu voor zichzelf per applicatie vaststellen hoe snel eventuele storingen in principe kunnen worden opgelost en wat daar vervolgens de financiële consequenties van zijn."

"Wat natuurlijk opvalt is dat de kosten zeer sterk oplopen naarmate de hersteltijd korter dient te zijn. De betrokken business managers weten dit nu ook en kunnen dus op een goed onderbouwde manier een beslissing nemen: hoeveel hebben we er financieel voor over om de hersteltijd van een toepassing op een bepaald niveau te krijgen? Veel meer dan voorheen is het nu een kwestie van het realistisch inschatten wat de waarde van een toepassing is voor het functioneren van het bedrijf. Hoe groter die waarde, hoe meer men dus waarschijnlijk voor uitwijkvoorzieningen zal willen uittrekken. En omgekeerd geldt natuurlijk ook: is het gezien de kosten voor een kortere hersteltijd nu werkelijk zo'n ramp wanneer een applicatie die niet van vitaal belang is voor de operatie een uur of misschien zelfs wel een dag langer 'uit de lucht' is?"