Jakich kryteriów używasz, by zdecydować między rollbackiem a hotfixem?

Question

IT Interview Practice · Accepted Answer

Domyślnie wybieraj **rollback** — to najszybszy, najbardziej niezawodny sposób przywrócenia znanego-dobrego stanu. Sięgaj po **hotfix** tylko wtedy, gdy rollback jest niemożliwy lub bardziej niebezpieczny niż naprawa do przodu. W trakcie aktywnego incidentu priorytetem jest **najpierw zatrzymać krwawienie**, diagnozować później.

## Kryteria decyzyjne

- **Czy rollback jest bezpieczny i możliwy?** Jeśli poprzednia wersja jest znana-dobra i nie wydarzyło się nic nieodwracalnego, zrób rollback. To zwykła odpowiedź.
- **Czy zły release stworzył nieodwracalny stan?** **Migracja bazy danych** lub uszkodzenie danych mogą uczynić rollback gorszym niż bug. Jeśli nie możesz bezpiecznie się cofnąć, musisz naprawiać do przodu.
- **Czy rozumiemy poprawkę?** Rollback nie wymaga diagnozy — w tym jego siła. Hotfix, którego nie rozumiesz w pełni, może pogłębić incident; nigdy nie wypuszczaj zgadywanki na prod pod presją.
- **Czas do bezpiecznego stanu.** Wybierz ścieżkę, która osiąga stabilność najszybciej przy najmniejszym ryzyku. Jednoliniowy, dobrze zrozumiany hotfix może pobić złożony rollback; ryzykowna naprawa do przodu nigdy nie pobije czystego reverta.
- **Promień rażenia i dotkliwość.** Pełna awaria wymaga najszybszego możliwego przywrócenia (zwykle rollback); drobna degradacja może pozwolić na ostrożny hotfix.

## Szybka tabela decyzyjna

| Sytuacja | Wybierz |
| --- | --- |
| Poprzednia wersja znana-dobra, brak migracji | Rollback |
| Wypuszczona nieodwracalna migracja DB | Hotfix / naprawa do przodu |
| Przyczyna nieznana, dotkliwy wpływ | Rollback (kup czas) |
| Trywialny, dobrze zrozumiany jednolinijkowiec | Hotfix |
| Sam rollback jest ryzykowny/nietestowany | Hotfix |

## Trade-offy i pułapki

- **Rollback** jest bezpieczny, ale leczy tylko objaw — wciąż jesteś winien prawdziwą poprawkę i postmortem.
- **Hotfix** adresuje root cause, ale pomija normalną siatkę bezpieczeństwa; bugi w hotfixach są częste właśnie dlatego, że są pośpieszne.
- **Nietestowana ścieżka rollbacku** to pułapka — jeśli nigdy jej nie przećwiczyłeś, może zawieść, gdy najbardziej jej potrzebujesz. Ćwicz rollbacki, zanim ich potrzebujesz.
- Strzeż się **debugowania na produkcji** pod presją; jeśli jesteś dalej niż kilka minut od pewnej poprawki, zrób rollback i badaj spokojnie.

## Dlaczego to ważne

Ta decyzja zapada w najgorszym możliwym momencie — system padł, zegar tyka, wszyscy patrzą. Tech Lead z jasną, przećwiczoną regułą na to drastycznie skraca MTTR i zapobiega klasycznemu błędowi prób bycia sprytnym w trakcie incidentu, gdy nudny revert był tuż obok. Najpierw przywróć, bądź sprytny później.

Sytuacja	Wybierz
Poprzednia wersja znana-dobra, brak migracji	Rollback
Wypuszczona nieodwracalna migracja DB	Hotfix / naprawa do przodu
Przyczyna nieznana, dotkliwy wpływ	Rollback (kup czas)
Trywialny, dobrze zrozumiany jednolinijkowiec	Hotfix
Sam rollback jest ryzykowny/nietestowany	Hotfix

Kryteria decyzyjne

Szybka tabela decyzyjna

Trade-offy i pułapki

Dlaczego to ważne

Powiązane pytania