Din webbplats i produktion gick precis ner. Hur hanterar du det?

Question

Accepted Answer

Första prioriteten är att **återställa tjänsten, sedan hitta orsaken** — åtgärd kommer före diagnos. Jag skulle deklarera en incident, fördela tydliga roller och driva mot den snabbaste säkra återställningen, med kommunikation hela vägen.

## Stabilisera först

- **Deklarera en incident** och öppna en enda kanal (war room / Slack-tråd) så att koordineringen inte blir spridd.
- **Fördela roller**: en **Incident Commander** som fattar beslut, en **comms-ansvarig** som uppdaterar stakeholders, och **responders** som undersöker. Som Tech Lead tar jag ofta IC-rollen så att ingenjörerna kan fokusera på problemet.
- **Sträck dig efter den snabbaste reversibla åtgärden.** Om en deploy korrelerar med avbrottet, gör en **rollback** först och ställ frågor sedan — att återställa användarna slår att ha rätt.

## Diagnostisera parallellt

- Kolla de **uppenbara signalerna**: dashboards, felfrekvenser, senaste deploys, infraändringar, trafiktoppar, utgångna certifikat.
- Formulera en hypotes, testa den billigaste först, och **undvik att ändra fem saker samtidigt** — då vet du inte vad som hjälpte.

## Kommunicera kontinuerligt

Tystnad föder panik. Jag skickar uppdateringar i en jämn kadens även när det inte finns några nyheter:

```
[14:05] Undersöker — checkout är nere, ~40% av användarna påverkade. Nästa uppdatering 14:20.
[14:20] Identifierat: dålig deploy. Gör rollback nu. ETA 10 min.
[14:35] Tjänsten återställd. Övervakar. Postmortem följer.
```

## Efter återställning

- Bekräfta full återställning, inte bara "det ser bättre ut".
- Kör en **blameless postmortem** inom några dagar: tidslinje, grundorsak, vad som gjorde den långsam att upptäcka/åtgärda, och **konkreta åtgärdspunkter med ägare**.
- Resultatet är systemisk förbättring (bättre alerts, skyddsräcken, automatiserad rollback) — inte ett namn att skylla på.

## Fallgropar

- **Att debugga innan man åtgärdar** medan användarna lider.
- **Ingen enskild beslutsfattare**, så fem personer gissar parallellt.
- **Att gå tyst** gentemot stakeholders.
- **Att skylla på individer**, vilket dödar den ärlighet som framtida incidents är beroende av.

## Varför det är viktigt

Avbrott är oundvikliga; hur du hanterar dem definierar teamets förtroende och kundernas tillit. Lugn, rollbaserad koordinering plus blameless uppföljning förvandlar en dålig dag till ett starkare system — och signalerar till dina ingenjörer att det är tryggt att röra sig snabbt, eftersom misslyckanden hanteras som en process, inte en häxjakt.