# Postmortem ## Hva det er En postmortem er den skriftlige gjennomgangen et team lager når en driftshendelse er over: hva som skjedde, hva det kostet, hva som ble gjort for å stoppe det, hvorfor det skjedde, og hva som skal endres slik at det ikke skjer på samme måte igjen. Ordet skrives også post-mortem med bindestrek, og mange norske team bruker det engelske uttrykket som det er. Googles bok Site Reliability Engineering definerer det nettopp slik: en skriftlig redegjørelse for hendelsen, konsekvensene, tiltakene som dempet eller løste den, de underliggende årsakene og oppfølgingstiltakene som skal hindre at den gjentar seg. Boken gir øvelsen tre mål: å dokumentere hendelsen, å forstå alle årsakene som bidro til den og ikke bare den første man fant, og å få på plass forebyggende tiltak som faktisk virker. Flertallsformen er viktig. I systemer av en viss størrelse har en hendelse sjelden én årsak, og en gjennomgang som stopper ved den første plausible forklaringen, ender gjerne med å rette utløseren og la forholdene som lot utløseren gjøre skade, stå urørt. Det som skiller praksisen fra en vanlig rapport, er at den er skyldfri, på engelsk blameless. En skyldfri postmortem leter etter bidragende årsaker uten å beskylde noen person eller noe team for dårlig oppførsel, og den går ut fra at alle involverte handlet i god tro og gjorde det riktige ut fra informasjonen de hadde der og da. SRE-boken fører tanken tilbake til helsevesenet og luftfarten, der en feil kan koste liv, og der hver feil ses som en sjanse til å gjøre systemet sterkere. Begrunnelsen er praktisk snarere enn snill: et menneske kan man ikke rette med en kodeendring, men et system eller en prosess kan man. Man skriver ikke en postmortem for hver lille hikke, for den koster tid. Boken nevner de vanlige utløserne, og hvert team justerer tersklene etter seg: - nedetid eller redusert tjeneste som brukerne merker, ut over en avtalt grense; - datatap av noe slag; - at vakthavende måtte gripe inn, for eksempel ved å rulle tilbake en release eller omdirigere trafikk; - en løsningstid over en avtalt grense; - svikt i overvåkingen, noe som vanligvis betyr at et menneske oppdaget problemet først. Kriteriene avtales før noe går i stykker, slik at ingen må diskutere midt i et utfall om akkurat dette teller, og enhver interessent kan be om en postmortem også når en hendelse faller utenfor dem. ## Hvorfor det er viktig En driftshendelse som blir rettet, men aldri skrevet ned, kommer lett tilbake. SRE Workbook går gjennom en postmortem som ble publisert fire måneder etter hendelsen; i mellomtiden gjentok den samme hendelsen seg, og teamet måtte nøste opp igjen det det hadde lært første gang. En gjennomgang som skrives raskt og ligger der folk finner den, gjør ett teams dårlige ettermiddag til kunnskap hele organisasjonen kan bruke. Dokumentet tvinger også fram oppfølgingen. Ben Treynor Sloss, sitert i Workbook, sier det rett ut: for brukerne er en postmortem uten påfølgende handling ikke til å skille fra ingen postmortem i det hele tatt. Derfor krever Google at hver postmortem etter et utfall som rammet brukerne, har minst én oppfølgingssak på en av de to høyeste prioritetene. Postmortemen er stedet der argumentet for det arbeidet føres med dokumentasjon, og der man senere kan se om det ble gjort. Skyldfriheten er det som gjør dokumentasjonen troverdig. Der folk blir hengt ut for feil, slutter de å fortelle om problemer, skriver SRE-boken, og Workbook legger til at de kan skjule nettopp de faktaene som trengs for å hindre en gjentakelse. En skyldfri kultur får med hele tidslinjen, også kommandoen noen kjørte ved en feil, fordi ingen straffes for å fortelle om den. Boken går et skritt videre: et team eller en person som skriver mange postmortemer, skal ikke behandles som et problem, for alternativet er hendelser ingen skriver om. Samlet blir postmortemene et datasett. Når hver av dem har de samme metadataene, kan en organisasjon følge utviklingen i tid til oppdagelse, tid til løsning og hvor langt en hendelse spredte seg, og se om pålitelighetsarbeidet lønner seg. De samme dokumentene brukes i opplæringen: Google spiller gjennom gamle postmortemer som rollespill for nye ingeniører og har lesesirkler og et nyhetsbrev med månedens postmortem. ## Slik ser det ut i praksis SRE-boken har et komplett eksempel i vedlegg D, skrevet for en fiktiv søketjeneste som var nede i 66 minutter under en plutselig trafikkbølge. Seksjonene er et godt utgangspunkt: status, sammendrag, konsekvenser, rotårsaker, utløser, løsning, oppdagelse, oppfølging, lærdommer (hva gikk bra, hva gikk galt, hvor var vi heldige) og en tidslinje i UTC. Tidslinjen markerer fire øyeblikk hver for seg: når utfallet begynte, når hendelsen ble erklært, når utfallet tok slutt, og når hendelsen formelt ble lukket. Det er ulike tidspunkter, og det er i mellomrommene mellom dem at lærdommene som regel ligger. Her er en postmortem i den formen for en oppdiktet hendelse, kortet ned til det som får plass på én skjerm: ```text Postmortem: betalingsfeil etter endret timeout Status: endelig, gjennomgått Eier: vakthavende ingeniør, sammen med hendelseslederen Sammendrag: betaling feilet for rundt hver tredje forespørsel i 31 min Konsekvens: rundt 4 100 mislykkede betalinger, ingen data tapt; feilbudsjettet for 28 dager brukt på én kveld Rotårsaker: timeout mot betalingsleverandøren senket fra 10 s til 1 s i en endring som ble gjennomgått som «bare konfig»; ingenting prøvde den under topplast før release Utløser: kveldens topplast gjorde leverandøren tregere enn 1 s Oppdagelse: varsel på feilrate kalte ut vakten 6 min etter første feil Løsning: endringen rullet tilbake; feilene stoppet 4 min senere Oppfølging Type Prio Eier Ferdig når forebygg P1 plattformleder konfig-endringer kjører lasttest oppdag P1 vaktansvarlig varsel ved timeout mot betaling demp P2 betalingsleder tilbakerulling av konfig er ett steg prosess P2 hendelsesleder konfig-endringer står i deploy-loggen Lærdommer Gikk bra: tilbakerullingen virket på første forsøk Gikk galt: en timeout-endring ble ikke behandlet som kode Var heldige: toppen var kort; en salgsdag ville gitt tre ganger så mye Tidslinje (UTC) 18:02 endringen merget og rullet ut 18:40 topplast; første mislykkede betalinger utfall begynner 18:46 varsel på feilrate kaller ut vakten 18:52 hendelse erklært, hendelsesleder utpekt hendelse begynner 19:07 timeout-endringen funnet, tilbakerulling startet 19:11 feilene stopper utfall slutter 19:41 tretti minutter med normal feilrate hendelse slutter ``` Legg merke til hva som mangler: ingen navn under årsakene og ingen oppfølging som ber noen være mer forsiktig. Hvert punkt har én eier, en prioritet og en sluttilstand som en annen kan etterprøve. Mesteparten av råmaterialet trenger heller ikke skrives etter hukommelsen. SRE-bokens kapittel om håndtering av hendelser lar hendelseslederen føre et levende dokument mens hendelsen pågår, og ber om at det tas vare på til postmortemen, og Workbook beskriver verktøy som fyller ut roller, tidslinje og berørte tjenester av seg selv. På dette nettstedet har casen om [en app som slukte 41 MB i sekundet](/nb/portfolio/an-app-that-ate-41-mb-a-second-stopped/), fra september 2026, det meste av anatomien til en postmortem. Den oppgir konsekvensen i målte tall (111 GB komprimerte sider på en maskin med 36 GB, en stigning på rundt 41 MB i sekundet og 610 996 logglinjer fra én kort økt), finner tre årsaker som multipliserte hverandre i stedet for én syndebukk, retter alle tre, legger til en regresjonstest slik at minnetaket er en egenskap ved bygget, og avslutter med en ærlig merknad om hva det nye frekvensbudsjettet for loggingen kaster. Casen [tre låser på døren, ingen av dem låst](/nb/portfolio/three-locks-on-the-door-none-of-them-locked/) beskriver en gjennomgang og ikke et utfall, men den slutter der en god postmortem bør: de tre rettelsene var små, og det som kom ut av arbeidet, var to regler som nå styrer repoet, slik at hele klassen av feil fanges og ikke bare de tre tilfellene. ## Hvor det går galt **Dokumentet peker ut en syndebukk.** En postmortem som sier at én person alene hadde ansvaret, eller som snakker om «skjødesløs uvitenhet», lærer alle andre å tie neste gang. Skriv om hva som skjedde og hva personen visste der og da, ikke om hvem vedkommende er, og hold språket nøkternt; Workbook peker på dramatiske formuleringer og utropstegn som noe som trekker oppmerksomheten bort fra fakta. **Oppfølgingen ber mennesker skjerpe seg.** «Vær mer forsiktig» og «forbedre driftshåndboken» kan aldri lukkes, og det er mindre pålitelig å endre atferd enn å endre systemet. Gi hvert punkt en type (forebygg, demp, oppdag), én eier, en prioritet og en sluttilstand som kan etterprøves, for eksempel et varsel som går over en bestemt terskel, og opprett en sak for hvert punkt i systemet teamet allerede følger med på. **Rotårsaken stopper ved utløseren.** «En konfigurasjonsendring forårsaket utfallet» navngir utløseren. Rotårsakene er hvorfor endringen kunne gjøre så mye skade: hvorfor gjennomgangen ikke fanget den, hvorfor ingen test oppdaget den, hvorfor varselet kom sent. Hold de to overskriftene adskilt, slik eksempelet i SRE-boken gjør. **Konsekvensen er et skuldertrekk.** Hvis varigheten er det eneste tallet i dokumentet, kan ingen se om rettelsen virket. Anslå berørte brukere, tapte forespørsler og forbrukt feilbudsjett; Workbook råder til at et velfundert anslag er bedre enn ingen data i det hele tatt. **Fire personer eier den, så ingen gjør det.** En postmortem trenger én eier som er det faste kontaktpunktet både for skrivingen og for oppfølgingen, med andre som hjelpere. Det samme gjelder hvert enkelt oppfølgingspunkt. **Den skrives for sent eller leses av ingen.** Hukommelsen svekkes i løpet av dager, og et dokument som sendes rundt måneder senere, kommer etter neste gjentakelse. Workbooks gode eksempel ble sendt ut mindre enn en uke etter at hendelsen var lukket, og til en bred krets. Og gå gjennom den: «En postmortem som ikke er gjennomgått, kunne like gjerne aldri ha eksistert», som SRE-boken skriver. Hold faste gjennomgangsmøter, og legg deretter resultatet i et arkiv det går an å søke i. **Oppfølgingen blir aldri lukket.** Når den samme hendelsen kommer igjen og igjen, sjekk om oppfølgingspunktene tar for lang tid, og om nye funksjoner hele tiden vinner over rettelsene. Mål avslutning, ikke forfatterskap: Google holder FixIt-uker to ganger i året og belønner ingeniørene som lukker flest oppfølgingspunkter fra postmortemer. ## Les mer - [Postmortem Culture: Learning from Failure](https://sre.google/sre-book/postmortem-culture/) — kapittel 15 i Googles bok Site Reliability Engineering: utløsere, skyldfrihet, gjennomgang og kulturen rundt det hele. - [Postmortem Culture: Learning from Failure](https://sre.google/workbook/postmortem-culture/) — SRE Workbooks kapittel med en dårlig og en god postmortem av den samme hendelsen og begrunnelsen for hvorfor de er som de er. - [Example Postmortem](https://sre.google/sre-book/example-postmortem/) — en komplett postmortem for et fiktivt utfall, med oppfølging, lærdommer og tidslinje. - [Managing Incidents](https://sre.google/sre-book/managing-incidents/) — kapittel 14 i SRE-boken: hendelseslederen, det levende hendelsesdokumentet og overleveringene som postmortemen senere bygger på.