Postmortem

Vad det är

En postmortem är den skriftliga genomgång ett team gör när en incident är över: vad som hände, vad det kostade, vad som gjordes för att stoppa det, varför det hände och vad som ska ändras så att det inte händer på samma sätt igen. Ordet skrivs också post-mortem med bindestreck; betydelsen är densamma. Googles bok Site Reliability Engineering definierar det just så: en skriftlig redogörelse för incidenten, dess konsekvenser, åtgärderna som mildrade eller löste den, grundorsakerna och de uppföljande åtgärder som ska förhindra att den upprepas.

Boken ger övningen tre syften: att dokumentera incidenten, att förstå alla orsaker som bidrog till den och inte bara den första man hittade, och att få på plats förebyggande åtgärder som faktiskt fungerar. Pluralformen är viktig. I system av någon storlek har en incident sällan en enda orsak, och en genomgång som stannar vid den första rimliga förklaringen slutar ofta med att utlösaren åtgärdas medan förhållandena som lät utlösaren göra skada blir kvar.

Det som skiljer praktiken från en vanlig rapport är att den är skuldfri, på engelska blameless. En skuldfri postmortem letar efter bidragande orsaker utan att anklaga någon person eller något team för dåligt beteende, och den utgår från att alla inblandade handlade i god tro och gjorde rätt utifrån den information de hade just då. SRE-boken härleder tanken till sjukvården och flyget, där ett misstag kan kosta liv och där varje fel ses som ett tillfälle att göra systemet starkare. Motiveringen är praktisk snarare än vänlig: en människa går inte att rätta med en kodändring, men ett system eller en process går att ändra.

Man skriver inte en postmortem för varje liten hicka, eftersom den kostar tid. Boken räknar upp de vanliga utlösarna, och varje team justerar trösklarna efter sina behov:

• driftstopp eller försämrad tjänst som användarna märker, utöver en överenskommen gräns;
• dataförlust av något slag;
• att den som har jouren måste ingripa, till exempel genom att rulla tillbaka en release eller leda om trafik;
• en lösningstid över en överenskommen gräns;
• ett fel i övervakningen, vilket oftast betyder att en människa upptäckte problemet först.

Kriterierna bestäms innan något går sönder, så att ingen behöver diskutera mitt i ett avbrott om just det här räknas, och vilken intressent som helst kan be om en postmortem även när en händelse faller utanför dem.

Varför det spelar roll

En incident som åtgärdas men aldrig skrivs ned kommer lätt tillbaka. SRE Workbook går igenom en postmortem som publicerades fyra månader efter incidenten; under tiden inträffade samma incident igen, och teamet fick pussla ihop det som det redan hade lärt sig första gången. En genomgång som skrivs snabbt och ligger där folk hittar den gör ett teams dåliga eftermiddag till kunskap som hela organisationen kan använda.

Dokumentet tvingar också fram uppföljningen. Ben Treynor Sloss, citerad i Workbook, säger det rakt ut: för användarna går en postmortem utan efterföljande åtgärder inte att skilja från ingen postmortem alls. Därför kräver Google att varje postmortem efter ett avbrott som drabbade användarna har minst ett uppföljningsärende på någon av de två högsta prioriteterna. Postmortemen är platsen där argumentet för det arbetet förs med underlag, och där man senare kan se om det blev gjort.

Skuldfriheten är det som gör underlaget trovärdigt. Där folk hängs ut för misstag slutar de berätta om problem, skriver SRE-boken, och Workbook tillägger att de kan dölja just de fakta som behövs för att förhindra en upprepning. En skuldfri kultur får med hela tidslinjen, även kommandot som någon körde av misstag, eftersom ingen straffas för att berätta om det. Boken går ett steg längre: ett team eller en person som skriver många postmortems ska inte behandlas som ett problem, för alternativet är incidenter som ingen skriver om.

Tillsammans blir postmortems ett dataset. När varje dokument har samma metadata kan en organisation följa utvecklingen av tid till upptäckt, tid till lösning och hur långt en incident spred sig, och se om tillförlitlighetsarbetet lönar sig. Samma dokument används i utbildningen: Google spelar upp gamla postmortems som rollspel för nya ingenjörer och har läsecirklar och ett nyhetsbrev med månadens postmortem.

Så ser det ut i praktiken

SRE-boken har ett komplett exempel i bilaga D, skrivet för en fiktiv söktjänst som låg nere i 66 minuter under en plötslig trafikvåg. Avsnitten är en bra utgångspunkt: status, sammanfattning, konsekvenser, grundorsaker, utlösare, lösning, upptäckt, åtgärdspunkter, lärdomar (vad gick bra, vad gick fel, var hade vi tur) och en tidslinje i UTC. Tidslinjen markerar fyra ögonblick var för sig: när avbrottet började, när incidenten deklarerades, när avbrottet tog slut och när incidenten formellt stängdes. Det är olika tidpunkter, och det är i luckorna mellan dem som lärdomarna oftast finns.

Här är en postmortem i den formen för en påhittad incident, nedkortad till det som får plats på en skärm:

Postmortem: betalningsfel efter ändrad timeout
Status:          slutlig, granskad
Ägare:           jourhavande ingenjör, tillsammans med incidentledaren
Sammanfattning:  betalningen misslyckades för var tredje begäran i 31 min
Konsekvens:      omkring 4 100 misslyckade betalningar, ingen data förlorad;
                 felbudgeten för 28 dagar förbrukad på en kväll
Grundorsaker:    timeout mot betalleverantören sänkt från 10 s till 1 s
                 i en ändring som granskades som ”bara konfig”; inget
                 testade den under topplast före release
Utlösare:        kvällens topplast gjorde leverantören långsammare än 1 s
Upptäckt:        larm på felfrekvens kallade jouren 6 min efter första felet
Lösning:         ändringen rullad tillbaka; felen upphörde 4 min senare

Åtgärdspunkter
  Typ         Prio  Ägare           Klart när
  förebygg    P1    plattformschef  konfigändringar kör lasttestet
  upptäck     P1    jouransvarig    larm vid timeout mot betalning
  mildra      P2    betalningschef  återställning av konfig är ett steg
  process     P2    incidentledare  konfigändringar syns i deploy-loggen

Lärdomar
  Gick bra:     återställningen fungerade på första försöket
  Gick fel:     en timeout-ändring behandlades inte som kod
  Hade tur:     toppen var kort; en readag hade gett tre gånger så mycket

Tidslinje (UTC)
  18:02  ändringen mergad och utrullad
  18:40  topplast; första misslyckade betalningar     avbrott börjar
  18:46  larm på felfrekvens kallar jouren
  18:52  incident deklarerad, incidentledare utsedd   incident börjar
  19:07  timeout-ändringen hittad, återställning startad
  19:11  felen upphör                                 avbrott slutar
  19:41  trettio minuter med normal felfrekvens       incident slutar

Lägg märke till vad som saknas: inga namn under orsakerna och ingen åtgärdspunkt som ber någon vara mer försiktig. Varje punkt har en ägare, en prioritet och ett sluttillstånd som någon annan kan kontrollera. Det mesta av råmaterialet behöver inte heller skrivas ur minnet. SRE-bokens kapitel om att hantera incidenter låter incidentledaren föra ett levande dokument medan incidenten pågår och ber att det sparas till postmortemen, och Workbook beskriver verktyg som själva fyller i roller, tidslinje och berörda tjänster.

På den här webbplatsen har fallstudien om en app som åt 41 MB i sekunden, från september 2026, det mesta av en postmortems anatomi. Den anger konsekvensen i uppmätta siffror (111 GB komprimerade sidor på en maskin med 36 GB, en ökning på ungefär 41 MB i sekunden och 610 996 loggrader från en enda kort session), hittar tre orsaker som multiplicerade varandra i stället för en syndabock, åtgärdar alla tre, lägger till ett regressionstest så att minnestaket blir en egenskap hos bygget, och avslutar med ett ärligt förbehåll om vad den nya taktbudgeten för loggningen kastar. Fallstudien tre lås på dörren, inget av dem låst beskriver en granskning och inte ett avbrott, men den slutar där en bra postmortem bör: de tre åtgärderna var små, och det som kom ut av arbetet var två regler som nu styr repot, så att hela klassen av fel fångas och inte bara de tre fallen.

Var det går fel

Dokumentet pekar ut en syndabock. En postmortem som säger att en person ensam bar ansvaret, eller som talar om ”slarvig okunnighet”, lär alla andra att tiga nästa gång. Skriv om vad som hände och vad personen visste just då, inte om vem hen är, och håll språket sakligt; Workbook pekar på dramatiska formuleringar och utropstecken som något som drar uppmärksamheten från fakta.

Åtgärdspunkterna ber människor skärpa sig. ”Var mer försiktig” och ”förbättra driftshandboken” kan aldrig stängas, och det är mindre tillförlitligt att ändra beteende än att ändra systemet. Ge varje punkt en typ (förebygg, mildra, upptäck), en ägare, en prioritet och ett sluttillstånd som går att kontrollera, till exempel ett larm som går över en angiven tröskel, och skapa ett ärende för varje punkt i det system teamet redan bevakar.

Grundorsaken stannar vid utlösaren. ”En konfigurationsändring orsakade avbrottet” namnger utlösaren. Grundorsakerna är varför ändringen kunde göra så stor skada: varför granskningen missade den, varför inget test fångade den, varför larmet kom sent. Håll de två rubrikerna isär, som exemplet i SRE-boken gör.

Konsekvensen är en axelryckning. Om varaktigheten är den enda siffran i dokumentet kan ingen se om åtgärden fungerade. Uppskatta berörda användare, förlorade förfrågningar och förbrukad felbudget; Workbooks råd är att en välgrundad uppskattning är bättre än inga data alls.

Fyra personer äger den, så ingen gör det. En postmortem behöver en ägare som är den fasta kontaktpunkten både för skrivandet och för uppföljningen, med andra som hjälper till. Detsamma gäller varje enskild åtgärdspunkt.

Den skrivs för sent eller läses av ingen. Minnet bleknar inom några dagar, och ett dokument som skickas runt månader senare kommer efter nästa upprepning. Workbooks goda exempel skickades ut mindre än en vecka efter att incidenten stängts, och till en bred krets. Och granska den: ”En ogranskad postmortem kunde lika gärna aldrig ha funnits”, som SRE-boken skriver. Håll regelbundna granskningsmöten och lägg sedan resultatet i ett sökbart arkiv.

Åtgärderna stängs aldrig. När samma incident kommer tillbaka gång på gång, undersök om åtgärdspunkterna tar för lång tid och om nya funktioner hela tiden vinner över rättningarna. Mät avslut, inte författarskap: Google håller FixIt-veckor två gånger om året och belönar de ingenjörer som stänger flest åtgärdspunkter från postmortems.

Läs mer

• Postmortem Culture: Learning from Failure — kapitel 15 i Googles bok Site Reliability Engineering: utlösare, skuldfrihet, granskning och kulturen runt omkring.
• Postmortem Culture: Learning from Failure — SRE Workbooks kapitel med en dålig och en bra postmortem av samma incident och skälen till att de ser ut som de gör.
• Example Postmortem — en komplett postmortem för ett fiktivt avbrott, med åtgärdspunkter, lärdomar och tidslinje.
• Managing Incidents — kapitel 14 i SRE-boken: incidentledaren, det levande incidentdokumentet och överlämningarna som postmortemen senare bygger på.