Exemplo hipotético: este cenário foi inventado para mostrar o método. Ele não descreve um cliente do rollfuse, uma medição interna nem um incidente real.
Um guardrail de rollout configurado pra abortar em p95 de latência vai fazer exatamente o que foi mandado: observar o meio-da-distribuição e ficar quieto enquanto esse meio estiver saudável. Num gateway de pagamento com múltiplos emissores, lógica de retry e checagem antifraude no caminho, é na cauda que as coisas realmente quebram, e o p95 não enxerga a cauda.
O formato da falha
LINHA DO TEMPO HIPOTÉTICA
O guardrail não estava mal configurado de nenhuma forma óbvia. Estava calibrado, testado, com histórico de disparar corretamente em rollouts anteriores. Só não estava observando a métrica onde essa classe específica de regressão aparece. O p95 ficou dentro do limite durante toda a janela.
Por que só o p95 não basta aqui
A maioria dos times configura o guardrail de latência padrão em p95 porque é a escolha padrão: captura degradação ampla sem reagir a outliers isolados. Esse padrão é razoável pra um serviço com grafo de dependências homogêneo. É insuficiente pra um serviço como um gateway de pagamento, onde a cauda especificamente, retries contra um emissor lento, uma checagem antifraude que às vezes dá timeout, pode representar uma fatia desproporcionalmente relevante do tráfego, mesmo num percentual pequeno.
A CORREÇÃO
Um rollout num serviço com dependência externa heterogênea deveria carregar dois guardrails de latência, não um: um referenciando uma métrica de p95, outro de p99. O rollfuse não calcula percentis: cada guardrail compara a média das observações da janela com o limite, então os valores de p95 e p99 precisam chegar já calculados pela sua fonte de métrica. Qualquer um dos dois disparando aborta o rollout de forma independente, sem que uma métrica precise "concordar" com a outra antes do rollout parar.
Por que a detecção manual chegou primeiro
Na linha do tempo acima, sete minutos separam a violação de p99 do primeiro alerta, e esse alerta veio de uma pessoa, não do sistema. Isso é o oposto do que um guardrail deveria entregar: o ponto inteiro é pegar uma regressão antes do cliente perceber, não depois. Vale auditar seus próprios guardrails especificamente atrás dessa lacuna: qualquer guardrail de latência configurado só em p95, num serviço onde a cauda importa, carrega o mesmo ponto cego.