Implantação Zero-Downtime

(Seção: Arquitetura e Protocolos)

1) O que é Zero-Downtime e porquê

• Zero fácil para clientes e integrações.
• Lançamentos previsíveis, reversão rápida e risco controlado.
• Manter o SLO/SLI (latência, erros, disponibilidade) nos limites dos acordos.

A chave para o ZDT não é uma técnica «mágica», mas uma combinação de patterns de entrega, compatibilidade de dados e roteamento de tráfego adequado.

2) Princípios básicos Zero-Downtime

1. Compatibilidade de versões: versões novas e antigas devem processar o tráfego e os dados de forma correta ao mesmo tempo.
2. Idempotidade das operações: O reaproveitamento não deve quebrar o estado.
3. Conclusão graceful (graceful shutdown) e drenagem de conexões.
4. Teste de saúde passo a passo: readiness/liveness amostras, health endpoint.
5. Retrocesso como primeira classe cidadão: rollback mais fácil e rápido do que hotfix.
6. Observabilidade by design: marcas de lançamento, dashboards unificados, alertas SLO.
7. Automação: cenários de lançamento e reversão - código, não instruções manuais.

3) Pattern de entrega sem downthame

3. 1 Rolling Update

Gradualmente, tiramos do tráfego algumas instâncias da versão antiga, atualizamo-las para uma nova versão e devolvê-las ao pool.

Vantagens: eficiente em infraestrutura, apenas em k8s/ASG.
Contras: há algum tempo, o cluster funciona com duas versões simultâneas (version skew).

3. 2 Blue-Green

Duas pilhas de prod completas: ativa (Blue) e candidato (Green). Mudança de tráfego - flip atômico.

Os benefícios são o retrocesso instantâneo, o isolamento puro.
Contras: ↑ gastos em infraestrutura, mais difícil com o stateful.

3. 3 Canary/Rollout progressivo

Damos uma pequena proporção de tráfego (1-5-10-25-50-100%) à nova versão com gates em métricas.

Os benefícios são o mínimo blast radius, data-driven da solução.
Contras: precisa de observação madura e rotação inteligente.

3. 4 Shadow traffic / Dark launch

Espelhar as solicitações reais para uma nova versão (sem resposta ao usuário) ou executar oculto para coletar métricas.

Vantagens, detecção precoce de problemas.
Contras: dupla carga de dependência, precisa de controle de efeitos colaterais.

4) Controle de tráfego e conexões

4. 1 Readiness/Liveness

Liveness diz ao orquestrador «reinicie-me».
Readiness - «Não dirijas o tráfego, ainda não estou pronto».
Não se pode soltar sem uma lógica readiness correta ou um tempo.

4. 2 Drenagem de conexões (Connation Draining)

• deixamos de aceitar novas conexões,
• aguardando a conclusão dos ativos,
• Interrompemos os «dependentes» por tempo.

4. 3 sessões de Sticky e rotação de nível L7

Sticky é útil para os cenários stateful, mas torna o equilíbrio de carga mais difícil.
As regras L7 (no caminho, cabeçalho, cookie, API) são fáceis para canary/ring.

4. 4 Compostos de longa vida

WebSocket/gRPC streaming: Antes de atualizar, ative o estilo drain + sinal «GOAWAY».
Planeje o windows para superar striptease e bacof-retrai clientes.

5) Compatibilidade de dados e migração de banco de dados

5. 1 Expand-Migrate-Contract

1. Expand: Adicione novas colunas/índices/tabelas sem quebrar a versão antiga.
2. Migrate: Transferimos dados de fundo e idumpotente (batches, checkpoint).
3. Contract: Só removemos o antigo após a estabilização.

5. 2 Práticas

Evite DDL exclusivos na janela de lançamento.
Versionize os contratos de API/evento (schema registry, CDC).
Para as migrações pesadas - ferramentas online, réplicas, mudanças graduais.
Gravação de dois contornos (dual-write) somente com dedução e usuários idumpotentes.
Outbox/Inbox para uma integração segura através de filas.

6) Cachês, sessões e tarefas de fundo

As sessões e o dinheiro são externos (Redis/Memcached) para que as versões sejam trocadas.
Aquecimento do cachê/jit/índice de ritmo antes de ser incluído no pool.
Divida as filas de fundo por versão ou use a liderança para evitar corridas.

7) Observabilidade e gates SLO

Golden signals: latência p95/p99, errante rate, RPS, saturação, fila de fila.
SLA de negócios: autorizações, conversões, pagamentos bem sucedidos, rejeição de passos de vórtice.
Gates: rollout só avança se canary ≤ baseline + liminares de degradação, e o Error Budet não queima.

8) Fim seguro e retrocesso

A reversão é o mesmo pipline, apenas para o lado inverso: comandos fixos, não craft manual.
Para blue-green - flip back; canary - baixa de peso de 0% ou passo estável anterior.
Dados: transações compensadoras, reaproveitamento, dedução de eventos.

9) Folhas de cheque Zero-Downtime

Antes do lançamento

• Coletado um artefato assinado (imutável), SBOM e verificação de dependências.
• Readiness/liveness implementados e testados.
• Plano de migração em modo expand, reversível confirmado.
• Dashboards e alertas para a nova versão estão prontos, as marcas de lançamento estão contidas.
• A reversão foi verificada em staging/pré-prod.

Durante o lançamento

• A drenagem das conexões está ativada e os temporizadores são adequados.
• O tráfego é traduzido gradualmente (canary/ring) ou flip (blue-green).
• As métricas são comparadas com baseline, e as liminares de gate são cumpridas.

Após lançamento

• Monitoramento post-N relógio, nenhum incidente.
• Migração contract concluída e bandeiras temporárias/rotas removidas.
• Retrospectiva, atualização de playbooks.

10) Anti-pattern

Recreate-deplay sem drenagem e readiness ⇒ as aberturas de solicitação.
DDL não preparados ⇒ bloqueios e temporizações no horário nobre.
Mistura esquemas incompatíveis entre versões do serviço.
Não há idempotidade em processadores e workers.
«Aluguer por sensações» sem gates ou comparação com baseline.
DNS-TTL comprido com blue-green, o que faz a flip durar horas.
Sessões locais/dinheiro na memória da sala de aula de rolling/canary.

11) Cenários de implementação

11. 1 Kubernetes (rolling + canary)

Deployment с `maxUnavailable=0`, `maxSurge=25%`.
Readiness está à espera de aquecimento (inicialização do cachê, migração menor).
Serviço-mesh/Ingress com weighted roting (1-5-10-25-50-100%).
Alerts, p95, 5xx, fila, vórtice de negócios.

11. 2 Blue-Green na nuvem

Duas pilhas atrás do balanceador. example. com` и `green. example. com`.
Aquecimento green, smoke/regresso, em seguida listiner/road swap (ou mudança DNS com TTL baixo).
Com problemas, flip back instantâneo.

11. 3 Estateful-serviço

Réplicas de dados + migração online; dupla leitura com validação.
Os fundos de fundo são transferidos pela «liderança» da versão ou por filas divididas.
Sessões/dinheiro fora de instância; o sticky está ligado apenas temporariamente.

12) Ficheflags e aplicativos de clientes

Os novos fichas são ativados com bandeiras (segmentos: funcionários → beta → todos).
Para os clientes móveis/desctop, leve em conta os limites de compatibilidade de protocolo e a vitalidade de versões antigas (deprecation policy, server-side fallback).

13) Desempenho e custo

Rolling é mais barato, mas exige compatibilidade cuidadosa.
O Blue-Green é mais caro durante o lançamento, mas a reversão é instantânea.
Canary reequilibra riscos e custos, mas requer forte observabilidade.
Economize através da proeminência ephemeral e limpeza automática dos estandes.

14) Mínimo ZDT ZDT

1. Build: artefacto único, assinatura, SBOM.
2. Test: unit/integration/contract + security.
3. Staging: smoke, carga, migração em modo expand, verificação de reversão.
4. Prod: shadow → canary (gates) ou blue-green flip.
5. Post-deploy: observação, contracto-cleanup, retrô.

15) Resumo breve

Zero-Downtime é uma disciplina: versões compatíveis + rotação correta + migrações controladas + observabilidade e reversão rápida. Selecione o pattern sob o contexto (rolling, blue-green, canary), automatize os gates por SLO, mantenha os dados idimpotentes - e os lançamentos deixarão de ser um evento, tornando-se um processo de rotina confiável.