Varför bör man lära sig från incidenter?
När en incident inträffar är din första reaktion förmodligen inte" Hurray, en inlärningsmöjlighet!" Din omedelbara prioritet är att ta reda på vad som gick fel och åtgärda det så snabbt som möjligt, för att minska påverkan på dina kunder och slutanvändare, som det borde vara. Det här är den incidenthanteringsprocess som vi diskuterade i en annan modul i den här utbildningsvägen.
Men när incidenten har lösts är det viktigt att följa upp och dra nytta av upplevelsen. Om vi inte tar oss tid att lära oss av incidenten förblir det bara en förlust av tid, pengar, rykte och så vidare; men om den incidenten kan vara en informationskälla (på det sätt som ingen annan källa kan) kan vi faktiskt dra viss nytta av den.
Granskningen efter incidenten är en del av analysfasen i livscykeln för incidenthantering. Inte alla granskningar efter incidenter är likadana. Det finns olika sätt att ta sig an processen. Om det läggs för stort fokus på vissa aspekter av problemet eller om frågorna inte ställs på rätt sätt kan det minska värdet av granskningen.
I den här lektionen börjar du tänka på inte bara varför, utan även hur du bäst kan lära dig av incidenter. Vi ska utöka "hur" i efterföljande enheter.
Komplexa system slutar fungera
Du måste "lära dig att lära dig" från fel, inte om dina system misslyckas, utan för att det är säkert att dina system kommer att misslyckas.
I den moderna världen är de flesta system som vi arbetar med idag – särskilt i en molnmiljö – komplexa. De består av många sammankopplade delar som måste fungera tillsammans, och det övergripande systembeteendet kommer från interaktionen av dessa delar lika mycket som från de enskilda delarna själva.
Tillförlitlighet är den röda tråden i den här utbildningsvägen, men komplexa system är aldrig hundra procent tillförlitliga. Sådana system har intressanta och kontraintuitiva beteenden. De består av många delar, och ofta kommer systemets beteende från interaktionerna mellan dessa delar lika mycket som från själva delarna.
För en mer djupgående diskussion om det här ämnet är en bra resurs tidningen med titeln How Complex Systems Fail by Dr. Richard I. Cook. Han är narkosläkare och forskare som har arbetat med säkerhet i komplexa system i årtionden, särskilt patientsäkerhet i sjukvårdssystemet. I den här artikeln förklarar han vad som är vanligt med komplexa system inom alla områden från sjukvård till programvaruverksamhet.
Några av hans centrala poänger är särskilt relevanta för processen för incidentanalys och granskning efter incident:
- Komplexa system innehåller föränderliga kombinationer av latent haveri. Det är omöjligt för dina system att köras utan att det finns flera brister. Haverier ändras konstant på grund av föränderlig teknik, arbetsorganisering och arbetet med att få bukt med haverier. Systemet kommer aldrig att fungera perfekt.
- Komplexa system körs i degraderat läge. Komplexa system körs alltid som "trasiga" system. De fortsätter att "arbeta" i det tillståndet eftersom de innehåller många redundanser, och människor kan hålla dem fungerande trots förekomsten av många brister. Systemdriften är dynamisk med komponenter som kontinuerligt slutar fungera och byts ut.
- Katastrofen väntar alltid runt hörnet. Komplexiteten i dessa system innebär att stora systemfel på lång sikt är oundvikliga. Det finns alltid en risk att komplexa system drabbas av katastrofhaveri, och det kan hända när som helst. Det är omöjligt att eliminera den här potentialen eftersom den är en del av systemets inneboende natur.
Prevention och åtgärd
I ditt arbete med att uppnå önskad tillförlitlighetsnivå för dina system och tjänster gör du allt du kan för att förhindra att incidenter inträffar. Men på grund av komplexiteten i dessa system, som tidigare beskrivits, är förebyggande inte alltid möjligt.
På grund av den här insikten måste vi ha en tvådelad metod för fel: förebyggande, och när det inte är möjligt, förberedelse för att svara snabbt och effektivt.
Prevention och åtgärd är sammankopplade. Du kan ha upplevt detta när din organisation distribuerade en avancerad automatisering som fungerade för det mesta. Visserligen var det toppen när den fungerade, men när den havererade skedde det förmodligen med emfas, vilket gjorde det svårare för operatörerna att förstå vad som hade gått snett.
De system som du arbetar med består av mer än bara den bakomliggande tekniken. I själva verket arbetar du inte "på" eller "med" ett system; du arbetar i systemet. Du är en del av systemet. Komplexa system omfattar både tekniska komponenter (maskinvara, programvara) och mänskliga komponenter (människor och deras personligheter, utbildning och kunskap). Våra system inbegriper människor, och människors sätt att agera när saker går snett är lika viktiga som att förhindra att saker går snett överhuvudtaget.
Språk
Språkbruk är viktigt. I den här modulen får du lära dig att vi kommer att vara mycket specifika om vilka termer vi använder och vilka termer vi avsiktligt inte använder.
De ord vi använder påverkar hur vi tänker på vad som hände i en incident och kan drastiskt ändra vad och hur mycket vi lär oss. Denna slutsats kommer från forskning inom säkerhetskritiska branscher som flyg, medicin, sökning och räddning, brandbekämpning med mera.
Tillsammans har detta forskningsområde blivit känt som Resilience Engineering (RE).
I teknikbranschen finns det mycket vi kan lära oss om Resilience Engineering. Senare i den här modulen delar vi några riktigt användbara saker som vi har lärt oss från RE-litteraturen, inklusive fyra av de vanligaste fällorna som människor hamnar i när de försöker lära sig av fel; men först måste vi definiera vissa termer.