Rollback e mitigação de incidentes

O problema

Tem release que da errado e o time reage com uma unica palavra:

rollback

As vezes funciona.

As vezes não.

E o erro esta em achar que rollback e a resposta universal para qualquer incidente ligado a deploy.

Na prática, existe uma pergunta que vem antes:

qual ação contem dano mais rápido agora?

Voltar versão pode ser uma delas.

Mas não e a unica.

Modelo mental

Rollback e uma tentativa de retornar para uma versão ou comportamento anterior.

Mitigação e qualquer ação que reduza o impacto do incidente rapidamente.

Isso pode incluir:

• rollback de versão
• desligar flag
• cortar tráfego
• desligar integração secundaria
• servir degradado
• abrir circuito

Ou seja:

rollback e uma ferramenta de mitigação, mas mitigação boa não depende só dele.

Quebrando o problema

Quando rollback ajuda muito

Rollback costuma funcionar bem quando:

• o problema veio claramente da release
• a versão anterior ainda e compativel
• não houve mudança de estado irreversivel
• a estratégia de deploy facilita voltar

Nesses casos, voltar reduz dano rápido.

Quando rollback não basta

Existem casos em que a versão anterior não resolve sozinha:

• migration já alterou schema ou dado
• evento ruim já foi publicado
• fila acumulou trabalho inconsistente
• fornecedor externo mudou comportamento

Aqui, voltar código pode ajudar um pouco, mas o dano já se espalhou por outras partes.

Por isso mitigação precisa ser mais ampla que rollback.

Mitigação forte pensa em contencao

Em incidente real, mitigação boa costuma perguntar:

• como diminuir o alcance agora?
• o que da para desligar sem derrubar tudo?
• o que precisa degradar para proteger o fluxo principal?

Exemplos:

• desligar funcionalidade não essencial por flag
• reduzir percentual do canary
• voltar tráfego para ambiente anterior
• bloquear escrita arriscada temporariamente
• responder com fallback mais simples

Rollback sem preparo vira teatro

Se o time diz que faz rollback, mas na prática:

• não sabe qual versão estava ativa
• não sabe como voltar
• não confia na versão anterior
• depende de passos manuais opacos

entao rollback e mais aspiracao do que capacidade.

Exemplo simples

Imagine uma nova release do checkout.

Depois do deploy:

• erro sobe
• latência piora
• conversão cai

Possiveis respostas:

1. desativar novo fluxo por flag
2. reduzir tráfego da versão canary
3. voltar para ambiente blue-green anterior
4. se preciso, bloquear funcionalidade secundaria para proteger compra principal

Repare que o objetivo imediato não e “fazer a arquitetura ficar bonita”.

E baixar dano agora.

Depois vem a analise mais calma.

Erros comuns

• Tratar rollback como resposta unica para tudo.
• Ignorar que dado e schema também entram na conta.
• Não preparar mecanismo claro para voltar ou desligar.
• Esperar demais para mitigar enquanto procura causa raiz perfeita.
• Confundir restaurar versão com restaurar estado.

Como um senior pensa

Quem tem mais experiência geralmente organiza a resposta assim:

1. conter impacto
2. estabilizar serviço
3. entender causa
4. corrigir e prevenir repetição

Esse raciocínio evita um erro comum em crise:

querer resolver elegantemente antes de reduzir dano.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver se você pensa operacionalmente sob pressao.

Você sobe de nivel quando:

• separa rollback de mitigação
• menciona flag, tráfego e degradação como opcoes
• reconhece limite de rollback em caso de estado alterado
• mostra prioridade em contencao de dano

Uma resposta forte costuma soar assim:

“Se a release piorou o sistema, minha primeira pergunta e qual ação reduz impacto agora. Pode ser rollback, pode ser desligar flag, pode ser voltar tráfego ou degradar funcionalidade. Depois eu investigo a causa com mais calma.”

Em incidente, elegancia vem depois. Primeiro vem reduzir o tamanho do estrago.