Deploy canário: libere primeiro para poucos usuários

Um deploy canário libera uma nova versão do seu software para uma pequena fatia do tráfego real, enquanto todo o resto continua na versão atual. Se o canário se comporta bem, você amplia essa fatia passo a passo. Se não, você manda o tráfego de volta e só alguns usuários foram afetados.

O nome vem do canário na mina de carvão: um pequeno alerta antecipado de que algo está errado antes que o grupo inteiro seja exposto. Uso isso principalmente quando estou mudando um sistema do qual pessoas reais dependem todos os dias, porque transforma um release arriscado em uma série de releases pequenos e reversíveis.

O que é um deploy canário?

Em um release normal, todos os usuários passam para a nova versão no mesmo momento. Se houver um bug, todo mundo esbarra nele. Em um release canário, duas versões rodam lado a lado: a estável e o canário. Um roteador, um load balancer ou um switch no nível da aplicação decide qual requisição vai para onde.

Você começa com uma parcela pequena, observa e aumenta em etapas. Em cada etapa você faz uma pergunta: o canário está pelo menos tão saudável quanto a versão estável? A comparação é o que importa. Uma taxa de erro isolada diz pouco, mas uma taxa de erro mais alta no canário do que na versão estável diz algo específico.

Qual a diferença para blue-green e feature flags?

O deploy blue-green mantém dois ambientes completos e muda todo o tráfego de um para o outro de uma vez. Um canário move o tráfego aos poucos. Feature flags controlam o comportamento dentro do código, muitas vezes por usuário, e são usadas com frequência para implementar um canário. As abordagens se sobrepõem, e muitos times as combinam: fazem o deploy do código desligado e depois o expõem para um grupo cada vez maior.

Como escolher quais usuários ou qual tráfego vão para o canário?

Essa é a decisão que faz a abordagem dar certo ou não. Um canário que só recebe tráfego com o qual ninguém se importa não prova nada. Um canário que atende primeiro o seu maior cliente é imprudência.

Uma sequência que funcionou para mim:

1. Usuários internos e equipe. Eles encontram os problemas óbvios e vão perdoá-los.
2. Uma pequena amostra aleatória do tráfego. A amostragem aleatória dá uma comparação justa com a versão estável.
3. Segmentos de baixo risco. Por exemplo, contas gratuitas, uma região ou um tenant que aceitou entrar antes.
4. Grupos mais amplos, em etapas, deixando os clientes de maior valor por último.

Atribuição aleatória ou fixa?

Torne a atribuição fixa. Se um usuário fica alternando entre versões a cada requisição, ele pode ver telas inconsistentes, perder a sessão ou esbarrar em dados gravados em um formato que a outra versão não consegue ler. Atribua por ID de usuário, ID de conta ou um cookie, para que a mesma pessoa fique na mesma versão durante o teste.

Cuidado com os fluxos de dinheiro e de dados

Tudo que cobra cartões, envia emails ou grava dados que a versão antiga também precisa ler merece cuidado extra. Por ter trabalhado no time de carrinho e checkout da Total Wine & More, trato o fluxo de dinheiro como o último lugar para ousar. Mantenha o canário pequeno por mais tempo nesses fluxos e confira se as duas versões convivem com os dados que a outra grava. Um canário não desfaz um registro corrompido, então a compatibilidade dos dados precisa estar resolvida antes de mover o tráfego.

Quais métricas mostram que o canário está saudável?

Escolha as métricas e os limites antes de começar. Se você decide o que conta como saudável enquanto encara um dashboard sob pressão, vai acabar racionalizando. Compare o canário com a versão estável na mesma janela de tempo.

As métricas de negócio são as que as pessoas pulam

Um release pode passar em todas as verificações técnicas e mesmo assim, silenciosamente, impedir as pessoas de concluir uma compra ou uma candidatura. Os dashboards de servidor não vão mostrar isso. Se o produto tem uma ação principal, acompanhe a taxa de sucesso dela nas duas versões. Em uma migração, esse costuma ser o sinal de saúde mais honesto que você tem.

Atenção ao tamanho da amostra

Com um canário muito pequeno, um punhado de requisições pode fazer uma porcentagem oscilar muito. Não promova só porque os primeiros dez minutos pareceram limpos. Deixe o canário rodar tempo suficiente, e com tráfego variado o bastante, para que a comparação signifique algo. Quanto tempo depende do seu volume, então trate qualquer duração específica como algo a ajustar para o seu sistema.

Quando promover ou fazer rollback de um canário?

Escrevo as regras como um checklist curto antes do release. Uma versão simples:

• Promova quando o canário ficar dentro da margem combinada em relação à versão estável em erros, latência e na métrica de negócio durante toda a janela de observação.
• Segure quando os resultados forem ambíguos. Fique na porcentagem atual e colete mais dados em vez de avançar.
• Faça rollback quando qualquer limite rígido for ultrapassado, como um aumento claro de erros, uma queda na ação principal do negócio ou qualquer sinal de dados sendo gravados incorretamente.

O rollback deveria ser entediante. O ideal é que signifique mudar um peso de roteamento ou desligar uma flag, não fazer um novo deploy sob estresse. Teste esse caminho antes de precisar dele. Se reverter exige um procedimento manual longo, seu canário está protegendo você menos do que você imagina.

Promoção e rollback automatizados são possíveis, e algumas ferramentas fazem isso com base em limites de métricas. Ainda assim, eu rodaria os primeiros releases com uma pessoa acompanhando, para que os limites sejam ajustados à realidade antes de você confiar neles para agir sozinhos.

Como os releases canário reduzem o risco em uma migração?

Migrar uma plataforma em produção é onde os canários mais compensam. Quando liderei a migração de uma plataforma que se candidata automaticamente a vagas de emprego pelos seus usuários, toda a arquitetura saiu de uma stack legada para uma nova enquanto as pessoas continuavam usando o produto todos os dias. Uma virada única teria significado apostar tudo em um único momento. Avançar aos poucos significou que cada parte podia ser comprovada primeiro com tráfego real.

O padrão é direto:

1. Coloque um switch na frente de tudo antes de escrever código novo, para controlar qual versão atende cada requisição. Esse é sempre o meu primeiro passo.
2. Mova uma pequena parte da funcionalidade para a nova stack.
3. Envie uma pequena parcela do tráfego para ela como canário e compare.
4. Amplie a parcela e depois aposente a parte antiga quando a nova tiver se provado.

É por isso que prefiro migração incremental a uma reescrita big-bang. Uma reescrita geralmente custa mais e demora mais, em parte porque o sistema antigo precisa continuar rodando em paralelo de qualquer forma. Um canário torna esse período em paralelo útil: você aprende com o comportamento real em vez de esperar o dia do lançamento para descobrir.

Um limite a ter em mente: um canário mostra como a nova versão se comporta para o tráfego que recebe. Ele não vai pegar um caso extremo raro que nenhuma parte desse tráfego acionou, então complementa testes e code review em vez de substituí-los. Para sistemas mais antigos, veja como mudar código antigo com segurança.

Você precisa de infraestrutura especial para deploys canário?

Não. Ferramentas especializadas facilitam em escala, mas a ideia funciona com estruturas modestas. Opções, da mais simples à mais elaborada:

• Feature flags na aplicação. Exponha o novo caminho de código para uma porcentagem ou uma lista de usuários. Não exige mudanças de roteamento.
• Roteamento ponderado em um load balancer ou proxy reverso. Muitos dos mais comuns permitem enviar uma porcentagem das requisições para um segundo conjunto de servidores.
• Divisão de tráfego no nível da plataforma. Plataformas de orquestração de containers e de nuvem costumam oferecer rollouts ponderados, e algumas plataformas de hospedagem oferecem divisão de tráfego. Confira a documentação atual do seu provedor para saber o que é suportado.
• Ferramentas dedicadas de entrega progressiva que automatizam a análise e o rollback.

O que você precisa, qualquer que seja a ferramenta, é observabilidade. Se você não consegue ver erros, latência e uma métrica de negócio separados por versão, você não está rodando um canário, está só liberando devagar. Marcar logs e métricas com a versão é a primeira coisa que configuro; o roteamento pode ser rudimentar.

Você também precisa lidar com o estado compartilhado. As duas versões vão acessar o mesmo banco de dados, então as mudanças de schema precisam ser retrocompatíveis enquanto as duas coexistem. Adicione colunas antes de usá-las e remova as antigas só depois que a versão antiga sair do ar.

Planejando um canário para o seu release?

Se você está avaliando como liberar uma migração ou um release arriscado, mande um email para me@filipeeduardo.dev com uma breve descrição do seu cenário. Fico feliz em dar uma olhada e dizer o que eu verificaria primeiro.