sua estratégia de deploy importa menos do que você pensa
Índice
- Recreate — Derruba tudo. Sobe de novo.
- Rolling — Troca o pneu com o carro andando.
- Blue/Green — O prédio espelhado.
- o mito do rollback
- Canary — Três mesas no fundo, pra ver se o salão passa mal.
- a conta que ninguém quer fazer
- Shadow — Trabalho sujo no escuro.
- o blast radius
- o pesadelo do banco de dados
- checklist tático
Sexta-feira, 15h12. Deploy de rotina. Alteramos o user_data.sh da instância — nada exótico. Rolling update, como sempre fazíamos.
O warmup time do Auto Scaling Group estava configurado para 5 minutos. Mas com as novas dependências que adicionamos, a instância passou a levar 9 minutos para subir. O ASG, impaciente, marcava a instância como unhealthy. Matava. Subia outra. Que também não bootava a tempo. Que também era marcada como unhealthy.
Em poucos minutos, efeito cascata. 2 instâncias viraram 20. Nenhuma saudável. A latência explodiu e a tela foi tomada por erros 5xx pra todo lado.
Tivemos um Rolling elegante no papel, mas um Recreate catastrófico na prática.
O problema não era a estratégia. Era um warmup que ninguém conferiu. Um script sem teste de carga. Um default que ninguém questionou.
Times gastam semanas debatendo arquiteturas no quadro branco como se fossem escudos mágicos contra quedas em produção. Não são.
A estratégia é só o envelope. O que decide se o sistema sobe ou desce são os parâmetros que ninguém olha: o readiness delay, o warmup time, o connection draining, o batch size. Ter um Canary perfeito com um health check genérico é pular de avião com paraquedas amarrado com nó cego. O design tá lindo, mas a execução vai ser fatal.
Pensa na sua infra como a reforma de um restaurante lotado. Três objetivos:
- Zero downtime: O restaurante nunca fecha; os clientes continuam comendo.
- Zero custo extra: Você não aluga um segundo prédio nem compra fogões sobressalentes.
- Zero risco: Se a nova cozinha falhar, a comida de ninguém queima.
A realidade é que você só pode ter dois. O terceiro sempre cobra — e é nessa troca que cada estratégia se posiciona.
o triângulo do deploy
escolha dois — o terceiro sempre cobra
—
Cada estratégia abaixo tem uma simulação interativa que você pode (e deve) quebrar. O ponto não é escolher a “vencedora” — é entender por que nenhuma delas te salva sozinha.
Recreate — Derruba tudo. Sobe de novo.
A versão antiga (v1) é completamente desligada. O ambiente zera. A versão nova (v2) assume do zero. Sem sobreposições.
A Prática: Você prega um aviso: “Fechado para reformas”. Desliga tudo. Por 30 dias, ninguém é atendido. Quando reabre, a operação é 100% nova e coerente. Sem misturar estado antigo com banco novo.
Como funciona no Servidor:
- Mata todo o tráfego v1.
- Aguarda o desligamento pleno.
- Inicia as instâncias v2.
- Religado.
Onde faz sentido: Quando o ambiente rejeita concorrência. Uma estrutura de banco que quebra fatalmente a versão anterior.
O Custo: Downtime absoluto. Não há choro.
| Prós | Contras |
|---|---|
| Zero risco arquitetural | Downtime inevitável |
| Sem colisão de versão | Usuários sem acesso |
| Menor complexidade | Rollback requer re-deploy imediato |
configuração de deploy
Quebre a simulação: Aumente para 4 instâncias e veja a matemática cruel. Quanto maior seu cluster, maior a janela de indisponibilidade. O tamanho da sua escala vira o tamanho do seu downtime.
Rolling — Troca o pneu com o carro andando.
A versão B estrangula a versão A gradualmente. Sai um, entra outro. Peça por peça até o ambiente estar 100% atualizado. O sistema se recusa a morrer completamente.
A Prática: O serviço não para. Você isola uma máquina do pool, atualiza, e sobe de novo. Metade do tráfego esbarra na versão velha, metade na nova. É um atrito temporário, mas o faturamento não engasga.
A Falha: Seu Banco de Dados é obrigado a gerenciar requisições da v1 e da v2 alterando a mesma estrutura simultaneamente. Essa estratégia cobra seu preço na frente.
O Custo: Capacidade ou velocidade. Você abre mão de uma.
| Prós | Contras |
|---|---|
| Zero downtime (no papel) | Dolorosamente arrastado |
| O Padrão Ouro da indústria | Exige retrocompatibilidade severa |
| Baixo custo agregado | Erros de drain são fatais |
configuração de deploy
parâmetros da estratégia
Quebre a simulação: Zere o
minActivee aumente seubatchSizeao máximo. Boom. Você esmagou a capacidade ativamente e o seu refinado Rolling acabou de virar um Recreate disfarçado de desastre. Aumente obootTimepra superar o health check e assista a tela pintar de vermelho — foi essa tela que derrubou nossa sexta-feira.
Blue/Green — O prédio espelhado.
Custo alto. Risco Mínimo. A versão B (Green) desponta numa infra paralela, blindada e idêntica. Testada às escuras. Ao cruzar a linha de segurança, aperta-se um botão. O roteador vira 100% do tráfego pro lugar novo.
A Prática: Você nunca mexe na infra principal. Sobe outro ambiente, contrata réplicas e testa em segredo. Tudo limpo? Vira a chave magnética (DNS/Load Balancer) no mesmo segundo. O cliente continua navegando e nem sente.
O Limite Colateral: Ambientes virgens precisam de banco de dados aquecido. Caches zumbis ou compartilhamento bruto de schemas fazem a porta trancar.
A Troca: Custo dobrado em nuvem de uma canetada só.
| Prós | Contras |
|---|---|
| Zero downtime (teórico) | O dobro na fatura no mês |
| O tão sonhado Rollback “Botão Vermelho” | Dependências estagnadas de Banco |
| Testes robustos de fumaça pré real | Cache frio mata a produção |
configuração de deploy
parâmetros da estratégia
Quebre a simulação: Vá nos parâmetros da estratégia e zere o Cache warmup. Na virada do switch, contemple a tempestade. Isso é a Manada em Fuga (Thundering Herd). Com caches vazios, requisições afogam instantaneamente o banco. O LB vira 100%, e máquinas hiper-saudáveis te disparam 504 na cara num lock de desespero! Você salvou o código, mas a percepção capotou.
o mito do rollback
Blue/Green é aclamado pelo sonho: aperto o Undo em 5 segundos. Mas é ilusão. Você desfaz código. Você nunca desfaz estado.
- O Evento: Kafka postou a notificação. 12 API’s consumiram. Sem Ctrl+Z.
- Side-Effects: A máquina rodou webhooks. O e-mail avisou os usuários. O gateway de pagamentos tirou fundos dos cartões.
- DB Alterado: Matou aquela tabela no banco mas jobs assíncronos ainda consultavam o
user_id_legacy? O sangramento já começou.
Sistemas distribuídos não aceitam “Ctrl+Z”. Preferir a precisão de falhar aos poucos (ex. Canary) é mais seguro que bater num freio de emergência invisível. A infraestrutura retrocede, mas a ferida nos dados fica aberta. Assuma que não tem volta — desenhe seu deploy para avançar (fix-forward) em frações menores.
Canary — Três mesas no fundo, pra ver se o salão passa mal.
Se Blue/Green provou que você não desfaz estado, Canary faz uma pergunta mais afiada: e se você nunca precisar? Falha tão pequena que o estrago é irrelevante.
A joia da coroa em mitigação de risco. Manda 1~5% do tráfego pra versão B. Fica observando. Se nada pegar fogo, abre pra 10%, 25%, e então 100%.
A Prática: Ninguém joga um update opressivo em 100% de cara. Você joga a nova versão num nó pequeno da ponta. Errou? O log espirra lixo sem queimar a operação geral.
O padrão das big techs — pegar o bug antes dele virar incêndio global.
O Custo: Tempo e matemática que ninguém quer fazer.
| Prós | Contras |
|---|---|
| Blast radius controlado | Demanda automação blindada |
| Métricas reais, não sintéticas | Amostra ridícula se o tempo for curto (leia abaixo) |
| Cultura de observabilidade | Deploy lento por design |
configuração de deploy
parâmetros da estratégia
Aviso anti-loucura: Não cruze A/B Test com Canary. A/B descobre a venda de produtos pra negócio (Qual cor os botões pagam?). Canary tenta salvar a integridade funcional de engenharia e servidor (Tem lixo de RAM destruindo query nova de JS?). Correm na mesma via, mas com direções divergentes.
a conta que ninguém quer fazer
Times compram o hype do The Canary com pífios “15 minutos a 5%” antes do pulo cego pra 100%.
Se existir um memory leak imperceptível que detona apenas 0,1% das requisições, você precisará de, no mínimo, 30 mil conexões direcionadas ao Canary só para o DataDog gerar um alerta estatisticamente válido. Deixar o tráfego 15 minutos pingando a 5% fora da escala de uma big tech não é rigor técnico, é teatro de segurança. É tentar tranquilizar a mente olhando para gráficos enquanto uma falha silenciosa se acumula no cluster.
Shadow — Trabalho sujo no escuro.
Copia todo request pro escuro. A versão A continua servindo o usuário de verdade. Em paralelo, a versão B recebe o mesmo tráfego, processa tudo — latência, CPU, erros — mas descarta a resposta. O usuário nunca sabe.
Na Prática: Você roda a versão nova sob tráfego real de produção, sem afetar ninguém. A pressão é real, os dados são reais, mas o cliente não sente nada.
A armadilha dos side-effects: Sem mocks blindados, a versão shadow dispara e-mails, cobra cartões e escreve no banco — tudo duplicado. Se você não isolar os efeitos colaterais, o shadow vira uma bomba.
O Custo: A maior precisão possível. Mas a conta de cloud dobra.
| Prós | Contras |
|---|---|
| Zero risco pro usuário | Custo de infra dobrado |
| Métricas de performance reais | Mock de side-effects é um pesadelo |
configuração de deploy
Quebre a simulação: Apenas encare ativamente o contador em amarelo. Veja a dupla faturação das máquinas na conta por nada a ser oferecido externamente. Essa é a paranoia total comprada em dólar e sem falhas perante os usuários.
o blast radius
Cinco estratégias, cada uma otimizando um lado diferente do mesmo triângulo. Mas estratégia é o quê. A pergunta mais perigosa é onde.
Deploys não acontecem apenas na camada de servidores. O escopo da mudança — o seu blast radius — escala desde uma única thread de CPU até o roteamento DNS intercontinental:
Simples
Menor custo / Maior risco
Complexo
Maior custo / Menor risco
Recreate
Downtime total
Rolling
Atualização gradual
Blue/Green
Cópia exata, dobra o custo
Canary
Roteamento percentual
Shadow
Tráfego espelhado
| Camada | Controle | Exemplos |
|---|---|---|
| Processos de SO | Portas / IPC | Gunicorn, PM2 |
| Pods / Containers | Ingress / Service Mesh | Kubernetes, Envoy |
| Instâncias / VMs | Load Balancers (ALB/NLB) | AWS EC2, Azure VMs |
| Tráfego Global | Roteamento Edge / DNS | Cloudflare, Route53 |
Dizer na daily que o time “faz Canary” é vago. Tão roteando 2% dos requests num load balancer local, ou jogando 10% do tráfego da Europa direto no Cloudflare? Sem saber o blast radius exato, você não sabe o tamanho do estrago.
o pesadelo do banco de dados
O blast radius te diz até onde o estrago se espalha. O banco de dados te diz onde ele fica.
Se existe uma força bruta capaz de triturar o seu Canary ou Rolling perfeito, é o banco de dados relacional.
A versão antiga não reconhece as alterações da mais nova. Se o script de deploy deita as instâncias v1 enquanto destrói uma coluna que estava sendo lida por elas, a aplicação apaga. O banco é o cemitério de estado compartilhado das estratégias elegantes.
Pra sobreviver a isso, a saída é o padrão Expand & Contract:
- Expansão: Cria as colunas novas. O código passa a escrever nos dois lugares ao mesmo tempo — mas a leitura continua no schema antigo.
- Migração: Um script em background move os dados antigos pro schema novo.
- Contração: Meses depois, quando nada mais lê o schema antigo, mata a coluna velha. Esse deploy “simples” leva um mês pra terminar com segurança.
checklist tático
A sexta-feira que abriu esse post? Estratégia certa. Parâmetro errado. Cada simulação que você quebrou acima provou a mesma coisa de um ângulo diferente.
Antes de aplicar a próxima mudança na infraestrutura, valide:
- Os parâmetros decidem tudo. Um
timeoutcurto ou um batch size no máximo transformam o Canary mais elaborado num Recreate acidental. - O banco não tem Ctrl+Z. Desenhe assumindo que falhas vão vazar pro estado persistido. A saída é avançar (fix-forward), não voltar.
- Amostra pequena = teatro. Canary com 5% de tráfego por 10 minutos em volume baixo não é validação — é autoengano. Se não atinge relevância estatística, o alerta é cego.
No fim do dia, a estratégia é só uma intenção. O que roda de verdade em produção são os valores que alguém preencheu num arquivo de configuração.