Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet het redactionele gedachtegoed van Computable.

Het maken van fouten is vooral ook leerzaam

08-02-2013 14:37 | Door Paul Bron | Er zijn 9 reacties op dit artikel | Dit artikel heeft nog geen cijfer (te weinig beoordelingen) | Permalink
Computable Expert
Paul Bron
Paul Bron

Vice President bij Schneider Electric

Expert van Computable voor de topics: Datacenters, Cloud Computing en Management

Meer

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!

Deel dit artikel via LinkedIn
Deel dit artikel via Facebook
Deel dit artikel via Twitter

Gerelateerde artikelen

03-05-13  'Mens belangrijkste oorzaak downtime'

18 vacatures
Technical ECM Consultant

Euroscript Delt , Eindhoven

Technisch Ontwerper

4DM Services BV , IJsselstein UT

Informatiearchitect (36 uur per week)

Gemeente Den Helder , Den Helder

Software Architect

VNU Vacature Media , Amsterdam

Oracle Ontwikkelaar JDeveloper Senior

Ordina , Nieuwegein

Top 10 reagerende bezoekers
      Aantal
reacties
Gemiddelde
waardering
Klik voor meer info 1 2034 6.81
Klik voor meer info 2 1523 6.70
Klik voor meer info 3 1236 6.70
Klik voor meer info 4 1144 6.65
Klik voor meer info 5 890 6.56
Klik voor meer info 6 609 6.33
Klik voor meer info 7 433 6.32
Klik voor meer info 8 1095 6.11
Klik voor meer info 9 722 6.08
Klik voor meer info 10 462 6.06