Sjabloon voor een engineering-postmortem (schuldloos, actiegericht)

Waarom postmortems ontaarden in schuldvragen

Postmortems mislukken op een specifieke manier: de ruimte begint oorzaken toe te wijzen voordat de ruimte een gedeelde tijdlijn heeft. Iemand zegt "de deploy heeft dit veroorzaakt" voordat het tijdstip van de deployment bevestigd is. Iemand anders zegt "de alert is niet afgegaan" zonder te weten of de alert voor dat scenario was geconfigureerd. Het gesprek wordt een debat over causaliteit voordat iemand heeft vastgesteld wat er daadwerkelijk is gebeurd, in welke volgorde.

De oplossing is structureel: bouw de incidenttijdlijn samen aan het begin van de postmortem, voordat iemand een grondoorzaak benoemt. Zodra de hele ruimte naar de volgorde van gebeurtenissen heeft gekeken — wat veranderde er wanneer, wie zag wat op welk moment — is de oorzaak veel makkelijker te bespreken en veel minder waarschijnlijk om in schuldtoewijzing te vervallen. Dit is de volgordefout die de meeste sjablonen maken: ze zetten de grondoorzaak vóór de tijdlijn omdat de grondoorzaak is waar het sjabloon voor bedoeld is. Maar de tijdlijn is wat de grondoorzaak eerlijk maakt.

De agenda (kopieer en plak dit)

Duur: 60 minuten voor een eenvoudig incident; 90 minuten voor complexe storingen over meerdere systemen
Vorm: begeleid; alle responders en de on-call-engineer aanwezig; bereid asynchroon voor met een leesdocument vooraf

Onderdeel 1 — Incidentsamenvatting (5 min)

Data en duur van het incident
Ernstclassificatie en getroffen systemen
Wie het detecteerde en hoe (klantmelding, alert, engineer, monitoring)
Dit onderdeel is uitsluitend feitelijk; nog geen analyse

Onderdeel 2 — Tijdlijn (20 min)

Bouw de tijdlijn gezamenlijk op het scherm — geen vooraf geschreven document
Volgorde: wat veranderde, wat werd waargenomen, wie handelde, wat werd besloten
Elk tijdstip zou een bron moeten hebben (logregel, PagerDuty, Slack-bericht)
Vraag als de tijdlijn compleet is: is iedereen het erover eens dat dit is gebeurd? Los meningsverschillen op voordat je verdergaat

Onderdeel 3 — Impactsamenvatting (5 min)

Klantimpact: wie werd getroffen, hoe lang, op welke manier
Bedrijfsimpact: omzet, SLA, reputatie
Interne impact: on-call-uren, teamontwrichting
Houd dit feitelijk; het verankert de vraag "hoe erg was het" zonder er commentaar aan toe te voegen

Onderdeel 4 — Grondoorzaak en bijdragende factoren (20 min)

Grondoorzaak: de meest directe wijziging of voorwaarde die het incident mogelijk maakte
Bijdragende factoren: de omstandigheden die het erger, moeilijker te detecteren of trager op te lossen maakten
De nuttigste postmortems identificeren 3-5 bijdragende factoren naast de grondoorzaak; alleen de grondoorzaak oplossen mist vaak de systemische omstandigheden
Vraag bij elke factor: nam een persoon of team een beslissing die redelijk leek gezien de beschikbare informatie? Zo ja, dan is de factor systemisch, niet persoonlijk

Onderdeel 5 — Wat ging goed (5 min)

Welke detectie of reactie werkte beter dan verwacht?
Welk bestaand proces of hulpmiddel beperkte de blast radius?
Dit zijn praktijken die het formaliseren waard zijn — als de runbook 20 minuten bespaarde, noteer dat dan zodat de runbook onderhouden blijft

Onderdeel 6 — Actiepunten (15 min)

Elk actiepunt pakt een grondoorzaak of een bijdragende factor aan — geen algemene verbetering
Eén verantwoordelijke per punt; een opleverdatum die de urgentie weerspiegelt
Categoriseer: eerder detecteren / sneller herstellen / herhaling voorkomen
Beperk je tot acties die het team realistisch kan afronden vóór het volgende incident, niet een uitputtende betrouwbaarheidsroadmap

Wat postmortem-sjablonen doet mislukken

De volgorde grondoorzaak-eerst is het belangrijkste structurele probleem — hierboven al behandeld. Het tweede is "actiepunten" behandelen als één enkele categorie. Detectieverbeteringen, herstelverbeteringen en preventieverbeteringen vereisen verschillende verantwoordelijken en verschillende tijdlijnen. Ze door elkaar husselen levert een lijst op die zes maanden en drie teams beslaat, wat betekent dat de verantwoordelijkheid vervaagt en geen ervan wordt opgeleverd.

De derde faalmodus is het overslaan van "wat ging goed" omdat het voelt als ongepast optimisme na een incident. Dat is het niet — het is de enige systematische manier om praktijken te identificeren en te formaliseren die onder druk werkten. Als de monitoring die het probleem opving op niemands roadmap stond om te bouwen, is het het documenteren waard om te leren dat het ertoe deed. Anders wordt het gedeprioriteerd nadat het incident is vervaagd, en ben je de volgende keer blind.

De opeenstapelende kosten van incidenten waarbij bijdragende factoren onopgelost blijven, en runbooks die werkten maar niet onderhouden worden, lopen snel op. De vergadertaks behandelt hoe terugkerende vergaderoverhead en incident-reviewschuld op elkaar inwerken.

Waarom een postmortem uniek moeilijk vast te leggen is

Postmortem-discussies genereren snel dichte, ongestructureerde inhoud: reconstructie van de tijdlijn, concurrerende interpretaties, actiepunttoewijzingen met meerdere personen, technische details die zonder context in een transcript nergens op slaan. Een postmortem-samenvatting die uit het geheugen of uit bewerkte audio is geschreven, is vrijwel altijd onvolledig, en onvolledige postmortem-verslagen zijn nutteloos voor patroonherkenning over incidenten heen.

Pavleur legt de volledige postmortem-discussie vast en genereert het rapport automatisch — de tijdlijn zoals gereconstrueerd, de bijdragende factoren zoals benoemd, de actiepunten met verantwoordelijken en categorieën zoals verwoord in de vergadering. Als iemand zijn scherm deelde om een log-extract, een monitoringgrafiek of de alertconfiguratie die niet afging te tonen, maakt die visual deel uit van het rapport. Tools met alleen audio missen dit volledig; een postmortem-verslag zonder de grafieken is een verslag zonder het bewijs. Iedereen in het team — ook engineers die na het incident aansluiten — kan het volledige verslag met visuele context lezen zonder iemand te vragen het te reconstrueren. Voor een directe vergelijking met andere tools hierover: Pavleur vs. alternatieven.

Over de frequentie van postmortems

Houd de postmortem binnen 48 uur na de oplossing van het incident, terwijl de details vers zijn. Hoe langer je wacht, hoe meer de reconstructie van de tijdlijn afhangt van geheugen in plaats van logs, en geheugen is onbetrouwbaar onder stress. Voor incidenten met hoge ernst is 24 uur beter. Voor kleine incidenten kunnen asynchrone postmortems — een gedeeld document met gestructureerde vragen, synchroon beoordeeld — efficiënter zijn dan een volledige vergadering. Het vergaderformat is het waardevolst wanneer het incident ambigu of belangrijk genoeg was dat gedeelde interpretatie ertoe doet.