Operações e Gerenciamento → Gerenciamento de alterações

Gerenciamento de alterações

1) Atribuição e princípios

O objetivo é fornecer mudanças de forma rápida e segura, reduzindo o risco de incidentes, interrupções e violações regulatórias.

• Predictable & Reversível: Cada alteração é planejada, verificável e reversível.
• Risk-based: a profundidade do controle depende do risco (jurisdição, dinheiro, PII).
• Small & Frequent: Pequenos encartes são mais fáceis de avaliar e reverter.
• Automation first: infraestrutura como código, testes, validações, máquinas automáticas.
• Single Six of Truth: um único RFC/tíquete, um calendário único e um cronograma de ação.

2) Área de alcance

Código de alimentos (backend/frontend, SDK móvel).
Infraestrutura (IaC, Kubernetes/VM/CDN/Edge).
Dados (esquemas de base de dados, migração, vitrine/ETL).
Configurações e bandeiras de fich.
Integração (PSP, KYC, provedores de jogos).
Políticas de segurança e acessibilidade.

3) Papéis e RACI

O dono da alteração é o Resolvível.
Supervisor de lançamento/RelEng - coordenação do trem de lançamento.
SRE/Ops - operação, gate SLO/SLA.
Segurança/Compliance - Verificação de risco e conformidade.
O FAB (Mudança Advisory Board) é a aprovação de alterações normais/de alto risco.
Steakhalders business/suporte - Informed.

4) Classificação de alterações

Padrão (padrão, pré-aprovado): frequente, de baixo risco, por playbook pronto (por exemplo, atualização da bandeira, rotação das chaves).
Normal: exigem RFC, avaliação, possível FAB, testes e plano de reversão.
Emergency: gravações de emergência para incidentes P1; Caminho burocrático mínimo, pós-faturamento revezamento/CAV.

5) Ciclo de vida de mudança

1. Iniciação (RFC): alvo, volume, risco, serviços/regiões afetados, plano de backout.
2. Avaliação de risco: matriz de Impacto x Likelihood, impacto sobre SLO/Complance/Custo.
3. Planejamento: janela, dependência, migração, comunicações, testes de validação.
4. Validação: auto, análise estática, cheque de segurança, performance.
5. Implantação: Estratégia Progressiva (consulte parágrafo 8), telemetria e gardrelas.
6. Observação: burn-rate SLO, alertas, métricas de negócios (GGR/NGR, conversão).
7. Conclusão: aceitação do resultado, atualização da documentação, pós-roubo.

6) RFC: composição mínima

O contexto é porque mudamos, a hipótese de influência.
Faixa de sistemas, regiões, versões de clientes.
Risco: matriz e cenários de falha, blast radius.
Plano de implantação: passo a passo, com critérios para ir/parar.
Plano de reversão (Backout): comandos/etapas, condições de lançamento, espera RTO/RPO.
O que testamos antes/depois (funcionalidade, performance, segurança).
Comunicações: Quem avisamos, modelos de mensagens.
Referências a tíquetes, comitas, artefatos CI/CD.

7) Calendário de alterações e janela

Calendário único: todos os lançamentos, migrações, desligamentos, eventos externos (esportes/marketing/feriados).
janelas Freeze: grandes vendas/campeonatos/relógios de pico, contabilidade fiscal.
Política de cruzamento: impede alterações conflitantes nas mesmas vias críticas.
Ondas regionais: primeiro regiões «quentes »/baixo tráfego, depois as principais.

8) Estratégias técnicas de implantação

Canary: pequena proporção de tráfego → comparação de métricas (p95 latency, erro%, conversão).
Azul-Green: Ambientes paralelos, mudança atômica de rota.
Progressive Delivery: porcentagem-roll com paragens automáticas.
Função Flags: botões funcionais, kill-switch, A/B.
Dark Launch/Shadow Traffic: Verificação de sombras sem afetar os usuários.
Limites de passo: aumento gradual do QPS/competição.

Gardrelles: paragem automática quando as liminares p95/erro%, aumento de devoluções/charjbacks, queda de autorizações/depósitos.

9) Alterações de dados e esquemas

Compatibilidade: migrações de extensão → código de leitura antiga e novo padrão.
Migrações de duas fases: (1) adicionar novos campos/índices → (2) mudar o código → (3) remover o antigo.
Versionização de contratos: Avro/Protobuf esquema de registro; back/forward compatible.
Migrações de grandes volumes, como batches, pausas, idempotidade, checkpoint e progresso.
Resistência ao desastre: RPO/RTO, ensaios de recuperação.
Dados BI: alteração de vitrines/métricas por MR/SR e dicionário de métricas (ID, fórmula).

10) Gerenciamento de configurações e segredos

Config as Data: configs versionizados, validação por esquema, promoção por ambiente.
Segredos: Rotação de chaves, princípios de privilégios mínimos, auditoria de acessos.
Overraids regionais: limites/parceiros (PSP/KYC) - através da configuração, não através de fork de código.

11) Complaens e auditoria (contexto iGaming)

Traços de mudança: quem/quando/o que mudou (bandeiras, configs, rotas, migrações).
Segregation of Duties: papéis diferentes para o autor, o revezador e o deploeur (SOX-igual).
Relatórios regulatórios: lançamentos de fix, controle de versões de cálculos (GGR/NGR, bónus), controle de acesso ao PII.
Fornecedores: versões de SDK/certificados de provedores, obrigações SLA.

12) Comunicações

Modelos de alerta: antes do lançamento (que/quando/risco), durante (status,% do tráfego, métricas), depois (resumo).
Mensagens externas: banners/página status quando afetar clientes.
Coordenação: canal # release-war-room, proprietário de lançamento, frequência de updates.

13) Métricas de eficiência

DORA: Deployment Frequency, Lead Time for Changes, Change Failure Rate (CFR), MTTR.
SLO Impact: proporção de tempo no SLO antes/depois dos lançamentos.
Backout Rate: taxa de reposição por categoria de alterações.
Release Debt: Migrações incompletas/bandeiras de fich em estado suspenso.
Business Impact: Conversão, KYC TTV, sucess rate PSP, GGR/NGR drivt durante as gravações.

14) Anti-pattern

Lançamentos Big bang: muitas mudanças de uma só vez - difícil de compreender o motivo da regressão.
Migrações incompatíveis: Remover ou renomear campos sem dupla leitura.
As bandeiras sem proprietários e data de retirada são os ramos «eternos» da lógica.
Lançamentos sem telemetria e sem critérios de parada, «de olho» e mais tarde detecção de danos.
Ignorar calendário: cruzamento com eventos/campanhas de pico.
Passos manuais sem playbooks ou auditoria: alta variabilidade e risco.

15) Folhas de cheque

Antes de começar (RFC pronto)

• O objetivo e o KPI de alterações foram formulados
• Risco e blast radius avaliados, classe de alteração selecionada
• O plano de implantação e o Backout estão definidos passo a passo
• O plano de teste e os resultados no estante/canal estão disponíveis
• As comunicações e o calendário foram atualizados, os steakhalders foram notificados

Durante a abertura

• Métricas p95/erro%, sinais de negócios e logs são monitores em tempo real
• Os estágios de progresso são confirmados com cheques
• Quando as gardrelas são ativadas - auto-parar e revogar

Depois

• O resultado do lançamento foi registrado (changelog, versões, artefatos)
• Pós-mortem em desvios (≤ 5 dias úteis)
• Dívidas (remoção de bandeiras, migração final) estão inscritas em backlog com proprietários

16) Mini-modelos

• Objetivo/hipótese
• Volume e impacto (serviços, regiões, dados, clientes)
• Risco (Impacto x Likelihood) e medidas de redução
• Plano de abertura (passos,% de tráfego, critérios go/no-go)
• Plano Backout (passos, RTO/RPO, dados)
• Plano de teste (funcionalidade/performance/segurança)
• Comunicações (canais, frequência)
• Artefatos (tíquetes, PR, números de dados)

• Alteração: "Payments-Service v2. 14 + migração psp _ limits"
• Janela: 2025-11-02 00: 00-01: 00 EET
• Regiões afetadas: EU, LATAM (10%→50%→100%)
• Riscos/gardrelas: erro%> 2% 10 min - parar e retrocesso
• Contatos: @ Owner, @ SRE-on-call, @ Apoio-lead

• Trigers: p95> + 25% 10 min, PSP sucess <97%
• Passos: (1) traffic −→ 0% em v2. 14; (2) mudar as bandeiras para v2. 13; (3) O retrocesso da migração através do snapshot/checkpoint; (4) testes smoke; (5) relatório.

17) Integração com o trem de lançamento

Release Trem: slots fixos (por exemplo, 2 x por semana), SLA em merge-cut.
Política Hotfix: comboios/ramais individuais, caminho acelerado para a proda.
Versioning: semver, marcas em artefatos e ambientes, SBOM.

18) Total

Controlar as alterações não é um freio de velocidade, é um mecanismo de aceleração segura. Classificação orientada ao risco, RFC bom, localização progressiva, migração de dados compatível, comunicações claras e medição de efeito transformam os lançamentos em um processo controlado, repetível e auditado.