Incident response playbook voor kleine en middelgrote teams

Kort: Wanneer vrijdag om 23:30 de productieserver valt, is het niet de tijd om procedure vanaf nul te bedenken. Een incident response playbook is een document dat rollen, communicatie en procedures definieert voordat je ze nodig hebt. Hier is een minimaal playbook geschikt voor een 5-20 persoons team.

Rollen tijdens een incident

Duidelijke rollen elimineren chaos. Zelfs een klein team heeft minstens nodig:

• Incident Commander (IC) - beheert het incident, neemt beslissingen, escaleert. Schrijft geen code.
• Technical lead - de persoon die het probleemgebied kent. Schrijft de fix.
• Communications lead - updatet status page, klanten, management. Voor klein team kan hetzelfde zijn als IC.
• Scribe - schrijft timeline, wie wat doet, wanneer. Cruciaal voor post-mortem.

In team tot 5 mensen typisch IC + Technical lead = 2 rollen verdeeld, anderen neemt IC.

Severity niveaus

Definieer 3-4 ernstniveaus van tevoren:

• SEV1 (Critical) - hoofdservice volledig niet beschikbaar. Onmiddellijk reageren, paging zelfs 's nachts.
• SEV2 (Major) - significante degradatie (deel van features, sommige gebruikers). Reactie binnen 30 min tijdens werkuren, binnen 1 u daarbuiten.
• SEV3 (Minor) - kleine impact, workaround bestaat. Reactie tegen volgende werkdag.
• SEV4 (Cosmetic) - zonder user-facing impact, gaat naar normale queue.

SEV1 procedure: de eerste 15 minuten

1. 00:00 - Detectie. Alert komt van monitoring of van klant. Iemand in on-call rotatie bevestigt dat probleem echt is.
2. 00:02 - IC activering. Dedicated communicatiekanaal opent (Slack #incident-N of Discord). Technical lead wordt geroepen.
3. 00:05 - Eerste status update. Op publieke status page: "Investigating reports of [probleem]." Email naar interne mensen die moeten weten.
4. 00:10 - Initial diagnostics. Controleer recente deploys, monitoring grafieken, error logs. Wat veranderde in de laatste 30-60 min?
5. 00:15 - Beslissing: rollback, hotfix of workaround? Als niet onmiddellijk duidelijk, IC escaleert of roept meer engineers.

Communicatie: de "5 + 30" regel

Status page update minstens elke 30 minuten tijdens SEV1, ook al heb je geen nieuwe info. "Nog steeds aan het onderzoeken, ETA nog onbekend" is een betere update dan stilte - klanten weten tenminste dat iemand aan het probleem werkt.

De eerste update moet binnen 5 minuten van detectie zijn. Ongeacht of je de oorzaak kent.

Rollback als default

Bij SEV1 die kort na een deploy begon, is rollback de eerste keuze, niet hotfix. Hotfix onder druk 's nachts is bron van meer bugs. Rollback herstelt een bekende goede staat en geeft tijd voor rustige diagnostiek 's morgens.

Voor rollback moet je hebben:

• Deployment versioning (Docker tags, Git tags, deployment artefact)
• Database migrations backwards compatible (als nieuwe versie kolom dropt, herstelt oude niet)
• Gedocumenteerde rollback procedure (commando's, hoe lang duurt, wie kan uitvoeren)

Post-mortem binnen 48 uur

Na elk SEV1/SEV2 incident schrijf document met structuur:

1. Summary - 2-3 zinnen wat gebeurde, hoe lang duurde, wie het beïnvloedde
2. Timeline - exacte tijden van detectie, sleutelacties, oplossing
3. Root cause - waarom het gebeurde (technische reden + procedurele reden)
4. Impact - aantal getroffen klanten, business impact
5. What went well - wat we goed deden (team waarderen)
6. What went wrong - waar we tijd verloren
7. Action items - concrete taken met owner en deadline (niet "beter testen" - liever "integratietest voor payment flow toevoegen binnen 14 dagen, owner: X")

Blameless post-mortem regel: Je zoekt geen schuldige, je zoekt een systeem zwakte. "John deployde slechte versie" is verkeerde conclusie - de juiste is "het deploy proces bevatte geen canary fase die de bug zou vangen voor volle rollout".

On-call rotatie

Voor team met 24/7 product:

• Wekelijkse rotaties - korter brandt op, langer betekent continuïteit van context
• Altijd primair + secundair on-call. Secundair neemt over wanneer primair niet binnen 5 min reageert.
• Compensatie (extra betaling, time-off) voor nachtelijke en weekend paging
• Maandelijkse "on-call review" - wie werd vaak gewekt, wat kan geautomatiseerd worden

Tools

• Monitoring (ePulz.io, Datadog, New Relic) - detectie + alerting
• Paging (PagerDuty, Opsgenie, Better Stack) - escalatie, rotatie, SMS/stem
• Status page (eigen, ePulz.io, StatusPage.io) - externe communicatie
• Runbook hosting (Notion, GitHub Wiki, internal docs) - playbooks en runbooks
• Postmortem template (Confluence, Notion template) - standaardisatie

Conclusie

Incident response kan niet onder druk worden geïmproviseerd. 30 minuten geïnvesteerd in het schrijven van een playbook verdient zich terug bij de eerste grote uitval - minder chaos, kortere MTTR, betere communicatie met klanten en een team dat weet wat te doen.

Begin met automatische detectie

ePulz.io lost de eerste minuten van incident response op: detectie + alerting via e-mail, Telegram en webhook naar Slack / Discord / PagerDuty.

Monitoring starten →