7 estrategias de rollback que salvam sua producao

Rollback em producao nao e improviso: e um processo planejado que define como reverter rapidamente um deploy problemático. A pergunta que guia a escolha da estrategia e simples: quanto tempo sua equipe pode ficar com o sistema degradado? A resposta varia, mas o objetivo e sempre o mesmo: restaurar a estabilidade com o menor impacto para o usuario. Abaixo, sete estrategias testadas, da mais simples a mais complexa, com criterios para decidir quando usar cada uma.

1. Redeploy da versao anterior

A estrategia mais direta: se a versao nova quebrou, o servidor volta a executar o artefato da versao anterior. Na pratica, isso significa manter os artefatos das ultimas versoes armazenados no registry, prontos para um novo deploy. O criterio de escolha: quando a falha esta no codigo e nao na infraestrutura. Um exemplo: uma API que comeca a retornar erro 500 apos o deploy. O redeploy da versao estavel resolve em minutos, mas nao corrige a causa raiz: o bug continua no branch principal.

2. Rollback de banco de dados com backup

Aqui o cuidado e redobrado. Se a versao nova alterou o schema do banco, reverter o codigo sem reverter o banco pode gerar inconsistencias. A estrategia exige backups automatizados antes de cada deploy, e um script de rollback que restaure o schema e os dados. O criterio de escolha: quando a migracao de banco e parte do deploy. Um contraexemplo: reverter apenas o codigo com uma migracao que adicionou uma coluna obrigatoria, e o sistema antigo nao conhece essa coluna, causando erros de escrita.

3. Feature flags para desativar funcionalidades

Feature flags permitem desligar uma funcionalidade especifica sem novo deploy. Se o bug esta isolado em uma feature nova, basta desativar a flag no painel de configuracao. O criterio de escolha: quando o problema e limitado a uma funcionalidade e nao ao sistema inteiro. Um exemplo pratico: um novo checkout que quebra pagamentos. Desativar a flag volta o checkout antigo em segundos, mantendo o resto do sistema no ar. A ressalva: requer disciplina para remover flags antigas, senao o codigo vira um labirinto.

4. Blue-green deployment

A estrategia blue-green mantem dois ambientes identicos: o azul (atual) e o verde (novo). O trafego vai para o azul; quando o verde esta validado, o balanceador muda o trafego. Se algo der errado, o retorno ao azul e imediato. O criterio de escolha: quando a infraestrutura suporta dois ambientes completos, o que dobra o custo. Um exemplo: um e-commerce que faz deploy em horario de pico. Com blue-green, a troca e transparente para o usuario. O ponto de atencao: o banco de dados precisa ser compartilhado ou ter estrategia de sincronizacao.

5. Canary release

O canary libera a versao nova para uma pequena porcentagem de usuarios (por exemplo, 5%) e monitora erros antes de expandir. Se a taxa de erro aumenta, o trafego e redirecionado para a versao estavel. O criterio de escolha: quando a equipe tem monitoramento em tempo real e confianca na observabilidade. Um caso concreto: um servico de streaming que testa uma nova recomendacao com 1% dos usuarios. Se o tempo de resposta piora, o canary e revertido sem afetar os demais. A limitacao: exige metricas claras e um painel que mostre o impacto em minutos.

6. Git revert

O git revert cria um novo commit que desfaz as mudancas da versao problematica, preservando o historico. E util quando o deploy e feito a partir de um branch e a reversao precisa ser versionada. O criterio de escolha: quando o codigo da versao anterior nao esta mais compativel com o banco ou com outras mudancas recentes. Um exemplo: um merge que introduziu um bug de logica. O revert resolve, mas se houver conflitos, pode ser mais lento que um redeploy. A ressalva: nao reverte migracoes de banco automaticamente, entao combine com a estrategia 2.

7. Restore de snapshot de infraestrutura

Se o problema afeta a infraestrutura como um todo (por exemplo, uma configuracao errada de rede), o restore de um snapshot da maquina ou do container pode ser a saida. O criterio de escolha: quando a falha esta em configuracao ou em dependencias do sistema, nao no codigo. Um exemplo: uma atualizacao de biblioteca que quebra a inicializacao do servico. Restaurar o snapshot da maquina virtual volta ao estado anterior. O limite: snapshots podem ter minutos de defasagem, e dados gravados nesse intervalo sao perdidos.

Como escolher a estrategia certa

Nao existe a melhor estrategia universal. O criterio central e o tipo de falha: se e no codigo, redeploy ou git revert; se e no banco, backup; se e em configuracao, snapshot; se quer minimizar impacto, canary ou blue-green. Para equipes com pouca maturidade, comecar com redeploy e backup resolve a maioria dos casos. Para quem ja tem monitoramento solido, canary reduz o risco de afetar todos os usuarios. O proximo passo pratico: documente um runbook de rollback com os passos de cada estrategia e teste-o em ambiente de staging antes de precisar dele em producao.

FAQ

O que e rollback em producao?

Rollback em producao e o processo de reverter um deploy para uma versao anterior estavel quando a versao atual apresenta falhas. O objetivo e restaurar o servico rapidamente, minimizando o impacto para os usuarios. Pode envolver codigo, banco de dados ou infraestrutura, dependendo da causa do problema.

Qual a diferenca entre rollback e redeploy?

Rollback e o termo generico para reverter uma mudanca; redeploy e uma acao especifica que reimplanta a versao anterior. Ou seja, redeploy e uma das estrategias de rollback, mas existem outras, como git revert, feature flags e restore de snapshot, que nao envolvem necessariamente reimplantar um artefato.

Como fazer rollback de banco de dados com seguranca?

O caminho seguro e ter backups automatizados antes de cada deploy e scripts de rollback que restaurem o schema e os dados. Teste esses scripts em staging regularmente. Nunca reverta apenas o codigo se a versao nova alterou o banco, pois a incompatibilidade pode gerar erros graves.

Rollback e a mesma coisa que feature flag?

Nao. Feature flag desativa uma funcionalidade em tempo de execucao, sem novo deploy, enquanto rollback reverte o deploy inteiro ou parte dele. Feature flags sao uteis para isolar problemas em funcionalidades especificas, mas nao substituem um rollback quando o problema afeta o sistema como um todo.

Quando usar canary release em vez de blue-green?

Use canary quando quiser testar com uma porcentagem pequena de usuarios e tiver monitoramento em tempo real. Use blue-green quando precisar de uma troca instantanea entre dois ambientes completos. Canary e mais barato, mas exige metricas solidas; blue-green e mais caro, mas o retorno e imediato.

O que fazer se o rollback nao resolver o problema?

Se o rollback nao resolver, o problema pode nao estar no codigo, mas em infraestrutura, configuracao ou dependencias. Nesse caso, verifique logs, metricas e snapshots. Tambem vale considerar que a versao anterior tinha um bug latente que so apareceu sob nova carga. Documente a ocorrencia e revise o runbook de rollback.