Hur leder du under en produktionsincident?

Question

Accepted Answer

Under en incident är ditt jobb att **återställa tjänsten lugnt och koordinera svaret**, inte att vara hjälten som fixar det ensam. Tydliga roller, lugn kommunikation och en bias för att minska effekten först skiljer ett smidigt svar från kaos.

## Hur man kör 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.
```

## Minska innan du diagnostiserar

Instinkten att hitta rotorsaken är stark, motstå den. Om en rollback återställer tjänsten, gör det *först*, sedan undersöka lugnt med trycket av. Användare bryr sig om att bli avblockerade, inte om din diagnos.

## Ett konkret exempel

En deploy bryter kassan. Debugga inte den nya koden live under tryck. Rulla tillbaka omedelbar, bekräfta att kassan fungerar, skicka ett uppdatering, *sedan* undersök den dåliga deployen under lugna förhållanden.

## En fälla

En skuldbelagd post-mortem lär människor att dölja problem. Håll den skuldlös, fokusera på de systemiska bristerna (ingen kanariegul, ingen avisering) som tillät det.

## Varför det spelar roll

Incidenter är högt stressiga och högt synliga, hur du leder formar både resultatet och teamets förtroende för dig.

Lugn samordning och skuldlös lärande förvandlar ett avbrott till ett system som är svårare att bryta nästa gång.