Wat doe je om te voorkomen dat hetzelfde soort incident een tweede keer gebeurt?

Question

Accepted Answer

Voer een **blameless postmortem** uit die de systemische oorzaak vindt, zet die dan om in **concrete, beheerde en gevolgde** actiepunten — en verifieer dat ze daadwerkelijk ge-shipt worden. Het doel is niet om iemand te beschuldigen; het is om het systeem te veranderen zodat dezelfde klasse van falen onmogelijk of zelf-detecterend wordt.

## De kernloop

1. **Blameless postmortem.** Bouw een eerlijke tijdlijn: wat er gebeurde, wanneer we het detecteerden, hoe we reageerden, wat de impact was. Schuld doodt de waarheid die je nodig hebt.
2. **Graaf naar de systemische oorzaak**, niet de trigger. "Een engineer pushte een slechte config" is een trigger; "er was geen validatie of staged rollout voor configs" is de oorzaak. Gebruik de **Five Whys** maar stop bij het systeem, nooit bij een persoon.
3. **Genereer preventielagen**, geen enkele fix:
   - **Voorkomen** — maak het falen onmogelijk (validatie, types, guardrails).
   - **Detecteren** — vang het eerder op (alerts, SLO's, synthetic checks).
   - **Mitigeren** — beperk de blast radius (rollback, flags, circuit breakers).
4. **Wijs eigenaren en deadlines toe.** Een actiepunt zonder eigenaar is een wens. Volg ze als echt werk in de backlog.
5. **Verifieer en sluit de loop.** Is de fix ge-shipt? Zou die het origineel hebben opgevangen? Verbeterden MTTR en detectie daadwerkelijk?

## Trade-offs en valkuilen

- **Postmortems die documenten produceren, geen veranderingen** — de meest voorkomende mislukking. Geen opvolging betekent dat je hetzelfde incident weer tegenkomt.
- **Het specifieke symptoom over-fixen** terwijl de bugklasse open blijft. Fix de categorie, niet alleen dit geval.
- **Alert fatigue** door detectie op te stapelen zonder af te stemmen; luidruchtige alerts worden genegeerd en het volgende incident glipt erdoor.
- **Blame culture** drijft rapportage ondergronds; je verliest de near-misses die je goedkoopste lessen zijn.
- Behandel **terugkerende incidents als signaal van procesfalen**, geen pech — volg recidive als metriek.

## Waarom het belangrijk is

Incidents zijn lesgeld dat je al betaald hebt; de enige verspilling is er niet van leren. Een team dat recidive systematisch voorkomt wordt elk kwartaal betrouwbaarder, terwijl een team dat alleen brandjes blust eeuwig dezelfde outages herbeleeft. Deze leerloop bouwen — en de veiligheid om er eerlijk in te zijn — is een van de meest duurzame dingen die een Tech Lead kan achterlaten.