Blue-Green e Canary lançamentos

(Seção: Arquitetura e Protocolos)

1) Para quê «saques seguros»

Em sistemas modernos, o lançamento não é apenas uma entrega de código, mas também uma experiência controlada de venda: ao mesmo tempo, minimizamos o risco (sem quebrar usuários) e reduzimos o tempo de feedback (vendo rapidamente o efeito). Duas estratégias clássicas, a Blue-Green e a Canary, resolvem isso de uma forma diferente, mas com um objetivo comum: downthame zero, reversão rápida, observabilidade SLO.

2) Definições básicas

Blue-Green

Mantenha duas cópias completas do ambiente de prod: A (Blue) ativa serve o tráfego; a (Green) passiva prepara uma nova versão. A mudança é atômica (switch/flip) ao nível do balanceador/roteador. Se piorar, voltamos para a Blue...

Canary

Primeiro, um pequeno% do tráfego (por exemplo, 1% a 5%), observamos métricas/SLO, e depois aumentamos passo a passo (10% → 25% → 50% → 100%). Em caso de degradação, reverter ou parar no passo estável anterior.

3) Quando a melhor abordagem

• Precisamos de um regresso instantâneo sem manobras complicadas.
• Arquitetura/orçamento permite duplicação dupla de infraestrutura.
• Queremos fazer migrações em larga escala ou atualizações de plataforma (OS/JDK/rentaim) isoladamente.
• A aplicação/pool de conexões é sensível a um estado gradual «misto».

• É preciso minimizar o radius blast e ver o comportamento na proporção dos usuários.
• Alta taxa de lançamento, entrega progressiva como normal.
• Há observabilidade madura e gates automáticos (error budget, latency, conversion).
• A equipa de alimentos quer verificar os efeitos da conversão, retenção, LTV, etc.

4) Princípios gerais de lançamento bem-sucedido

Artefatos Bilos Idumpotentes, a mesma imagem/pacote em todas as etapas.
Configuração definida, config como código, comparabilidade de ambientes.
Observabilidade by design: logs, métricas, traçados, alertas; SLI/SLO com antecedência.
Retrocesso rápido e automático: botão/comando de reversão - parte do Pipline, não magia manual.
Mudanças de padrão compatíveis: estratégia de expand-migrate-contract (consulte o parágrafo 10).
Rotação L7 (preferencialmente): flexibilidade em cabeçalhos/cookies/caminhos/versões da API.

5) Blue-Green: arquitetura e processo

5. 1 Topologia

Duas pilhas de prod, Blue (ativo) e Green (candidato).
Dependências externas comuns, CDN, APIs externas, filas; O Banco de Dados é um caso especial (consulte por. 10).
Ponto de mudança: balanceador/Ingress/Gateway.

5. 2 Passo a passo flow

1. Levantamos o Green sob um artefacto novo.
2. Inspeção de carros contra Green (e2e, contratual, regressão).
3. Aqueça o dinheiro/sessão (se aplicável) e sincronize o fundo/fila.
4. Alterna o tráfego para o Green: flip atômico (DNS TTL baixo, Rota/Listiner swap, Ingress weight = 100%).
5. Observamos SLO nos primeiros minutos/horas (golden signals: latency, errors, saturation + métricas de negócios).
6. Problemas: retorno instantâneo ao Blue (flip back).

5. 3 prós/contras

Os benefícios são o retrocesso instantâneo, o modelo mental simples, o isolamento puro.
Contras: duplicação da infraestrutura, dificuldade com componentes estateful e migração de dados.

6) Canary: arquitetura e processo

6. 1 Topologia

Um único cluster de prod; várias versões do serviço (stable e canary) em frente.
O tráfego é dividido por balança (1-5-10-25-50-100%) ou por destino (cabeçalho/coque/ID).

6. 2 Passo a passo flow

1. Deploy canary no mesmo cluster/ASG/NSG.
2. Roda parte do tráfego (por exemplo, 1-5%) em canary.
3. Verificações automáticas de SLI/SLO e métricas de negócios; gates em CI/CD (erro rate, p95 latency, CPU/RES, conversão, rejeição/retorno).
4. Aumento passo a passo da proporção de tráfego durante a passagem de gates.
5. Rollout completo até 100% e desativação da versão antiga; em degradação - auto-rollback.

6. 3 prós/contras

Vantagens: risco mínimo para a maioria dos usuários, solução data-driven.
Contras: É preciso observação madura, instrução adequada, risco de «version skew» entre as instâncias.

7) Rotação de tráfego

Nível L4: equilíbrio IP/portos; simples, mas pouca flexibilidade.
Nível L7: regras HTTP/S - no caminho, hóspede, cabeçalho, cookie, User-Agente, GeoIP, SNI.

• Weighted itinering (peso 1-100%).
• Header-based/Cookie-based (fixar o usuário em um grupo).
• Sessão stickiness (importante para os cenários stateful/cajados).
• Shadow/Traffic mirroring (espelhando os pedidos para uma nova versão «silenciosa»).

8) Ferramentas e implementações (exemplos)

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.
Облака: AWS ALB/ELB, Route 53 weighted records, ECS/EKS; GCP Load Balancing + NEG; Azure Front Door/App Gateway.
Plataformas de CD: Spinnaker, Argo CD, GitHub Action + Progressive Delivery plugins, GitLab/CD.

9) Observabilidade, SLI/SLO e gates

Golden signals: Latency (p95/p99), Error rate (5xx/4xx по типам), RPS, Saturation (CPU/Memory/GC), Queue lag.
Métricas de negócios: conversão, permissões, pagamentos/progressos, cheque médio, rejeição de passos de vórtice.

• Limite de erro (por exemplo, error rate canary ≤ baseline + X%).
• A latência p95 é tão boa quanto a baseline em mais de 1 segundo.
• Limite de negócios (por exemplo, queda da conversão
• O Error Budget SLO não deve ser acelerado.

Duração do passo: tempo mínimo suficiente para a importância estatística (dependendo do tráfego).

10) Migração de base de dados e compatibilidade de circuitos

A regra principal é que os lançamentos são seguros se as versões para trás e para frente forem compatíveis.

1. Expand: Adicionamos novas colunas/índices/tabelas sem quebrar a versão antiga.

2. Deploy app vNext (leia/escreve em um novo esquema, mas também pode trabalhar com o antigo).

3. Migrate data (background/batch, idimpotente, com checkpoint).

4. Contract: Removemos os campos/fichas antigos após a estabilização.

Anti-pattern: migração que requer bloqueio exclusivo no momento em que o Blue-Green muda; a impossibilidade de um esquema de downgrade; «gravação dupla» sem dedução.

11) Retrocesso (rollback) e planos de acidentes

Blue-Green: flip instantânea na Azul; Monitorial de cauda de fundo do Green.
Canary: reversão de peso (por exemplo, de 25% para trás de 5% ou 0%); abort automático com alertas.
Dados: políticas de repetição/compensação elaboradas (idempotency keys, «inbox/outbox» pattern, dedução de mensagens).
Phicheflagi: rápido kill switch para desativar a capacidade parcialmente desativada.

12) Trabalhar com bife e sessões

Sticky sessions para canarinhos, ou armazenamento de sessões no exterior (Redis/Memcached) para que as versões sejam trocáveis.
O dinheiro aquecer com antecedência (Green warm-up) e considerar a invalidação na flip.
Worker de fundo: Não permita «corridas» entre versões - Separar filas ou «liderança» de versão.

13) Segurança e conformidade

Acesso ao Green/Canary - por Zero Trust - contas de serviço, funções minimamente necessárias.
Segredos e chaves - através do KMS/Segredos Gerente; Acendam a rotação.
Tráfego - apenas TLS; as versões de endpoint 'ov estão claramente marcadas; auditoria de rotação e lançamentos.

14) Custo e desempenho

Blue-Green dobra a infraestrutura (durante o lançamento ou permanentemente) - coloque o orçamento.
Canary é mais econômico, mas requer ferramentas de observabilidade e tempo de engenharia para automação.
Otimização: skailing automático, ambiente ephemeral, redução da janela de versões paralelas.

15) Folhas de cheque

Antes do lançamento

• Imagem/cartão foi percorrido a partir de uma única fonte, e as assinaturas foram verificadas.
• Plano de teste, alertas e gates SLO configurados.
• Migração de BB - em modo expand, os planos de downgrade estão disponíveis.
• Plano de reversão - verificado em staging/producition-like.

Durante o lançamento

• Métricas e logs são comparados com baseline.
• Para Canary - passos e liminares são registrados; para Blue-Green - disposição flip-back.
• Os comandos on-call estão cientes, há uma janela de feedback.

Após lançamento

• O SLO não pediu, o erro é normal.
• Migração pós-lançamento/limpeza concluída.
• Retrospectiva e atualização de playbooks.

16) Erros frequentes e anti-pattern

Sem métricas, sem dados, sem solução controlada.
Mistura de esquemas de base de dados incompatíveis, falta de estratégia de downgrade.
Combinação aleatória de tráfego: sem stickiness, usuários saltando entre versões.
Dependências estateful ocultas (discos locais, in-memory cachês).
O longo DNS-TTL atrapalha a rápida flip (Blue-Green).
Falta de auto-gates: soluções manuais travam e aumentam os riscos.

17) Abordagens combinadas

Blue-Green + Canary: Primeiro, arranje o Green e, no interior do Green, espalhe o Canary para serviços individuais.
Shadow/Migração de tráfego: Antes do Canary, execute o tráfego de espelhos para a nova versão.
Função flags (progressive delivery): a função é ativada sobre uma versão estável de bandeiras escuras por segmentos.

18) Exemplos de cenário (esboços)

1. Desenrolar o Green (v2) atrás do novo Listiner/Ingress.

2. Aquecer os cachês, fazer verificações readonly, smoke.

3. Alterando o peso para Green = 100%.

4. Observamos um SLO de 30 a 60 minutos; Se estiver tudo bem, desligamos a Blue.

1. Deploy canary vNext (réplicas de 5%).

2. Activamos o tráfego de 5% para contas/segmento de teste interno.

3. Regate automático: erro rate ≤ baseline + 0. 3%, p95 ≤ +20ms.

4. Elevamos 10% → 25% → 50% a cada N minutos quando passamos gates.

5. Traduzimos 100% do fichiflag em todos os segmentos; removemos a versão antiga.

19) Variações para diferentes arquiteturas

Monolito: Blue-Green é mais simples, Canary é mais difícil devido à indivisibilidade do Fich; use os fichicheflags.
Microsserviços Canary é natural; acompanhe os contratos entre servidores (consumer-driven contracts).
Estateful Serviços: prefira Blue-Green com migrações cuidadosamente elaboradas e stickiness.

20) Comparação breve (resumo)

Velocidade de reversão: Blue-Green = instantaneamente; Canary = rápido, mas com recuo de peso.
Custo da infraestrutura: Blue-Green ↑; Canary ↔︎/↓.
Risco para os usuários: Canary inferior (controle de participação).
Dificuldade de implementação: Blue-Green mais fácil de iniciar; Canary requer forte observabilidade e automação.
Compatibilidade de dados/diagramas: crítico para ambos; planeje o expand-migrate-contract.

21) Total

Blue-Green e Canary não são estratégias mutuamente exclusivas, mas sim elementos de entrega progressiva. A escolha depende dos limites de custo, maturidade de observabilidade e natureza das mudanças. Independentemente da abordagem, o lançamento sustentável é mantido em quatro pilares: automação, observabilidade, compatibilidade inversa e retrocesso rápido.