Incident response-runbooks med PagerDuty för snabbare MTTR.
Det värsta läget att försöka tänka klart i är mitt i en incident, klockan tre på natten, med en tjänst nere och adrenalinet pumpande. Ändå är det precis då många team först börjar fundera på vad de ska göra. En runbook flyttar tänkandet till en lugn stund i förväg, så att den som är på plats när det brinner kan följa en plan i stället för att improvisera. Kopplat till ett verktyg som PagerDuty blir det skillnaden mellan en kontrollerad incident och en kaosartad.
Vad en runbook faktiskt är
En runbook är inte en tjock manual. Det är en kort, konkret beskrivning av hur man hanterar en specifik typ av problem: vad man kollar först, vad de vanligaste orsakerna är, och vilka steg som brukar lösa det. Tänk på den som en checklista skriven av den som senast löste problemet, för den som löser det nästa gång, ofta en stressad kollega som inte har sammanhanget färskt.
Det viktiga är att den är konkret och handlingsinriktad. En runbook som säger undersök databasen är värdelös. En som säger kontrollera antalet aktiva anslutningar här, och om det är över den här nivån, gör det här, är guld värd mitt i natten. Specificiteten är hela poängen.
Börja med dina vanligaste incidenter
Du behöver inte skriva runbooks för allt på en gång, och du ska inte heller försöka. Börja med de incidenter som faktiskt inträffar oftast. Om du tittar tillbaka på de senaste månadernas störningar ser du nästan alltid ett mönster: ett fåtal typer av problem står för majoriteten av larmen. Skriv runbooks för dem först, så får du störst effekt för minst arbete.
- Gå igenom historiken och hitta de återkommande incidenttyperna.
- Skriv en kort runbook för var och en, gärna direkt efter att den lösts medan minnet är färskt.
- Förbättra dem löpande, varje incident är ett tillfälle att göra runbooken bättre.
PagerDuty: få rätt person dit i tid
En runbook hjälper bara om rätt person ser den i tid. Det är där PagerDuty kommer in. Det hanterar jourscheman, eskalering och själva larmandet, så att en incident hamnar hos rätt person direkt, och hos nästa om den första inte svarar. Det tar bort frågan om vem som egentligen har ansvar just nu, vilket annars kan kosta dyrbara minuter i början av en incident.
Det riktigt värdefulla är att koppla ihop larmet med runbooken. När PagerDuty larmar om en viss typ av incident kan larmet länka direkt till rätt runbook, så att den som väcks slipper leta. Den lilla detaljen, att rätt instruktion finns ett klick bort i larmet, kortar tiden till lösning märkbart. Hur larm, runbooks och deploy hänger ihop i en helhet beskriver jag i min tjänst för DevOps-plattform.
Automatisera det säkra, inte allt
När en runbook är väl beprövad kan delar av den ofta automatiseras. Om de tre första stegen vid en viss incident alltid är desamma och alltid säkra, går de att köra automatiskt så att en människa slipper. Men jag är försiktig här. Automatisering av fel sak under en incident kan göra ont värre. Jag automatiserar bara de steg som är ofarliga och väl förstådda, och låter de steg som kräver omdöme vara manuella.
Tumregeln är att automatisera diagnos och informationssamling generöst, men vara restriktiv med automatiska åtgärder som ändrar tillstånd. Att automatiskt samla ihop relevanta loggar och mått när ett larm går är nästan alltid säkert och sparar mycket tid. Att automatiskt starta om eller skala något kräver mer eftertanke.
Lär av varje incident
Den sista biten är att stänga cirkeln. Efter varje incident av betydelse håller jag ett kort, blameless eftersnack: vad hände, vad lärde vi oss, och vad gör vi annorlunda. Ofta är resultatet en ny eller förbättrad runbook, ett justerat larm eller en liten automatisering. På så sätt blir varje störning en investering i att nästa liknande störning blir lugnare. Det är så ett team gradvis bygger verklig motståndskraft.
Relaterat
- Platform Engineering 2026: Backstage vs Port vs Cortex
- GitOps med ArgoCD vs Flux: Vilket passar er K8s-stack?
- SRE för 5-personers team: Error budgets, SLO:er och on-call light
Vill du se hur incidenthantering satts upp i ett skarpt projekt finns exempel i min casebook.
Vill du ta det vidare?
Om dina incidenter i dag hanteras genom improvisation hjälper jag dig att bygga runbooks och en jour som gör dem lugna. Hör av dig via kontaktsidan.
“En runbook flyttar tänkandet till en lugn stund i förväg, så att den som är på plats kan följa en plan.”
- Simon Axelsson
Vanliga frågor
- Hur kort ska en runbook vara?
- Så kort som möjligt utan att tappa konkretion. Den ska kunna läsas och följas av en stressad person mitt i natten. Långa manualer används inte i en incident, korta handlingsinriktade checklistor gör det.
- Behöver jag PagerDuty, eller räcker det med larm i en chatt?
- För enkla fall kan en chatt räcka, men den hanterar inte eskalering och jourscheman. PagerDuty säkerställer att en incident når rätt person och eskaleras om ingen svarar, vilket är avgörande för att korta tiden till åtgärd.
- Hur mycket av incidenthanteringen bör jag automatisera?
- Automatisera diagnos och informationssamling generöst, eftersom det är säkert och sparar tid. Var restriktiv med automatiska åtgärder som ändrar tillstånd, och automatisera bara de steg som är väl beprövade och ofarliga.
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.
Fler artiklar
