Downtime bij organisaties komt op wereldwijd niveau regelmatig voor. Maar wat voor lering trekken we nu eigenlijk uit datacenter-incidenten? Het valt mij op dat bedrijven na incidenten intern gaan onderzoeken hoe het fout heeft kunnen gaan. De buitenwereld krijgt deze informatie echter nooit te zien. Begrijpelijk, want niemand is trots op het maken van fouten en je wilt uiteraard de reputatieschade beperken. Toch blijft het zonde, want andere organisaties kunnen van jouw fouten leren.
Ik zie dat andere branches vaak meer open (moeten) zijn over de gemaakte fouten en de lessons learned. Op het moment dat een vliegtuig neerstort, gaat een onderzoeksraad onderzoek uitvoeren. De uitkomsten van het onderzoek zijn openbaar, zodat andere vliegtuigmaatschappijen niet dezelfde fouten meer hoeven te maken. Moeten we dan een onderzoeksraad hebben voor ict-incidenten? Volgens Professor Inald Lagendijk van TU Delft wel, maar helaas heeft zijn oproep nog niet tot initiatieven geleid.
Toch kunnen we in de datacenter-wereld wel lering trekken uit bestaande onderzoeken. Zo heeft de Onderzoeksraad voor de Veiligheid en de Amerikaanse National Transportation Safety Board (NTSB) het nodige materiaal over incidenten openbaar gemaakt. Bij mijn organisatie hebben we deze informatie geanalyseerd, en hebben we vier lessons learned kunnen opstellen om de grootste praktijkproblemen te voorkomen.
Lessons learned
Ontwerpfouten: Tal van organisaties maken geen grondige planning en selecteren leveranciers en adviseurs niet nauwkeurig genoeg. Het gevolg hiervan: ontwerpfouten. Het is belangrijk om een ontwerpintentiedocument op te stellen, waarin de vereisten van het te realiseren datacenter tot in detail zijn beschreven. Gebruik deze documentatie niet alleen bij datacenters die nog moeten worden gebouwd, maar ook bij aanpassingen binnen bestaande datacenters.
Onderhoudswerkzaamheden: Stel een programma op voor het onderhoud van het datacenter. Beschrijf ook welke maatregelen van belang zijn als downtime ontstaat vanwege onderhoudswerkzaamheden. Vergeet ook niet het belang van proactief onderhoud. Analyseer storingen op grondige wijze, zodat iedere betrokkene weet welke aanpassingen moeten worden gedaan. Op deze manier kunnen datacenters voorkomen dat de storingen opnieuw plaatsvinden.
Wat organisaties bij het onderhoud vaak vergeten, is dat het personeel goed moet zijn opgeleid. Zij moeten immers goed weten welke acties ze moeten ondernemen bij eventuele problemen. Hiervoor is een goede kennis van de gebruikte datacenter-apparatuur nodig. Maar is ook enige installatiekennis vereist. De kennis die medewerkers tijdens trainingen opdoen, moeten uiteraard regelmatig worden geüpdatet.
Aandacht voor kleine incidenten: Een reeks aan kleine ongemakken – ofwel samengesteld falen – kan elkaar versterken. Bekijk en analyseer dus ook altijd de hele kleine incidenten en los deze zo snel mogelijk op.
Menselijke fouten: We weten vrijwel allemaal dat menselijke fouten een belangrijke oorzaak zijn van downtime. Het trainen van medewerkers is daarom een vereiste, maar een plan van aanpak is minstens zo belangrijk. Beschrijf de wijze waarom het onderhoud in een datacenter moet worden uitgevoerd zo uitgebreid mogelijk. Zorg ervoor dat iedereen zich aan deze regels houdt en test de omschreven procedures altijd uit.
Ondanks dat organisaties het belang van de lessons learned kennen, gaat het in de praktijk nog vaak fout. Achteraf horen we vaak dat niet alle voorzorgsmaatregelen zijn genomen, omdat de organisatie haast had met het in werking stellen van het datacenter. Of ze willen op kosten besparen. Het uiteindelijke resultaat is alleen maar meer downtime en hogere kosten. Onderschat de lessons learned daarom niet!
Ik neem het mee in mijn bagage… ;-D
Hoop dat mijn werkgever dat ook gaat doen.
Helemaal eens. Maar niet iedereen durft zijn fouten toe te geven. En zijn of haar ervaringen er over te delen.
Dus het blijft een lastige discussie.
Paul,
Een onderzoeksraad voor ICT-incidenten, een soort van incidentmanagement op grote schaal?
Nu kan ik me wel een aantal ICT projecten voor de geest halen waar ik inderdaad best zou willen weten hoe het zo mis heeft kunnen gaan en hoe dat in de toekomst voorkomen kan worden. Maar het lijkt me een kansloze oproep omdat veel organisaties namelijk helemaal niet op transparantie zitten te wachten, hoewel professor blijkbaar wel op werk. Oproep heeft dus een groot ‘project-x’ gehalte omdat dit soort onderzoeken achteraf meestal meer kosten dan de geleden schade.
Het maken van “fouten” is de enig juiste manier voor een mens om haar/zijn EGO weer op 1 lijn te krijgen met haar/zijn hart en zeer effectieve manier om weer met beiden benen uit je illusie te stappen, terug naar de harde realiteit van alle dag 🙂
Als ter zake kundige professional kan ik me wel in het artikel vinden. Je zit alleen met het gegeven dat geen enkele organisatie fails aan de grote klok zou willen hangen. Ik heb regelmatig crashcourses gegeven hoe je zeer eenvoudig downtime en IT fails kunt voorkomen. Dit overigens voor zowel IT als Non- IT management. De basics zijn tamelijk eenvoudig.
KaiZen
Zonder zweverig te worden. KaiZen is de kunst van perfectioneren. Dit gebeurd in stapjes. Het stelt namelijk dat het nu eenmaal gegeven is dat fouten worden gemaakt, maar rekent niemand er op af. Elk element word als waardevol gezien in het grotere geheel. Wat dat geheel ook zou zijn. Doel is hiaten en fouten te repareren met een oog deze fout/storing zich niet te laten herhalen in de toekomst.
E2E procedure
Ik heb destijds voor een grote international een kort document beschreven die generiek toepasbaar is genaamd ‘E2E procedure’. Geënt op de KaiZen gedachte dat een ieder even verantwoordelijk was voor zichzelf maar ook voor zijn medemens, heeft dan ook de verantwoordelijkheid stappen te nemen wanneer zij/hij een onvolkomenheid of direct gevaar ziet.
Tenslotte
Menig IT Professional, en al helemaal natuurlijk de non IT professional, hebben een zeer goed idee van de discipline die ze individueel vervullen. Hu eigen ‘Trucje’ zogezegd. Slechts weinigen weten en begrijpen hoe de IT is als materie en hoe het zich beweegt.
Zou men dit wel weten, dan pas zou men een aantal tegenstellingen, die de IT zo kan karakteriseren, tot stand komen en een antwoord hebben op dat communicatieve gat wat er zo vaak is. Want die is niet zo heel moeilijk te dichten.
T.a.v. het artikel
Dat organisaties niet naar buiten treden met onverwachte downtimes moge duidelijk zijn. In eerdere blogs en artikelen heb ik al gewaarschuwd dat de grootschalige incidenten zoals diginotar, C2000, KPN vs Hacker of Vodafone brand in Rotterdam, alleen maar toe zullen gaan nemen.
Reden?
Dat corporate nog steeds denkt dat je spastisch in IT denkt te kunnen snijden als het economisch tegen zit, de verkeerde mensen op de verkeerde plaats en als derde, de commercie. We kunnen ook in 2013 een toename verwachten van kleinere en grotere IT incidenten, incidenten die relatief eenvoudig te voorkomen zijn als men zich op de hoogte wil stellen van de materie IT, hoe die werkt, en de wetmatigheden die de IT karakteriseren.
Tenslotte is IT een prachtige en voorspelbare vehicle die besparingen moet bewerkstelligen en niet dat die initiële en beoogde besparingen door incompetentie tot financiële debacles uitgroeien.
Naast mogelijke imago-schade is er nog een aspect wat meespeelt: de claim-cultuur van de laatste jaren.
Op het moment dat jij als bedrijf publiekelijk toegeeft dat er een fout in jouw product zit, zijn er altijd wel een paar gewiekste advocaten die daar op duiken om te kijken of er geen claim uit te halen valt. Zijn er mensen door in gevaar gebracht? Is er niet een ondeugdelijk product verkocht, waardoor mensen recht zouden kunnen hebben op vergoeding? Is er geen economische schade geleden omdat iets niet gefunctioneerd heeft zoals verwacht?
Om vergelijkbare reden zijn er ook bedrijven die liever niet aan de grote klok hangen dat ze met bepaalde software werken. Mocht zulke software (denk aan het RubyOnRails verhaal van pas geleden) gebreken voorkomen, dan wil je als bedrijf daar niet mee geassocieerd worden of een boel lastige vragen krijgen van klanten.
Paul
Goed artikel. Ik mis echter nog de controleslag na een wijziging om er zeker van te zijn dat de wijziging goed gegaan is. Goede monitoring kan hierbij helpen – maar dat moet wel goed ingericht zijn..
Afrekencultuur maakt dat men graag de schuld bij een ander legt. Dat lost het probleem niet op, noch voorkom ze dat ze ontstaan. Leren van de fouten – het beste wat er is.
“Als je nooit bent gevallen weet je niet hoe moeilijk het is om te blijven staan”.
Bij ons zijn er vandaag (wegens fouten) 3 naar huis gestuurd.
Van de 150 medewerkers op die betreffende afdeling.
De kop maakt: Het maken van fouten is vooral ook leerzaam.
OK, ze waren werkzaam in het magazijn, maar maakt voor hun het probleem niet minder. Schijnbaar denkt onze werkgever daar anders over.