De meeste postmortems zijn archeologie: een accuraat verslag van iets dat niemand gaat veranderen. Een nuttige levert een klein aantal dingen op die daadwerkelijk gebeuren.
Het doel van een postmortem is niet documenteren wat er gebeurd is. Het is het volgende incident minder waarschijnlijk of minder schadelijk maken. Alles in het document hoort daaraan bij te dragen; wat dat niet doet, is ceremonie.
Blameless is een mechanisme, geen omgangsvorm
Blameless postmortems worden vaak uitgelegd als vriendelijkheid. Dat doet ze tekort. Ze bestaan omdat mensen die schuld verwachten informatie achterhouden — en juist die achtergehouden informatie had herhaling voorkomen.
Een structuur die werkt
- Samenvatting — drie zinnen: wat er stukging, hoe lang, wie geraakt werd. De meeste lezers stoppen hier, dus die moet op zichzelf staan.
- Impact — duur, getroffen gebruikers, gevolgen voor omzet of data, in cijfers waar mogelijk
- Tijdlijn — feiten met tijdstempels, van eerste symptoom tot herstel, inclusief wanneer mensen ervan wisten
- Bijdragende factoren — meervoud, en eerlijk over de procesfactoren, niet alleen de technische trigger
- Wat goed ging — echt nuttig om de detectie of reactie die werkte te versterken
- Actiepunten — elk met een eigenaar en een datum
De hoofdoorzaak is meestal een verhaal, geen regel
«De deploy veroorzaakte de storing» is waar de analyse stopt als de meeting gehaast is. Echte bijdragende factoren zien er meestal zo uit:
| Laag | Voorbeeldbevinding |
|---|---|
| Trigger | Er werd een configuratiewijziging gedeployd |
| Waarom het stukging | De wijziging was syntactisch geldig maar semantisch fout |
| Waarom niets het ving | Geen staging-omgeving kwam overeen met de productieconfiguratie |
| Waarom het 40 minuten duurde | Alerting keek naar CPU, niet naar het slagingspercentage van afrekenen |
| Waarom herstel traag was | Rollback was nooit getest voor wijzigingen die alleen config raken |
Vier van die vijf zijn procesproblemen. Repareer alleen de trigger en dezelfde klasse incidenten komt terug in andere kleren.
Actiepunten: het deel dat bepaalt of dit ergens toe deed
- Maximaal drie tot vijf punten — een lijst van twintig is een lijst van nul
- Elk met een bij naam genoemde eigenaar, niet een team
- Elk met een datum, bijgehouden in hetzelfde systeem als normaal werk
- Geef de voorkeur aan punten die een klasse van falen wegnemen (een vangrail) boven punten die één geval oplossen
- Neem ze door bij het volgende postmortem — onafgeronde punten van vorige keer zijn het belangrijkste agendapunt
Een postmortem zonder afgeronde actiepunten tegen het volgende incident is geen proces. Het is een archiveergewoonte.
Timing en publiek
- Concept binnen 48 uur — accuratesse vervalt snel
- Kom 30-45 minuten bijeen, niet langer; het document doet het meeste werk
- Betrek iedereen die erbij was, plus iemand die er niet bij was (die stelt de voor de hand liggende vragen die ingewijden overslaan)
- Deel het breed — interne transparantie over falen is hoe organisaties hier beter in worden
Maak preventieve acties controleerbaar
Een postmortem moet een controle of beslissing veranderen. Elke actie vraagt bewijs van afronding naast een datum.
- Scheid feiten, hypotheses en bijdragende omstandigheden.
- Koppel acties aan het aangepakte faalmechanisme.
- Verifieer met een test, alarmoefening of herstelproef.
Veelgestelde vragen
Hoe snel na een incident hoort een postmortem plaats te vinden?
Concept binnen 48 uur en bijeenkomen binnen een week. Het geheugen voor de exacte volgorde en redenering vervalt snel, en de details die het meest tellen — wat iemand op dat moment geloofde en waarom — verdwijnen als eerste.
Wat maakt een postmortem in de praktijk blameless?
Vragen hoe het systeem de fout toeliet in plaats van wie hem veroorzaakte. In de praktijk: geen namen bij fouten in het document, vragen geformuleerd over mechanismen in plaats van beslissingen, en actiepunten die vangrails toevoegen in plaats van mensen te vragen voorzichtiger te zijn.
Hoeveel actiepunten hoort een postmortem op te leveren?
Drie tot vijf, elk met een bij naam genoemde eigenaar en een datum. Langere lijsten zijn een betrouwbaar teken dat er niets gebeurt — en onafgeronde punten horen het eerste agendapunt van de volgende review te zijn.
Wanneer is een postmortemactie afgerond?
Als het afgesproken resultaat is geleverd en beoordeeld. Een gesloten ticket of bijgewerkt document bewijst niet vanzelf ander systeemgedrag.
Herhalen jullie incidenten zich?
Dat is een procesprobleem, geen pechprobleem. Wij auditen de levering- en incidentpraktijk en repareren het mechanisme.
Verder lezen
Een productiestoring aanpakken: een playbook voor kleine teams
Bij een storing is het technische probleem zelden het moeilijke deel. Coördinatie wel. Dit is de volgorde die voorkomt dat een klein team het erger maakt.
Audit van engineeringprocessen: waar we naar kijken en waarom
Als een team traag levert, ligt de oorzaak vrijwel nooit bij de engineers. Meestal zijn het vier of vijf concrete wrijvingen die niemand heeft gemeten.