En postmortem är en kort skriftlig genomgång av ett avbrott: vad som hände, hur det påverkade användarna, varför det hände och vad ni ändrar så att det inte händer igen. En skuldfri postmortem fokuserar på system och processer snarare än på vem som gjorde fel. Grundmallen har sex delar: sammanfattning, påverkan, tidslinje, grundorsak, vad som gick bra och dåligt, samt åtgärder med ansvariga och datum.
Nedan får du veta när du ska skriva en, vilka principer som håller den användbar, en komplett mall att kopiera, ett ifyllt exempel och hur du gör om den till en sammanfattning för kunderna.
När du ska skriva en postmortem
Inte varje litet hack behöver ett dokument. Bestäm tydliga kriterier så att beslutet inte fattas under press. Vanliga kriterier:
Kunderna kunde inte använda en kärnfunktion, till exempel kassan, inloggningen eller API:et, i mer än några minuter.
Data gick förlorad, blev korrupt eller exponerades.
Incidenten förbrukade en stor del av månadens felbudget.
Kunder eller en uppdragsgivare rapporterade problemet innan övervakningen gjorde det.
Samma typ av incident har inträffat tidigare.
Skriv den inom några arbetsdagar, medan minnen och loggar är färska. En postmortem som skrivs tre veckor senare är mest gissningar.
Skuldfria principer
En skuldfri postmortem utgår från att alla agerade rimligt utifrån den information de hade just då. Om en person kunde ta ner sajten med ett enda kommando är problemet att ett enda kommando kunde ta ner sajten. Skuldbeläggning får folk att dölja detaljer, och det är detaljerna du behöver.
Beskriv handlingar, inte personer. ”Importjobbet startades under högtrafik” i stället för ”Anna startade importen vid fel tidpunkt”.
Fråga ”hur”, inte ”vem”. Hur kunde systemet tillåta detta? Hur fick vi veta det? Hur hade vi kunnat få veta det tidigare?
Leta efter flera orsaker. Incidenter har sällan en enda grundorsak. Oftast möter en utlösande faktor en svaghet som ett saknat skydd inte fångade upp.
Använd fakta och tidsstämplar. Övervakningsdata, loggar och chatthistorik slår minnet.
Håll åtgärdslistan kort. Två eller tre ändringar som blir gjorda slår tio som inte blir det.
Mallen för postmortem
Kopiera den här till er wiki, ert repository eller ert dokumentverktyg. Varje rubrik har en uppmaning om vad som hör hemma där.
# Postmortem: [kort rubrik]
Datum för incidenten: [ÅÅÅÅ-MM-DD]
Författare: [namn]
Status: [utkast / under granskning / slutlig]
Allvarlighetsgrad: [t.ex. SEV1 / SEV2 / SEV3]
## Sammanfattning
[Två eller tre meningar: vad som gick sönder, hur länge och hur det åtgärdades.]
## Påverkan
– Berörda tjänster och komponenter:
– Varaktighet (från start till återställning):
– Berörda användare eller kunder:
– Affärspåverkan (beställningar, registreringar, SLA):
– Kundkommunikation (statussida, mejl, ärenden):
## Upptäckt
– Hur upptäcktes incidenten? (övervakning, kund, teammedlem)
– Tid från start till larm:
– Tid från larm till kvittering:
## Tidslinje
[Alla tider i en och samma tidszon. En rad per händelse.]
HH:MM händelse
HH:MM händelse
## Grundorsak och bidragande faktorer
– Utlösande faktor:
– Underliggande orsak:
– Varför skydden inte fångade det:
## Åtgärd
[Vad som gjordes för att återställa tjänsten, och av vem (roll, inte skuld).]
## Vad som gick bra
–
## Vad som gick dåligt
–
## Där vi hade tur
–
## Åtgärder
| Åtgärd | Typ (förebygga / upptäcka / hantera) | Ansvarig | Klart senast | Ärende |
|——–|————————————–|———-|————–|——–|
| | | | | |
## Sammanfattning för kunder
[Kort version för statussidan eller mejlet till kunden.]
Avsnittet ”Där vi hade tur” är lätt att hoppa över men ofta det mest värdefulla. Det fångar de situationer där det var nära ögat: incidenten hände på natten, backupen hade körts en timme tidigare, den enda person som kände till systemet råkade vara vaken.
Ett ifyllt exempel
Här är mallen tillämpad på en påhittad incident i en webbutik, northwind.shop. Detaljerna är påhittade för att illustrera, men strukturen är hur en riktig postmortem bör se ut.
Sammanfattning
Från 03:12 till 03:19 CET svarade kassan på northwind.shop med 503 Service Unavailable. En nattlig produktimport använde alla PHP-FPM-workers, så förfrågningar till kassan avvisades. Jourutvecklaren stoppade importen och startade om PHP-FPM. Total nertid: 7 minuter.
Påverkan
Kassan och varukorgen var otillgängliga i 7 minuter. Produktsidorna levererades från cache och var uppe hela tiden.
Serverloggarna visar 23 misslyckade förfrågningar till kassan under perioden (exempelsiffra).
Statussidan visade ”Kassa: större avbrott” från 03:13. Inga supportärenden kom in.
Tidslinje
03:00 Den nattliga produktimporten startar.
03:12 Upptidskontrollen mot northwind.shop/checkout svarar 503.
03:13 En andra kontroll bekräftar felet. En incident öppnas, jourutvecklaren larmas via Telegram och detaljerna publiceras i teamets Slack-kanal. Statussidan markerar Kassa som nere.
03:15 Jouren kvitterar i Slack och öppnar serverns dashboard. Minnes- och CPU-användningen är hög på web-01.
03:17 PHP-FPM-statusen visar att alla workers är upptagna med importförfrågningar. Importjobbet stoppas.
03:18 PHP-FPM startas om.
03:19 Kontrollerna går igenom igen. Ett meddelande om återställning skickas ut med en total nertid på 7 minuter.
Grundorsak och bidragande faktorer
Utlösande faktor: leverantörens produktflöde var tre gånger större än vanligt efter en katalogändring.
Underliggande orsak: importen körs i samma PHP-FPM-pool som butiken. Stora importer kan använda varenda worker.
Saknat skydd: importen har ingen gräns för samtidiga förfrågningar, och det fanns inget larm när alla workers var upptagna.
Varför slut på workers visar sig som just det här felet förklarar vi i vår guide till felet 503 Service Unavailable.
Vad som gick bra, dåligt och där vi hade tur
Bra: upptäckten tog en minut och kvitteringen två. Statussidan uppdaterades utan manuellt arbete.
Dåligt: det tog fyra minuter att hitta orsaken eftersom ingenting kopplade importjobbet till webbservrarna.
Tur: det hände 03:12, inte under kvällens högtrafik.
Åtgärder
ÅtgärdTypAnsvarigKlartKör importen i en separat worker-pool med en gräns för samtidighetFörebyggaBackend-ansvarigInom 2 veckorLarma när minnet på web-01 ligger kvar över 85 %UpptäckaDriftDen här veckanLägg till ett heartbeat som rapporterar när importen är klarUpptäckaBackend-ansvarigDen här veckanLägg till runbooken för ”503 i kassan” i övervakningenHanteraJourschematDen här veckan
Publicera en sammanfattning för kunderna
Den interna postmortem-rapporten är till för teamet. Kunderna behöver en kortare version utan servernamn: vad som hände, hur länge, om deras data är säker och vad ni ändrar. Publicera den på din statussida och länka till den från incidentmejl och uppdateringar till kunder. I Uptimecheck skriver du incidentgenomgången direkt på incidenten, bredvid dess tidslinje, och kan välja att visa den under incidenten på din statussida.
Kassan otillgänglig, 03:12 till 03:19 CET
Mellan 03:12 och 03:19 CET kunde kunder inte slutföra köp på
northwind.shop. Det gick att bläddra bland produkterna som vanligt, och
inga beställningar eller betalningsuppgifter gick förlorade.
Orsaken var en schemalagd produktuppdatering som använde mer
serverkapacitet än väntat. Vi stoppade den, och kassan fungerade igen 03:19.
Vi flyttar de här uppdateringarna till separat kapacitet så att de inte
kan påverka kassan igen, och har lagt till tidigare varningar för den här
typen av belastning.
Håll tonen saklig och löftena konkreta. ”Vi tar driftsäkerhet på största allvar” säger ingenting; ”importer körs nu på separat kapacitet” säger något. Vår guide om hur du skapar en statussida går mer i detalj igenom formuleringar för incidentuppdateringar.
Det hjälper också att veta hur många som märkte av det. Uptimecheck har statistik för statussidor på varje statussida, med besök per dag och per land, hänvisande sida och enhet under de senaste 30 dagarna, så att du kan lägga till i postmortem-rapporten hur många som tittade på sidan den dag incidenten inträffade. Tillsammans med incidentens tidslinje får du start, larm, kvittering, återställning och räckvidd utan att gräva i loggar. Incidenter för webbplatser innehåller också det felande svaret, med en skärmbild eller en traceroute, vilket är en bra start för avsnitten om upptäckt och grundorsak.
Följ upp åtgärderna
En postmortem utan genomförda åtgärder är en berättelse, inte en lösning. Behandla åtgärderna som vilket annat arbete som helst:
Skapa ett ärende för varje åtgärd i samma ärendesystem som teamet redan använder, och länka till det från postmortem-rapporten.
Ge varje åtgärd en enda ansvarig och ett datum.
Märk åtgärderna efter typ: förebygga, upptäcka eller hantera. Om varje åtgärd är ”var mer försiktig” är genomgången inte klar.
Gå igenom öppna åtgärder från postmortems på ett återkommande möte, till exempel varannan vecka.
Markera postmortem-rapporten som slutlig först när alla åtgärder är klara eller uttryckligen strukna med en motivering.
Med tiden blir själva postmortem-rapporterna data. Räkna hur många incidenter som upptäcktes av övervakningen jämfört med av kunder, och följ tiderna för upptäckt och hantering från en incident till nästa. Vår artikel om MTTR, MTTA och MTBF förklarar hur du räknar ut dem.
Så leder du genomgångsmötet
Vid större incidenter hjälper ett möte på 30 till 45 minuter. Dela utkastet i förväg, låt den som ledde hanteringen gå igenom tidslinjen och lägg det mesta av tiden på bidragande faktorer och åtgärder. En neutral mötesledare som inte arbetade med incidenten håller samtalet skuldfritt och inom tidsramen. Avsluta med att bekräfta ansvariga och datum för varje åtgärd.
Få tidsstämplarna till din nästa postmortem automatiskt. Testa Uptimecheck gratis i 14 dagar, inget kreditkort krävs.