Um guardrail de deploy é uma regra que observa uma métrica durante um rollout e aborta automaticamente se essa métrica cruza um limite, ninguém precisa estar olhando um painel quando a regressão acontece, e a reversão não espera um humano perceber, ser acionado e apertar o botão manualmente.
As três partes de um guardrail
Todo guardrail tem o mesmo formato não importa o que esteja observando: uma métrica (os valores chegam ao rollfuse como observações, enviadas pela API ou puxadas por um conector de uma fonte HTTPS, como a API de consulta do Prometheus; veja como monitorar um rollout progressivo especificamente pra conexão com Prometheus), um limite e uma comparação que dizem quando a métrica está em violação (latência p95 acima de 400ms, taxa de erro acima de 1%, uma métrica de negócio abaixo de um piso), e uma janela de avaliação (o trecho de observações recentes cuja média é calculada a cada checagem, então um único ponto de dado ruidoso é diluído em vez de disparar o rollback sozinho).
Quando a média da janela passa do limite, o guardrail aborta o rollout: a flag volta a servir a variação padrão para 100% do ambiente, e o rollout para de avançar pro próximo estágio. Esse é o mecanismo inteiro, a complexidade que importa está em escolher a métrica e o limite certos, não na lógica de abort em si.
Reutilizável, não algo pontual
Uma política de guardrail é definida uma vez como um template e anexada a qualquer rollout que precisar dela, em vez de escrita à mão pra cada rollout. É isso que transforma "alguém lembrou de configurar o guardrail de p95 do jeito certo" em "todo rollout instala o mesmo guardrail de p95 revisado num passo só". Instalar um template continua sendo uma ação explícita em cada rollout; o rollfuse não anexa sozinho. Templates de Guardrail cobre como definir um limite uma vez e reutilizá-lo em todo rollout que precisar.
O que "automático" realmente evita
O modo de falha que um guardrail existe pra fechar não é "ninguém estava olhando" no sentido literal, a maioria dos times de fato observa rollouts importantes. É o intervalo entre uma regressão acontecer e um humano decidir agir sobre ela: o tempo que alguém gasta percebendo um alerta, contextualizando ele contra um rollout em andamento, e decidindo que reverter é a decisão certa, tudo isso enquanto o tráfego continua avançando pro próximo estágio. Com que frequência um guardrail deve abortar um rollout? mostra como ler a sua própria taxa de abort e calibrar um limite que fecha esse intervalo sem disparar por ruído.
Guardrails não substituem o julgamento sobre em qual métrica confiar
Um guardrail só é tão bom quanto a métrica que observa. Uma métrica agregada pela frota inteira, diluída pelo tráfego ainda na versão antiga, pode esconder uma regressão de estágio que uma métrica bem escopada pegaria de imediato, e uma métrica que parece boa no p95 ainda pode estar escondendo um problema real de p99 embaixo dela. Anatomia de um Quase-Desastre de Guardrail: Quando o p95 Esconde um Problema de p99 é um caso concreto onde exatamente isso aconteceu, e o que mudou depois.
Anexando um
POST /v1/rollouts/{rollout_id}/guardrails
{
"metric_definition_id": "<id da definição de métrica de latência p95>",
"comparison_operator": "gt",
"threshold": 0.4,
"evaluation_window_seconds": 300
}
Esse guardrail é violado quando a média das observações de latência p95 (em segundos) dos últimos 300 segundos passa de 0,4. Os valores chegam ao rollfuse como observações, do jeito descrito acima. O guardrail é avaliado periodicamente enquanto o rollout está ativo ou pausado, não uma vez por estágio. Veja Conduzindo um Rollout Progressivo a Partir de um Serviço Go pra ver conectado a um deploy real.