Canary Deployment (Lançamento Gradual)

O Canary Deployment é a estratégia que expõe a versão nova de um serviço a uma fração pequena e crescente do tráfego real, avaliando métricas de saúde a cada etapa antes de autorizar o aumento seguinte. O nome vem do canário de mina: uma pequena população sinaliza primeiro qualquer problema, protegendo a massa do tráfego. É a estratégia mais sofisticada das três formas de substituição de instâncias, porque não apenas lança gradualmente como também julga o resultado, promovendo ou revertendo automaticamente com base em dados observados. Em produção, o canary reduz o raio de explosão de um deploy ruim a percentuais controlados, tipicamente 5% ou menos na primeira etapa. O custo é a exigência de infraestrutura de roteamento por peso e de análise automatizada de métricas, peças que serviços pequenos nem sempre têm maturidade para operar.

Conceito e problema que resolve

O problema que o canary resolve é a incerteza estatística dos testes pré-produção. Nenhum ambiente de staging reproduz fielmente o volume, a variedade de dados e os padrões de uso da produção; bugs de performance, gargalos de memória e interações raras só aparecem sob tráfego real. O rolling update e o blue-green expõem todo mundo à versão nova com base em validações limitadas. O canary trata o lançamento como um experimento controlado: a versão nova prova seu valor numa amostra antes de receber o público inteiro.

Duas propriedades distinguem o canary do rolling update, embora ambos lancem por etapas. Primeiro, o canary roteia por peso explícito, e não por substituição natural de réplicas, de modo que a fração exposta é uma decisão consciente e não um efeito colateral da matemática de surge. Segundo, o canary tem um avaliador: cada etapa tem critérios de promoção baseados em métricas, e a falha deles interrompe e reverte o processo sem esperar humanos reagirem.

Funcionamento interno: rampa de percentuais

Uma rampa canary típica segue a sequência de 1%, 5%, 25%, 50% e 100%, com pausas de observação entre as etapas. A primeira etapa é a mais reveladora, pois as falhas grosseiras, como panics, erros de configuração e incompatibilidades de contrato, aparecem com pouquíssimos usuários afetados. As etapas finais concentram o teste de capacidade, porque é lá que o serviço novo precisa sustentar o volume total.

Cada pausa serve para acumular amostra suficiente de métricas e executar a análise. O intervalo precisa respeitar a duração dos ciclos de negócio relevantes; cinco minutos podem bastar para taxas de erro de infraestrutura, mas nada capturam de um fluxo de checkout que só ocorre dezenas de vezes por minuto. A duração de cada etapa é, portanto, uma decisão de estatística aplicada, e não de impaciência do pipeline.

# Roteamento por peso em service mesh: etapa canary de 5%
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: pagamentos-vs
spec:
  hosts:
    - pagamentos
  http:
    - route:
        - destination:
            host: pagamentos
            subset: stable      # versão atual recebe 95% do tráfego
          weight: 95
        - destination:
            host: pagamentos
            subset: canary      # versão nova recebe 5% do tráfego
          weight: 5
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: pagamentos-dr
spec:
  host: pagamentos
  subsets:
    - name: stable
      labels:
        version: v2.4.1         # rótulo da frota estável
    - name: canary
      labels:
        version: v2.5.0         # rótulo da frota canária

Na plataforma Kubernetes, operadores como Flagger e Argo Rollouts automatizam exatamente esse ciclo: criam o Deployment canário, manipulam os pesos do mesh ou do Ingress, consultam o Prometheus entre as etapas e executam promoção ou rollback conforme as regras declaradas. Em provedores de nuvem gerenciados, o mesmo padrão aparece no CodeDeploy com roteamento por canary e no App Mesh ou no Gateway API com pesos de backend.

Análise automatizada de métricas

O coração do canary é a análise. A cada etapa, o avaliador compara a frota canária com a estável nas mesmas janelas de tempo, neutralizando variações do tráfego global. Os candidatos naturais são os golden signals: taxa de erro, latência por percentil, throughput e saturação de recursos. Métricas de negócio, como conversão no checkout ou taxa de resposta em formulários, elevam a análise a outro patamar, porque capturam regressões funcionais que nenhuma métrica técnica revela.

A análise ingênua, que compara a canária com um valor absoluto fixo, produz dois vintões: falsas paradas por flutuação natural e passagens silenciosas com degradação real. A prática consolidada usa a frota estável como baseline simultâneo e exige margem relativa, por exemplo, a taxa de erro da canária não pode exceder a da estável em mais de um ponto percentual. Janelas de análise curtas demais acumulam amostra insuficiente para percentis de latência confiáveis, e o avaliador precisa considerar esse mínimo amostral antes de decidir.

• Taxa de erro HTTP por código, comparada com o baseline da estável na mesma janela.
• Latência p95 e p99, pois a média esconde as caudas onde os incidentes moram.
• Throughput por instância, para detectar regressões de capacidade e gargalos.
• Saturação, com CPU, memória e uso de pool de conexões por frota.
• Métricas de negócio relevantes para o serviço, com a ressalva de janelas maiores.

Promoção e rollback automáticos

O resultado da análise é binário por etapa: promover para o próximo peso ou reverter para o estado estável. A promoção eleva o peso do canário conforme a rampa declarada; a reversão devolve o peso a zero, remove a frota canária e deixa o serviço exatamente como estava, em minutos. O rollback pode ser acionado manualmente a qualquer momento, e é justamente a existência do botão, somada à certeza de que ele funciona, que autoriza deploys mais frequentes e ambiciosos.

# Políticas de análise do Flagger: critérios de promoção e rollback
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: pagamentos
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: pagamentos
  progressDeadlineSeconds: 600
  service:
    port: 80
  analysis:
    interval: 2m               # janela de análise de cada etapa
    threshold: 3               # 3 falhas seguidas disparam rollback
    stepWeight: 10             # rampa de 10% por etapa
    maxWeight: 50              # teto antes da promoção final
    metrics:
      - name: error-rate
        templateRef:
          name: error-rate-template
        thresholdRange:
          max: 1               # erro acima de 1% relativo reprova
      - name: latency-p99
        templateRef:
          name: latency-p99-template
        thresholdRange:
          max: 500             # p99 acima de 500ms reprova
    webhooks:
      - name: smoke-test       # gate funcional adicional por etapa
        type: pre-rollout
        url: http://tester.ambiente/verificar

O threshold de falhas seguidas evita o rollback por ruído: uma etapa com uma métrica fora da margem por um ciclo pode ser estatística, três ciclos seguidos fora raramente são. O progressDeadline impede o cenário patológico da rampa eternamente parada, e o gate pre-rollout acrescenta a camada funcional, com testes de fumaça executados contra a frota canária antes da primeira etapa de tráfego.

Golden signals na avaliação

A escolha das métricas define a sensibilidade e a especificidade do canário. Os quatro golden signals do Google SRE formam a base consensual, e cada um captura uma classe distinta de falha.

Nenhum sinal é suficiente sozinho. Taxa de erro baixa com p99 elevado indica degradação silenciosa de latência; throughput estável com saturação crescente antecipa um colapso por memória. A análise conjunta é o que dá ao canário sua confiabilidade como juiz.

Comparação com blue-green e rolling update

O canary e o blue-green compartilham a coexistência de duas frotas, mas divergem no propósito: o blue-green troca o tráfego por completo após validação sintética, enquanto o canário valida com tráfego real fracionado. O canary e o rolling update compartilham a exposição gradual, mas divergem no controle: o rolling update não roteia por peso e não analisa métricas por etapa.

Erros comuns e boas práticas

Os erros clássicos transformam o canário de instrumento de segurança em burocracia de pipeline.

• Etapas curtas demais, com amostra insuficiente para os percentis; a análise aprova por falta de dados, e não por qualidade.
• Baseline ausente, comparando a canária com valores absolutos herdados de outro horário de tráfego, o que gera falsas reprovações e falsas aprovações.
• Ignorar a contaminação da amostra: sessões com estado em cache de roteamento ou sticky session podem concentrar o mesmo usuário na canária, distorcendo a avaliação.
• Rampas idênticas para serviços diferentes; um serviço de autenticação e um worker de relatório exigem métricas e durações distintas.
• Canário sem teste de carga final, deixando a etapa de 100% sem cobertura de capacidade verificada.
• Falha de rollback não testada, descobrindo em incidente que o caminho de reversão está quebrado por mudança de rótulos ou de gateway.

Entre as boas práticas, comece a rampa em percentuais baixos o bastante para o pior bug não virar incidente, use a frota estável como baseline simultâneo, declare thresholds como código versionado no repositório, e complemente métricas técnicas com ao menos uma métrica de negócio. Para serviços onde a análise estatística não é viável, o canário degenera em rollout gradual com pausas, o que já captura grande parte da proteção; a análise automática é o aprimoramento, não o pré-requisito.