Waarom leren van incidenten?

Wanneer er een incident optreedt, is uw eerste reactie waarschijnlijk niet, 'Hurray, een leerkans!' Uw onmiddellijke prioriteit is uitzoeken wat er mis is gegaan en het zo snel mogelijk oplossen, om de impact op uw klanten en eindgebruikers te verminderen, zoals het zou moeten zijn. Dit is het proces voor incidentrespons dat we in een andere module in dit leertraject hebben besproken.

Zodra het incident is opgelost, is het echter belangrijk om de ervaring op te volgen en te profiteren van de ervaring. Als we niet de tijd nemen om van het incident te leren, blijft het gewoon tijdverlies, geld, reputatie, enzovoort; maar als dat incident een bron van informatie kan zijn (op de manier waarop geen andere bron kan) kunnen we er daadwerkelijk voordeel van afleiden.

De beoordeling na incidenten maakt deel uit van de analysefase van de levenscyclus van de incidentrespons. Niet alle evaluaties na een incident zijn gelijk. Er zijn verschillende manieren om het proces te benaderen en te veel aandacht te besteden aan bepaalde aspecten van het probleem of het stellen van vragen op de verkeerde manier, kan de waarde van de beoordeling verminderen.

In deze les gaat u niet alleen nadenken over waarom, maar ook hoe u het beste kunt leren van incidenten. In volgende eenheden gaan we verder met het 'hoe'.

Complexe systemen mislukken

U moet leren om te leren van fouten, niet voor het geval uw systemen mislukken, maar omdat het een zekerheid is dat uw systemen mislukken.

In de moderne wereld zijn de meeste systemen waarmee we vandaag werken, met name in een cloudomgeving, complex. Ze bestaan uit veel onderling verbonden onderdelen die moeten samenwerken en het algehele systeemgedrag komt van de interactie van die onderdelen, net zo veel als van de afzonderlijke onderdelen zelf.

Betrouwbaarheid is de rode draad die door dit leertraject loopt, maar complexe systemen zijn nooit honderd procent betrouwbaar. Dergelijke systemen gedragen zich op interessante en contraintieve manieren. Ze bestaan uit veel onderdelen en vaak is het gedrag van het systeem afkomstig van de interacties tussen die onderdelen, net zo veel als van de onderdelen zelf.

Voor een uitgebreidere bespreking van dit onderwerp is een goede bron het document getiteld How Complex Systems Fail door Dr. Richard I. Cook. Hij is een anesthesioloog en onderzoeker die decennia heeft gewerkt aan veiligheid in complexe systemen, met name patiëntveiligheid in het gezondheidszorgsysteem. In dit artikel legt hij uit wat gebruikelijk is voor complexe systemen op alle gebieden, van gezondheidszorg tot softwarebewerkingen.

Enkele van zijn belangrijkste punten zijn met name relevant voor de incidentanalyse en het incidentbeoordelingsproces:

• Complexe systemen bevatten veranderende mengsels van latente fouten. Het is onmogelijk dat uw systemen worden uitgevoerd zonder dat er meerdere fouten aanwezig zijn. De fouten veranderen voortdurend vanwege veranderende technologie, werkorganisatie en inspanningen om fouten uit te roeien. Uw systeem werkt nooit perfect.
• Complexe systemen worden uitgevoerd in gedegradeerde modus. Complexe systemen worden altijd uitgevoerd als 'verbroken' systemen. Ze blijven werken in die toestand omdat ze veel redundantie in zich hebben en mensen ze toch kunnen laten functioneren ondanks de aanwezigheid van veel defecten. Systeembewerkingen zijn dynamisch, waarbij onderdelen voortdurend mislukken en worden vervangen.
• Catastrofe is altijd om de hoek. De complexiteit van deze systemen betekent dat grote systeemfouten op lange termijn onvermijdelijk zijn. Complexe systemen beschikken altijd over het potentieel voor catastrofale fouten en kunnen op elk gewenst moment gebeuren. Het is onmogelijk om dit potentieel te elimineren omdat het deel uitmaakt van de inherente aard van het systeem.

Preventie en reactie

In uw inspanningen om uw gewenste betrouwbaarheidsniveau voor uw systemen en services te bereiken, doet u alles wat mogelijk is om te voorkomen dat incidenten optreden. Vanwege de complexiteit van deze systemen, zoals eerder uitgelegd, is preventie echter niet altijd mogelijk.

Door deze realisatie moeten we een tweeledige benadering nemen van falen: preventie, en als dat niet mogelijk is, moeten we ons voorbereiden om snel en effectief te reageren.

Preventie en respons zijn gekoppeld. Mogelijk hebt u dit ervaren wanneer uw organisatie een geavanceerd automatiseringsonderdeel heeft geïmplementeerd dat de meeste tijd werkte. Het was geweldig dat het de meeste tijd werkte, maar toen het mislukte, was het waarschijnlijk spectaculair mislukt en maakte het voor operators moeilijker om te begrijpen wat er mis was gegaan.

De systemen waaraan u werkt, bestaan uit meer dan de technologie. In feite werkt u niet ‘aan’ of ‘met’ een systeem; u werkt in het systeem. Je maakt deel uit van het systeem. Complexe systemen omvatten zowel technische onderdelen (hardware, software) als menselijke componenten (personen en hun persoonlijkheden, training en kennis). Onze systemen zijn systemen waar mensen onderdeel van zijn en hoe mensen reageren wanneer dingen fout gaan, is als belangrijk als het voorkomen dat dingen überhaupt misgaan.

Taal

Taal is belangrijk. In deze module leert u dat we heel specifiek zijn over welke termen we gebruiken en welke we opzettelijk niet gebruiken.

De woorden die we gebruiken, zijn van invloed op hoe we denken over wat er in een incident is gebeurd en kunnen drastisch veranderen wat en hoeveel we leren. Deze bevindingen zijn afkomstig uit onderzoek naar veiligheidskritieke industrieën, zoals luchtvaart, geneeskunde, zoek- en reddingsacties, brandbestrijding en meer.

Gezamenlijk is dit onderzoeksveld bekend geworden als Resilience Engineering (RE).

We hebben veel te weten te komen over Resilience Engineering in de technische sector. Verderop in deze module delen we enkele nuttige dingen die we uit de RE-literatuur hebben geleerd, waaronder vier van de meest voorkomende traps waarin mensen vallen wanneer ze proberen te leren van fouten; maar eerst moeten we enkele termen definiëren.