По каким критериям вы выбираете между rollback и hotfix?

Question

Accepted Answer

По умолчанию — **rollback**: это самый быстрый и надёжный способ восстановить заведомо рабочее состояние. Тянитесь к **hotfix** только тогда, когда rollback невозможен или опаснее, чем чинить вперёд. В активном incident приоритет — **сначала остановить кровотечение**, диагностировать позже.

## Критерии решения

- **Безопасен и возможен ли rollback?** Если предыдущая версия заведомо рабочая и ничего необратимого не произошло — откатывайтесь. Это обычный ответ.
- **Создал ли плохой релиз необратимое состояние?** **Database migration** или порча данных могут сделать rollback хуже бага. Если безопасно вернуться нельзя, надо чинить вперёд.
- **Понимаем ли мы фикс?** Rollback не требует диагностики — в этом его сила. Hotfix, который вы не до конца понимаете, может углубить incident; никогда не выкатывайте догадку в prod под давлением.
- **Время до безопасного состояния.** Выбирайте тот путь, что достигает стабильности быстрее с наименьшим риском. Однострочный, хорошо понятный hotfix может обойти сложный rollback; рискованный fix-forward никогда не бьёт чистый revert.
- **Радиус поражения и серьёзность.** Полный outage требует быстрейшего возможного восстановления (обычно rollback); незначительная деградация может допустить аккуратный hotfix.

## Быстрая таблица решения

| Ситуация | Выбрать |
| --- | --- |
| Предыдущая версия заведомо рабочая, нет migration | Rollback |
| Выкачена необратимая DB migration | Hotfix / fix-forward |
| Причина неизвестна, серьёзное влияние | Rollback (выиграть время) |
| Тривиальный, хорошо понятный однострочник | Hotfix |
| Сам rollback рискован/непроверен | Hotfix |

## Компромиссы и подводные камни

- **Rollback** безопасен, но лишь лечит симптом — вы всё ещё должны настоящий фикс и postmortem.
- **Hotfix** обращается к корневой причине, но обходит обычную страховочную сеть; баги в hotfix'ах часты именно потому, что их спешат.
- **Непроверенный путь rollback** — это ловушка: если вы никогда его не репетировали, он может подвести, когда нужнее всего. Репетируйте rollback до того, как он понадобится.
- Остерегайтесь **дебага в production** под давлением; если вы более чем в нескольких минутах от уверенного фикса — откатывайтесь и расследуйте спокойно.

## Почему это важно

Это решение случается в худший возможный момент — система лежит, часы тикают, все смотрят. Tech Lead с чётким, отрепетированным правилом для него резко сокращает MTTR и предотвращает классическую ошибку — пытаться быть умным посреди incident, когда скучный revert был прямо под рукой. Сначала восстановить, потом быть умным.

Ситуация	Выбрать
Предыдущая версия заведомо рабочая, нет migration	Rollback
Выкачена необратимая DB migration	Hotfix / fix-forward
Причина неизвестна, серьёзное влияние	Rollback (выиграть время)
Тривиальный, хорошо понятный однострочник	Hotfix
Сам rollback рискован/непроверен	Hotfix