Rollback automático de deploy é um padrão de release em que um deploy ruim se reverte sozinho. Ninguém precisa perceber, decidir e agir. O sistema observa uma métrica real durante o rollout e, se ela cruza um limite definido, reverte o tráfego pro último estado saudável conhecido, por conta própria.
Parece simples. Na prática, três peças separadas precisam funcionar juntas pra isso acontecer de verdade, e a maioria dos setups de "rollback automático" está sem pelo menos uma delas.
As três peças que um rollback automático de verdade precisa
Uma métrica sendo observada de verdade, não só logada. Painel é pra gente olhar. Rollback automático exige algo avaliando essa métrica numa programação, independente de alguém estar olhando pra tela.
Um limite com uma janela de avaliação de verdade. Um único ponto ruim de dado não deveria disparar um rollback; isso é ruído, e um sistema que reage a ruído tem seus alertas ignorados dentro de um mês. O limite precisa ser checado contra uma janela (os guardrails do rollfuse usam um evaluation_window_seconds, avaliado de forma contínua), não uma leitura instantânea isolada.
Uma ação que reverte algo de verdade, automaticamente. É a parte que mais falta. Muita ferramenta alerta quando um limite é violado. Poucas agem sobre isso sem um humano no meio, e um rollback que exige alguém clicar "confirmar" enquanto está de plantão às 3 da manhã não é automático, é assistido.
O que "reverter" significa na prática
Num rollout em estágios, reverter não significa fazer redeploy do binário anterior. Isso é lento e é a camada errada. Significa reverter o split de tráfego: o rollout é abortado e a flag naquele ambiente volta a servir a variação padrão para 100% do tráfego. O código que causaria a regressão continua deployado; só não está mais exposto a ninguém. Essa é a diferença entre um rollback medido em minutos (pipeline de redeploy) e um medido em segundos (reversão de split de tráfego).
Onde isso quebra na prática
O modo de falha mais comum não é um guardrail ausente. É um guardrail configurado contra a métrica errada, ou com um limite frouxo demais pra disparar algum dia. Um guardrail que nunca é violado não é seguro, é decorativo. Se você está configurando um, seja honesto sobre o que acontece se a regressão desse rollout específico aparecer numa métrica que você não está observando: esse é o teste real de se "rollback automático" aqui significa algo ou é só uma caixinha marcada.
Como isso é de ponta a ponta
Um guardrail pertence a exatamente um rollout e referencia exatamente uma definição de métrica: um operador de comparação, um limite e uma janela de avaliação.
POST /v1/rollouts/{rollout_id}/guardrails
{
"metric_definition_id": "...",
"comparison_operator": "gt",
"threshold": 0.01,
"evaluation_window_seconds": 900
}
Toda avaliação é registrada como uma entrada própria de auditoria: o que a métrica leu, qual era o limite, e qual ação seguiu. Então "por que isso reverteu" é sempre respondível a partir do registro, não da memória de alguém sobre o que aconteceu.