Egenskaper och komponenter i en bra granskning efter incident
- 3 minuter
Nu vet du vad en granskning efter incident är, dess roll i incidenthanteringsprocessen och när du bör utföra en. I den här lektionen går du lite djupare in på detaljerna i vad som gör en granskning efter incident mest effektiv.
Eftersom incidenter skiljer sig åt kan den exakta makeupen av granskningar efter incident också vara annorlunda. Det finns dock några vanliga egenskaper och komponenter i en bra granskning som kan ge dig en solid grund för att genomföra processen.
Vad det inte är
Innan du kan förstå de egenskaper som ger en bra granskning efter incident bör du överväga vad det inte är.
- Det är inte ett dokument eller en rapport. Det är lätt att se en "granskning" som en skriftlig sammanfattning, och en sammanfattningsrapport följer ofta en granskning efter incidenten. Det här är dock två olika och distinkta delar av analysfasen i livscykeln för incidenthantering.
- Det är inte en bestämning av orsakssamband. Din granskning tittar på de faktorer som bidrog till felet, men syftet är inte att hitta en skyldig (särskilt inte en enda rotorsak; komplexa system misslyckas nästan alltid på grund av en hel uppsättning bidragande faktorer). Det är att tänka på och dela information om alla aspekter av incidenten för att lära sig och förbättra. Det är inte en lista över åtgärdsobjekt. Du kan få en sådan lista som ett resultat av det du lär dig i recensionen, men det är inte fokus. Om du inte kommer undan med en lista över objekt i en biljettkö eller buggrapporter i ett felrapporteringssystem, men du vet mer om dina system än tidigare, lyckades granskningen.
Incidentgranskningen är mer än något annat en konversation. Det är ett definierat utrymme där ditt team kan granska vad de visste vid den tidpunkten och vad de vet nu, och utforska och bättre förstå hur delar av systemet – inklusive de mänskliga delarna – fungerar eller inte fungerar tillsammans som svar på problem.
Egenskaper och komponenter
Som vi nämnde i den förra lektionen måste en incidentgranskning vara felfri. Även om du måste undersöka hur de mänskliga delarna av systemet interagerade med det, gör du inte detta för att märka någon "fel". Fokus bör ligga på teknikens och processens misslyckanden, inte på människorna.
Rama in dina frågor för att återspegla detta, till exempel:
- Vad var underskottet i vår övervakning som misslyckades med att ge personen vid tangentbordet det nödvändiga sammanhanget för att fatta rätt beslut?
- Varför fanns det ett alternativ för att "förstöra hela databasen" i verktyget alls?
- Eller ännu bättre: Varför bad inte verktyget om bekräftelse innan den här funktionen utfördes?
När saker går fel kan det vara frestande att peka fingrar. Du måste dock komma ihåg den här nyckelpunkten:
Du kan inte sparka dig till tillförlitlighet.
Att skambelägga och skylla på, eller en utredning som syftar till att hitta och avskeda den person som är "ansvarig," kommer inte att leda till mer tillförlitliga system. I stället leder det till ett oerfaret eller till och med tomt driftsteam och personal som är rädda för att agera.
Närma dig granskningen som en sökning efter kunskap och sammanhang, inte en jakt på vem som gjorde vad och en reaktion på det.
Även om granskningen handlar om teknikens fel är det inte en teknisk process lika mycket som det är en personprocess. Prata – och ännu viktigare, lyssna – med de personer som var inblandade i incidenten. Ha ett öppet sinne. Olika människor har olika perspektiv och inte alla kommer att hålla med, och den blandningen av perspektiv är ovärderlig för inlärningsprocessen.
En granskning efter incident är en ärlig undersökning. Därför omfattar den följande viktiga komponenter:
- Diskussion
- Diskurs
- Meningsskiljaktighet
- Upptäckt
Dessa "4 Ds" skapar ett ramverk där du kan skapa en granskning efter incident som kan resultera i mer tillförlitliga system och mer produktiva team som arbetar tillsammans.
I nästa lektion pratar vi mer om den process som du kan följa för att skapa en effektiv granskning efter incident.