Estratégias Rollback e lançamentos atômicos

Estratégias Rollback e lançamentos atômicos

1) Por que precisa de um retorno rápido

• Reduzir o MTTR para minutos.
• Limitar o raio de impacto (mínimo de usuários/transações afetados).
• Preservar a integridade dos dados e a compatibilidade dos contratos.

A chave é construir lançamentos para que a reversão seja uma ação trivial, não um projeto.

2) Conceito de «lançamento atômico»

Lançamento atômico - quando a inclusão de uma nova versão/comportamento pode ser executada (e cancelada) por uma única cirurgia atômica sem efeitos colaterais duradouros.

• Artefato imutável (imagem assinada/pacote).
• Configs versionizados (versão promovida em vez de edição manual).
• Separar «entrega» de «inclusão» (rotação/bandeiras).
• Padrão de dados compatível (ambas as versões podem viver simultaneamente).
• Runbook reversão: um passo compreensível (mudança de seletor/peso/bandeira) + verificação.

3) Inventário de mecanismos de rollback

3. 1 Nível de tráfego (mais rápido)

Blue-Green: mudar o seletor/target group para uma versão estável.
Canary: baixar o peso para 0% e congelar a progressão.
Gateway/NGINX/Service Mesh: recuperar os pesos/rotas anteriores.

3. Nível de montagem 2

Helm/Argo Rollouts: 'abort/rollback' para a revisão anterior.
GitOps: revert MR/commit no repositório manifesto (o controlador fará o resto).

3. 3 Aplicativo/fichas

Função-flags/kill-switch: desliga instantaneamente o caminho de risco.
Toggle configh, voltar ao anterior config.

3. 4 Dados

Migração roll-forward (preferida) + compatibilidade.
Ponto-in-time recovery (PITR) e bacapes para acidentes.
Compensações (Saga) e idempotency para ações reversíveis.

4) Pattern «expand → migrate → contract» (BD)

Para que a reversão seja segura, o esquema de dados deve permitir que as versões antigas e novas possam ser vividas.

1. Expand - Adicionar novos campos/índices (nullable) sem quebrar a lógica antiga.
2. Migrate - dupla gravação/leitura, back-fill, job's de fundo com idempotency.
3. Contract - Remover campos/código antigos após sair 100% da janela.

5) SLO-gating e auto-revezamento

A entrada de cada estágio de lançamento deve ser «guardada» por métricas.

SLO técnico: p95/p99 Latitude, 5xx-rate, saturação (CPU/Memory), erro-budet burn.
Métricas de negócios: CR de depósito/caixa, pagamentos negados, juros de frode, erros KYC.

• 5xx > 0. 5% 10 minutos → rollback.
• p95 ↑> 20% da → básica hold + análise.
• Erro no PSP> 0. 3 p.p. → rollback + mudança de rota de pagamento.

6) Exemplos: Kubernetes/Helm/Argo/NGINX

6. 1 Blue-Green (K8s Service selector)

yaml
Service points to "blue"; switch to green - change selector apiVersion: v1 kind: Service metadata: {name: app-svc}
spec:
selector: { app: app, version: blue }
ports: [{ port: 80, targetPort: 8080 }]

Retrocesso = devolver o seletor para 'blue' (atômico, sem cruzamento).

6. 2 Canary (Istio VirtualService веса)

yaml http:
- route:
- destination: { host: app, subset: stable } # 100 weight: 100
- destination: { host: app, subset: canary } # 0 weight: 0

Retrocesso = weight canary → 0, stable → 100.

6. 3 Argo Rollouts — abort

yaml kubectl argo rollouts abort app # stop and return to stableService

6. 4 Helm - rollback para revisão

bash helm history app -n prod helm rollback app 17 -n prod # revert to revision 17

6. 5 NGINX - upstream peso

nginx upstream app {
server blue:8080 weight=100;
server green: 8080 weight = 0; # rollback - return 100/0
}

7) Função-flags e kill-switch como «paraquedas»

Kill-switch para fluxos de alto risco (depósitos/pagamentos/bônus) - obrigatório.
Stickiness: Atribuir «opção» aos usuários através de uma chave de hash - comparações previsíveis.
Fail-safe: se o servidor de bandeiras não estiver disponível, um default seguro.

ts const enabled = flags. bool("new_cashout_flow", false);
if (! enabled) return classicFlow () ;//instant rollback - disable the return newFlow () flag;

8) Contratos de API e eventos: como não «quebrar o retrocesso»

Versionize contratos (OpenAPI/gRPC/Avro): A nova versão adiciona campos, não altera a semântica dos antigos.
Event-versioning: 'tipo = v2', os consumidores são obrigados a ignorar campos desconhecidos.
Outbox + Idempotency: Qualquer repetição de evento é segura, e o consumidor é idimpotente.

9) Transações compensadoras (Saga)

• Fizeram o cancelamento - compensação, reembolso, registo, registo.
• Registro de compensação e retrai antes do sucesso.
• Chaves Idumpotentes para cada cirurgia.

json
{
"sagaId": "b7d2...",
"action": "withdraw. execute",
"idempotencyKey": "user123:withdraw:7845",
"compensation": "withdraw. refund"
}

10) Configs e segredos: retrocesso como versão

Armazene configs como artefatos com versões (semver/commit-sha).
Retrocesso = Retornar config à versão anterior (GitOps revert) em vez de «corrigir com as mãos».
Segredos - por armazenamento (KMS/Vault); rotação e versionagem estão incluídos no lançamento.

11) Runbook reversão (mínimo)

1. Pausa de progressão (canary/rollouts).
2. Retorno do tráfego (peso/seletor).
3. A verificação de SLO/métricas de negócios voltou para a linha de base.
4. Estabilizar os job's de fundo (parar a migração/back-fill se necessário).
5. Incidente e pós-faturamento, artefactos (logs/trailers/métricas), hipóteses, correção.
6. Limpar: fechar as bandeiras, remover o código deixado, devolver os horários de job's.

12) Políticas de proteção automática

Impede 'latest' e marcas de formatação para imagens.
Controlo admissional, apenas artefactos assinados.
Porta CI: SAST/SCA/Policy-checks deve ser verde para promoção.
Janela Freeze: proibição de lançamentos/peso> X% em períodos de risco.

13) Frequentes anti-pattern

«Retroceder» base de DDL-para-baixo em vez de compatibilidade - bloqueios longos/simples.
Migrações instantâneas sem idempotency e back-fill.
Misturar «entrega» e «ativação» - não é possível recuperar o tráfego rapidamente.
Edição manual em prod config sem auditoria.
Não há kill-switch em pagamentos/saques.
Cruzamento de artefato para prod (violação «build once - run many»).
Não há um único botão de reversão/runbook não trabalhado.

14) Folha de cheque de implementação (0-45 dias)

0-10 dias

Ativar Blue-Green/Canary em serviços essenciais.
Proibir 'latest', incluir a assinatura de imagens e o histórico Helm/Argo.
Ligar tábuas SLO (latency, 5xx, sinais de negócio chave).

11 a 25 dias

Implementar kill-switch para o risco-flow.
Traduzir migração de BD para expand-migrate-contract + idempotency.
Adicionar auto-stop/rollback por SLO (Argo AnalisTemplate/alertas).

26-45 dias

Versionizar configs (GitOps), reverter por MR-revert.
Rodar o runbook em «game-day» (simulação de incidente e reversão).
Impor compensações Saga onde não é possível reverter «para baixo».

15) Métricas de maturidade

MTTR reversão: alvo <5 min

% de lançamentos onde o retrocesso = mudança de rota/bandeira (sem cruzamento)> 90%.
Taxa de migração expand-migrate-contract> 90%.
Cobertura de serviços kill-switch bandeiras> 95%.
O número de incidentes devido a esquemas/contratos incompatíveis → 0.

16) Aplicativos: mini-modelos

Argo AnalysisTemplate: pare a 5xx

yaml apiVersion: argoproj. io/v1alpha1 kind: AnalysisTemplate metadata: { name: guard-5xx }
spec:
metrics:
- name: http_5xx_rate interval: 1m successCondition: result < 0. 005 provider:
prometheus:
address: http://prometheus. monitoring:9090 query:
sum(rate(http_requests_total{app="app",status=~"5.."}[5m])) /
sum(rate(http_requests_total{app="app"}[5m]))

Kubernetes: reversão rápida do Deployment

bash kubectl rollout undo deploy/app -n prod

Helm: lançamento atômico

bash helm upgrade --install app chart/ \
--atomic \
--timeout 5m \
--set image. tag=v1. 9. 3

NGINX: «torneira» para canarinhos

nginx map $cookie_canary $weight {
default 0;
"~ on" 10; # enable 10% by cookie
}

17) Conclusão

Um retrocesso confiável não é um botão de incêndio, mas uma propriedade de arquitetura: artefatos de imutabos, separação de entrega e inclusão, esquema de dados compatível, bandeiras de fich e gaiting SLO. Construa lançamentos atômicos, ensaia runbook e automatize os portões de segurança - e qualquer lançamento será reversível em minutos, sem dor para os usuários e empresas.