Hvordan leder du under en produktionsincident?

Question

Accepted Answer

Under en incident er dit job at **genoprette servicen roligt og koordinere reaktionen**, ikke at være helten, der reparerer alt alene. Klare roller, rolig kommunikation og fokus på at mindske problemet først adskiller en glat reaktion fra kaos.

## Sådan kører du en incident

```text
1. ASSIGN roles — incident commander (coordinates), responders (fix),
   comms (updates stakeholders). One person can't do all three.
2. MITIGATE first — stop the bleeding (roll back, feature-flag off)
   before chasing root cause.
3. COMMUNICATE on a cadence — even "still investigating" every 15-30 min.
4. STAY CALM — the team mirrors your energy. Blame comes later, or never.
5. After: BLAMELESS post-mortem — fix the system, not the person.
```

## Mindsk før du diagnosticerer

Instinktet til at finde rodårsagen er stærkt, modstå det. Hvis en rollback genopretter servicen, gør det *først*, derefter undersøg roligt, når presset er væk. Brugere bekymrer sig om at blive aflastet, ikke om din diagnose.

## Et konkret eksempel

En udrulning ødelægger checkout. Debug ikke den nye kode live under pres. Rollback med det samme, bekræft at checkout virker, post en opdatering, *derefter* undersøg den dårlige udrulning under rolige forhold.

## En fælde

En skyldbelagt post-mortem lærer folk at skjule problemer. Hold det skyldfrit, fokuser på de systemiske huller (ingen canary, ingen alert), der tillod det at ske.

## Hvorfor det betyder noget

Incidenter er høj-stress og høj-synlighed, hvordan du leder, former både resultatet og holdets tillid til dig.

Rolig koordination og skyldfri læring gør et serviceafbrud til et system, der er sværere at ødelægge næste gang.