Runbook

Wat is een runbook?

Een runbook is een draaiboek voor een operationele taak of incident. Het beschrijft welke stappen iemand moet volgen, welke controles nodig zijn en wanneer er geëscaleerd wordt.

In een dataomgeving kan een runbook gaan over een gefaalde pipeline, een vertraagd dashboard, een verkeerde lading, een herstelactie of een securitymelding.

Een goed runbook voorkomt dat mensen tijdens stress moeten gokken. Het maakt het werk herhaalbaar.

Wat staat er in een runbook?

• Trigger. Wanneer gebruik je dit runbook?

• Impact. Welke systemen, rapporten of gebruikers zijn geraakt?

• Stappenplan. Wat controleer je eerst, daarna en op het einde?

• Beslispunten. Wanneer mag je zelf herstellen en wanneer is approval nodig?

• Communicatie. Wie verwittig je en met welke boodschap?

• Controle na afloop. Hoe weet je dat het probleem echt opgelost is?

Voorbeeld

Een nachtelijke pipeline laadt orderdata niet. Het runbook zegt eerst de orchestrator te controleren, daarna de bron-API-status, daarna de laatste succesvolle watermark. Als de bron niet beschikbaar is, communiceert het data team dat het salesdashboard vertraagd is. Als de bron werkt, mag de operator de job één keer opnieuw starten.

Na herstel controleert het runbook de rij-aantallen, freshness en een paar KPI's. Pas daarna wordt het incident gesloten.

Runbook versus automatisatie

Een runbook hoeft niet handmatig te blijven. Veel stappen kunnen later naar een workflow engine, script of alertingtool verhuizen.

Toch blijft de tekstversie nuttig. Ze legt uit waarom een stap bestaat, welke risico's erbij horen en wanneer een mens moet beslissen. Automatisatie zonder runbook wordt snel een zwarte doos.

Wanneer maak je een runbook?

1. Een incident komt vaker terug. Herhaling vraagt een vaste aanpak.

2. Herstel heeft risico. Een backfill, delete of herpublicatie kan data veranderen.

3. Meerdere teams zijn betrokken. Dan moet communicatie helder zijn.

4. Een taak gebeurt zelden. Juist dan vergeet je stappen.

Waar moet je op letten bij runbooks

• Test ze buiten incidenten. Een runbook dat nooit geoefend is, kan ontbreken wat je nodig hebt.

• Hou ze kort genoeg. In een incident leest niemand een roman.

• Gebruik echte namen en dashboards. Vage stappen zoals "controleer de data" helpen niet.

• Werk ze bij na incidenten. De beste verbeteringen komen uit echte herstelacties.