Runbook

Ordet stammer fra mainframe-driften, hvor en run book listede de jobs, parametre og genopretningstrin, som operatørerne skulle bruge for at afvikle en batchplan. I moderne drift er en runbook procedurel og snæver: én alarm eller én rutineopgave, med en forudsætning, en række diagnosticerende og afhjælpende trin, en kontrol af at rettelsen virkede, og et eskaleringspunkt. Ordet playbook bruges ofte i flæng, men mange organisationer bruger playbook om den bredere, scenariebaserede respons (en ransomware-playbook eller en playbook for brud på persondatasikkerheden, der dækker roller, kommunikation og anmeldelse til myndigheder), med runbooks som de tekniske procedurer, der kaldes derfra. Googles SRE-bog oplyser, at det giver cirka en tredobbelt forbedring af den gennemsnitlige tid til genopretning (MTTR) at nedskrive bedste praksis på forhånd i en playbook frem for at improvisere.

En velstruktureret runbook til en alarm beskriver, hvad alarmen betyder, og hvordan brugerne påvirkes, linker til de dashboards og forespørgsler, der skal bruges til at bekræfte den, oplister diagnostiske kommandoer i rækkefølge med forventet output, angiver afhjælpning fra mindst til mest indgribende (dræn en node, rul den seneste udrulning tilbage, fail over til en anden region), siger, hvornår man skal stoppe og eskalere og til hvem, og registrerer ejer og dato for seneste gennemgang. Når runbooken linkes direkte fra alarmen, fx via en runbook_url-annotation på en Prometheus-regel, kommer den vagthavende frem til den i ét skridt fra opkaldet.

Runbooks forældes: infrastrukturen ændrer sig, kommandoer henviser til hosts, der ikke længere findes, og trin, der var korrekte, bliver farlige. Typiske modtræk er at have runbooks i versionsstyring ved siden af tjenestens kode, gennemgå dem efter hver hændelse, hvor de blev brugt, øve dem på game days og slette alarmer uden en meningsfuld runbook, da en alarm uden dokumenteret handling som regel ikke burde vække nogen. Runbooks skrevet som fortællende prosa frem for eksekverbare, kontrollerbare trin er sværere at følge klokken tre om natten.

Den naturlige udvikling er automatisering. Trin, der er fuldt deterministiske, kan laves om til scripts, dernæst til værktøjer til runbook-automatisering eller eksekverbare notebooks og til sidst til selvhelende controllere, der handler uden at tilkalde nogen, hvorefter alarmen bør nedgraderes eller fjernes. På sikkerhedssiden implementerer SOAR-platforme samme idé for SOC-arbejdsgange og udfører berigelse og inddæmning automatisk, når en SIEM-alarm kommer ind. NIST SP 800-61 Rev. 3 (april 2025) indplacerer hændelseshåndtering i funktionerne i NIST Cybersecurity Framework 2.0 og forventer, at organisationer vedligeholder dokumenterede responsprocedurer; runbooks er den mest konkrete form for sådanne procedurer, og for enheder omfattet af NIS2 eller DORA indgår de i dokumentationen for, at hændelseshåndteringen reelt fungerer.