De menselijke factor

Inleiding

Eigenlijk is heel veel (en misschien wel alles) van wat hierna wordt verteld te beschouwen als één grote ‘open deur’. Wie het leest, zal denken: ja, natuurlijk, dat spreekt toch allemaal vanzelf? Natuurlijk wijzigen we de default passwords van Oracle accounts, uiteraard hebben eindgebruikers geen toegang tot het productiesysteem…. Helaas is de realiteit anders.
Volgens vele studies wordt zo’n 80% van alle ongeplande downtime van IT-systemen veroorzaakt door menselijk falen of falende processen. Dat is behoorlijk veel, en het beperken van de menselijke factor (en dus ook menselijk falen) kan een aanzienlijk grotere systeembeschikbaarheid opleveren. Dit vraagstuk beperkt zich echter niet alleen tot de IT. Dit wordt getoond door de volgende cijfers:

• Onderzoek Universiteit van Californië in Berkeley naar 600 goed gedocumenteerde, maar falende civieltechnische projecten toont aan dat 80% van het falen werd veroorzaakt door menselijke factoren, organisatorische aspecten en kennisonzekerheden.
• Na bestudering van 500 projecten met falende funderingen kwam men tot de conclusie dat in maar liefst 88% van de gevallen menselijk falen de boosdoener was. De rest was te wijten aan gebrek aan technologie.
• En voor wie vaak vliegt: 50 tot 60% van de vliegtuigongelukken in de burgerluchtvaart is te wijten aan menselijk falen.

Menselijke fouten gebeuren echter niet zomaar: ze zijn meestal het gevolg van onderliggende (management)oorzaken. 

Risicofactoren

• Training
• Ervaring
• Vervanging bij afwezigheid, ontslag etc. (Single Point of Failure in mensen)
• Coaching
• Screenen van externe inhuur
• Eindgebruikers
• Procedures/werkwijzen

Training

Niets is zo belangrijk als zorgen voor voldoende training. Zonder adequate kennis (en het bijhouden van die kennis) is de kans op het maken van fouten zeer groot.

Geef mensen ook op het werk zelf de tijd om zich op gezette tijden te verdiepen in nieuwe technologieën, in plaats van dat iedereen altijd bezig is met het oplossen van problemen of met de dagelijkse gang van zaken. Spreek bijvoorbeeld af dat iedere medewerker 1 dag in de week mag besteden aan ‘bijspijkeren’.

Stimuleer daarnaast de medewerkers ook tot het verder kijken dan de ‘eigen’ expertise: elke Oracle DBA heeft de Oracle basiskennis, maar meestal weinig tot geen kennis van bijvoorbeeld het OS. In geval van calamiteiten kan deze kennis cruciaal zijn.

Overigens moet de training zich niet beperken tot alleen technische (vakmatige) training: ook communicatietrainingen, leren omgaan met stress etc zijn belangrijk, omdat betere communicatie leidt tot het beter en sneller vinden van een oplossing voor een probleem.

En wat te denken van trainingen op gebied van schrijven van documentatie?

Ervaring

De beste, en waarschijnlijk ook meest veilige mix van mensen in een bedrijf is een mix van ervaren mensen (seniors) en mensen met minder tot geen ervaring (mediors en juniors). Dit lijkt een open deur, maar in de praktijk wordt er helaas weinig rekening gehouden met dit gegeven. Vooral bij legacy-systemen is er vaak alleen sprake van een zeer beperkt aantal zeer ervaren mensen en is er geen instroom van juniors. Uiteindelijk (meestal via natuurlijk verloop) stromen de ervaren mensen uit, en het gevolg is dat er geen kennis meer van die oude systemen beschikbaar is in de organisatie.

Zorg dus voor de juiste mix, en geef de ervaren mensen ook de tijd om de onervaren mensen in te werken.

Vervanging (Single Point of Failure voor mensen)

De organisatiestructuur dient zodanig te zijn dat bij afwezigheid van medewerkers voldoende backup/expertise is om dat op te vangen. Je kunt ook denken aan tijdelijke inhuur, waarbij er dan wel gezorgd moet worden voor goede documentatie, zodat de ingehuurde krachten redelijk snel aan de slag kunnen.

Coaching

De behoefte aan coaching vloeit voort uit de noodzaak om kennis over te dragen van seniors naar mediors en juniors. Wijs daarom één of meerdere coaches aan, die elk een aantal juniors onder hun hoede nemen, en geef deze coaches ook de tijd voor het coachen.
Screenen van externe inhuur
Kijk goed naar de CV’s, vraag vooral naar referenties (dit gebeurt in de praktijk vrijwel nooit). Zorg er simpelweg voor dat je weet wat je in huis haalt. De gevolgen kunnen imers enorm zijn.

Eindgebruikers

De eindgebruikers vormen een potentieel gevaar voor de beschikbaarheid van een systeem. Zij hebben vaak niet de ervaring van de IT-specialisten (en hoeven die ook niet te hebben), maar hebben wel vaak toegang tot productiesystemen: via (soms zelfgemaakte) query’s kunnen ze de productiedata raadplegen, met het risico van bv locking of slechte performance.

Procedures/werkwijzen/documentatie

• Change management
• Problem management
• Documenteer de IT processen
• Documenteer werkwijzen

Laat procedures/werkwijzen na iedere wijziging reviewen en indien mogelijk testen!

Maar pas in geval van voortschrijdend inzicht ook de procedures en werkwijzen aan, en stel vervolgens alle betrokkenen daarvan op de hoogte.

Leg documentatie vast op 1 centrale plaats binnen het systeem. Bewaar geen documentatie op een eigen laptop of werkstation! Maak het documentbeheersysteem niet te moeilijk: niemand vindt documenteren leuk en een ingewikkeld systeem om documentatie te maken c.q. te wijzigen heeft vaak het gevolg dat men het achterwege laat.

Ook niet onbelangrijk: geef mensen ook tijd voor documenteren en laat collega’s de producten reviewen! Waarschijnlijk is een documentatie-training ook geen overbodige luxe.
Maak gebruik van centraal vastegelegde en gemakkelijk te vinden templates om de leesbaarheid van de documentatie te bevorderen.

Indekken tegen menselijk falen

Deze paragraaf heeft alleen betrekking op menselijk falen in combinatie met IT-systemen.

• Beperk toegang van een gebruiker tot het systeem tot alleen die data en diensten die hij nodig heeft om zijn werk te kunnen doen. Oracle heeft een scala aan tools om de toegang van de gebruikers te controleren of te authenticeren. Het is zelfs mogelijk om data toegang te beperken op rij-niveau, middels Virtual Private Database (VPD)
• Voer altijd de basala beveiligingsaspecten van een Oracle database uit
• Gebruik een monitor-tool voor dagelijks database beheer (zoals OEM GC)
• Stel dagelijks de gegevens velig en maak gebruik van archive logging
• Maak indien gewenst gebruik van Flashback technologie
• Maak een lijst met fouten die kunnen voorkomen, begin met de meest voor de hand liggende en zorg dat voor het oplossen van elk van de fouten een stappenplan beschikbaar is met de te nemen actie, inclusief eventuele scripts.
• Maak indien gewenst gebruik van een documentbeheersysteem
• Maak indien gewenst gebruik van  een change management tool

« terug naar Availability Adventure