Varför lära sig av 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. Alla incidentutvärderingar skapas inte lika. Det finns olika sätt att närma sig processen, och för mycket fokus på vissa aspekter av problemet eller inramning av frågor på fel sätt kan 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 utveckla "hur" i kommande avsnitt.
Komplexa system misslyckas
Du måste "lära dig att lära dig" från misslyckanden, inte för att dina system eventuellt kan misslyckas, utan för att det är en säkerhet 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.
Reliability är tråden som löper genom den här utbildningsplanen, men komplexa system är aldrig hundra procent tillförlitliga. Sådana system beter sig på intressanta och kontraintuitiva sätt. 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 dokumentet med titeln How Complex Systems Fail av 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 viktigaste punkter är särskilt relevanta för incidentanalysen och granskningsprocessen efter incidenten:
- Komplexa system innehåller föränderliga blandningar av latenta fel i dem. Det är omöjligt för dina system att fungera utan att det finns flera fel. Felen förändras ständigt på grund av föränderlig teknik, arbetsorganisation och ansträngningar för att utrota fel. Systemet fungerar aldrig perfekt.
- Komplexa system körs i degraderat läge. Komplexa system fungerar 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. Systemåtgärder är dynamiska, med komponenter som kontinuerligt misslyckas och ersätts.
- Katastrofen är alltid runt hörnet. Komplexiteten i dessa system innebär att stora systemfel på lång sikt är oundvikliga. Komplexa system har alltid potential för katastrofala fel, och det kan inträffa när som helst. Det är omöjligt att eliminera den här potentialen eftersom den är en del av systemets inneboende natur.
Förebyggande och svar
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 insikten måste vi ha en tvådelad strategi för att hantera fel: förebyggande, och när detta inte är möjligt, förberedelse för att svara snabbt och effektivt.
Förebyggande och svar är sammankopplade. Du kan ha upplevt detta när din organisation distribuerade en avancerad automatisering som fungerade för det mesta. Det var fantastiskt att det fungerade för det mesta, men när det misslyckades misslyckades det förmodligen spektakulärt och gjorde det svårare för operatörerna att förstå vad som hade gått fel.
De system som du arbetar med består av mer än 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 är system som inkluderar människor, och hur människorna reagerar när saker går fel är lika viktigt som att förhindra att saker går fel i första hand.
Språk
Språket ä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).
Vi har mycket att lära oss om Resilience Engineering inom tekniksektorn. 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.