Runbooks gør komplekse driftsopgaver håndterbare, selv når pulsen stiger. For små produktteams er de forskellen mellem panik og ro i leverancen. Her er en enkel ramme til at komme i gang, så I reagerer hurtigt, ensartet og trygt, når noget pludseligt går galt.
Hvad er en runbook – kort fortalt
En runbook er en kort, handlingsorienteret vejledning til en bestemt hændelse: hvem gør hvad, hvornår og hvordan. Den beskriver trigger, ansvar, nøgletrin, standardkommandoer samt beslutningspunkter og fallback. Den virker, fordi den reducerer kognitiv belastning, giver fælles sprog og gør reaktionen forudsigelig – også når den mest erfarne ikke er på vagt. For små teams betyder det færre misforståelser, hurtigere stabilisering og nemmere oplæring.
Når minutter tæller under et nedbrud, gavner det at kombinere runbooks med en enkel model for incident response, som sikrer tydelige roller og enkel kommunikation.
Sådan skriver du den første runbook
Start småt og konkret, fx “database utilgængelig”. Hold formatet ens, så runbooks kan læses under pres. Brug følgende skelet og hold hvert punkt maksimalt to linjer.
- Trigger: klare tegn på at runbooken skal bruges.
- Ansvar: hvem leder, hvem udfører, hvem informerer.
- Trin: kort sekvens med kommandonavne, links og forventet varighed.
- Fallback: stopkriterier, rollback og eskalationsvej.
Publicér den i jeres repo eller driftswiki, så alle kan finde den.
Gør dem brugbare i praksis
En runbook virker kun, hvis den er nem at finde og bruge. Placér dem ét sted, giv dem klare navne og test dem jævnligt med “tørtræning”. Notér virkelige output-eksempler og tilføj skærmbilleder, hvor det giver mening. Under vagter bør runbooken være det primære arbejdsdokument, mens chat eller call bruges til koordinering.
Efter en hændelse bør I samle læring uden at pege fingre, og strukturerede postmortems uden skyld i teams gør det lettere at omsætte erfaringer til forbedringer.
Vedligehold og ejerskab i små teams
Sæt ansvar på hver runbook: en ejer, en stedfortræder og en fast review-frekvens. Brug versionsstyring og små pull requests, så ændringer kan spores. Aftal et “aflivningskriterium”: runbooks, der ikke anvendes, arkiveres eller samles med andre. Knyt runbooks til alarmer og dashboards, så signal fører direkte til handling. Indfør en kvartalsvis gennemgang, hvor I tester de vigtigste runbooks end-to-end. Næste skridt er at vælge én kritisk service og skrive en smal runbook i dag.
