Egenskaper och komponenter i en bra granskning efter incident
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.
Olika incidenter skiljer sig åt, och det gäller även utformningen av granskningar efter incidenter. 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. Men det är två olika saker och olika 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.
Formulera dina frågor med detta i åtanke, till exempel så här:
- 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 och ting går snett är det frestande att vilja peka ut skyldiga. Kom dock ihåg följande centrala punkt:
Du kan inte utlösa din väg till tillförlitlighet.
Att skylla på 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.
Se granskningen som sökandet efter kunskap och kontext, inte en jakt efter vem som gjorde vad och hur man ska hantera 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. Släpp eventuella förutfattade meningar. Olika personer har olika perspektiv. De håller inte alltid med varandra, och just den blandningen av perspektiv är ovärderlig för lärandeprocessen.
En granskning efter incident är en ärlig frågeställning. Därför inbegriper den följande viktiga komponenter:
- Diskussion
- Samtal
- Meningsskiljaktigheter
- Identifiering
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 du kan följa för att skapa en effektiv granskning efter incident.