En postmortem etter en hendelse er en kort skriftlig gjennomgang av et driftsavbrudd: hva som skjedde, hvordan det påvirket brukerne, hvorfor det skjedde og hva dere endrer for at det ikke skal skje igjen. En postmortem uten skyldfordeling (blameless) handler om systemer og prosesser, ikke om hvem som gjorde en feil. Grunnmalen har seks deler: sammendrag, konsekvenser, tidslinje, rotårsak, hva som gikk bra og dårlig, og tiltak med ansvarlige og frister.
Nedenfor finner du når du bør skrive en, prinsippene som gjør den nyttig, en komplett mal du kan kopiere, et utfylt eksempel og hvordan du gjør den om til en oppsummering for kundene.
Når du bør skrive en postmortem
Ikke alle små hikke trenger et dokument. Sett tydelige kriterier, så beslutningen ikke tas under press. Vanlige kriterier:
Kundene kunne ikke bruke en kjernefunksjon, som kassen, innloggingen eller API-et, i mer enn noen få minutter.
Data gikk tapt, ble ødelagt eller ble eksponert.
Hendelsen brukte en stor del av det månedlige feilbudsjettet ditt.
Kunder eller en klient meldte fra om problemet før overvåkingen gjorde det.
Den samme typen hendelse har skjedd før.
Skriv den innen noen få virkedager, mens hukommelsen og loggene er ferske. En postmortem som skrives tre uker senere, er stort sett gjetning.
Prinsipper uten skyldfordeling
En postmortem uten skyldfordeling forutsetter at alle handlet fornuftig ut fra informasjonen de hadde på det tidspunktet. Hvis én person kunne ta ned nettstedet med én kommando, er problemet at én kommando kunne ta ned nettstedet. Skyldfordeling får folk til å skjule detaljer, og det er detaljene du trenger.
Beskriv handlinger, ikke personer. «Importjobben ble startet i rushtiden» i stedet for «Anna startet importen på feil tidspunkt».
Spør «hvordan», ikke «hvem». Hvordan kunne systemet tillate dette? Hvordan fant vi det ut? Hvordan kunne vi ha oppdaget det tidligere?
Se etter flere årsaker. Hendelser har sjelden én enkelt rotårsak. Som regel møter en utløser en svakhet som en manglende sikring ikke fanget opp.
Bruk fakta og tidsstempler. Overvåkingsdata, logger og chathistorikk slår hukommelsen.
Hold tiltakslisten kort. To eller tre endringer som blir gjennomført, slår ti som ikke blir det.
Postmortem-malen
Kopier denne inn i wikien, repoet eller dokumentverktøyet ditt. Hver overskrift har en ledetekst for hva som hører hjemme der.
# Postmortem: [kort tittel]
Dato for hendelsen: [ÅÅÅÅ-MM-DD]
Forfatter(e): [navn]
Status: [utkast / til gjennomgang / endelig]
Alvorlighetsgrad: [f.eks. SEV1 / SEV2 / SEV3]
## Sammendrag
[To eller tre setninger: hva som gikk i stykker, hvor lenge og hvordan det ble løst.]
## Konsekvenser
– Berørte tjenester og komponenter:
– Varighet (fra start til gjenoppretting):
– Berørte brukere eller kunder:
– Forretningsmessige konsekvenser (bestillinger, registreringer, SLA):
– Kommunikasjon med kunder (statusside, e-post, saker):
## Oppdagelse
– Hvordan ble hendelsen oppdaget? (monitor, kunde, teammedlem)
– Tid fra start til varsel:
– Tid fra varsel til bekreftelse:
## Tidslinje
[Alle tider i én tidssone. Én linje per hendelse.]
TT:MM hendelse
TT:MM hendelse
## Rotårsak og medvirkende faktorer
– Utløser:
– Underliggende årsak:
– Hvorfor sikringene ikke fanget det opp:
## Løsning
[Hva som ble gjort for å gjenopprette tjenesten, og av hvem (rolle, ikke skyld).]
## Hva som gikk bra
–
## Hva som gikk dårlig
–
## Der vi hadde flaks
–
## Tiltak
| Tiltak | Type (forebygge / oppdage / respondere) | Ansvarlig | Frist | Sak |
|——–|—————————————–|———–|——-|—–|
| | | | | |
## Oppsummering for kunder
[Kortversjon for statussiden eller e-post til kunden.]
Delen «Der vi hadde flaks» er lett å hoppe over og ofte den mest verdifulle. Den fanger opp nestenulykkene: hendelsen skjedde om natten, sikkerhetskopien hadde kjørt en time tidligere, den ene personen som kjente systemet, var tilfeldigvis våken.
Et utfylt eksempel
Her er malen brukt på en oppdiktet hendelse i en nettbutikk, northwind.shop. Detaljene er laget for illustrasjonens skyld, men strukturen er slik en ekte postmortem bør se ut.
Sammendrag
Fra kl. 03.12 til 03.19 CET returnerte kassen på northwind.shop 503 Service Unavailable. En nattlig produktimport brukte alle PHP-FPM-workerne, så forespørsler til kassen ble avvist. Utvikleren som hadde vakt, stoppet importen og startet PHP-FPM på nytt. Total nedetid: 7 minutter.
Konsekvenser
Kassen og handlekurven var utilgjengelige i 7 minutter. Produktsidene ble levert fra hurtigbufferen og holdt seg oppe.
Serverloggene viser 23 mislykkede forespørsler til kassen i tidsrommet (eksempeltall).
Statussiden viste «Kasse: større driftsavbrudd» fra kl. 03.13. Ingen henvendelser kom inn til kundestøtte.
Tidslinje
03.00 Den nattlige produktimporten starter.
03.12 Oppetidssjekken mot northwind.shop/checkout returnerer 503.
03.13 En ny sjekk bekrefter feilen. En hendelse åpnes, vakthavende utvikler varsles på Telegram, og detaljene legges ut i teamets Slack-kanal. Statussiden markerer Kasse som nede.
03.15 Vakthavende bekrefter i Slack og åpner serverdashbordet. Minne og CPU er høye på web-01.
03.17 PHP-FPM-statusen viser at alle workerne er opptatt med importforespørsler. Importjobben stoppes.
03.18 PHP-FPM startes på nytt.
03.19 Sjekkene går gjennom igjen. Et varsel om gjenoppretting sendes ut med en total nedetid på 7 minutter.
Rotårsak og medvirkende faktorer
Utløser: leverandørfeeden var tre ganger større enn vanlig etter en katalogoppdatering.
Underliggende årsak: importen kjører gjennom den samme PHP-FPM-poolen som butikken. Store importer kan bruke opp alle workerne.
Manglende sikring: importen har ingen grense for samtidige forespørsler, og det fantes ikke noe varsel om metning av workere.
Vil du vite hvorfor utbrukte workere gir akkurat denne feilen, kan du lese guiden vår om feilen 503 Service Unavailable.
Hva som gikk bra, dårlig og hvor vi hadde flaks
Bra: oppdagelsen tok ett minutt og bekreftelsen to. Statussiden ble oppdatert uten manuelt arbeid.
Dårlig: det tok fire minutter å finne årsaken fordi ingenting koblet importjobben til webserverne.
Flaks: det skjedde kl. 03.12, ikke midt i kveldsrushet.
Tiltak
TiltakTypeAnsvarligFristKjør importen i en egen worker-pool med grense for samtidighetForebyggeBackend-ansvarligInnen 2 ukerVarsle når minnet på web-01 holder seg over 85 %OppdageDriftDenne ukenLegg til en heartbeat som melder fra når importen er ferdigOppdageBackend-ansvarligDenne ukenLegg runbooken «503 i kassen» til monitorenRespondereVaktrotasjonenDenne uken
Publiser en oppsummering for kundene
Den interne postmortemen er for teamet. Kundene trenger en kortere versjon uten servernavn: hva som skjedde, hvor lenge, om dataene deres er trygge og hva dere endrer. Legg den ut på statussiden din og lenk til den fra e-poster om hendelsen og oppdateringer til kunder. I Uptimecheck skriver du gjennomgangen rett på hendelsen, ved siden av tidslinjen, og kan velge å vise den under hendelsen på statussiden.
Kassen utilgjengelig, kl. 03.12 til 03.19 CET
Mellom kl. 03.12 og 03.19 CET kunne ikke kunder fullføre kjøp på
northwind.shop. Det var fortsatt mulig å se på produkter, og ingen
bestillinger eller betalingsopplysninger gikk tapt.
Årsaken var en planlagt produktoppdatering som brukte mer serverkapasitet
enn forventet. Vi stoppet den, og kassen var tilbake kl. 03.19.
Vi flytter disse oppdateringene til egen kapasitet, slik at de ikke kan
påvirke kassen igjen, og har lagt til tidligere varsler for denne typen
belastning.
Hold tonen saklig og løftene konkrete. «Vi tar driftssikkerhet på alvor» sier ingenting; «importer kjører nå på egen kapasitet» sier noe. Guiden vår om hvordan du lager en statusside går nærmere inn på ordlyden i hendelsesoppdateringer.
Det hjelper også å vite hvor mange som la merke til det. Uptimecheck inkluderer statistikk for statussider med hver statusside, med besøk per dag og etter land, henvisningskilde og enhet de siste 30 dagene, så du kan føye til i postmortemen hvor mange som sjekket siden den dagen hendelsen skjedde. Sammen med tidslinjen for hendelsen gir det deg start, varsel, bekreftelse, gjenoppretting og rekkevidde uten å grave i logger. Hendelser på nettsteder har også med det feilende svaret, med et skjermbilde eller en traceroute, som er en god start på delene om oppdagelse og rotårsak.
Følg opp tiltakene
En postmortem uten fullførte tiltak er en historie, ikke en løsning. Behandle tiltakene som alt annet arbeid:
Opprett en sak for hvert tiltak i det samme verktøyet teamet allerede bruker, og lenk til den fra postmortemen.
Gi hvert tiltak én ansvarlig og en frist.
Merk tiltakene etter type: forebygge, oppdage eller respondere. Hvis hvert tiltak er «vær mer forsiktig», ble ikke gjennomgangen fullført.
Gå gjennom åpne tiltak fra postmortemer i et fast møte, for eksempel annenhver uke.
Merk postmortemen som endelig først når alle tiltak er gjennomført eller uttrykkelig droppet med en begrunnelse.
Over tid blir postmortemene selv til data. Tell hvor mange hendelser som ble oppdaget av overvåkingen og hvor mange av kunder, og følg oppdagelses- og responstidene fra én hendelse til den neste. Artikkelen vår om MTTR, MTTA og MTBF forklarer hvordan du regner dem ut.
Slik gjennomfører du gjennomgangsmøtet
Ved større hendelser hjelper det med et møte på 30 til 45 minutter. Del utkastet på forhånd, la personen som ledet responsen gå gjennom tidslinjen, og bruk mesteparten av tiden på medvirkende faktorer og tiltak. En nøytral møteleder som ikke jobbet med hendelsen, holder samtalen fri for skyldfordeling og innenfor tiden. Avslutt med å bekrefte ansvarlige og frister for hvert tiltak.
Få tidsstemplene til neste postmortem automatisk. Prøv Uptimecheck gratis i 14 dager, uten kredittkort.