Operações e Gerenciamento → Previsões de incidentes

Prever incidentes

1) Por que é necessário

Os incidentes raramente explodem do nada. Antes da recusa, a plataforma emite sinais: crescimento acelerado do p99, lentidão do orçamento errador, filas de raios, crescimento dos retais no downstream específico, aproximação das quotas do provedor. A previsão do sistema traduz a reação de «apagar um incêndio» em «intervenção precoce», reduzindo a MTTR, a Mudança Failure Rate e a perda de receita.

• Identificar patterns de precursor e iniciar automaticamente ações preventivas.
• Reduzir a participação P1/P2 através da mudança para a esquerda.
• Incorporar previsões nos processos de lançamento, feelover e capacity.

2) Mapa dos sinais (lead indicators)

• Aceleração p95/p99 (gradiente), «caudas» de atrasos, aumento da variação.
• Filas/striam: Crescimento de 'lag' e derivativos positivos de lag; A HPA está no máximo.
• BD/dinheiro: 'action _ conns/max _ conns',' replicação _ lag ',' evictions ', queda' cachê _ hit '.
• Rede: erros de mTLS/handshake, altura de 5xx/timeout para fora.

• 'outbound _ erro _ rate '/' retry _ rate' a um provedor específico, 'circuito _ aberto', 'cota _ usage> 0. 9`.
• Provedor SLA: janelas de planejamento, degradação.

• Carga anormal (campanhas/jogos), saltos RPS/TPS, micos de regiões/canais extraordinários.
• A conversão de depósitos/taxas cai com o aumento de p99 → quase proxy incidente.

• Burn-rate orçamento errante> limiar (por exemplo,> 4 x durante 10-15 min).
• Pequenas violações frequentes do SLO (micro-degradação) como um marcador de falha que se aproxima.

3) Fontes e vitrines de dados

TV online: Prometheus/OTel (métricas, logs, trailers).
Eventos de incidentes: tíquetes/estatais/pós-mórtemos (verdade para a meta).
Planos/factos de mudanças: lançamentos, fichiflags, migração, janelas de provedores.
Guias: mapa de dependências, quotas, proprietários.
Imagens DWH: unidades de treinamento/validação (janela sincronizada!).

Requisitos de qualidade: totalidade de ≥99%, alinhamento horário/minuto TZ, definições p95/p99.

4) Abordagens de previsão

4. 1 Regras/não-aramétricas (início rápido)

Alertas de limite para velocidade de alteração: 'deriv (p99)', 'z-score' para janelas curtas.
Condições compostas: 'lag↑ + HPA = max + circuito _ aberto (to = «PSP-X»)'.
SLO-burn-gates: remanescentes/canários em burn-rate> X.

4. 2 Detecção de anomalias

Seasonal baselines (STL/Prophet tais ideias), rolling mediana + MAD.
Multivariate: anomalia colaborativa 'p99 + retry + open _ circuito + quota'.
Mudança-point detation: CUSUM/BOCPD para mudanças de tendência.

4. 3 modelos ML (supervised)

Classificação «Incidente T + K?» pela janela de sinais (por exemplo, 10-30 min antes).
Sinais: estatísticas, derivados, sobras sazonais, provedores one-hot/regiões, bandeiras de lançamento.
Marcas: 'incident{severity∈[P1,P2] a.' no intervalo [t, t + K].
Expainability: SHAP/Permutation importance para credibilidade e operacionalidade.

4. 4 SRE-first híbrido

Modelo → mapeamento de risco (0-1) → política de ação (ficheflags/feelover/pré-scail), com HITL para críticas.

5) Engenharia de sinais (função engineering)

Janelas deslizantes (1/5/15 min): mean, p95/p99, std, max, slope.
Os indicadores relativos são 'p99/baseline _ 1d', 'erro _ rate _ delta'.
Fichas de linha: provedor, região, tipo de jogo/jogo, canal de dispositivo.
Fichas de carga: RPS, payload size, número de WS abertos.
Sistema: 'hpa _ desired/max', 'db _ conn _ ratio', 'redis _ evictions> 0'.
As bandeiras de evento são «lançamento», «canário 10%», «janela do provedor».

6) Mecânica de previsões e ações

1. Mapeamento de risco a cada N segundos por domínio (Payments/Bets/Games/KYC).

• Risco ≥ 0. 8 + os sinais de confirmação → página do dono do domínio;
• 0. 6–0. 8 → aviso + preparar medidas.

• pré-scail (HPA minReplicas↑), ativação do dinheiro, limitação das funções pesadas;
• mudar para o provedor de reserva/rota;
• pausa/rollback canário;
• limite de retrações para downstream estreito.

4. HITL: Uma pessoa confirma medidas de «mudança de comportamento».

7) Integração em processos diários

Lançamentos: Gates preditivos em canários (comparação entre antes/depois e risco).
Feelover: preparação automática/aquecimento da rota de reserva em caso de risco do provedor.
Capacity: "early uplift' quando o headroom cai e as lajes crescem.
Alertas: fita separada «príncipe-invidente» + anotações em dashboards.

8) Observabilidade e dashboards

Risk Overview: risco em domínios e provedores, tendências, contribuições de sinais.
Lead Signals: top-N precursores (gradiente p99, lag, breakers abertos).
Ações & Outcomes: O que foi ativado, o efeito sobre p95/erro, os incidentes cancelados.
Modelo Health: precisão/recall/latency, sinais draft, frequência automática.

9) Métricas de qualidade das previsões

Recall @ P1/P2 (sensibilidade para incidentes críticos).
Precision (menos «falsas pagas»).
Lead Time (mediana «quantos minutos para o fato»).
Intervenção Win-rate (proporção de casos em que a ação reduziu o risco/custo).
Alert Fatigue Index (alert/mudança/pessoa).
Draft Score (stat. distinção entre as distribuições de sinais vs período de treinamento).

Os alvos padrão são Recall (P1) ≥ 0. 7, Precision ≥ 0. 6, Lead Time mediana ≥ 8-10 min

10) Gerenciamento de risco do modelo (ML Ops/Governance)

Versionização de dados/código/artefatos, reprodução.
Champion/Challenger: O novo modelo vem em paralelo, comparando off/online.
À deriva: PSI/KL divergência, controle automático de liminares, alert «modelo obsoleto».
Explainability: para cada decisão, armazenar a importância dos sinais e um link de dados.
Segurança/Ética: Acessibilidade, camuflagem PII, controle da atuação automática das políticas.

11) Exemplos de regras e políticas

policy:
if slo_burn_rate{service="payments"} > 4 for 10m and release_phase in ["canary", "post-deploy_30m"]:
action: pause_release_and_rollback notify: squad-payments

risk_psp_x = sigmoid(
1. 2z(outbound_p99_ms) +
1. 5z(outbound_error_rate) +
0. 8z(retry_rate) +
1. 0I(quota_usage>0. 9) +
0. 7I(circuit_open=1)
)
if risk_psp_x > 0. 8 for 5m -> route_to_psp_y + reduce_features

if (consumer_lag > 5e6 and deriv(consumer_lag) > 5e4) and hpa_desired == hpa_max:
action: scale_consumers + throttle_producers + enable_batching

12) Folha de cheque de implementação (30-60 dias)

• Catálogo de sinais e «verdades» sobre incidentes (severity, times).
• Linhas básicas e sazonalidade para métricas-chave (antes/depois do lançamento).
• Regras de sinais iniciais (gradientes p99, lag, burn-rate).
• Dashboards Risk/Lead Signals/Action.
• Integração com phicheflags/canários, pré-scail HPA.
• Piloto de classificação ML em um único domínio (por exemplo, Payments).
• Políticas HITL e Registro de Desempenho Automático.
• Métricas de qualidade e alertas à deriva/saúde modelo.

13) Anti-pattern

Bolas de cristal: modelo ML complexo sem linhas básicas ou regras simples.
Não há actionabilidade: prevemos «mau», mas não fazemos nada automaticamente.
Ignorar a sazonalidade/calendário de eventos (jogos/torneios) → alarme falso.
A mistura de zonas de tempo → janelas erradas de métricas/incidentes.
Falta de explainability → desconfiança, desativação do predicado por comandos.
Limiar global unificado para todos os domínios/regiões → baixa precisão.

14) Especificidades de domínios (iGaming)

Payments: provedores/quotas, crescimento de 'retry _ rate' e 'circuito _ open' → um feelover inicial.
Bets: atraso na atualização de coeficientes, crescimento do WS-Fan-out → limite de transmissão.
Games/Live: elevações de conexões, limites de estúdios → degradação UI/cachê.
KYC/AML: atrasos no webhook, filas de verificações → HITL e processamento atrasado.

15) Exemplos de métricas e alertas (ideias)

ALERT PreIncidentRiskHigh
IF risk_score{domain="payments"} > 0. 8 FOR 5m
LABELS {severity="critical", team="payments"}

ALERT LeadSignalP99Slope
IF deriv(api_p99_ms{service="bets"}[5m]) > 15 AND api_p99_ms > baseline_1d 1. 2 FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderEarlyQuota
IF usage_quota_ratio{provider="psp_x"} > 0. 85 FOR 10m
LABELS {severity="info", team="integrations"}

ALERT StreamLagStorm
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"}

16) Programa de previsões KPI

Príncipe-Invident Detect Rate (proporção de incidentes evitados/atenuados).
Avg Lead Time antes do incidente.

Redução em P1/P2 kv/quadrado

MTTR (esperado ↓ devido ao contexto inicial).
Falso Alarm Rate/Alert Fatige (estável ↓).
Costa Avoidance (avaliação de perdas/multas evitadas/overskale).

17) Início rápido (receita)

1. Inclua as regras de gradiente em p99/lag e SLO-burn;

2. Adicione condições compostas para provedores;

3. Vincule o predicado aos fichiflags e pré-skale;

4. Relatório de previsão → ação → efeito;

5. Piloto ML no mesmo domínio; escala após o crescimento do Precision/Recall.

18) FAQ

Como começar sem o ML?
A: Linhas básicas sazonais + gradientes + regras compostas. Isso dá um aumento notável de recall sem dificuldades.

Como não se afogam em fols positivos?
A: Combinar sinais, inserir histerese e tempo de confirmação, ajustar liminares per domínio/região, avaliar Precision e Alert Fatige.

Q: Quais são os primeiros a automatizar?
A: Seguro e reversível: pré-scail, ativação de dinheiro/degradação, pausa/rollback canário, alteração do provedor em sinais confirmados.