Hoe je een succesvolle herstelprocedure voor ICT-systemen opzet

by | nov 5, 2018 | Artikelen, Storingen

Een succesvolle herstelprocedure voor ICT-systemen

Laat ik hem Mario noemen. Ik was net begonnen in mijn eerste week als interim-manager voor een callcenter met bereikbaarheidsdiensten. Je weet wel, zo’n bedrijf dat de telefoon voor je opneemt met: “Goedemorgen Kaderbreed, waarmee kan ik u van dienst zijn?” “Nee, de heer Martens is niet aanwezig. Kan ik een boodschap aannemen?” Dat werk dus.

Ze waren net verhuisd naar een nieuwe pand en volgens mijn voorganger was alles tip top geregeld. De servers waren allemaal dubbel uitgevoerd, er was een UPS die het eerste uur stroomuitval kon overbruggen en in de kelder stond een gloednieuwe noodgenerator die binnen 5 minuten automatisch zou opstarten en het zonder onderbreking kon overnemen. Niets kon ons gebeuren.

Het was een regulier overleg waarbij een periodieke checklist voor een milieucertificering werd doorlopen. En Mario zat erbij. Er werd een vraag gesteld over de noodgenerator. Waarop Mario zich achteloos liet ontvallen: “Oh, die staat al twee weken in storing.” Toen hem gevraagd werd wanneer hij dacht dat op te lossen, en zijn reactie niet de gewenste was, was het feest compleet: nog geen kwartier later kreeg ik van diverse kanten te horen wat er gebeurd was. Tijd voor actie dus.

Plan gemaakt

Het eerste wat ik deed was natuurlijk aan Mario vragen wat er gebeurd was. Mario’s weergave strookte volledig met de beschrijving die ik van eerdere personen kreeg. Inclusief zijn reactie. “Maar waarom reageerde je dan zo?” vroeg ik. Toen kwam het: hij wilde graag een goede oplossing neerzetten en niet in twee weken iets in elkaar knutselen om vervolgens drie maanden lang bezig te zijn met het goedklooien van iets dat in de basis al slecht was. En daar kon ik het natuurlijk alleen maar mee eens zijn. Vanaf dat moment hebben Mario en ik een pact gesloten: ik ging hem helpen goede oplossingen neer te zetten en hij ging mij helpen er een mooie afdeling van te maken.

Het vervolg was simpel. Wat heb je allemaal op je bordje liggen? Wat zou wat jou betreft de volgorde daarin moeten zijn? Welke stappen en werkzaamheden moet je uitvoeren om de stroomvoorziening wel goed in te richten? En in welke volgorde zou je dat willen uitvoeren? Er volgde een keurig overzicht van activiteiten en een plan van aanpak voor de stroomvoorziening. Vervolgens heb ik de communicatie op me genomen om dat gewoon uit te voeren, inclusief de keuze voor de dingen die we niet of later gingen doen.

En toen het plaatje compleet was, sprak ik de legendarische woorden “dan hoop ik maar dat we in de tussentijd geen stroomstoring krijgen.”

Stroomstoring

Dat had ik beter niet kunnen zeggen. Want die stroomstoring kwam er natuurlijk wel. Binnen een week om precies te zijn. De UPS deed gelukkig zijn werk, maar binnen 15 minuten lag alles plat. Het bood mij uitstekende informatie over de taakverdeling bij calamiteiten. Hoe de communicatie verliep (of niet verliep) . Wat er ontbrak. En wat er allemaal verbeterd kon worden. Door alles op te schrijven ontstond er vanzelf een stappenplan voor stroomstoringen, calamiteiten, uitwijk en eigenlijk al die plannen die je nodig hebt om de continuïteit van je ICT-systemen te waarborgen. Een van de zaken waar we achter kwamen was dat we een persoon nodig had die eens in de zoveel tijd een jerrycan met diesel ging vullen bij het tankstation. Gelukkig kon de noodgenerator na 15 minuten opgestart worden en konden daarna alle systemen een voor een opgestart worden. In 45 minuten waren we weer volledig operationeel en gelukkig was de storing tijdens een rustig moment, dus waren er er weinig klanten die last hadden gehad van de storing.

Nu was het een kwestie van een evaluatie uitvoeren met alle betrokkenen, verbeterpunten verzamelen, en daar acties aan koppelen en die te belegen. Uit de evaluatie kwam naar voren dat we met 2 maanden zover konden zijn dat we een test konden uitvoeren van de noodstroomvoorziening. De noodgenerator werd gerepareerd. De werking van UPS werd doorgrond. Er bleken ook nog eens de verkeerde batterijen in te zitten, dus die werden vervangen. Er werd een procedure voor het opnieuw opstarten van het alle servers geschreven. En uiteraard werd er een stappenplan voor de test zelf geschreven.

Noodstroomtest

En toen kwam natuurlijk de grote test: zou alles werken zoals het zou moeten? Met alle operationele managers werd een tijdstip gekozen voor het uitvoeren van de test. Alle personen die aanwezig moesten zijn werden ingepland. En toen moest het gebeuren. Een monteur van de elektrische installatie zou na afstemming van het plan de knop omzetten. Het plan werd met alle betrokkenen afgestemd en er werd afgesproken hoe te communiceren via de walkie talkies. En toen gebeurde het: de monteur deed de schakelaar om. En er gebeurde… helemaal niets!!!

Nu de noodstroomvoorziening succesvol getest was, waren we gewapend tegen noodstroomstoringen. De uitwijk was nog niet geregeld. Of in ieder geval: nog niet getest. En hierbij moet je niet alleen aan servers en een uitwijklocatie denken (al dan niet met back-ups om op te starten). Een callcenter heeft namelijk niet echt loyale klanten. De vorige storing was gelukkig tijdens lunchtijd, waardoor het nauwelijks klanten had gekost. Maar als je als callcenter niet binnen 24 uur weer volledig in bedrijf bent, zijn al je klanten uitgeweken naar je concurrenten en komen ze nooit meer terug. Dan ben je dus failliet.

Voorzieningen treffen

Een succesvolle herstelprocedure voor ICT-systemen begint met het treffen van de volgende voorzieningen.

  • Je moet servers op geografisch gescheiden locaties hebben, die het al dan niet automatisch over kunnen nemen;
  • Je moet over een procedure beschikken waarmee de functionaliteit op de uitwijklocatie voor klanten transparant of uitlegbaar beschikbaar komt;
  • En je moet een testplan maken wat eens in de zoveel tijd – gecontroleerd – daadwerkelijk uitgevoerd wordt.

Maar voor dit soort acties heb je dus niet alleen de ICT-afdeling nodig. Hiervoor moeten ook alle operationele afdelingen een plan hebben liggen. Als je het risico wil afdekken van brand, neerstortende vliegtuigen en ander onheil waarmee de locatie volledig onbeschikbaar raakt moet je ook binnen de tijd die je daarvoor stelt, werkplekken hebben of kunnen regelen voor het personeel dat je nodig hebt om als bedrijf operationeel te blijven.

Uiteindelijk zijn het allemaal afwegingen van risico, schade en kosten. Wat is de maximale tijd dat ik niet bereikbaar/operationeel mag zijn? Hoeveel bedragen de kosten van de verschillende alternatieven? En wat is mij welk risico waard? Het kan natuurlijk prima dat je zegt dat het risico gewoon wilt lopen. Dat de businesscase niet positief is . Maar dan heb je die afweging in ieder geval bewust gemaakt.

Conclusie

Het opzetten van een goede herstelprocedure hoeft niet ingewikkeld te zijn. Vaak weten de mensen die in het proces zitten prima wat er allemaal moet gebeuren. Je moet alleen de tijd vrijmaken om die acties allemaal uit te voeren en de hele procedure op een veilig moment testen. Dan pas ben je verzekerd van een goede herstelprocedure.

Wil je vaker dit soort artikelen lezen? Schrijf je dan hier in en ontvang maximaal eens per twee weken een nieuw artikel in de mailbox.

Reinout Martens

Reinout Martens

Eigenaar en oprichter van Kaderbreed B.V.

Toen Reinout een jaar of 21 was – hij studeerde nog – zat hij op een feestje, waar iemand vertelde dat er een interim manager bij haar bedrijf gestart was. Een botte boer die, zonder rekening te houden met zorgvuldig opgebouwde gewoontes, relaties, werkverhoudingen, etc. overal de bijl inzette en geen rekening leek te houden met wat dat met de mensen deed. Reinouts eerste gedachte was:

“dat kan anders en ik ga dat bewijzen”.

Lees ook deze artikelen

Het luikje bij de chinees

Het luikje bij de chinees

Je kent het vast wel. Je ziet het steeds minder. Maar ik vind het een mooie vergelijking. Het luikje bij de afhaalchinees. De grote vraag is natuurlijk: "Wat gebeurt daar achter dat luikje?" De  vergelijking met IT werd gebruikt door een architect. Toen hij een...

Assumption is the mother of all fuckups

Assumption is the mother of all fuckups

Assumption is the mother of all fuckups. Het is een veelgehoorde uitspraak in IT. En terecht, want een misverstand is snel geboren. Als je het verkeerde IP-adres intikt, gaat het gewoon niet werken. Zeker als systemen met elkaar moeten communiceren. Dat weten IT’ers...

Share This