Rollback de deploy: como voltar sem transformar falha em crise

Voltar o código é simples apenas quando nada mais mudou. Um rollback real precisa considerar dados, configuração, filas e compatibilidade.

Cinco minutos antes do deploy, responda: “voltar para onde?” A versão atual é 2.8.4 . A nova versão é 2.9.0 . O pipeline está pronto para publicar. Antes de aprovar, a equipe executa um exercício de mesa: Se a taxa de erros subir depois da publicação, qual comando restaura a operação? A primeira resposta é: Voltamos para a imagem 2.8.4 . Então aparecem outras perguntas: a versão 2.9.0 executa uma migração; um campo antigo será removido; a configuração de sessão muda; mensagens serão publicadas em um novo formato; um job começará a preencher dados; o frontend novo pode ser armazenado no cache do navegador. Voltar apenas a imagem pode colocar uma aplicação antiga diante de: banco novo; dados transformados; mensagens incompatíveis; configuração nova; cache novo. Rollback não é “executar o deploy ao contrário”. É levar o sistema para um estado conhecido e coerente. O exercício de mesa Preencha antes da publicação: Camada O que muda? Como voltar? Limite Aplicação imagem 2.8.4 → 2.9.0 promover 2.8.4 depende de banco compatível Banco adiciona coluna e inicia preenchimento manter alteração aditiva não remover dados Configuração timeout 5 s → 2 s restaurar versão anterior exige recarregar serviço Fila evento v1 → v2 publicar nos dois formatos consumidor antigo precisa funcionar Frontend bundle novo promover bundle anterior cache precisa de nomes versionados Infraestrutura regra de rede reaplicar plano anterior revisado estado atual pode ter mudado Se uma linha não possui resposta, a equipe não tem rollback completo. Rollback, restore, failover e roll forward são diferentes Rollback Retorna aplicação ou configuração para uma versão anterior conhecida. Restore Recupera dados a partir de backup, snapshot ou log. Failover Move o serviço para uma instância, nó, região ou sistema alternativo. Roll forward Publica uma nova correção em vez de retornar. Desativação por feature flag Mantém o artefato, mas desliga comportamento específico. Um incidente pode exigir mais de uma ação. Exemplo: Não chame restauração de banco de rollback. Restaurar pode perder alterações legítimas feitas depois do backup. O guia sobre backup e restauração trata desse risco. O artefato anterior precisa continuar disponível Uma tag mutável não é uma versão confiável. Evite: como única referência operacional. Registre: O rollback precisa usar o artefato testado anteriormente, não reconstruir código antigo naquele momento. Build novo a partir do mesmo commit pode variar por: dependências; imagem base; repositório; compilador; horário; ferramenta. O pipeline de CI/CD seguro deve preservar e promover artefatos imutáveis. Estrutura por releases facilita o retorno em servidores tradicionais Uma aplicação operada com diretórios versionados pode usar: A reversão da aplicação pode trocar o symlink: Depois: Esses comandos são exemplos. Antes de usar: confirme os caminhos; confirme a release; valide permissões; verifique banco; preserve logs; execute healthcheck; registre a ação. Um script deve recusar releases inexistentes: O script não resolve compatibilidade de banco. Ele apenas torna a ação da aplicação reproduzível. Kubernetes guarda revisões, mas não o sistema inteiro Um Deployment pode ser inspecionado: Reversão: Ou para revisão específica: A documentação de Deployments do Kubernetes explica que revisões são criadas quando o template do Pod muda. O comando não reverte automaticamente: banco; Secret alterado fora do template; ConfigMap consumido dinamicamente; recurso externo; mensagem publicada; objeto deletado; armazenamento; mudança de DNS. Também depende da retenção do histórico. Não trate rollout undo como plano completo. Banco de dados decide se o rollback é possível Alteração incompatível: Se a nova aplicação falhar, a versão antiga pode depender de full name . Mudança expansiva: Uma sequência mais segura: Essa estratégia é conhecida como expand and contract. O retorno de B para A continua possível porque a estrutura antiga ainda existe. Ela custa mais: código temporário; dupla escrita; backfill; validação; remoção posterior. O custo compra compatibilidade durante o deploy. A AWS Builders' Library enfatiza que mudanças precisam preservar compatibilidade com versões anteriores durante a janela de rollback. Reverter migração nem sempre é seguro Uma migration down pode parecer simétrica: Se a tabela já recebeu dados legítimos, a reversão destrói informação. Antes de executar uma migração reversa: identifique dados criados; verifique dependências; produza backup; defina retenção; avalie perda; confirme versão da aplicação; registre autorização. Em muitos incidentes, a escolha correta é: reverter aplicação; manter schema aditivo; corrigir posteriormente. Configuração também precisa de versão Mudanças operacionais podem falhar sem código novo: timeout; limite de conexão; endpoint; modo de cache; flag; algoritmo; credencial; política. Registre a configuração ativa: Não registre valores secretos. A reversão precisa saber: qual revisão anterior; quais parâmetros mudaram; se a aplicação lê em tempo real; se precisa reiniciar; se o valor antigo ainda é válido. Uma credencial rotacionada não deve ser “desrotacionada” para uma chave comprometida. Mensagens e filas exigem compatibilidade temporal Durante um deploy, produtor e consumidor podem executar versões diferentes. Mensagem v1: Mensagem v2 incompatível: Se a versão antiga retornar, poderá não interpretar mensagens v2 já armazenadas. Prefira evolução aditiva: Consumidores precisam: ignorar campos desconhecidos; tratar versões; ser idempotentes; suportar repetição; possuir dead letter; registrar falhas. Rollback de aplicação não remove mensagens incompatíveis já publicadas. Feature flag reduz alcance, mas cria estado operacional Uma flag pode separar deploy de ativação: Durante falha: pode ser mais rápido que reconstruir ou reimplantar. Mas a flag precisa de: valor padrão seguro; owner; auditoria; expiração; testes nos estados; comportamento durante indisponibilidade; remoção posterior. Não use flag para contornar uma vulnerabilidade estrutural indefinidamente. Defina critérios antes do deploy Evite decidir durante o incidente o que é “erro demais”. Exemplo hipotético: Os valores precisam ser calibrados. O Azure Well Architected Framework recomenda modelos de saúde, exposição progressiva e avaliação contínua durante deployments seguros. Critérios devem considerar: volume; sazonalidade; baseline; significância; SLO; impacto; capacidade de recuperação. Quem pode declarar rollback? Defina papéis: responsável pelo deploy; pessoa de plantão; owner da aplicação; owner do banco; comunicação; aprovação quando necessária. Durante impacto crítico, exigir uma cadeia longa de aprovações pode atrasar recuperação. Uma política pode autorizar o operador de plantão a reverter para a última versão conhecida quando critérios objetivos forem atingidos. Depois, a decisão é revisada. O runbook de rollback Um runbook precisa ser executável por outra pessoa, não apenas por quem o escreveu. Depois do retorno, valide o serviço Rollback bem sucedido no pipeline não significa recuperação. Verifique: Técnica processos ativos; healthchecks; conexões; filas; consumo; erros. Funcional login; consulta; criação; pagamento; envio; tarefa principal. Dados consistência; duplicidade; perda; backfill; transações pendentes. Experiência taxa de sucesso; latência; abandono; contatos de suporte. A observabilidade fornece a evidência de recuperação. Teste o rollback sem esperar o incidente Em homologação: 1. publique versão A; 2. crie dados; 3. publique versão B; 4. execute migração; 5. crie mais dados; 6. retorne para A; 7. valide leitura e escrita; 8. promova B novamente. Teste também: configuração anterior; mensagem produzida pela versão nova; cache; sessão; jobs; backup; permissão. A separação de ambientes deve permitir esse ensaio. Quando não fazer rollback Roll forward pode ser mais seguro quando: a correção é pequena e conhecida; banco já mudou de forma incompatível; retorno perderia dados; artefato anterior possui vulnerabilidade crítica; operação antiga depende de serviço indisponível; rollback demoraria mais. A decisão não deve proteger o orgulho do deploy. Deve minimizar impacto e risco. Critério de prontidão Antes de liberar uma mudança, a equipe precisa saber: qual versão voltará; onde está o artefato; como o tráfego será movido; se o banco permanece compatível; quais mensagens já poderão existir; qual configuração será restaurada; quais dados podem ser perdidos; quem autoriza; como confirmar a recuperação. Um rollback seguro é preparado quando tudo ainda está funcionando. Quando a falha começa, o trabalho deveria ser executar uma decisão conhecida — não descobrir, sob pressão, o que “voltar” significa.