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.
De meeste kleine teams pakken hun eerste serieuze storing slecht aan — niet uit onkunde, maar omdat iedereen tegelijk debugt, niemand met klanten praat en twee mensen tegenstrijdige fixes deployen. Het onderstaande playbook bestaat om dat te voorkomen.
De eerste tien minuten
- Roep het uit. Zeg het woord «incident» hardop in het teamkanaal. Onduidelijkheid of dit serieus is kost meer tijd dan welke technische stap ook.
- Wijs een incident lead aan. Eén persoon, expliciet. Die debugt niet — die coördineert, beslist en houdt de tijdlijn bij.
- Bepaal de impactstraal: wie is getroffen, beweegt er geld verkeerd, staan data op het spel. Dat bepaalt al het volgende.
- Stelp de bloeding vóór je de oorzaak zoekt. Rollback, feature uitzetten, onderhoudspagina. Begrijpen kan wachten; klantimpact niet.
- Plaats een statusbericht. Zelfs «we onderzoeken het» verslaat stilte — stilte maakt van een storing een vertrouwensprobleem.
Rollen, zelfs in een team van vier
| Rol | Doet | Doet NIET |
|---|---|---|
| Incident lead | Beslist, coördineert, bewaakt de tijdlijn | Debuggen — zodra hij dat doet, stopt de coördinatie |
| Onderzoeker | Vindt en verhelpt de oorzaak | Met klanten praten |
| Communicatie | Werkt statuspagina, klanten en intern team bij | Publiekelijk speculeren over de oorzaak |
In een klein team kan één persoon twee rollen dragen — maar incident lead en onderzoeker mogen tijdens een serieus incident nooit dezelfde persoon zijn.
Wat je klanten vertelt
- Snel bevestigen, ook zonder antwoorden — «we zijn ervan op de hoogte en onderzoeken het» binnen minuten
- Impact in hun termen benoemen: wat ze nu niet kunnen, niet welke dienst gedegradeerd is
- Een tijdstip voor de volgende update geven, en dat nakomen ook als er niets is veranderd
- Nooit speculeren over een onbevestigde oorzaak — rectificaties kosten meer vertrouwen dan stilte zou hebben gedaan
- Duidelijk zeggen wanneer het opgelost is, en bij materiële impact een schriftelijke uitleg laten volgen
Daarna: het deel dat iedereen overslaat
Een postmortem binnen 48 uur, terwijl het geheugen nog klopt. Blameless — niet uit vriendelijkheid, maar omdat schuld mensen informatie doet achterhouden en het volgende incident daardoor moeilijker te voorkomen is.
- Tijdlijn: wat gebeurde er, wanneer, wie deed wat — alleen feiten
- Impact: duur, getroffen gebruikers, gevolgen voor geld of data
- Bijdragende factoren, meervoud — één hoofdoorzaak is vrijwel altijd een versimpeling
- Actiepunten met eigenaren en data; punten zonder allebei zijn versiering
- Wat goed ging — de detectie of reactie die werkte is het versterken waard
Je stijgt niet naar het niveau van je incidentresponsplan. Je zakt naar het niveau van het plan dat je werkelijk hebt geoefend.
Voorbereiden voordat het gebeurt
- Alerteren op symptomen die klanten voelen (afrekenen mislukt), niet alleen op infrastructuurmetrieken (CPU hoog)
- Een rollback die één commando is en in rustige omstandigheden is geoefend
- Een statuspagina die bestaat voordat je hem nodig hebt
- Schriftelijke escalatie: wie wordt om 3 uur 's nachts gebeld, en wie als die niet opneemt
- Eén oefening — maak bewust iets stuk in staging en volg het playbook
Bevestig herstel met echte gebruikersroutes
Minder foutmeldingen kunnen inconsistente gegevens verbergen. Bepaal welk bewijs nodig is voordat het incident sluit.
- Leg impact, laatste werkende toestand en recente wijzigingen vast.
- Kies een omkeerbare actie met eigenaar en stopcriterium.
- Controleer kernroutes, vertraagde taken en gegevensafstemming.
Veelgestelde vragen
Wat doe je als eerste als productie plat gaat?
Een incident uitroepen en één persoon als incident lead aanwijzen, en dan mitigeren in plaats van diagnosticeren — rollback, de kapotte feature uitzetten of onderhoudsmodus aan. Dienstherstel gaat voor; de oorzaak begrijpen is een taak voor daarna, als klanten weer kunnen werken.
Moeten we klanten meteen informeren?
Ja. Bevestig binnen minuten, beschrijf de impact in termen van wat ze niet kunnen, en zeg wanneer de volgende update komt. Stilte tijdens een storing schaadt vertrouwen meer dan de storing zelf, en speculatie die je later intrekt is erger dan allebei.
Is een postmortem nodig bij elk incident?
Bij alles met klantimpact wel — en het moet binnen 48 uur geschreven worden, zolang de herinnering klopt. Houd het blameless: teams die schuld toewijzen krijgen minder eerlijke informatie, wat het volgende incident waarschijnlijker maakt, niet minder.
Moeten we elke verdachte uitrol terugdraaien?
Nee. Onderzoek eerst gegevenswijzigingen en externe gevolgen. Code terugzetten maakt die niet altijd ongedaan en kan de storing vergroten.
Nu midden in een incident?
Wij doen technische noodrespons — triage, mitigatie, hoofdoorzaak en de postmortem daarna.
Verder lezen
Postmortem best practices: er een schrijven die mensen echt lezen
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.
Technische MVP-audit: wat we in de eerste 48 uur controleren
De meeste MVP-audits leveren een document op. Een nuttige levert beslissingen op: wat brandt, wat kan wachten en wat het kost om het te herstellen.