Playbook de exercício de rollback: restaure uma release quebrada em 5 minutos

Por que rollbacks parecem assustadores (e por que praticar ajuda)

Uma release pode parecer ok nos testes e quebrar nos primeiros cinco minutos de tráfego real. A parte assustadora geralmente não é o bug. É a incerteza: o que mudou, o que você pode desfazer com segurança e se um rollback pode piorar as coisas.

Logo após uma release, as falhas costumam ser simples e dolorosamente visíveis. Um botão novo pode travar a página no mobile. Uma mudança no backend pode retornar um formato de dado errado e impedir o checkout. Um pequeno ajuste de configuração pode quebrar login, e-mails ou pagamentos. Mesmo quando a correção é fácil, a pressão aumenta porque os usuários estão vendo e cada minuto parece caro.

O pânico começa quando o caminho de rollback não está claro. As pessoas fazem as mesmas perguntas ao mesmo tempo: Temos um snapshot? Qual versão foi a última boa? Se revertermos o app, e o banco? Quem tem acesso para fazer isso? Quando essas respostas não estão escritas, o time perde tempo debatendo em vez de restaurar o serviço.

Chutar durante um incidente tem custo real. Você perde tempo, usuários perdem confiança e mudanças apressadas podem causar um segundo incidente por cima do primeiro. Engenheiros também são puxados em muitas direções: debugar, comunicar e tomar decisões.

Um ensaio muda o clima porque substitui incerteza por memória muscular. Um bom rollback drill não é só “conseguimos reverter código”. É uma rotina repetível: o que você snapshota, o que restaura, o que verifica e quem tem autorização para agir. Após alguns exercícios, rollback para de parecer uma falha e vira uma ferramenta de segurança.

Se seu fluxo de deploy já suporta snapshots e restauração (algumas plataformas, incluindo Koder.ai, integram isso no fluxo de release), os exercícios ficam mais fáceis porque “voltar para o conhecido bom” é uma ação normal, não um procedimento de emergência. De qualquer forma, o objetivo é o mesmo: quando o momento chegar, ninguém deve improvisar.

O que “restaurar em 5 minutos” realmente significa

“Restaurar em 5 minutos” não quer dizer que tudo volta perfeito. Quer dizer que você consegue colocar os usuários novamente em uma versão funcional rapidamente, mesmo que a release nova ainda esteja com problema.

Serviço primeiro, correção depois. Se você consegue restaurar o serviço rápido, ganha tempo tranquilo para achar o bug real.

Os 5 minutos são para ação, não debate

O cronômetro começa quando você concorda: “Estamos revertendo.” Não inclui uma longa discussão sobre se as coisas podem se recuperar sozinhas.

Decida seu gatilho de rollback com antecedência. Por exemplo: “Se erros no checkout ficarem acima de X% por 3 minutos após o deploy, fazemos rollback.” Quando o gatilho disparar, siga o script.

O que conta como “restaurado”

“Restaurado” deve ser um pequeno conjunto de sinais que dizem que os usuários estão seguros e o sistema está estável. Mantenha simples e fácil de checar:

• A ação chave do usuário funciona de novo (login, checkout, busca, ou a coisa que seu app precisa fazer)
• Taxa de erro volta perto do normal
• Latência volta a um patamar aceitável
• Não há loop de crash ou tempestade de reinícios

Quando esses sinais estiverem bons, pare o cronômetro de 5 minutos. Todo o resto pode esperar.

Para manter o exercício honesto, marque explicitamente o que você NÃO fará durante o caminho de 5 minutos: debugging profundo, mudanças de código ou hotfixes, e qualquer coisa que vire trabalho de engenharia.

Escolha uma abordagem de rollback que seu time consiga repetir

Um rollback só parece rápido quando a decisão já está em grande parte pré-feita. Escolha uma abordagem que funcione para a maioria dos incidentes e pratique até ficar chata.

Seu exercício deve responder quatro perguntas:

• Vamos reverter ou aplicar um hotfix?
• Para o que vamos reverter?
• O que aciona o rollback?
• Quem tem autoridade para dizer “vai”?

Rollback vs hotfix: escolha um padrão

Rollback é melhor quando a nova release está prejudicando usuários ou dados, e você já tem uma versão conhecida como boa para voltar. Hotfix é melhor quando o impacto é pequeno, a mudança é isolada e você confia que pode corrigir com segurança.

Um padrão simples funciona bem: se os usuários não conseguem completar a ação principal (checkout, login, cadastro) ou as taxas de erro disparam, faça rollback primeiro e corrija depois. Reserve hotfixes para problemas incômodos mas não perigosos.

Escolha o alvo do rollback

Seu “alvo” deve ser algo que o time possa selecionar rapidamente, sem debate. A maioria das equipes usa três alvos comuns:

• A versão anterior (última release que passou nas checagens)
• Um snapshot de deployment que você pode restaurar
• Um rollback só de configuração (feature flag ou mudança de ambiente)

Se você tem snapshots de deployment confiáveis, faça disso o padrão porque é o mais repetível sob pressão. Mantenha o rollback só de config como caminho separado para casos onde o código está ok, mas uma configuração está errada.

Também defina o que conta como “anterior bom.” Deve ser a release mais recente que completou as checagens de monitoramento e não tinha incidente ativo — não “a que as pessoas lembram”.

Defina gatilho e autoridade

Não espere por reunião durante um incidente. Escreva os gatilhos que iniciam um rollback e obedeça a eles. Gatilhos típicos incluem fluxo principal quebrado por mais de alguns minutos, taxa de erro ou latência ultrapassando limites acordados, risco de gravações erradas (cobranças duplicadas), e qualquer preocupação de segurança/privacidade introduzida pela release.

Depois decida quem pode aprovar o rollback. Escolha um papel (incident lead ou on-call), mais um backup. Todos os outros podem aconselhar, mas não bloquear. Quando o gatilho bater e o aprovador disser “rollback”, o time executa os mesmos passos sempre.

O que snapshotar antes de cada release

Um rollback drill só funciona se você consegue voltar a um estado conhecido com rapidez. Snapshots não são apenas “legais de ter”. São os recibos que provam o que estava rodando, o que mudou e como voltar.

As cinco coisas para capturar

Antes de cada release, certifique-se de poder pegar estes itens sem vasculhar chats:

• O build exato que você enviou: hash do commit, número da versão e o artefato do build (tag do container, bundle ou pacote).
• Estado do banco e plano de migrations: quais migrations foram aplicadas e se são reversíveis. Para mudanças arriscadas, faça um backup ou snapshot restaurável rapidamente.
• Configuração no momento do deploy: feature flags, variáveis de ambiente, endpoints de terceiros e o que mudou. Segredos devem ficar em um sistema seguro, mas você precisa de um registro versionado das mudanças.
• Infraestrutura e configurações de roteamento: domínios, certificados, regras de load balancer e quaisquer chaves de “para onde vai o tráfego”.
• Uma nota curta de release: uma sentença sobre o que mudou e uma sentença sobre como verificar um rollback bem-sucedido.

Segurança do banco é a armadilha usual. Um rollback rápido de app não ajuda se o banco agora espera o novo schema. Para migrations arriscadas, planeje um release em duas etapas (adicionar campos primeiro, começar a usá-los depois) para que o rollback continue possível.

Nomeie snapshots para achar em segundos

Use uma regra de nome única em todo lugar e faça-a ordenável:

prod-2026-01-09-1420-v1.8.3-commitA1B2C3

Inclua ambiente, timestamp, versão e commit. Se suas ferramentas suportam snapshots em UI, use a mesma regra lá para que qualquer pessoa encontre o ponto de restauração certo durante um incidente.

Papéis: quem clica o quê (e quem só observa)

Um rollback drill é mais rápido e calmo quando cada um sabe sua faixa. O objetivo não é “todo mundo entra”. É uma pessoa tomando decisões, uma pessoa executando a ação, uma pessoa confirmando que funcionou e uma pessoa informando os outros.

Para times pequenos e médios, estes papéis funcionam bem (uma pessoa pode cobrir dois papéis se necessário, mas evite combinar Deployer e Verifier durante o exercício):

• Incident lead (cronometrista e decisor): declara a meta de sucesso e chama o rollback.
• Deployer (mãos no teclado): executa os passos de rollback exatamente como escrito e narra o que faz.
• Verifier (prova de que funcionou): roda as checagens obrigatórias e observa os sinais principais.
• Communicator (uma voz externa): publica atualizações curtas e regulares para stakeholders e suporte.

As permissões decidem se o plano é real ou só um documento bonito. Antes do drill, concorde quem pode reverter produção e como funcionam as emergências.

Uma configuração simples:

• Dê ao Deployer direitos de rollback durante a rotação de on-call ou janelas agendadas de drill.
• Deixe o Incident lead aprovar a ação (mesmo que não tenha o botão).
• Garanta que o Verifier tenha acesso de leitura a dashboards e logs.
• Configure uma opção break-glass (acesso auditado e por tempo limitado).
• Teste os acessos durante o setup do drill, não durante o cronômetro de 5 minutos.

Se você usa uma plataforma que suporta snapshots e rollback (incluindo Koder.ai), decida quem pode criar snapshots, quem pode restaurá-los e onde essa ação é registrada.

Passo a passo: runbook do exercício de rollback

Um rollback drill funciona melhor quando parece um exercício de incêndio: mesmos passos, mesmas palavras, mesmos lugares para clicar. O objetivo não é perfeição. É que qualquer pessoa de plantão consiga restaurar a última versão conhecida como boa rapidamente, sem debater opções.

Antes de começar

Escolha um gatilho claro e diga em voz alta quando o exercício começar. Exemplos: “Checkout retorna 500 por mais de 1 minuto” ou “Taxa de erro 5x o normal logo após o deploy.” Dizer em voz alta evita que o time deslize para modo de troubleshooting.

Mantenha um checklist curto ao lado do runbook:

• Confirme que você vê sinais de saúde ao vivo (uptime, taxa de erro, fluxo chave)
• Confirme o identificador da última versão conhecida como boa (tag, build, nome do snapshot)
• Confirme onde os rollbacks são executados (CI/CD, console de hosting, UI da plataforma)
• Confirme como pausar novos deploys
• Confirme quem registra os timestamps

O runbook de 5 minutos

1. Inicie o cronômetro. Uma pessoa declara o gatilho e a decisão: “Estamos revertendo agora.”

2. Congele mudanças. Pause novos deploys e pare edições não essenciais que possam alterar o sistema no meio do rollback.

3. Tire um snapshot de última chance (se for seguro e rápido). É proteção caso precise recriar o estado quebrado depois. Nomeie claramente e siga em frente.

4. Execute a ação de rollback exatamente como documentado. Não improvise. Leia os prompts de confirmação em voz alta para que o registrador capture o que aconteceu.

5. Confirme que o rollback foi concluído em um lugar confiável. Use uma tela e um sinal únicos sempre (histórico de deploys, rótulo “versão atual” ou um indicador de status claro).

Logo após a ação, capture o que importa enquanto está fresco:

• Hora da decisão (gatilho declarado)
• Hora de início do rollback (primeiro clique/comando)
• Hora de conclusão do rollback (versão anterior ativa)
• Primeira verificação verde (checagem chave passa)
• Surpresas (permissão faltando, botão confuso, passo lento)

Se o rollback levar mais de 5 minutos, não justifique. Encontre o passo lento, corrija o runbook e rode o exercício de novo.

O que verificar após o rollback

Um rollback “funcionou” apenas quando os usuários percebem que funcionou. Você não está tentando provar que a versão antiga foi implantada; está provando que o serviço voltou a ser utilizável e estável.

Mantenha a verificação pequena e repetível. Se a lista tiver mais de cinco itens, as pessoas vão pular sob estresse.

As 3–5 checagens obrigatórias

Use checagens rápidas, com pass/fail claro:

• Usuário pode logar (ou se cadastrar) e chegar à tela inicial sem erros
• A transação principal funciona (checkout, reserva, envio de formulário)
• Um endpoint de API chave retorna 200 e a resposta parece normal
• Admin/suporte consegue fazer uma ação crítica (reembolso, cancelamento, atualizar status)
• Um fluxo de borda que costuma quebrar (reset de senha, upload de arquivo, busca) ainda funciona

Depois das checagens funcionais, dê uma olhada no sinal de saúde mais simples que você confia. Você quer ver a taxa de erro cair e a latência parar de disparar em alguns minutos.

Confirme também que as partes menos visíveis estão funcionando de novo. Jobs em background devem processar e filas devem drenar, não crescer. Checagens rápidas do banco: conexões estáveis, sem bloqueios óbvios, e o app consegue escrever.

Por fim, teste o mundo externo onde importa. Se puder fazer com segurança, rode um teste de pagamento, confirme entrega de e-mail e verifique que webhooks estão sendo aceitos (ou pelo menos não falhando).

Decida a frase de “tudo certo”

Escreva uma frase para ninguém improvisar:

“Rollback completo. Fluxos centrais verificados (login + checkout). Taxa de erro e latência de volta ao normal. Monitorando por 30 minutos. Próxima atualização às 14:30.”

Exemplo: uma release quebrada e uma restauração limpa em 5 minutos

São 10:02 numa terça. Uma nova release vai ao ar e, em um minuto, uma parcela de usuários não consegue logar. Alguns recebem “sessão inválida”, outros veem um spinner que nunca termina. Cadastros ainda funcionam, então o problema é fácil de passar despercebido no começo.

O primeiro sinal normalmente não é um apagão dramático. É um pico silencioso: tickets de suporte, queda em logins bem-sucedidos e algumas mensagens raivosas de usuários reais. On-call vê um alerta “taxa de sucesso de login caiu 18% em 5 minutos” e suporte posta: “3 usuários não conseguem logar após a atualização.”

A restauração de 5 minutos (como pode ser)

Como o time praticou, eles não debatem muito. Confirmam, decidem e agem.

• 10:03: On-call confirma e designa um incident lead.
• 10:04: Decisão por rollback. Regra: se login está quebrado e não há correção segura em 2 minutos, revertamos.
• 10:05: Deployer aciona rollback para o snapshot conhecido como bom.
• 10:06: Tráfego volta para a versão anterior. Time retesta login na web e mobile.
• 10:07: Incident lead posta “Login restaurado, monitorando por 10 minutos” e pede para suporte responder aos usuários afetados.

O que é revertido: código da aplicação e config para os serviços web e API. O que fica: banco de dados e dados de usuário.

Se a release incluiu uma migration de banco, a regra do exercício é simples: nunca reverta o banco no caminho de 5 minutos. Mantenha migrations compatíveis com versões anteriores ou pause e peça uma segunda opinião antes de deployar.

O que é comunicado (durante e depois)

Durante o rollback, o incident lead publica atualizações curtas a cada poucos minutos: o que os usuários veem, qual ação está em curso e quando a próxima atualização sai. Exemplo: “Estamos revertendo a última release para restaurar login. Próxima atualização em 2 minutos.”

Depois do rollback, fecham o ciclo: “Login está normal. Revisão de causa raiz em andamento. Vamos compartilhar o ocorrido e o que mudamos para evitar repetição.”

Erros comuns em exercícios de rollback (e soluções simples)

Um bom drill deve parecer chato. Se parece estressante, o exercício provavelmente revela lacunas reais: acesso, snapshots faltando ou passos que só existem na cabeça de alguém.

Erros que desperdiçam minutos

• Você pratica assumindo acessos, não com permissões reais. Pessoas descobrem no meio do incidente que não conseguem fazer deploy, mudar configuração ou acessar dashboards. Correção: rode o exercício com as mesmas contas e papéis que usaria no incidente.

• Snapshots existem, mas são incompletos ou difíceis de achar. Equipes snapshotam o app e esquecem mudanças de env, feature flags ou roteamento. Ou o nome do snapshot não diz nada. Correção: torne a criação de snapshot parte do passo de release com regra de nomeação e verifique durante drills que o snapshot é visível e restaurável rápido.

• Migrations de banco tornam rollback inseguro. Uma mudança de schema incompatível transforma um rollback rápido em problema de dados. Correção: prefira migrations aditivas. Se uma mudança quebradora for inevitável, planeje uma correção para frente e marque claramente a release: “rollback permitido: sim/não.”

• Você declara sucesso antes de checar o que os usuários sentem. O app parece ter sido revertido, mas login continua quebrado ou jobs estão presos. Correção: mantenha a verificação curta, real e com timebox.

• O exercício é complexo demais para repetir. Ferramentas demais, checagens demais, vozes demais. Correção: reduza o exercício a uma página e um dono. Se não der para fazer a partir de um único runbook e um canal de comunicação, não vai acontecer sob pressão.

Um bom rollback drill é hábito, não performance heróica. Se você não consegue terminar com calma, elimine passos até conseguir e só adicione o que realmente reduz risco.

Checklist rápido e próximos passos

Um rollback drill funciona melhor quando todos seguem o mesmo checklist de uma página. Mantenha-o fixado onde o time realmente olha.

Uma versão compacta que você pode rodar em menos de 10 minutos (incluindo setup e verificação):

• Antes do release: confirme o ponto de rollback (snapshot/versão), registre o comportamento esperado, atribua papéis (deployer, verifier, comms).
• Gatilho: declare “rollback iniciando”, ligue o cronômetro, congele novos deploys.
• Ação de rollback: restaure a última release conhecida como boa, capture o que foi clicado e em que ordem.
• Verifique: rode 2–3 checagens críticas (login, fluxo principal, uma integração ou checagem de API), confirme queda nas taxas de erro.
• Feche: declare “serviço estável”, escreva três notas (o que funcionou, o que atrasou, o que mudar), descongele deploys.

Rode exercícios com frequência suficiente para que os passos pareçam normais. Mensal é um bom padrão. Se seu produto muda diariamente, faça a cada duas semanas, mas mantenha a verificação focada no principal caminho do usuário.

Depois de cada drill, atualize o runbook no mesmo dia enquanto está fresco. Armazene com as notas de release e adicione uma linha datada “último testado” para ninguém confiar em um procedimento obsoleto.

Meça apenas o que ajuda a melhorar:

• Tempo para rollback (declaração até restauração)
• Tempo para verificação (restaurado até estável)
• Clareza de papéis (onde houve hesitação ou duplicação de trabalho?)
• Informações faltantes (credenciais, permissões, localização do snapshot)

Se seu time usa Koder.ai, trate snapshots e rollback como parte do hábito: nomeie snapshots consistentemente, ensaia restaurações na mesma interface que você usará on-call e inclua verificações rápidas de domínio customizado e integrações na etapa de verificação. Mencionar isso no runbook mantém o exercício alinhado com o jeito que você realmente entrega.