Tempo de rollback é o intervalo entre "algo parece errado" e "os usuários voltaram para a versão que funcionava". Este passo a passo usa um time inventado para mostrar para onde vai esse tempo quando reverter significa fazer redeploy, o que muda quando o release fica atrás de um rollout com guardrail, e como medir a diferença no seu próprio sistema.
Antes: reverter significa redeploy
Imagine um time que entrega releases de checkout sem rollout com guardrail: sobe para 100%, observa os painéis e, se algo parece errado, começa um rollback manual. Sem um release baseado em flag, esse rollback é um redeploy completo da imagem anterior, não o clique num interruptor.
A maior parte do tempo nesse caminho é mecânica, não tempo de decisão:
- alguém precisa perceber o problema, muitas vezes por um chamado de suporte ou um painel;
- o engenheiro certo precisa ser acionado e confirmar o diagnóstico;
- o pipeline de deploy precisa gerar ou buscar a versão anterior e colocá-la no ar.
Cada um desses passos acontece enquanto o release ruim atende todo o tráfego de checkout.
Depois: rollout em estágios com guardrail
Agora o mesmo time coloca o novo comportamento do checkout atrás de uma feature flag e libera com um rollout em estágios, por exemplo 5%, 25%, 50% e depois 100% do tráfego, com um guardrail de latência p95 no endpoint de checkout.
Duas coisas mudam:
- A detecção é automática. O rollfuse avalia o guardrail periodicamente contra a média da métrica na janela de avaliação. Ninguém precisa reparar num painel antes.
- Reverter é uma mudança de configuração, não um deploy. Quando o limite do guardrail é ultrapassado, o rollfuse aborta o rollout pelo mesmo caminho do abort manual, e a flag volta a servir a variação padrão para todo mundo naquele ambiente. O código antigo continua no binário em execução, então nenhum pipeline precisa rodar.
O rollout para no estágio em que estiver. Se a regressão ultrapassar o limite enquanto o rollout está em 5%, os outros 95% do tráfego nunca a veem.
A troca
Chegar a 100% demora mais no caso normal, porque o rollout passa pelos estágios em vez de ir direto para o ar. É uma objeção justa: você troca um dia bom um pouco mais lento por um dia ruim mais curto e menor.
O guardrail também só protege o que ele observa. Um guardrail de p95 pode ficar quieto enquanto o p99 piora, como mostra este quase-acidente ilustrativo. E o plantão, os painéis e o pipeline de deploy continuam no lugar: o rollout com guardrail fica em cima do processo de release, não o substitui.
Como medir no seu próprio time
Não temos números de clientes para mostrar, então o jeito honesto de saber quanto isso vale para você é medir. Acompanhe estes pontos em alguns releases antes e depois:
- Tempo até detectar: do início da regressão até algo reagir (uma pessoa ou um guardrail).
- Tempo até reverter: da detecção até os usuários voltarem ao comportamento que funcionava.
- Exposição na reversão: que fatia do tráfego estava na versão ruim quando ela foi revertida.
O rollfuse registra cada avaliação de guardrail com o horário, o valor da métrica, o limite e a ação tomada, o que dá os horários do lado "depois". O tutorial de rollback automático com guardrail mostra como configurar e ler esse histórico, e guardrails de deploy aprofunda a ideia.