Dan liever in de lucht

Vorige maand las u hier een kort verslag over een paar e-commerce-transacties waarbij de prijs, de kwaliteit en de levertijd van het gebodene niet direct aanleiding gaven tot beleggingen in dotcoms en aanverwante fondsen. Toch was het niet een en al droefenis wat de klok sloeg.

Er kon tenminste iets besteld worden: websites waren gewoon in de lucht en reageerden binnen redelijke tijd op het indrukken van knoppen. Dat is wel eens anders. Op internet zijn lang niet alle aanbieders even goed te bereiken. Een merkwaardige zaak. Wie zaken wil doen, moet bereikbaar zijn. Wie niet bereikbaar is, kan geen zaken doen.
Internet verschilt daarin niet van andere kanalen. De supermarkt, de snackbar en de stomerij sluiten hun deuren ook niet als de concurrent gewoon open is. Elke ondernemer zal dit beamen. (Wie hier 'biemen' leest, lijdt aan 'powerpoint'-verdwazing. En nu we het toch over dit fraaie product hebben: de laatste tijd weer iets teveel presentatoren meegemaakt die midden in een goed voorbereide diashow bleven hangen of de zaal ongewild het bekende blue screen of death voorschotelden. Maar we dwalen af.)
In de internet-economie betekent bereikbaarheid dat het netwerk, de website, de helpdesk en de backoffice continu klaar moeten staan. Onder normale, maar ook onder minder normale omstandigheden. Zoals? Overbelasting door een onverwachte toestroom van klanten. Installatie van een nieuwe softwareversie. Stroomstoring. Virusaanval. Bommelding door een rancuneuze oud-medewerker. Uitval van het netwerk. Bugs in de software. Brandje in de machinekamer. Hardwarestoring. Wateroverlast door een gesprongen leiding. 'Denial-of-service attack' door een clubje 'script kiddies'. Om van de echte calamiteiten maar niet te spreken: een grote brand, een explosie, een vliegtuigramp en andere gebeurtenissen die nooit voorkomen - behalve soms dan.
Dus: hoe kun je ervoor zorgen dat je systemen onder zulke normale en abnormale omstandigheden toch gewoon door blijven draaien? Een eenvoudige vraag die steeds moeilijker te beantwoorden is. Vroeger was het leven simpel. Je had een mainframe. Draaide er op dat mainframe een tijdkritische applicatie, dan was alles dubbel uitgevoerd en had je een eersteklas onderhoudscontract met je leverancier. Voor echt zwaar weer had je afspraken met het uitwijkcentrum in de polder. Nu ziet de wereld er anders uit. Onze kritische processen draaien allang niet meer op één mainframe, maar op netwerken van tientallen servers en routers die de afgelopen jaren door een steeds wisselend team systeembeheerders ongedocumenteerd aan elkaar geknoopt zijn alsof er een wereldrecord macrameeën gebroken moest worden.
Het gevolg is dat we niet altijd meer kunnen voldoen aan de eisen die onze klanten aan de beschikbaarheid van onze systemen stellen - of dat we in de loop der jaren zelfs vergeten zijn welke eisen dat ook alweer waren. Soms liggen die eisen vast in 'service level agreements' of contracten met klanten. Maar in de meeste gevallen moeten ze helemaal opnieuw in kaart gebracht worden. Gelukkig kan dat bijna altijd op de achterkant van een sigarendoosje. Maak een lijstje van de belangrijkste systemen en vraag aan elke eigenaar hoe lang zijn systeem maximaal uit de lucht mag zijn. De antwoorden verschillen van systeem tot systeem en van omstandigheid tot omstandigheid. Zo moet een internet-portal onder normale omstandigheden ongeveer 168 uur per week in de lucht zijn, maar kan een factureringssysteem onder abnormale omstandigheden best een maand gemist worden. Bovendien verschillen de antwoorden van jaar tot jaar. Bij veel organisaties is e-mail een stuk tijdkritischer dan een paar jaar geleden. Een echte kenniswerker 'ken' niet zonder zijn e-mail.
Zijn de belangrijkste beschikbaarheidseisen eenmaal boven water, dan is de volgende vraag: kunnen we met onze huidige infrastructuur aan deze eisen voldoen? Helaas is het antwoord niet altijd even bemoedigend. Als voorbeeld kan een recent onderzoek dienen bij een grote onderneming waaruit bleek dat de meeste systemen bij een grote calamiteit best een paar weken stil mochten liggen. Goed nieuws dus. Waarna de automatiseringsafdeling moest toegeven dat zelfs aan deze soepele eis niet kon worden voldaan, omdat het herstellen van de infrastructuur tenminste twee maanden in beslag zou nemen. Zoveel tijd was nodig voor het inventariseren van de schade, het bestellen van vervangende servers en routers, het aanleggen van nieuwe datacommunicatieverbindingen, het installeren en configureren van de apparatuur, het terugladen van backups en het testen van de nieuwe omgeving. Er wordt nu nagedacht over een nieuwe architectuur. Zeker is dat het geld gaat kosten.
En zo zullen meer bedrijven en instellingen de komende jaren forse investeringen moeten doen om net zo bereikbaar te blijven als hun concurrenten. Ze zullen hun systemen centraliseren om een eind te maken aan de wildgroei in hun infrastructuur. En ze zullen die systemen vervolgens spreiden om minder kwetsbaar te zijn voor lokale incidenten. Eén ding is zeker. Business continuity management maakt ondernemen in de nieuwe economie nog duurder dan het al was.
 
Edo Roos Lindgreen, partner bij KPMG Information Risk Management, en docent IT & Auditing aan de Universiteit van Amsterdam.