Når noget går ned, er minutter dyrebare. Små produktteams har sjældent en fuldt bemandet driftsafdeling, så incident response skal være let at bruge, selv når pulsen stiger. Her får du en enkel model, der skaber ro, prioriterer indsats og forkorter tiden til normal drift.
Definér ansvar og klare signaler
Start med at gøre ansvar synligt: hvem er primær vagt, hvem er backup, og hvem kommunikerer udadtil? Et simpelt rotationsskema og en delt kontaktliste fjerner tvivl. Definér også tydelige signaler for, hvornår en hændelse eskaleres: påvirkede brugere, forringet performance eller brud på aftalte mål (SLO’er). Med faste kriterier undgår I diskussioner, når det brænder på, og kan reagere konsekvent. Aftal desuden, hvordan statussen deles med interessenter uden at forstyrre fejlretningen, så teamet kan arbejde fokuseret. Begynd med et kort dokument, der beskriver roller og eskaleringspunkter.
En letvægtsproces der virker
Hold processen kort, genkendelig og gentagelig. Brug en fast skabelon med få trin, så alle ved, hvad der sker næste gang alarmen lyder.
- Opdag og triager: bekræft problemet og vurder påvirkning inden for 10 minutter.
- Stabilisér: stop blødningen først (midlertidige afværgninger, skalering eller midlertidig nedlukning af berørte dele).
- Gendan: rul sikkert tilbage, deploy et kendt stabilt build eller aktiver feature flags.
- Dokumentér: noter årsag, afhjælpning, data for varighed og påvirkning.
Lav et kort “runbook”-notat for jeres top-3 fejlscenarier og test det ved næste øvelse.
Værktøjer I kan mestre på en uge
Vælg få værktøjer, I mestrer: overvågning med simple dashboards, alarmer med fornuftige tærskler, og en dedikeret kanal til hændelser. Feature flags giver kontrolleret aktivering og hurtig deaktivering, mens CI/CD med automatisk rollback begrænser risikoen ved fejl. Brug en delt incident-log og en skabelon til statusopdateringer for at sikre sporbarhed. Start småt: ét dashboard, én alarm per kritisk service og en procedure for rollback, der er prøvet i praksis.
Planlæg en time til at rydde op i alarmer og dokumentere jeres vigtigste rollback-vejledning.
Fra hændelse til forbedring
Styrken ligger i læringen efterfølgende. Afhold en kort, skyldfri gennemgang med fokus på fakta og systemiske årsager. Brug “5 hvorfor” til at finde rodårsager, og omsæt dem til små, konkrete forbedringer: bedre alarmering, skarpere runbooks eller mere robusthed i kode og infrastruktur. Følg op på actions, til de er lukkede, så I bygger stabilitet over tid. Mål tid til opdagelse, stabilisering og fuld gendannelse for at se fremskridt. Book næste gennemgang, mens læringen er frisk.
