”Mänskliga faktorn” är ingen grundorsak: post-mortem utan syndabock

Natten mot onsdag, 02.47. Larmet går, betalflödet står stilla och den som har jouren hittar till slut felet: en konfigurationsändring från eftermiddagen. Ändringen backas, tjänsten kommer tillbaka, alla somnar om. På torsdagen hålls ett möte. I protokollet står det: ”Orsak: mänskliga faktorn. Åtgärd: vara mer noggranna.” Det mötet tog en timme och förändrade ingenting. Samma incident kommer tillbaka — med en annan person i huvudrollen.

Det här är det vanligaste sättet att slösa bort en incident. En blameless post-mortem är motsatsen: en genomgång som utgår från att människor gjorde det som verkade rimligt med den information de hade, och som därför letar efter felet i systemet runt dem. Det låter mjukt. Det är i själva verket den hårdare varianten — för den godtar inte ”någon slarvade” som svar.

”Någon gjorde fel” är sant — och oanvändbart

Att någon gjorde fel är nästan alltid sant och nästan aldrig användbart. Frågorna som ger något handlar om varför felet var möjligt, och varför det såg rätt ut just då:

• Varför gick ändringen att göra? Om ett kommando kan ta ner produktion utan att något stoppar det är det en egenskap hos systemet, inte hos den som skrev kommandot.
• Varför såg det rätt ut? Dokumentationen var gammal, miljöerna hette nästan samma sak, förra gången fungerade det. Den som gjorde felet hade skäl — och skälen är fynden.
• Varför tog det tid att märka? Larmet som gick sent, eller i en kanal ingen läser på natten, är ofta en större lärdom än själva felet.
• Varför var det svårt att backa? Tiden mellan ”vi vet vad det är” och ”det fungerar igen” säger mer om er leveranskedja än om incidenten. Att rulla tillbaka ska vara att peka om, inte att bygga om — mer om det i Bygg en gång.

Ett enkelt test: byt ut personen i berättelsen. Hade incidenten kunnat hända ändå var det inte personen som var orsaken.

Skuldfritt betyder inte kravlöst

Den vanligaste invändningen är att skuldfrihet blir ansvarslöshet. Det är tvärtom. Skuldfritt handlar om vad som händer med den som berättar — inte om hur höga krav som ställs på det som kommer ut av genomgången:

• Ärlighet kräver trygghet. Den som riskerar något på att berätta vad den såg kommer att berätta mindre. Då utreder ni en tillrättalagd version av incidenten.
• Ansvaret flyttar till åtgärderna. Ingen hängs ut, men varje åtgärd har en ägare och ett datum. Det är där kravet ligger.
• Första frågan sätter tonen. ”Vem gjorde det?” och ”vad gjorde det möjligt?” ger två helt olika möten. Den som leder genomgången väljer vilket.

Vad en bra post-mortem innehåller

Ett dokument, inte ett mötesprotokoll. Det behöver inte vara långt, men det ska svara på samma frågor varje gång:

• Tidslinje. Vad hände när, från första ändring till återställd tjänst — med klockslag ur loggar och chattar, inte ur minnet.
• Påverkan. Vad märkte användarna, och hur länge? Det avgör hur mycket arbete incidenten är värd.
• Upptäckt. Hur fick ni veta — ett larm, en kund, en slump? Och hur lång tid gick mellan fel och upptäckt?
• Bidragande orsaker. I plural. En incident är sällan en enda sak som gick fel, utan flera som råkade sammanfalla.
• Vad som fungerade. Runbooken som stämde, rollbacken som gick fort. Det som räddade er den här gången är värt att skydda.
• Åtgärder. Få, konkreta, med ägare och datum.

Där det brukar gå sönder

1. ”Vara mer noggranna”. En åtgärd som bygger på att människor skärper sig är ingen åtgärd. Fråga i stället vad som hade stoppat felet även en trött natt: en spärr, ett test, ett larm, en enklare rollback.
2. Åtgärdslistan ingen äger. En lång lista utan ägare och datum hamnar i en backlogg och stannar där. Några få åtgärder som blir gjorda slår en ambitiös lista som inte blir det.
3. Genomgången som kommer för sent. Minnet bleknar och loggar roteras bort. Håll den inom några dagar, medan tidslinjen fortfarande går att rekonstruera.
4. Bara de stora incidenterna räknas. Nära ögat-händelserna är billigast att lära av: ingen är pressad, ingen kund är arg, och mönstret är detsamma.
5. Dokumentet ingen hittar. En post-mortem i någons privata mapp lär en person något. Samla dem där nästa team kan läsa dem — gärna innan de gör samma ändring.

Så börjar du

Det här kräver ingen incidentplattform. Det kräver en mall och en vana:

1. Ta er senaste incident och skriv tidslinjen i efterhand — bara tidslinjen. Luckorna ni hittar är de första fynden.
2. Skriv en mall på en sida med rubrikerna ovan och lägg den där incidenter redan hanteras.
3. Bestäm en tröskel: vilka händelser ger alltid en post-mortem? Påverkan på användare är en bra gräns att börja med.
4. Låt någon som inte själv stod mitt i incidenten leda genomgången. Den personens enda uppgift är att hålla frågorna vid systemet.
5. Begränsa åtgärderna till det ni faktiskt tänker göra, och följ upp dem där annat arbete följs upp — inte i ett eget dokument.

Över tid är det här som syns i återställningstiden: inte för att felen upphör, utan för att varje incident gör nästa lättare att upptäcka, förstå och backa. Och har ni en felbudget är det post-mortems som berättar vart den tog vägen.

Det är också kärnan i hur vi arbetar med DevOps och SRE: drift handlar inte om att aldrig få fel, utan om att bli bättre av dem man får.

Vårt korta svar

Incidenten har ni redan betalat för. Fråga vad som gjorde felet möjligt, inte vem som gjorde det, och låt varje genomgång sluta i några få åtgärder med ägare och datum. Då får ni något för pengarna.

Står det ”mänskliga faktorn” i rapporten är utredningen inte klar. Den har precis börjat.