Reversão automática de lançamentos

1) Por que precisa de um auto-recall

• reduz o CFR e o MTTR;
• protege o SLO (auth-sucess, p99 «stavka→settl», erro-rate);
• impede incidentes complicados (PII/RG/AML).

2) Princípios

1. Revert is a função: O retrocesso está previsto para o desenho de lançamento.
2. Policy-as-Código: liminares, janelas, exceções - validação na linha de montagem.
3. Canary-first: promoção de degraus, reversão de estágios espelhados.
4. Data-safe: as migrações são reversíveis/somativas; configh - versioniruemas.
5. SLO-gates: vermelho SLI/guelrails → revezamento automático imediato.
6. Explorabilidade: Timeline, Difs, Razões - Revista WORM.
7. No single button of doom: restrições, confirmação de risco-ação, SoD.

3) Desencadeadores de reversão de carro (sinais)

3. 1 SLI técnico/KRI

auth _ sucess _ rate drop por GEO/PSP/BIN (por exemplo, 10% em TR ≥10 min).
latency p99/erro-rate caminhos-chave (depósito/retirada/setl).
queue lag / DLQ rate / retry storm.
db replication lag / cache miss surge.

3. 2 Sinais de negócios

deposit _ conversion - X p.p. no canarinho contra o controle.
setle throughput queda em relação à linha de base.
chargeback/decline spikes (soft/hard).

3. 3 Eventos críticos

Falha do SRM em A/B ativo (distorção de tráfego).
Activação de segurança/guardrail PII.
Incompatibilidade de padrão/configs (validador/linter).

4) Modelos arquitetônicos de reversibilidade

Canary → Ramp → Full: promoção de 5%→25%→100%; reversão - reversível (100→25→5→0).
Blue-Green, um suingue atômico do tráfego entre a Blue e a Green.
Função Flags: kill-switch para alterações comportamentais (TTL, guardrails, SoD).
Config as Data: promoção GitOps/re-promoção da versão anterior; runtime-snapshots.

• Duas fases (expand→contract),
• reversível (script down),
• write-shadow (novos campos são escritos duplicados),
• read-compat (o código antigo compreende o novo padrão).

5) Políticas de retrocesso (policy-engine)

• `auto_rollback if auth_success_rate. drop(geo="TR") > 10% for 10m AND coverage>=5%`
• `auto_rollback if bet_settle_p99 > SLO1. 25 for 15m`
• `auto_pause_flag if api_error_rate > 1. 5% for 5m`
• `deny_promote if slo_red in {"auth_success","withdraw_tat_p95"}`
• `require_dual_control if change. affects in {"PSP_ROUTING","PII_EXPORT"}`

Todas as regras são versionizadas, testadas e reviradas.

6) Fluxo de reversão de carro (end-to-end)

1. O detector de regressão é acionado (métrica/alert/validador).
2. Verificação de exceções (picos de festa, janelas de teste).

7) Integração

Incidente-bot: '/release rollback <id> ', timeline automática, referências a dashboards e difs.
Metrics API: Estágios SLO e guardrail prontos; explars para RCA.
Função Flags: '/flag off <id> ', ausa automática de guarda.
GitOps/Config: `/config rollback <snapshot>`; o detector draft confirma o resultado.
Página status: updates públicos opcionais (via CL/política).

8) Observabilidade e telemetria reversível

Release Dashboard: auth-success, error-rate, p95/p99, settle throughput, PSP по GEO/BIN.
O Guardrail Board: regras ativas/ativas, janelas, histeroses.
Histórico de revestimentos:% canários/bandeiras/regiões no tempo.
Auditoria: quem/o/quando/porquê; difs de artefactos; versão de políticas; o resultado.

9) Segurança, SoD e complacência

4-eyes/JIT para ações que afetam pagamentos/PII/RG.
Geo-fances: Os retrocessos que afetam os requisitos regulatórios são aplicados localmente.
Registros WORM - Traço imutável para verificações.
Pacotes comm públicos: compatíveis com CL/Legal; os detalhes das experiências não são revelados.

10) Exemplos de artefatos

10. 1 Política de Retorno Automático (YAML)

yaml apiVersion: policy.platform/v1 kind: AutoRollbackRule metadata:
id: "payments-auth-success-tr"
spec:
scope: { tenants: ["brandA","brandB"], regions: ["EU"], geo: ["TR"] }
signal:
metric: "auth_success_rate"
condition: "drop > 10% for 10m"
compareTo: "canary_control"
action:
strategy: "step_down"  # 100%->25%->5%->0%
cooldown: "15m"
exceptions:
calendar: ["2025-11-29:black_friday"]
manualOverride: false audit:
owner: "Payments SO"
riskClass: "high"

10. 2 Manifesto de reversão de configuração

yaml apiVersion: cfg.platform/v1 kind: ConfigRollback metadata:
id: "psp-routing-revert-2025-11-01"
spec:
from: "payments-routing-2025-11-01"
to:  "payments-routing-2025-10-29"
criteria:
- metric: "auth_success_rate"
where: "geo=TR"
condition: "drop>10% for 10m"
notify:
incidentBot: true stakeholders: ["Payments","SRE","Support"]

10. 3 Kill-switch bandeira

yaml apiVersion: flag.platform/v1 kind: KillSwitch metadata:
id: "deposit.flow.v3"
spec:
guardrails: ["api_error_rate<1.5%","latency_p99<2s","slo_green:auth_success"]
autoPauseOnBreach: true ttl: "30d"

11) Trabalhar com migrações de dados

• Expand: adicionar novas colunas/índices sem quebrar a leitura.
• Migrate: dupla gravação/réplica, verificação de consistência.
• Contract: Remover o antigo somente após o lançamento com sucesso + janela de observação.
• Script down: obrigatório; estimativa de tempo e bloqueios.
• Shadow-leitura: comparação entre os resultados do antigo/novo caminho (sem efeitos colaterais).
• Os critérios de cancelamento do contracto são «vermelho».

12) Processos e RACI

Release Gerente: dono de linha de montagem e políticas.
Service Owner: aprova regras de domínio, aceita riscos.
SRE: implementa detectores, mecânicos de retalho, dashboards.
Segurança/Compliance: SoD, controle PII/RG, auditoria.
On-call IC/CL: comunicações, status-página.
FAB: Pós-faturamento visão auto-saques, correção de regras.

13) KPI/KRI funções

Auto-Rollback Rate: proporção de lançamentos revertidos automaticamente (taxa baixa, mas não zero).
Time-to-Rollback: detekt→otkat (mediana/p95).
SLO-Breach Avoided: Casos em que um auto-retrocesso impediu a violação de alvos.
Falso Positivo: proporção de retrações «falsas» (alvo: ↓).
CFR antes/depois da implementação do revezamento automático.
Costa of Rollbacks: tempo extra, canários, recursos de computação.
Auditório Completeness:% dos eventos com timeline completa e difs.

14) Mapa de trânsito de implementação (6-10 semanas)

Ned. 1-2: catálogo de métricas críticas e liminares básicos; Escolha de estratégias (canary/blue-green/flags); Inventário da reversibilidade migratória.
Ned. 3-4: implementação de detectores e policy-engine; integração com o incidente-bot; GitOps-rollback para configs; dasbords de guardrails.
Ned. 5-6: piloto no domínio Payments (auth-sucess, PSP-routing), treino tabletop; O diário WORM e os relatórios.
Ned. 7-8: extensão em Games/KYC; paragem automática das bandeiras; Ensinamentos de Dr. com blue-green.
Ned. 9-10: calibração de liminares, redução de false positivo, FinOps estimativa de custo, formalização de RACI e treinamento.

15) Antipattern

«Um dia destes», falta de plano e reversibilidade das migrações.
Ativação/desativação instantânea global sem degraus.
Retrocesso em métricas cruas sem contexto (nenhuma stratação GEO/PSP/BIN).
Ignorar SRM e peeking em experiências.
Um lançamento sem histerese → um flapping de reembolsos.
Edição manual de configs em venda sem Git/Auditoria.
Remova o padrão antigo antes de passar pela janela de vigilância.

Resultado

A reversão automática de lançamentos é uma grade de segurança da plataforma: políticas como código, sinais e liminares corretamente selecionados, soluções de arquitetura reversíveis (canary/blue-green/flags/reversível migrações), comunicações integradas e uma auditoria completa. Esse caminho reduz drasticamente o risco de lançamentos, protege o SLO e a receita e aumenta a confiança de reguladores e parceiros.