Estava falando com o claude sobre canary essa semana, vou deixar uns trechos da conversa que ajudam a entender o canary:
(Sim, é uma cópia de IA, leia se quiser, o texto está bom)
Canary é, no fundo, um rolling com um cérebro analítico em cima — e essa única diferença reorganiza tudo. Onde o rolling avança baseado só em "a réplica está saudável?", o canary avança baseado em "as métricas da versão nova estão tão boas quanto as da antiga, sob tráfego real?".
Rolling assume que saúde = correção. Canary não confia nisso — ele mede o comportamento real antes de comprometer. É essa desconfiança institucionalizada que custa caro em infra e devolve em segurança.
Canary não impõe exigências só na aplicação; impõe na sua plataforma de observabilidade e roteamento. Faltando qualquer um destes, você tem "canary no nome" — que é pior que rolling honesto, porque dá falsa sensação de segurança.
Observabilidade com métricas etiquetadas por versão. Inegociável. Você tem que conseguir comparar "erro da v2" contra "erro da v1" lado a lado. Isso exige que toda métrica carregue um label de versão (version=v2) e que você tenha o baseline pra comparar. Sem isso, o canary está cego — você roteou 5% e não tem como saber se aquilo está bem ou mal.
Critérios de sucesso definidos (SLOs). Antes de começar você precisa saber o que torna um canary "bom". Tipicamente um conjunto: taxa de erro (5xx), latência em percentis (p95/p99, não média — média esconde cauda), saturação (CPU/memória), e — o mais esquecido — métricas de negócio (taxa de checkout concluído, conversão, sucesso de pagamento). Um bug que não levanta erro HTTP mas derruba a conversão só é pego por métrica de negócio.
Volume de tráfego suficiente. Canary é estatística. 5% de um serviço com pouco tráfego = poucos requests = ruído demais pra concluir qualquer coisa. Se a v2 atende 12 requests em 10 minutos, "0 erros" não significa nada. Serviços de baixo volume são péssimos candidatos a canary — não há significância estatística pra extrair sinal.
Os detalhes profundos que quebram na prática
Comparação de métricas é estatisticamente traiçoeira. Com pouco tráfego no canary, ruído vira "sinal": um pico aleatório de latência em 8 requests dispara um falso negativo e aborta um deploy bom; ou erros raros não aparecem na amostra pequena e um deploy ruim passa (falso positivo de saúde). Canary honesto exige amostra grande o bastante pra significância — o que reforça o requisito de volume.
O baseline injusto — o erro mais sutil e mais comum. A tentação é comparar o canary (réplicas novas, frias: pool de conexão vazio, JIT não aquecido, cache local zerado) contra a v1 estável que roda há dias, quentinha. Quase toda diferença que você vê aí é de temperatura, não de código — e o canary aborta por um problema que não existe. A correção idiomática (que o Kayenta do Spinnaker faz por padrão): suba também uma cópia nova da v1 — o "baseline" — e compare canary novo contra baseline novo, ambos igualmente frios. Aí a diferença restante é de código, que é o que você quer medir.
Escolher as métricas erradas = canary que aprova o desastre. Se você só monitora taxa de erro 5xx, um bug que retorna 200 OK com o preço errado da joia, ou que derruba a conversão do checkout, passa limpo pelo gate. Canary só é tão bom quanto as métricas que você escolheu — precisa cobrir sistema (erro, latência, saturação) e negócio (a métrica que de fato importa pro Ourivus: pedido concluído, pagamento aprovado).
Acredito que o mais importante aqui são as métricas de negócio.
Como o autor disse:
Canary direciona uma fração pequena do tráfego (1%, 5%, 10%) para a versão nova. Métricas de erro, latência e saturação são observadas
Isso é um "rolling chamado de canary"
olhar apenas tráfego e taxa de sucesso não tem nenhuma inteligência
Canary tem que olhar conversão, saúde do negócio, não apenas taxa de erro de requests