Operações e Gerenciamento → Prevenção de incidentes

Prevenção de incidentes

1) Por que é necessário

A melhor resposta ao incidente foi a ausência dele. Para iGaming/fintech cada minuto de inatividade - taxas perdidas/depósitos, multas de provedores, riscos de reputação. A prevenção do sistema reduz a Mudança Failure Rate, estabiliza o SLO e libera o tempo dos comandos para desenvolver em vez de apagar incêndios.

• Minimizar a possibilidade de incidentes em vias críticas (depósito, aposta, lançamento de jogo, conclusão).
• Interceptar a degradação antes de atingir o SLO e a carteira.
• Limitar o raio de falha (blast radius) e acelerar a recuperação.

2) Princípios básicos de prevenção

1. SLO-first e error budet: as alterações não são liberadas se o SLO correr risco e queimar o orçamento.
2. Defence in depth: as camadas são de esquemas de dados e configs a políticas de rede e fichiflags.
3. Design for failure: breakers, temporizadores, retais com jitter, idempotação, degradação.
4. Small & reversível changes: pequenos encartes + reversão rápida (função flags/canário).
5. Observabilidade by design: métricas/logs/trailers para cada passo crítico e conexão.

3) Mapa de riscos e caminhos críticos

Mapeie a dor pelos domínios Payments, Bets, Games, KYC, Promoções, Jackpots, Conteúdo.

• Métricas de negócios (conversão, GGR, cheque médio).
• SLO técnico (latency p95/p99, uptime, sucess rate).
• Dependências (interna/externa), limites/quotas.
• Comportamento «Safe modo» (que desativamos/simplificamos).
• Runbook dono.

4) Guardrails (barreiras de proteção)

Timeouts e breakers: O serviço de chamamento tem um tempo mais curto do que o valor interno; o breaker abre quando os erros/latência crescem.
Bulkhead-isolamento: pool individual de conexões/worker para downstream.
Rate limit & backpressure: Protecção contra avalanches e tempestades retraias.
Ficheflags de degradação: «modo mínimo» - respostas fáceis, capas-replai, desligamento de fitas pesadas.
Multi-wendor e feelover: opcionais PSP/KYC, mudança de rota.
Validação de configurs: circuitos/liners/políticas para alterar fiéis e limites de forma segura.

5) Gerenciamento de alterações

Pré-release gates: testes, segurança, CDC (consumer-driven controls), compatibilidade de circuitos.
Lançamento canário + auto-gates: 1% → 10% → 100%; auto-parar para p99/error rate/orçamento de combustão.
Função flags: reversão instantânea/mudança de comportamento sem deploy.
Release calendar: evite janelas de pico de esportes/torneios e maintenance nos provedores.
Post-deploy checks: gravador automático, comparando as métricas «antes/depois» com liminares.

6) Testes como medida preventiva

Unit/contract/integração: contratos OpenAPI/AsyncAPI, CDC contra provedor/moka.
Load & stors: perfis de tráfego para horário nobre; testes para os limites de conectórios/IOPS/quotas.
Soak/long-haul: fuga de recursos, aumento de atrasos no horizonte de horas/dias.
Chaos/game-days: queda do corretor/PSP/KYC, quebra da região, «lento provedor».
Disaster Recovery Drills: treinos regulares de mudança de região e recuperação de BD.

7) Detecção precoce de degradações

Capacity-alerts: headroom, lajes de fila, conectórios de BD, evicção nas caixas.
SLO-burn-rate: sinal a uma velocidade perigosa de «queimar» o orçamento.
Liminares adaptáveis: sazonalidade/modelos diários para reduzir falsos.
Alertas compostos: «lag ↑ + HPA at max + open circuito» ⇒ alto risco.
Vendor health: quotas/temporizações/erros para cada provedor + custo de chamadas.

8) Trabalhar com provedores externos

OLA/SLA ↔ SLO: Vincular os acordos aos nossos objetivos.
Playbooks feelowers: rotas PSP-X ⇆ PSP-Y, dinheiro de tokens, modos de depósito grace.
Sandbox e contratos, flow de teste antes de cada mudança maior.
As janelas dos provedores são anotações em dashboards e regras supress automáticas.

9) Dados, configs e segredos

Políticas de mudança: código-review de dois pares de olhos, validação de circuitos/JSON/YAML.
Segredos: KMS/Secret Gerente, rotação, divisão de ambientes/papéis.
Bandeiras/limites: alteração por API com áudio e retração instantânea.
Migrações: «bi shag» (expand → migrate → contract), compatibilidade total reversa.

10) Treinamento e preparação de equipes

On-call Training: Simulações de Incidentes, Serviço Shadow, runbook centralizado 'i.
Formatos de comunicação unificados: modelos de status/hendover/incidente-update.
Uma cultura segura, sem acusações, razões mecânicas e ações preventivas.

11) Dashboards de prevenção (mínimo)

Risk & Readiness: SLO/orçamento, headroom por camadas, «laços mais vulneráveis».
Mudança Safety: porcentagem de canarinhos, reversíveis, alertas após o lançamento, CTR auto-gates.
Vendor Painel: p95/erro/quotas/valor para cada provedor, hora da resposta da saforta do vendedor.
Chaos/Dr. Readiness: frequência de exercícios, tempo de mudança de região, sucesso de recuperação.
Config/SecOps: alterações de bandeiras/limites/segredos, anomalias.

12) Exemplos de alertas preventivos

ALERT SLOBurnRateHigh
IF slo_error_budget_burnrate{name="payments_api"} > 4 FOR 10m
LABELS {severity="critical", team="payments"}

ALERT PostDeployRegression
IF (api_p99_ms{service="bets"} > baseline_1d 1. 3) AND (release_window="canary")
FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderQuotaNearLimit
IF usage_quota_ratio{provider="psp_x"} > 0. 9 FOR 5m
LABELS {severity="warning", team="integrations"}

ALERT QueueLagAtRisk
IF (kafka_consumer_lag{topic="ledger"} > 5e6 AND rate(kafka_consumer_lag[5m]) > 5e4)
AND (hpa_desired == hpa_max)
FOR 10m
LABELS {severity="critical", team="streaming"}

13) Folha de aviso de cheque (diariamente/antes dos picos)

• Calendário atual de picos (jogos, torneios, campanhas, janelas de provedores).
• Headroom por API/BD/Cam/filas, HPA/VPA pronto, armazenamento de dinheiro.
• O estado dos provedores (quotas, limites, degradação em 24h), o feelover está configurado.
• Gates canários estão incluídos, os fichiflags são acessíveis aos proprietários.
• As alertas SLO/Capacity estão ativas e a supressão está indicada para os trabalhos programados.
• Runbook 'e atualizados, on-call confirmado, canais de escalação operacionais.

14) Anti-pattern (o que evitar)

«Grandes lançamentos noturnos» sem canários e bandeiras.
Balas de fluxo compartilhadas para todos os downstream (head-of-line blocking).
Retraias para cirurgias não-ideais e temporizações de estreitos.
A falta de histerese nos alertas → a serragem no limite.
Fé cega em um vendedor SDK sem observabilidade e controle de temporizações.
«Fazemos em venda», sem stage/sandbox e CDC.

15) KPI de prevenção

Mudar Failure Rate (alvo de 10-15% ou seu alvo).
Príncipe-Invident Detect Rate: proporção de incidentes evitados na fase de degradação.
Mean Time Between Incidents (MTBI) и MTTR.
Coverage fecha:% das vias críticas com bandeiras/breakers/temporizadores/canário.
Chaos/DR. cadence: frequência e sucesso dos exercícios.
Vendor readiness: tempo médio de mudança para o provedor de reserva.

16) Início rápido (30 dias)

Semana 1: mapa das vias críticas, SLO e proprietários; incluir as alertas SLO-burn e capacity-alerts.
Semana 2: Gates canários + fichiflags; chaos-de-base (provedor/fila).
Semana 3: dashboards de Mudança Safety e Vendor Painel, playbooks.
Semana 4: Doutor ensinamento (parcial), retrospectiva e plano de hardening 'a para o quarteirão.

17) Modelos (fatias)

canary_policy:
guardrails:
- metric: api_p99_ms threshold: 1. 3 baseline_1d window: 10m action: pause_and_rollback
- metric: error_rate threshold: 2 baseline_1d window: 5m action: pause max_step: 10%
step_interval: 15m required_annotations: [release_notes, feature_flags, runbook_link]

safe_mode:
payments:
- freeze_heavy_providers
- enable_cached_token_flow
- route_to_psp_y_if(psp_x_error_rate > 5%)
games:
- limit_broadcasts
- reduce_lobby_heavy_widgets bets:
- raise_risk_score_threshold
- cache_odds_snapshot

18) FAQ

O que implementar primeiro se os recursos são escassos?
A: SLO-burn-alerts em vias críticas, gates canários e ficheflags de retoma; em seguida, um mapa de risco e um feedback dos provedores.

Como compreender que a prevenção «funciona»?
A: A Mudança Failure Rate está diminuindo, o número de incidentes evitados cresce, o MTTR está caindo e o ruído de alertas, e o número de pagas noturnas está diminuindo.

São necessários ensinamentos regulares de chaos?
A: Sim. Sem treinar, o feedback e o DR. são quase sempre mais longos e dolorosos do que parece no papel.