Revertendo um Deploy Quando a Taxa de Erro Aumenta

Taxa de erro é a métrica mais comum por trás de um rollback automático, e com razão: é diretamente observável, é o mesmo sinal pra quase todo serviço, e um pico quase sempre significa alguma coisa. Também é a métrica de guardrail mais frequentemente configurada errado.

O que "taxa de erro" precisa significar de fato

"Taxa de erro" não se define sozinha. Antes de poder embasar um guardrail, três coisas precisam ser decididas explicitamente:

• O que conta como erro. Só HTTP 5xx, ou 4xx também? Um timeout sem resposta nenhuma? Uma requisição que foi retentada e acabou dando certo? Cada resposta muda o que a métrica realmente mede.
• Taxa de quê. Erros sobre total de requisições (uma razão, tipo de agregação average ou rate dependendo de como é calculado antes) se comporta de forma bem diferente sob carga do que erros por segundo (count/sum). A primeira é estável independente do volume de tráfego, a segunda não é.
• Sobre qual janela. Uma janela de 30 segundos reage rápido e dá falso positivo em ruído comum. Uma janela de 15 minutos é estável mas lenta pra pegar uma regressão brusca. Não tem número universalmente correto. Depende de quanta exposição você está disposta a tolerar antes do guardrail conseguir sequer enxergar o problema.

Configurando o limite

O erro mais comum dos times: configurar o limite em "zero erros". Todo serviço real tem uma taxa de erro de base: timeouts retentados, requisições malformadas de cliente, instabilidade de upstream que não tem nada a ver com o rollout atual. Um limite configurado no piso do ruído dispara o tempo todo, e um guardrail que dispara o tempo todo tem a janela de avaliação alargada, depois o limite afrouxado, e eventualmente é desativado. É o oposto do que você queria. Configure o limite contra a própria linha de base histórica do serviço, com margem, não contra um zero idealizado.

O que "automático" exige de fato aqui

Um guardrail referenciando uma definição de métrica de taxa de erro, com operador de comparação e limite:

POST /v1/rollouts/{rollout_id}/guardrails
{
  "metric_definition_id": "<metrica-taxa-de-erro>",
  "comparison_operator": "gt",
  "threshold": 0.02,
  "evaluation_window_seconds": 300
}

Quando o valor agregado viola o threshold dentro dessa janela, o rollout aborta pelo mesmo caminho que uma ação manual de operador usaria. A flag naquele ambiente volta a servir a variação padrão para 100% do tráfego, sem as regras do rollout, e a avaliação que disparou isso (o valor da métrica, o limite, um id de correlação) fica registrada, então o rollback é explicável depois, em vez de algo que alguém precisa reconstruir de memória.

O cenário que isso realmente protege

A regressão que mais importa aqui não é a que aparece num painel que alguém está encarando. É a que acontece entre dois check-ins, num estágio de rollout que ninguém estava observando em tempo real. É nesse caso que guardrails de taxa de erro se pagam: não evitando todo deploy ruim, mas transformando os que chegariam a 100% sem ninguém perceber em rollouts que pararam em 5% ou 25%, automaticamente, com um registro exato do porquê.