Efter nedbruddet: post mortem, der forhindrer gentagelsen

Kort svar: Et post mortem er en skriftlig opsamling på én side efter et nedbrud, skrevet inden for en uge efter én regel: vi leder efter årsager, ikke skyldige. Den indeholder tidslinjen med klokkeslæt, rodårsagen (spørg “hvorfor?” op til fem gange), konsekvensen i tal, hvad der gik godt og skidt – og præcis to handlinger: én, der forebygger gentagelsen, og én, der forbedrer processen. Giv handlingerne en ansvarlig og en dato, og tjek ved kvartalstjekket, at de blev gennemført.

Fagligt gennemgået: 2. oktober 2026

Et nedbrud koster to gange: først da det skete, og igen når det gentager sig, fordi ingen samlede læringen op. Post mortem-rutinen er forsikringen mod den anden regning.

Den kræver hverken lange møder eller tunge skabeloner: én side, cirka én time og to handlinger. Her er, hvordan du gør.

Princippet: årsager, ikke skyldige

Princippet om at gå efter årsager frem for skyld (ofte kaldet “blameless” eller “blame-free”) er ikke pynt – det er det, der får metoden til at virke. Leder opsamlingen efter en skyldig, får du forsvar og tavshed. Den vigtigste information, fx “jeg sprang testen over, fordi vi havde travlt”, kommer aldrig frem, og fejlen gentager sig med et andet navn på.

Leder opsamlingen efter årsager, får du svar på systemniveau: testen var for besværlig, opdateringsvinduet lå forkert, varslet gik til en postkasse, ingen læste.

Derfor skrives dokumentet i systemsprog: “opdateringen blev udrullet uden funktionstest”, ikke “X glemte at teste”. Selv en enkeltmandsvirksomhed kan holde reglen over for sig selv. Formålet er ikke at få ret eller fordele skyld, men at gøre næste nedbrud mindre sandsynligt eller mindre dyrt.

Hvornår du skal skrive et post mortem

Ikke alle hændelser fortjener en hel side. En enkel tommelfingerregel:

• Altid, når kunder mærkede hændelsen, fx nedetid, fejlende checkout eller mails, der ikke kom frem.
• Altid, når den samme type fejl sker igen.
• Som regel, når håndteringen kostede mere end en halv times arbejde.
• Ikke nødvendigt ved små fejl, der blev fanget og rettet hurtigt. Her er to linjer i ændringsloggen nok.

Den, der håndterede hændelsen, skriver typisk første udkast. Er I flere, så læs det igennem sammen i en kort snak – det er her, de manglende detaljer kommer frem.

Formatet: én side

Dokumentet har seks korte afsnit:

1. Tidslinjen med klokkeslæt: hvornår og hvordan det blev opdaget – forhåbentlig af overvågningen, ikke af en kunde – første handling, årsag fundet, løst. Ændringsloggen og statussidens opdateringer leverer den næsten færdig.
2. Årsagen: både den tekniske årsag og rodårsagen (se næste afsnit).
3. Konsekvensen i tal: varighed, berørte funktioner og et nøgternt skøn over tab. Det styrer, hvor meget handlingerne må koste.
4. Hvad gik godt: alarmen kom hurtigt, tilbagerulningen virkede. Det skal bevares og er lige så vigtigt som fejlene.
5. Hvad gik skidt: vi ledte 20 minutter efter kundenummeret hos hostingen, statussiden blev opdateret for sent.
6. Handlingerne: præcis to, med ansvarlig og dato.

Skriv det inden for en uge – efter to uger er detaljerne væk. Arkivér alle post mortems samlet ét sted, så mønstre på tværs kan ses. Her er en skabelon, du kan kopiere:

Post mortem: [kort titel] – [dato]
Skrevet af: [navn]   Gennemgået: [dato]

1. Tidslinje
   [kl.] Opdaget af ...
   [kl.] Første handling ...
   [kl.] Årsag fundet ...
   [kl.] Løst ...

2. Årsag
   Teknisk årsag: ...
   Rodårsag (hvorfor kunne det ske?): ...
   Rodårsag (hvorfor varede det så længe?): ...

3. Konsekvens
   Varighed, berørte funktioner, skønnet tab

4. Hvad gik godt

5. Hvad gik skidt

6. Handlinger
   Forebyggende: ... – ansvarlig: ... – dato: ...
   Proces: ... – ansvarlig: ... – dato: ...

Rodårsagen: fem gange hvorfor

Den tekniske årsag er sjældent den rigtige at handle på. “Fem gange hvorfor” er den enkleste vej ned til rodårsagen. Et eksempel:

1. Sitet var nede. Hvorfor?
2. Et plugin fejlede efter en opdatering. Hvorfor gik det galt?
3. Det var flere versioner bagud, så springet var stort. Hvorfor var det bagud?
4. Licensen var udløbet, så opdateringerne stoppede. Hvorfor opdagede ingen det?
5. Varslet gik til en tidligere medarbejders mail.

Rodårsagen er altså varslingsadresser, og den rigtige handling er en fælles postkasse til varsler, som beskrevet i guiden om udløbsdatoer – ikke kun at opdatere det ene plugin.

Stop, når svaret bliver et forhold, I kan ændre: en rutine, et varsel eller en aftale. Det er ikke altid præcis fem trin. Acceptér gerne to rodårsager: én for, at fejlen opstod, og én for, at den gjorde ondt så længe, fx manglende alarm eller famlende eskalering. Den sidste er typisk stof til proceshandlingen.

De to handlinger

Disciplinen er præcis to handlinger:

• Én forebyggende, der adresserer rodårsagen: varsler til fællespostkassen, funktionstest efter opdatering af betalingsplugins eller en alarm, når der ikke kommer ordrer, jf. overvågning af checkout og formularer.
• Én procesforbedring, der gør næste hændelse billigere: kundenummeret ind i nødlisten, skabeloner til statussiden skrevet på forhånd, eller nedbrudsplanen justeret med det lærte.

Hvorfor kun to? Fordi ti handlinger er en ønskeliste, og to er en aftale. Hver handling får en ansvarlig og en dato, kommer i kalenderen og i ændringsloggen – og bliver faktisk gjort.

Er hændelsen stor nok til flere, så vælg de to vigtigste nu, og læg resten i den almindelige opgavekø. Post mortem’ets troværdighed hænger på, at handlingerne altid gennemføres.

Kommunikation til kunderne

Var hændelsen synlig for kunderne, kan en kort og ærlig opsummering bygge mere tillid end tavshed. Hold den til tre ting:

• Hvad skete der, og hvor længe – i almindeligt sprog.
• Hvem blev ramt, og om kunderne selv skal gøre noget, fx gennemføre en ordre igen.
• Hvad I gør for at undgå, at det sker igen.

Statussidens historik eller en kort mail er det naturlige sted. Den interne version med navne og detaljer bliver internt. Har hændelsen berørt persondata, er det en anden sag med egne regler – læs om det i guiden om sikkerhedshændelser på kundesites, og tjek Datatilsynets vejledning om brud på persondatasikkerheden.

Opfølgningen, der gør forskellen

Dokumenter forhindrer ingenting – gennemførte handlinger gør. Derfor har rutinen to opfølgninger:

• Ved næste kvartalstjek gennemgås åbne post mortem-handlinger. Er de ikke gjort, kommer de øverst på listen.
• Én gang om året læses årets post mortems i sammenhæng. Tre hændelser med samme type rodårsag – udløb, ændringer uden test, afhængighed af én person – er ikke tre uheld, men ét strukturelt problem og årets vigtigste prioritering.

Lad også hostingen tage sin del. Med WordPress hosting hos Hostious får du daglig og manuel backup med selvbetjent gendannelse og dansk support døgnet rundt, når en hændelse peger mod serverlaget. Så kan dine egne post mortems handle om det, kun du kan ændre.

Læs også

• Hub: Driftshåndbogen
• Nedbrudsplanen: hvem gør hvad, når sitet er nede?
• Din egen statusside: informér kunder ved nedbrud
• Kvartalstjekket: performance, sikkerhed og indhold på én formiddag
• Ændringsloggen: dokumentér ændringer, så fejlfinding tager minutter
• WordPress hosting hos Hostious – daglig backup med selvbetjent gendannelse og dansk support døgnet rundt

Ofte stillede spørgsmål om post mortems

Hvornår er en hændelse stor nok til et post mortem?

Når kunder mærkede den, eller den kostede mere end en halv times arbejde – og altid ved gentagelser. Små hændelser kan nøjes med to linjer i ændringsloggen.

Hvor lang tid skal det tage?

Cirka én time inden for en uge. Tidslinjen ligger næsten færdig i ændringslog og statusside, og formatet er én side med seks afsnit og to handlinger.

Hvad hvis rodårsagen var en menneskelig fejl?

Så spørg én gang til: hvorfor var fejlen mulig og let at begå? Svaret er næsten altid et forhold i systemet – en manglende test, et dårligt tidspunkt, en uklar rutine – og dét kan ændres.

Skal kunderne se vores post mortem?

Ikke det interne dokument. Var hændelsen synlig, så send en kort opsummering: hvad skete der, hvem blev ramt, og hvad I gør for at undgå gentagelse. Navne og interne detaljer bliver internt.