Estratégias de lançamento: blue-green e canary

(Secção Tecnologia e Infraestrutura)

Resumo curto

O Blue-Green oferece uma mudança instantânea entre dois vidros completos (Blue/Green) com uma retração simples. Canary está gradualmente aumentando a proporção de tráfego para uma nova versão sob controle de gates SLO (latência, error-rate, métricas de negócios). Para iGaming é uma forma de lançar sem downthame no auge dos torneios e promoções, mantendo o p99 estável e qualidade.

1) Quando escolher

Blue-green - lançamentos rápidos, complexidade mínima, precisa de um orçamento de cluster duplo/recursos. Bom para API/frente sem migração de estado.
Canary - lançamentos de alto risco (novos flow, mudanças críticas), permite «capturar» degradação entre 1% e 5% do tráfego. Requer telemetria e gates automáticos.

2) Princípios arquitetônicos

1. Rotação L7: balanceador/Ingresss/serviço-mesh (módulos de tráfego ponderado, cookie/flag-routing).
2. Dependências isoladas, configurações, fichiflags, segredos, cachês - separados para revisões.
3. Compatibilidade de dados: migração de BB para frente-compatível (expand→migrate→contract).
4. Observabilidade: rótulos/editoras individuais de versões em métricas/logs/trens.
5. Auto-gates: comparação p95/p99, erro-rate, negócio KPI; rollback automático.

3) Blue-green: pattern básico

Fluxo

1. Implantando o Green (cópia do Blue) → aquecendo o cachê/conexão.
2. Iniciando os testes de health-/smoke.
3. Alterna o tráfego (DNS/LB/Ingress) para Green.
4. Mantemos o Blue em estado «quente» como fallback até ao fim da janela.

Exemplo: mudar para o nível do Insress (ideia)

yaml
Annotated/Backend Option - In Prod, it is usually controlled by the spec operator/rollout:
rules:
- host: api. example. com http:
paths:
- path: /
backend:
service:
name: api-green # used to be api-blue port:
number: 80

Prós/contras

Um simples retrocesso (devolvido pela Blue).
Hora de lançamento previsível.
Requer duplicação de recursos.
Risco de «Big Bang» sem medida canareira.

4) Canary: ampliação gradual

Fluxo

1. O tráfego shadow (opcional) → 1% do tráfego real → 5% → 25% → 50% → 100%.
2. Cada estágio tem gates SLO/métricas de negócios.
3. Em caso de degradação, auto-recall e preservação de artefatos de diagnóstico.

Exemplo: Argo Rollouts (fatia)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: payments-api }
spec:
strategy:
canary:
canaryService: payments-canary stableService: payments-stable steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: slo-latency
- setWeight: 25
- pause: { duration: 10m }
- analysis:
templates:
- templateName: error-rate
- setWeight: 50
- pause: { duration: 20m }
- setWeight: 100

Exemplo: Flagger + Istio/NGINX (ideia)

yaml apiVersion: flagger. app/v1beta1 kind: Canary metadata: { name: games-api }
spec:
targetRef:
apiVersion: apps/v1 kind: Deployment name: games-api service:
port: 80 analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke

5) Aquecimento e gerenciamento de estado

Cachês/fontes: aqueça o Redis/HTTP-dinheiro/CDN, prepare as conexões warm-pool para o banco de dados/PSP.
ML/LLM/modelos: Barateamento de balanças/índices/embeddings, KV-cash, consultas primárias para «aquecimento».
Arquivos/artefatos: conteúdo estático, modelos, configs - forneça com antecedência para volume local/sidecar.
Ficheflagi: rollout em 1% a 5% do público/segmento, capacidade emergency-kill.

6) Bancos de dados: estratégia «expand → migrate → contract»

1. Expand: adicionar nullable/novas colunas/índices, suportar ambas as versões.
2. Migrate: o código usa um novo padrão; os velhos caminhos permanecem valiosos.
3. Contract: Removemos os campos/índices antigos após a aparência completa.

As revistas registram a versão do esquema e do cliente; todas as alterações são idoneais.
Para as migrações pesadas, existem janelas de negociação de fundo, throttling e «stop-the-world».

7) Observabilidade e gates (SLO/SLA)

Métricas SRE: p50/p95/p99, error-rate, saturação (CPU/GPU/IO), queue-depth, tempo de partida frio.
Métricas de negócios: conversão de pagamentos, sucesso de apostas, tempo de saída (TTW), respostas de promoção.
Qualidade de conteúdo/LLM: tocens/s, comprimento de resposta, toxicidade, RAG-score.
Gates: promoção automática/reversão ao sair das liminares e/ou quando a «métrica útil» cair.

gate:
p95_latency_ms <= 250 error_rate %  <= 1. 0 payment_conv  >= baseline - 0. 3%
action:
promote      rollback

8) Lançamento-orquestra e integração com CI/CD

GitOps: alterações de versões/peso - por PR para um repositório manifesto.
Máquinas automáticas: smoke/e2e antes do tráfego começar.
Planeamento de lançamento: agendamento de estágios canary, responsáveis, canais de ChatOps, janelas de reversão.
Arquivamento de artefatos, configs de routing, snipshots de dashboards, logs de comparação de métricas.

9) Multiregião e edge

Ordem: primeiro a região «menos crítica »/RR, depois as principais.
Latency-based roting: acompanhe o SLO local; não misture o tráfego sem razão.
A Blue na região-A pode ser uma área de Dr. Green na região-B.

10) Segurança e compliance de lançamento

Imagens assinadas/lista, SBOM; verificação de assinaturas em políticas admissórias.
Segredos: apenas gerentes externos; versões independentes para Blue/Green.
PII/regionalidade: Não tire o tráfego do PII pela região «alheia»; disfarça os logs na comparação.
Auditoria: Quem promoveu, quais gates funcionaram, onde é que o repasse.

11) Exemplos de configuração

NGINX: canarinho por cookie/cabeçalho (ideia)

nginx map $http_x_canary $canary {
default 0;
"1"   1;
}

upstream api_stable { server stable:80; }
upstream api_canary { server canary:80; }

server {
location / {
if ($canary) { proxy_pass http://api_canary; }
proxy_pass http://api_stable;
}
}

Função-flag «fractional rollout» (pseudo)

yaml feature: new_checkout rollout:
percentage: 5 criteria:
country: ["TR", "BR", "MX"]
cohort: "new-users"
kill_switch: true

12) Runbooks (cenários típicos)

P99 em canais: pare a promoção → aumenta o batch/timeout, desliga os fichas pesados através de bandeiras → reinicie parte do suporte.
Queda na conversão de pagamentos: compare as rotas PSP/fici, incluir a regulação shadow, reverter para estável.
O problema com a migração de BB é congelar o tráfego para a gravação, ativar o modo read-only, reverter o esquema (se possível) e corrigir o sistema de emergência.
O incidente PII é cortar a versão canária, recuperar segredos, relatórios e auditorias.

13) Folha de cheque de implementação

1. Defina a política: onde está o blue-green, onde está o canary; o que é considerado «crítico».
2. Configure o roteiro ponderado (Ingress/mesh/roteador).
3. Fixe os liminares SLO e reversíveis automáticos.
4. Realize expand→migrate→contract para o banco de dados; testes de migração.
5. Ative o aquecimento em dinheiro/modelo e conexões warm-pool.
6. Digite o GitOps e registro de todos os lançamentos.
7. Visualize a comparação entre as métricas (a vs canarela é estável).
8. Realize o game-day: simule o retrocesso/fracasso do gate/problema do banco de dados.
9. Documente o runbooks e o botão vermelho (kill-switch).
10. Planeje os lançamentos multiregião por vez, em vez de simultaneamente.

14) Anti-pattern

O lançamento canário sem gates e telemetria → mais tarde a detecção de degradações.
Misturar o padrão de base de dados: migrações destruidoras até a divulgação do código.
Uma caixa de espera compartilhada para Blue e Green sem isolamento → o impacto mútuo.
Alternância DNS com TTL baixo sem verificação - «flapping» de tráfego.
Segredos/configs comuns para ambas as revisões → um retrocesso difícil.
Tráfego sem shadow/smoke - risco de «big bang».
Falta kill-switch/função-flag para desligar rapidamente.

Resumo

O Blue Green fornece uma mudança instantânea e simples, canary - risco controlado e detecção precoce de problemas. Em iGaming, ambos os pattern combinam o canal em mudanças «agudas» + blue-green como um mecanismo básico sem downthame. Adicione SLO-gates, GitOps, aquecimento, compatibilidade de BD e isolamento de dependências - e lançamentos serão previsíveis, reversíveis rápidos e p99 e métricas de negócios estáveis mesmo em períodos de pico.