Incident response playbook voor kleine en middelgrote teams

Rollen tijdens een incident

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

• Incident Commander (IC) - beheert het incident, neemt beslissingen en escaleert. Schrijft zelf geen code.
• Technical lead - de persoon die het probleemgebied kent. Schrijft de fix.
• Communications lead - updatet de status page, informeert klanten en management. In een klein team kan dit dezelfde persoon zijn als de IC.
• Scribe - houdt de timeline bij: wie wat doet en wanneer. Een cruciale basis voor het post-mortem.

In een team tot 5 mensen worden meestal de IC en de Technical lead afgesplitst, en de IC neemt de overige rollen op zich.

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 de features, sommige gebruikers). Reactie binnen 30 min tijdens werkuren, binnen 1 u daarbuiten.
• SEV3 (Minor) - kleine impact, er bestaat een workaround. Reactie tegen de volgende werkdag.
• SEV4 (Cosmetic) - zonder user-facing impact, gaat naar de normale queue.

SEV1 procedure: de eerste 15 minuten

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

Communicatie: de "5 + 30" regel

Update de status page tijdens een SEV1 minstens elke 30 minuten, 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 na de detectie komen, ongeacht of je de oorzaak al kent.

Rollback als standaard

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

Een rollback vereist:

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

Post-mortem binnen 48 uur

Schrijf na elk SEV1/SEV2 incident een document met deze structuur:

1. Summary - 2-3 zinnen over wat er gebeurde, hoe lang het duurde en wie het beïnvloedde
2. Timeline - de exacte tijden van detectie, sleutelacties en oplossing
3. Root cause - waarom het gebeurde (technische en procedurele reden)
4. Impact - aantal getroffen klanten en 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", maar liever "een integratietest voor de payment flow toevoegen binnen 14 dagen, owner: X")

Blameless post-mortem regel: Je zoekt geen schuldige, maar een systeemzwakte. "John deployde een slechte versie" is de verkeerde conclusie - de juiste is "het deploy proces bevatte geen canary fase die de bug zou hebben gevangen voor de volledige rollout".

On-call rotatie

Voor een team met een 24/7 product:

• Wekelijkse rotaties zijn de gulden middenweg - kortere putten mensen uit, langere overbelasten de primaire on-caller
• Zorg altijd voor een primaire + secundaire on-call. De secundaire neemt over wanneer de primaire niet binnen 5 min reageert.
• Compenseer nachtelijke en weekend paging (toeslag of vrije tijd)
• Voer een maandelijkse "on-call review" in - wie werd het vaakst gewekt en 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 →