Canary Deploys: lançando mudanças para uma parcela pequena dos usuários

O que são Canary deploys e a origem do nome

A metáfora da mineração aplicada ao software

O termo canary vem da prática de mineiros que levavam canários para detectar gases tóxicos nas minas — o pássaro morria antes que o gás atingisse concentração fatal para humanos. Em software, um canary deploy direciona uma fração pequena do tráfego real para a nova versão antes de expô-la a todos os usuários. Se a nova versão tiver problemas, apenas uma parcela pequena dos usuários é afetada — o canário "morreu" e o time pode reverter antes de causar um incidente amplo. É uma estratégia de validação em produção com dados reais, mas com risco controlado e superfície de impacto mínima.

Splitting de tráfego — percentuais e estratégias

Como direcionar usuários para a nova versão

O splitting de tráfego pode ser feito por diferentes mecanismos. No nível de load balancer, pesos definem o percentual de requisições para cada versão — 5% para o canary, 95% para a versão estável. Service meshes como Istio e Linkerd permitem splitting baseado em headers HTTP, user-agent, cookies ou ID do usuário, criando cohorts determinísticos. Sticky sessions garantem que um usuário que caiu no canary continue no canary durante toda a sessão, evitando comportamentos inconsistentes. Percentuais típicos começam em 1-5% e avançam em estágios: 5%, 10%, 25%, 50%, 100%, com períodos de observação entre cada avanço.

Critérios de promoção — quando expandir o canary

Métricas que autorizam avançar o percentual

A promoção do canary não deve ser manual nem baseada em intuição — deve ser orientada por métricas objetivas. As métricas típicas de promoção incluem: taxa de erros HTTP 5xx abaixo do baseline histórico, latência P99 não aumentando mais de X% em relação à versão estável, zero aumento na taxa de exceções monitoradas via APM, e ausência de alertas de negócio (carrinho abandonado, falhas de pagamento). Ferramentas como Argo Rollouts e Flagger automatizam essa análise: consultam o sistema de métricas (Prometheus, Datadog) em intervalos definidos e avançam o percentual automaticamente quando os critérios são atendidos.

Critérios de rollback — métricas que disparam retrocesso

Detectar e reverter antes do impacto escalar

O rollback automático é a proteção mais importante do canary. Qualquer métrica crítica acima do threshold configurado dispara a reversão: taxa de erros acima de 1%, latência P99 aumentando mais de 20%, aumento de exceções de negócio, redução de conversion rate acima de X%. Ferramentas de análise como Kayenta (Netflix) e o provider de análise do Argo Rollouts comparam o canary com a versão baseline usando statistical significance, evitando rollbacks por ruído estatístico. O rollback reverte o splitting de tráfego para 0% no canary e o orquestrador remove os pods da nova versão. Todo o processo pode acontecer em menos de 2 minutos após a detecção da anomalia.

Canary em Kubernetes — Argo Rollouts e Flagger

Automação nativa para releases progressivos

Argo Rollouts estende o Kubernetes com um custom resource Rollout que substitui o Deployment padrão e adiciona estratégias de canary e blue-green nativas. O Rollout define os steps do canary (setWeight, pause, análise de métricas) e o Argo Rollouts Controller executa automaticamente cada etapa. Flagger é uma alternativa que funciona com qualquer service mesh (Istio, Linkerd, AWS App Mesh) e monitora métricas de tráfego para promover ou reverter automaticamente. Ambas as ferramentas integram com Prometheus para análise de métricas e com sistemas de notificação para alertar o time sobre o progresso do canary. A escolha entre elas depende do ecossistema já adotado no cluster.

Feature flags como canary controlado

Segmentação de usuários mais granular que splitting de tráfego

Feature flags permitem um tipo de canary mais preciso: em vez de percentual aleatório de tráfego, a nova feature é ativada para cohorts específicos — usuários beta, clientes enterprise, usuários de uma região geográfica ou um ID de usuário específico. Plataformas como LaunchDarkly, Unleash e Split.io oferecem targeting rules e rollout percentual com persistência de cohort. A combinação de canary de infraestrutura (splitting de tráfego) com feature flags é poderosa: o código da nova versão está em produção, mas a feature fica desativada por flag até que métricas de infraestrutura confirmem estabilidade. Só então a flag é ativada progressivamente para os usuários.

A/B testing vs Canary — diferenças de objetivo

Validação técnica vs validação de negócio

Canary e A/B testing são frequentemente confundidos por usarem splitting de tráfego, mas têm objetivos diferentes. Canary valida estabilidade técnica: a nova versão está estável? A latência aumentou? As taxas de erro pioraram? O critério de sucesso é técnico. A/B testing valida hipóteses de negócio: qual versão do botão tem mais cliques? Qual fluxo de checkout converte mais? O critério é métrica de negócio e requer significância estatística com amostras grandes. A/B tests rodam por semanas para atingir significância; canary deploys duram horas. É possível e desejável combinar ambos: validar estabilidade técnica com canary e, após promoção completa, iniciar um A/B test para otimizar métricas de negócio.

Métricas de sucesso para canary

O que medir e como interpretar

Um canary saudável deve manter as métricas do canary dentro de um intervalo de confiança em relação ao baseline. As métricas essenciais são: taxa de sucesso de requisições (porcentagem de respostas 2xx), latência P50, P95 e P99, taxa de erros de negócio (pagamentos falhos, logins falhos) e métricas de recursos (CPU, memória, conexões de banco). A análise deve ser comparativa, não absoluta: se o baseline tem P99 de 200ms, o canary com P99 de 210ms pode ser aceitável; com P99 de 400ms, claramente não. Ferramentas de progressive delivery calculam essas comparações automaticamente usando modelos estatísticos para separar sinal de ruído amostral.

Canary e banco de dados — compatibilidade entre versões

O desafio de duas versões escrevendo no mesmo banco

Durante um canary deploy, as versões antiga e nova da aplicação coexistem e acessam o mesmo banco de dados simultaneamente. Isso exige que todas as mudanças de schema sejam retrocompatíveis: adicionar colunas com valor default é seguro; remover ou renomear colunas enquanto o código antigo ainda as usa causa erros. A regra é: nunca deploy de código e schema migration destrutiva no mesmo canary. Primeiro faça a migration aditiva (nova coluna, nova tabela) e aguarde estabilizar; depois faça o deploy do código que usa a nova estrutura; depois, em um terceiro deploy, remova as estruturas antigas. Essa disciplina de expand-contract protege canary e blue-green igualmente.

Conclusão

Canary deploy como prática de release engineering madura

Continue em: Fundamentos obrigatórios antes de produção.