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 perguntas ajudam a comparar as estratégias:
- O serviço fica no ar? O salão continua atendendo enquanto a cozinha muda.
- Quanto custa manter? É preciso duplicar espaço, equipe ou equipamentos?
- Se falhar, quantas pessoas sentem? A cozinha nova começa com poucos pedidos ou atende todo mundo de uma vez?
Os três cantos respondem a essas perguntas. Quanto mais o desenho chega perto de um canto, melhor a estratégia costuma se sair naquele ponto.
comparação rápida
o que cada estratégia prioriza
mais perto do canto = melhor naquele objetivo
Rolling
Troca poucas instâncias por vez.
- ponto forte
- mantém o serviço no ar sem duplicar toda a frota
- em troca
- v1 e v2 precisam funcionar juntas
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.
Sobre o modelo: Os tempos foram comprimidos para caber na página, e falhas, latências e divergências usam probabilidades ilustrativas. Cada execução pode variar. Compare relações de causa e efeito — não use os números como benchmark de produção.
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.
- Religa o tráfego.
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 |
|---|---|
| Sem coexistência de versões | 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 observe a drenagem, o custo e o volume de capacidade reciclada crescerem. Como as novas instâncias sobem em paralelo, o tamanho do cluster sozinho não alonga automaticamente o downtime; quem domina essa janela é o tempo até a primeira v2 ficar pronta para receber tráfego.
Rolling — Troca o pneu com o carro andando.
A versão B substitui a versão A gradualmente. Sai um, entra outro. Peça por peça até o ambiente estar 100% atualizado.
A Prática: Com minActive, readiness e draining bem calibrados, o serviço continua disponível. Você drena uma máquina do pool, sobe sua substituta em v2 e repete. Durante a transição, parte do tráfego chega na versão velha e parte na nova — a proporção muda a cada lote.
A Falha: O banco precisa atender v1 e v2 ao mesmo tempo. Se as duas versões não forem compatíveis com o mesmo schema, leituras e escritas podem falhar durante toda a coexistência.
O Custo: Capacidade, velocidade ou surge temporário. Os limites operacionais decidem qual conta chega primeiro.
| Prós | Contras |
|---|---|
| Disponibilidade contínua com salvaguardas corretas | Pode ser arrastado |
| Padrão conhecido e amplamente suportado | 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 obatchSizeao máximo. Boom. Você autorizou o lote a drenar toda a capacidade e o seu refinado Rolling virou um Recreate disfarçado. Depois aumente obootTimeacima do readiness delay e da tolerância do health check: instâncias prematuras entram no caminho do tráfego, falham e disparam reposições.
Blue/Green — O prédio espelhado.
Custo alto. Risco reduzido. A versão B (Green) sobe numa infra paralela e equivalente. Testada fora do caminho principal. Ao cruzar a linha de segurança, o roteamento passa para o ambiente novo.
A Prática: Você preserva o ambiente ativo enquanto sobe e testa o Green. Tudo limpo? Um Load Balancer pode trocar o destino quase imediatamente; uma mudança por DNS ainda depende de TTL e caches para convergir. Se readiness, capacidade e dependências estiverem corretos, o cliente não percebe a virada.
O Limite Colateral: O Green pode nascer com caches frios, conexões ainda não aquecidas e diferenças de configuração. Compartilhar o mesmo banco também mantém o risco de estado entre os dois ambientes.
A Troca: Durante a coexistência, a capacidade de aplicação pode chegar perto do dobro. Isso não significa necessariamente dobrar a fatura mensal inteira.
| Prós | Contras |
|---|---|
| Virada sem downtime quando bem preparada | Capacidade quase dobrada durante a sobreposição |
| Rollback rápido de tráfego | Não reverte estado já alterado |
| Testes robustos de fumaça em pré-produção | Cache frio pode saturar dependências |
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, contemple a Manada em Fuga (Thundering Herd): o Green passa num health check raso, mas as primeiras requisições disputam cache e banco. O gateway começa a devolver 504 porque os upstreams não respondem a tempo. Código saudável; serviço indisponível.
o mito do rollback
Blue/Green é aclamado pelo sonho: aperto o Undo em 5 segundos. Isso pode ser verdade para o tráfego, mas não para o estado. Você consegue voltar o código. Não consegue desfazer automaticamente tudo o que ele já alterou.
- O Evento: Kafka publicou a notificação. 12 APIs 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ê limitar o estrago antes de precisar voltar?
Canary é uma das ferramentas mais fortes para limitar blast radius. Manda uma fração pequena do tráfego para a versão B, observa por uma janela definida e só então promove para percentuais maiores.
A Prática: Você começa com poucos usuários ou uma pequena fração de requests. Se os sinais piorarem, interrompe a promoção enquanto a maior parte da operação continua na v1.
É uma forma disciplinada de encontrar regressões antes que elas atinjam toda a base.
O Custo: Tempo, observabilidade e critérios estatísticos definidos antes do deploy.
| Prós | Contras |
|---|---|
| Blast radius controlado | Demanda automação confiável |
| Métricas de produção reais | Amostra pode ser insuficiente em baixo volume |
| Promoção orientada por sinais | Deploy lento por design |
configuração de deploy
parâmetros da estratégia
Não confunda teste A/B com Canary: Um teste A/B compara resultados de produto entre variantes. Um rollout Canary limita a exposição operacional enquanto valida se uma nova versão é segura. Eles podem usar o mesmo mecanismo de roteamento, mas respondem a perguntas diferentes.
a conta que ninguém quer fazer
Times compram o hype do Canary com pífios “15 minutos a 5%” antes do pulo cego pra 100%.
Se uma falha independente atingir 0,1% das requisições, cerca de 3 mil requests no Canary dão apenas 95% de chance de observar ao menos uma ocorrência: 1 - (1 - 0,001)^n ≥ 0,95. Com 5% do tráfego no Canary, isso exige aproximadamente 60 mil requests totais — e detectar uma piora contra o baseline, com confiança, costuma exigir uma amostra ainda maior e um teste estatístico explícito.
Deixar o tráfego 15 minutos pingando a 5% em baixo volume não é rigor técnico, é teatro de segurança. A janela de observação precisa nascer da taxa do evento, do volume e do sinal que realmente dispara a decisão.
Shadow — Trabalho sujo no escuro.
Na simulação, cada request é copiado para o ambiente shadow. Em produção, você também pode espelhar apenas uma amostra. A versão A continua respondendo ao usuário; em paralelo, a versão B processa a cópia — latência, CPU, erros e conteúdo da resposta — mas seu resultado não volta para o cliente.
Na Prática: Você roda a versão nova sob tráfego real sem colocá-la no caminho de resposta. Para não acrescentar latência ou pressão à produção, o espelhamento precisa ser assíncrono, isolado e sujeito a limites.
A armadilha dos side-effects: Sem isolamento, a versão shadow dispara e-mails, cobra cartões e escreve no banco — tudo duplicado. Recursos compartilhados também podem saturar e afetar a produção mesmo que a resposta shadow seja descartada.
O Custo: Com espelhamento integral e uma frota do mesmo tamanho, o compute pode chegar perto do dobro durante a janela. Amostragem e uma frota menor reduzem essa conta.
| Prós | Contras |
|---|---|
| Nova resposta fora do caminho do usuário | Custo extra proporcional ao espelhamento |
| Performance e divergência sob tráfego real | Isolar side-effects é difícil |
configuração de deploy
Quebre a simulação: Observe o contador em amarelo: nesta configuração, a frota shadow replica toda a capacidade de produção sem servir respostas externas. O custo compra evidência comparável — não ausência automática de risco. Se a resposta divergir ou o mirror falhar, o usuário continua na v1, mas sua validação ficou incompleta.
o blast radius
Cinco estratégias, cada uma respondendo de um jeito diferente às mesmas três perguntas. 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 pode não reconhecer as alterações da mais nova. Se um deploy remove uma coluna que instâncias v1 ainda leem, essas requisições começam a falhar. 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: Semanas ou meses depois, quando telemetria e código confirmam que nada mais lê o schema antigo, remove a coluna velha. Um deploy aparentemente simples pode atravessar várias entregas até 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 o comportamento operacional. Um
timeoutcurto, readiness prematuro ou batch size agressivo podem transformar um rollout gradual em indisponibilidade. - 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.
resultado das simulações desta página
Cemitério de Requests
Aqui ficam as falhas acumuladas enquanto você experimenta as estratégias.
O cemitério está vazio
Execute uma simulação acima. Os resultados desta sessão aparecerão aqui.