Quais critérios você usa para decidir entre um rollback e um hotfix?

Question

IT Interview Practice · Accepted Answer

Por padrão, **rollback** — é a forma mais rápida e confiável de restaurar um estado bom conhecido. Recorra a um **hotfix** apenas quando o rollback é impossível ou mais perigoso do que corrigir para frente. Em um incident ativo, a prioridade é **estancar o sangramento primeiro**, diagnosticar depois.

## Os critérios de decisão

- **O rollback é seguro e possível?** Se a versão anterior é conhecida como boa e nada irreversível aconteceu, faça rollback. Esta é a resposta usual.
- **A release ruim criou estado irreversível?** Uma **migração de banco de dados** ou corrupção de dados pode tornar o rollback pior do que o bug. Se você não consegue voltar com segurança, precisa corrigir para frente.
- **Entendemos a correção?** O rollback não precisa de diagnóstico — esse é seu poder. Um hotfix que você não entende totalmente pode aprofundar o incident; nunca suba um chute para prod sob pressão.
- **Tempo até o estado seguro.** Escolha o caminho que chega à estabilidade mais rápido com o menor risco. Um hotfix de uma linha, bem compreendido, pode vencer um rollback complexo; uma correção para frente arriscada nunca vence um revert limpo.
- **Raio de impacto e severidade.** Uma queda total exige a restauração mais rápida possível (geralmente rollback); uma degradação menor pode permitir um hotfix cuidadoso.

## Uma tabela rápida de decisão

| Situação | Escolha |
| --- | --- |
| Versão anterior conhecida como boa, sem migração | Rollback |
| Migração de DB irreversível subida | Hotfix / corrigir para frente |
| Causa desconhecida, impacto severo | Rollback (ganhar tempo) |
| Trivial, one-liner bem compreendido | Hotfix |
| O próprio rollback é arriscado/não testado | Hotfix |

## Trade-offs e armadilhas

- O **rollback** é seguro, mas só trata o sintoma — você ainda deve uma correção real e um postmortem.
- O **hotfix** ataca a causa raiz, mas pula a rede de segurança normal; bugs em hotfixes são comuns justamente porque são apressados.
- **Um caminho de rollback não testado** é uma armadilha — se você nunca o ensaiou, ele pode falhar quando você mais precisa. Pratique rollbacks antes de precisar deles.
- Cuidado com **depurar em produção** sob pressão; se você está a mais do que alguns minutos de uma correção confiável, faça rollback e investigue com calma.

## Por que isso importa

Essa decisão acontece no pior momento possível — sistema fora, relógio correndo, todo mundo olhando. Um Tech Lead com uma regra clara e ensaiada para ela reduz o MTTR drasticamente e evita o erro clássico de tentar ser esperto no meio do incident quando o revert chato estava ali ao lado. Restaure primeiro, seja esperto depois.

Situação	Escolha
Versão anterior conhecida como boa, sem migração	Rollback
Migração de DB irreversível subida	Hotfix / corrigir para frente
Causa desconhecida, impacto severo	Rollback (ganhar tempo)
Trivial, one-liner bem compreendido	Hotfix
O próprio rollback é arriscado/não testado	Hotfix

Os critérios de decisão

Uma tabela rápida de decisão

Trade-offs e armadilhas

Por que isso importa

Perguntas relacionadas