En postmortem er en kort skriftlig gennemgang af et nedbrud: hvad der skete, hvordan det påvirkede brugerne, hvorfor det skete, og hvad du vil ændre, så det ikke sker igen. En postmortem uden skyld (blameless) fokuserer på systemer og processer frem for på, hvem der lavede en fejl. Grundskabelonen har seks dele: opsummering, påvirkning, tidslinje, grundårsag, hvad der gik godt og skidt, og opgaver med ansvarlige og datoer.
Nedenfor kan du læse, hvornår du skal skrive en, hvilke principper der holder den brugbar, en komplet skabelon at kopiere, et udfyldt eksempel, og hvordan du gør den til en opsummering til kunderne.
Hvornår skal du skrive en postmortem?
Ikke alle små udfald kræver et dokument. Fastsæt klare kriterier, så beslutningen ikke skal træffes under pres. Almindelige kriterier:
Kunderne kunne ikke bruge en kernefunktion som checkout, login eller API’et i mere end et par minutter.
Data gik tabt, blev beskadiget eller blev eksponeret.
Hændelsen brugte en stor del af dit månedlige error budget.
Kunder eller en klient meldte problemet, før overvågningen gjorde.
Den samme type hændelse er sket før.
Skriv den inden for få arbejdsdage, mens hukommelsen og logs er friske. En postmortem, der skrives tre uger senere, er mest gætværk.
Principper for en gennemgang uden skyld
En postmortem uden skyld går ud fra, at alle handlede fornuftigt ud fra den information, de havde på det tidspunkt. Hvis én person kunne lægge sitet ned med én kommando, er problemet, at én kommando kunne lægge sitet ned. Skyld får folk til at skjule detaljer, og det er netop detaljerne, du har brug for.
Beskriv handlinger, ikke personer. “Importjobbet blev startet i spidsbelastningen” i stedet for “Anna startede importen på det forkerte tidspunkt”.
Spørg “hvordan”, ikke “hvem”. Hvordan tillod systemet det? Hvordan fandt vi ud af det? Hvordan kunne vi have opdaget det før?
Kig efter flere årsager. Hændelser har sjældent én grundårsag. Som regel møder en udløser en svaghed, som en manglende sikring ikke fangede.
Brug fakta og tidsstempler. Overvågningsdata, logs og chathistorik slår hukommelsen.
Hold opgavelisten kort. To eller tre ændringer, der bliver gennemført, slår ti, der ikke bliver.
Postmortem-skabelonen
Kopier den ind i jeres wiki, repository eller dokumentværktøj. Hver overskrift har en hjælpetekst om, hvad der hører til der.
# Postmortem: [kort titel]
Dato for hændelsen: [ÅÅÅÅ-MM-DD]
Forfatter(e): [navne]
Status: [kladde / under gennemgang / endelig]
Alvorlighed: [fx SEV1 / SEV2 / SEV3]
## Opsummering
[To eller tre sætninger: hvad gik i stykker, hvor længe, og hvordan blev det løst.]
## Påvirkning
– Berørte tjenester og komponenter:
– Varighed (start til genopretning):
– Berørte brugere eller kunder:
– Forretningsmæssig påvirkning (ordrer, tilmeldinger, SLA):
– Kommunikation til kunder (statusside, e-mails, henvendelser):
## Opdagelse
– Hvordan blev hændelsen opdaget? (monitor, kunde, teammedlem)
– Tid fra start til alarm:
– Tid fra alarm til kvittering:
## Tidslinje
[Alle tider i én tidszone. Én linje pr. hændelse.]
TT:MM hændelse
TT:MM hændelse
## Grundårsag og medvirkende faktorer
– Udløser:
– Underliggende årsag:
– Hvorfor sikringerne ikke fangede det:
## Løsning
[Hvad blev gjort for at genoprette driften, og af hvem (rolle, ikke skyld).]
## Hvad gik godt
–
## Hvad gik skidt
–
## Hvor vi var heldige
–
## Opgaver
| Opgave | Type (forebyg / opdag / reager) | Ansvarlig | Frist | Ticket |
|——–|———————————|———–|——-|——–|
| | | | | |
## Opsummering til kunder
[Kort version til statussiden eller e-mailen til kunden.]
Afsnittet “Hvor vi var heldige” er nemt at springe over og ofte det mest værdifulde. Det fanger de nære ved-ulykker: hændelsen skete om natten, backuppen var kørt en time før, den ene person, der kendte systemet, var tilfældigvis vågen.
Et udfyldt eksempel
Her er skabelonen brugt på en fiktiv hændelse i en webshop, northwind.shop. Detaljerne er opfundet til illustration, men strukturen er, som en rigtig postmortem bør se ud.
Opsummering
Fra 03:12 til 03:19 CET returnerede checkout på northwind.shop 503 Service Unavailable. En natlig produktimport brugte alle PHP-FPM-workers, så forespørgsler til checkout blev afvist. Den vagthavende udvikler stoppede importen og genstartede PHP-FPM. Samlet nedetid: 7 minutter.
Påvirkning
Checkout og kurv var utilgængelige i 7 minutter. Produktsider blev leveret fra cache og forblev oppe.
Serverlogs viser 23 mislykkede forespørgsler til checkout i tidsrummet (eksempeltal).
Statussiden viste “Checkout: større nedbrud” fra 03:13. Der kom ingen supporthenvendelser.
Tidslinje
03:00 Den natlige produktimport starter.
03:12 Oppetidstjekket af northwind.shop/checkout returnerer 503.
03:13 Et andet tjek bekræfter fejlen. En hændelse åbnes, den vagthavende udvikler får en alarm på Telegram, og detaljerne postes i teamets Slack-kanal. Statussiden markerer Checkout som nede.
03:15 Den vagthavende kvitterer i Slack og åbner serverdashboardet. Hukommelse og CPU er høje på web-01.
03:17 PHP-FPM-status viser alle workers optaget af importforespørgsler. Importjobbet stoppes.
03:18 PHP-FPM genstartes.
03:19 Tjekkene består igen. En besked om genopretning sendes ud med en samlet nedetid på 7 minutter.
Grundårsag og medvirkende faktorer
Udløser: leverandørens feed var tre gange større end normalt efter en katalogopdatering.
Underliggende årsag: importen kører gennem den samme PHP-FPM-pool som shoppen. Store importer kan bruge alle workers.
Manglende sikring: importen har ingen grænse for samtidige forespørgsler, og der var ingen alarm på mætning af workers.
Vil du vide, hvorfor opbrugte workers viser sig som netop denne fejl, så se vores guide til fejlen 503 Service Unavailable.
Hvad gik godt, skidt og heldigt
Godt: opdagelsen tog ét minut og kvitteringen to. Statussiden blev opdateret uden manuelt arbejde.
Skidt: det tog fire minutter at finde årsagen, fordi intet forbandt importjobbet med webserverne.
Heldigt: det skete kl. 03:12, ikke under aftenens spidsbelastning.
Opgaver
OpgaveTypeAnsvarligFristKør importen i en separat worker-pool med en grænse for samtidighedForebygBackend-leadInden for 2 ugerAlarm, når hukommelsen på web-01 ligger over 85%OpdagDriftDenne ugeTilføj et heartbeat, der melder, når importen er færdigOpdagBackend-leadDenne ugeTilføj runbooken “503 i checkout” til monitorenReagerVagtrotationenDenne uge
Sådan offentliggør du en opsummering til kunderne
Den interne postmortem er til teamet. Kunderne har brug for en kortere version uden servernavne: hvad der skete, hvor længe, om deres data er sikre, og hvad du ændrer. Læg den på din statusside, og link til den fra alle e-mails om hændelsen eller opdateringer til kunder. I Uptimecheck skriver du gennemgangen af hændelsen direkte på selve hændelsen ved siden af dens tidslinje og kan vælge at vise den under hændelsen på din statusside.
Checkout utilgængelig, 03:12 til 03:19 CET
Mellem 03:12 og 03:19 CET kunne kunder ikke gennemføre køb på
northwind.shop. Det var stadig muligt at se produkter, og ingen ordrer
eller betalingsoplysninger gik tabt.
Årsagen var en planlagt produktopdatering, der brugte mere serverkapacitet
end forventet. Vi stoppede den, og checkout var tilbage kl. 03:19.
Vi flytter disse opdateringer til separat kapacitet, så de ikke kan påvirke
checkout igen, og har tilføjet tidligere advarsler for denne type belastning.
Hold tonen saglig og løfterne konkrete. “Vi tager driftssikkerhed alvorligt” siger ingenting; “importer kører nu på separat kapacitet” siger noget. Vores guide til, hvordan du laver en statusside, gennemgår formuleringer til opdateringer om hændelser mere detaljeret.
Det hjælper også at vide, hvor mange der lagde mærke til det. Uptimecheck inkluderer statistik for statussider med alle statussider, med besøg pr. dag og fordelt på land, henviser og enhed over de seneste 30 dage, så du kan tilføje til postmortem’en, hvor mange der tjekkede siden på dagen for hændelsen. Sammen med hændelsens tidslinje får du start, alarm, kvittering, genopretning og rækkevidde uden at grave i logs. Hændelser på websites indeholder også det fejlende svar med et skærmbillede eller en traceroute, hvilket er en god start på afsnittene om opdagelse og grundårsag.
Sådan følger du op på opgaverne
En postmortem uden gennemførte opgaver er en historie, ikke en løsning. Behandl opgaverne som alt andet arbejde:
Opret en ticket for hver opgave i det værktøj, teamet allerede bruger, og link til den fra postmortem’en.
Giv hver opgave én ansvarlig og en frist.
Mærk opgaverne efter type: forebyg, opdag eller reager. Hvis alle opgaver lyder “vær mere forsigtig”, er gennemgangen ikke færdig.
Gennemgå åbne postmortem-opgaver på et fast møde, fx hver anden uge.
Marker først postmortem’en som endelig, når alle opgaver er udført eller udtrykkeligt droppet med en begrundelse.
Med tiden bliver selve postmortems til data. Tæl, hvor mange hændelser der blev fundet af overvågningen i forhold til af kunderne, og følg tiden til opdagelse og reaktion fra den ene hændelse til den næste. Vores artikel om MTTR, MTTA og MTBF forklarer, hvordan du beregner dem.
Sådan holder du gennemgangsmødet
Ved større hændelser hjælper et møde på 30 til 45 minutter. Del udkastet på forhånd, lad den person, der ledte indsatsen, gennemgå tidslinjen, og brug det meste af tiden på medvirkende faktorer og opgaver. En neutral mødeleder, der ikke arbejdede på hændelsen, holder samtalen fri for skyld og inden for tiden. Slut af med at bekræfte ansvarlige og frister for hver opgave.
Få tidsstemplerne til din næste postmortem automatisk. Prøv Uptimecheck gratis i 14 dage, uden kreditkort.