Implantar configurações

1) Porquê

A configuração muda mais do que o código e afeta diretamente a receita (routing PSP, limites, coeficientes, fios de frente) e a complacência (KYC/AML, RG). É necessário um processo repetível, verificável e reversível de entrega de configs para a proda, com tolerância e observabilidade rigorosas.

2) Princípios

1. Configuration as Data: configs - Dados versionáveis (YAML/JSON) em vez de «cliques manuais».
2. Schema-first: Qualquer gravação é validada contra o esquema (JSON Schema/Protobuf).
3. Políticas como código, gates, permissões, SoD no repositório de políticas.
4. GitOps: A única fonte de verdade é Git; os clusters estão alinhados com o reconsilar.
5. Entrega progressiva: Lançadores de canais, por segmento (GEO/tenante/banco/provedor).
6. Zero-downtime: suinges atômicas, tampão duplo, compatibilidade de formatos.
7. Observabilidade by design: auditoria, métricas de aplicação, detector draft.
8. Segurança: privilégios mínimos, segredos separados, SoD/4-eyes mudanças arriscadas.

3) Modelo de configuração

Estáticos: raramente mudam, exigem lançamento (portas, temporizações do núcleo).
Dinâmicas: Aplicadas sem restart (routing PSP, fichas, limites).
Segredos: chaves/tokens; um caminho separado (KMS/Secret Gerente).
Artefatos: arquivos de regras/mappings (BIN→bank, GEO→PSP, limites de bónus).

As chaves de endereço são «tenant», «region», «ambiente», «service», «version», «segment» (psp/bank _ group/device).

4) Formatos e esquemas

json
{
"$schema": "https://json-schema. org/draft/2020-12/schema",
"title": "pspRouting",
"type": "object",
"properties": {
"version": {"type": "string"},
"rules": {
"type": "array",
"items": {
"type": "object",
"required": ["geo","binGroup","primary","fallback"],
"properties": {
"geo": {"type":"string"},
"binGroup":{"type":"string"},
"primary":{"type":"string"},
"fallback":{"type":"array","items":{"type":"string"}},
"limits":{"type":"object","properties":{"perMinute":{"type":"integer"}}}
}
}
}
},
"required": ["version","rules"]
}

5) Ciclo de vida (GitOps)

1. Autoring: PR para o repositório de configurs: dados + referência a tíquete/alteração.
2. Lint/Validate: CI: esquemas, links, semântica (regras de conflito), dry-run no estande.
3. Policy Gates: SoD/4-eyes, classe de risco, janelas freeze, conformidade com o estado SLO.
4. Estaging Apply: testes de integração/sintéticos, verificação de SLI.
5. Progressive Delivery: prod canareira (1-5%) → 25% → região/tenante → 100%.
6. Post-monitoring: 30-60 min/alertas; a fixação do resultado.
7. Promoção/Rollback: rótulos de lançamento, reversão rápida por Git revert/« previous versão ».

6) Estratégias de abertura

Canarela por segmento: 'tenant = A, geo = TR, banco = BIN _ XXXX'.
Por região, picos de relógio.
A função é incluir a bandeira (função flag) com os limites de abrangência (TTL).
Blue/Green para fonte config: mudar os leitores para um novo snapshot.

7) Download dinâmico e compatibilidade

Reiniciar quente (watchers/consoles/OTel Colector pipeline reload).
Formato duplo (v1 + v2): a proda lê ambos, os fabricantes escrevem para o novo.
Coerência: versão em API/métricas para ver «quem está em qual configuração».

8) Segurança, segredos, SoD

Segredos separados: armazenamento no KMS/Secret Gerente, criptografia ao nível do campo, acessível por ABAC.
SoD/4-eyes: alteração do roteamento de pagamento/limites de bônus/exportação PII - somente mediante duplo aval.
Direito de JIT: tokens temporários para operações, auditoria completa.
Verificações de segurança: o linter proíbe chaves PII/teste no configh prod.

9) Validações antes da aplicação

Esquemas (JSON Schema/Protobuf), linteres, testes de radicalidade.
Semântica de domínio: sem ciclos/duplicados/» buracos pretos», compatibilidade com as dependências atuais.
Shadow-tráfego/simulação: «expulsar» novas regras de routing/fluxo real como leitura-sem-gravação.
SLO-gate: SLI vermelho → proibição de promoção.

10) Observação e auditoria

Métricas de implantação: tempo de aplicação, sucesso, proporção de cobertura, erros de parsing, rollbacks.
Eventos: quem/o/o/o/porquê, o diff (incluindo a ocultação de segredos).
Detector Draft: comparação entre «o que está no Git» e «o que está no rante»; alert em caso de divergência.
Instâncias (exemplars): referência a 'trace _ id' das operações de leitura de configs.

11) Catálogo de configs típicos (iGaming)

Payments itinering: PSP por GEO/BIN/método; limites de retrações; fici 3DS.
KYC/AML: provedores, temporizadores, TTL, regras fallback/verificação manual.
Risk & RG: limites velocity, caps diurnos/mensais, exceções geo.
Games/Core: coeficientes de cachê, tamanho de pool, fichiflags (histórico de repetições, novos modos).
Ops/Observabilidade: liminares alert, regras sampling, classes de retenção, sintético.
Status/Comms: modelos de mensagens, localização, programação de updates.

12) Exemplo de pacote de configuração (manifesto)

yaml apiVersion: cfg. platform/v1 kind: ConfigRelease metadata:
id: payments-routing-2025-11-01 change: "RTE-421: reroute TR BIN_4571 → PSP2"
spec:
scope:
tenants: [brandA, brandB]
regions: [EU]
segments:
geo: [TR]
strategy:
steps:
- name: canary coverage: "5%"
duration: "20m"
- name: ramp coverage: "25%"
duration: "30m"
- name: region-full"
coverage: "100%"
gates:
require:
- policy: "slo-green"
- approval: ["Payments Lead","Compliance"]
- freeze: "not-in-effect"
rollback:
to: "payments-routing-2025-10-29"
autoIf:
- metric: "auth_success_rate"
condition: "drop>10% for 10m"

13) Reversões (rollback) e segurança de alterações

Reversão por Git: 'revert '/' promote previous'.
Botão de átomo: os leitores mudam para o antigo botão.
Critérios de reversão automática: degradação do SLI/KRI, aumento dos erros de parsing/validador.
Comunicações: O incidente-bot publica o status do auto-revezamento.

14) Multi-tenante e geo-residente

Espaços de nomes no nível de arquivos/pastas e chaves ('tenant/region/eng').
Políticas de leitura: os serviços só veem o seu acervo.
Cópias geo de configs (EU/LATAM/APAC) e atrasos nas replicações com SLA.
Diferentes janelas de marcação para diferentes jurisdições (compliance/feriado).

15) Desempenho e custo (FinOps)

Cash snapshots: local/distribuído; TTL/ETag/If-None-Match.
Tamanho dos configs: limites de volume e profundidade das estruturas; dividir-se em módulos.
Cartão de acesso: melhores consumidores de leitura; otimização da taxa de bala.
Custo de erro: contador de saques «caros »/canarinhos adicionais.

16) Integração

Alerting/SLO: gate promoção, auto-revezamento.
Release-gates - Bloquear lançamentos de código se os configurs não estiverem concluídos.
Incidente-bot: comandos '/config promote ', '/config rollback', referências a difs e dashboards.
Workflow Engine: human-task para alterações de alto risco; temporizadores de escalações.

17) KPI/KRI funções

Configuração do Lead Time: PR→prod.
Mudar Failure Rate (CFR): proporção de alterações com retração.
MTTR config incidente.
Draft rate: taxa de variação de Git↔runtime.
SLO-gates pass rate: proporção de alterações feitas sem exceções manuais.
Custo de alteração CPU/IO, canários, incidentes.

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

Ned. 1-2: catálogo de configs, circuitos, linters; Git-repo; I básico (validação/diff).
Ned. 3-4: GitOps-reconsailer, dry-run/staging, status-dashboard; ficheflags com TTL.
Ned. 5-6: policy-as-código (SoD/janelas/freeze/SLO-gates), sinalização de canais, auto-revezamento.
Ned. 7-8: detector draft, segredos através de KMS, multi-tenante e geo-cópias, incidente-bot de integração.
Ned. 9-10: testes de sinalização/caos, relatório FinOps, treinamento de comandos e modelos.

19) Modelos de artefatos

PR Template: alvo, classe de risco, área (tenant/region), plano de localização, plano de reversão, resultados de dry-run.
Policy Pack: Gates SLO, SoD/4-eyes, calendário freeze, limites de tamanho/radicalidade.
Runbook: «como ler a versão atual/diff/estado dos canarinhos», «como parar manualmente a promoção».
Config Catalog: proprietário, esquema, leitores, frequência de atualizações, notas complicadas.

20) Antipattern

Redações manuais «no Admino» sem Git/Auditoria.
Configs misturados com código de arremesso, sem possibilidade de substituição quente.
Nenhum padrão/validação → queda no parsing.
Uma varredura global de um ponto único sem canarinhos.
Segredos comuns no configh; segredos em Git.
Não há saques/TTL/guardrails em fichicheflags.
Falta de detector draft.
Retirar os gates SLO por chamada e sem gravação.

Resultado

A implantação de configurações é uma linha de montagem controlada, com dados de políticas → e gates → GitOps e entrega progressiva → carregamento quente e reversibilidade → observabilidade e auditoria → segurança e custo. Este esqueleto permite uma mudança rápida e segura no comportamento da plataforma iGaming, mantendo SLO, receita e conformidade regulatória.