Hvilke kriterier bruger du til at beslutte mellem en rollback og en hotfix?

Question

IT Interview Practice · Accepted Answer

Som standard **rollback** — det er den hurtigste, mest pålidelige måde at genoprette en kendt-god tilstand. Grib til en **hotfix** kun når rollback er umulig eller mere farlig end at fikse fremad. I en aktiv incident er prioriteten at **stoppe blødningen først**, diagnosticere senere.

## Beslutningskriterierne

- **Er rollback sikker og mulig?** Hvis den forrige version er kendt-god, og intet irreversibelt er sket, så roll back. Dette er det sædvanlige svar.
- **Skabte den dårlige release irreversibel tilstand?** En **database-migration** eller datakorruption kan gøre rollback værre end buggen. Hvis du ikke sikkert kan gå tilbage, må du fikse fremad.
- **Forstår vi fixet?** Rollback kræver ingen diagnose — det er dens styrke. En hotfix, du ikke fuldt forstår, kan uddybe incidenten; ship aldrig et gæt til prod under pres.
- **Tid til sikker tilstand.** Vælg den vej, der når stabilitet hurtigst med mindst risiko. En enkeltlinje, velforstået hotfix kan slå en kompleks rollback; en risikabel forward-fix slår aldrig en ren revert.
- **Blast radius og alvorlighed.** Et fuldt nedbrud kræver den hurtigst mulige genopretning (som regel rollback); en mindre forringelse kan tillade en omhyggelig hotfix.

## En hurtig beslutningstabel

| Situation | Vælg |
| --- | --- |
| Forrige version kendt-god, ingen migration | Rollback |
| Irreversibel DB-migration shippet | Hotfix / fix-forward |
| Årsag ukendt, alvorlig impact | Rollback (køb tid) |
| Triviel, velforstået enkeltlinjer | Hotfix |
| Selve rollbacken er risikabel/utestet | Hotfix |

## Trade-offs og faldgruber

- **Rollback** er sikker, men behandler kun symptomet — du skylder stadig en rigtig fix og en postmortem.
- **Hotfix** adresserer root cause, men springer det normale sikkerhedsnet over; bugs i hotfixes er almindelige, netop fordi de er forhastede.
- **Utestet rollback-sti** er en fælde — hvis du aldrig har øvet den, kan den fejle, når du har mest brug for den. Øv rollbacks, før du har brug for dem.
- Pas på **debugging i produktion** under pres; hvis du er mere end et par minutter fra en sikker fix, så roll back og undersøg roligt.

## Hvorfor det betyder noget

Denne beslutning sker på det værst tænkelige tidspunkt — system nede, uret kører, alle kigger med. En Tech Lead med en klar, indøvet regel for det skærer MTTR dramatisk og forhindrer den klassiske fejl at forsøge at være smart midt i en incident, når den kedelige revert var lige der. Genopret først, vær smart bagefter.

Situation	Vælg
Forrige version kendt-god, ingen migration	Rollback
Irreversibel DB-migration shippet	Hotfix / fix-forward
Årsag ukendt, alvorlig impact	Rollback (køb tid)
Triviel, velforstået enkeltlinjer	Hotfix
Selve rollbacken er risikabel/utestet	Hotfix

Beslutningskriterierne

En hurtig beslutningstabel

Trade-offs og faldgruber

Hvorfor det betyder noget

Relaterede spørgsmål