Alertas em tempo real

1) Propósito e princípios

O objetivo é notificar as pessoas/sistemas a tempo, com precisão e direcionamento sobre os eventos que ameaçam o SLO, a receita e a complicação e iniciar ações corretas (manuais/automáticas).
Princípios: SLO-first, minimização do ruído, explicabilidade, contexto, priorização do impacto empresarial, «um sinal é uma ação compreensível».

2) Taxonomia de sinais

SLO: burn-rate do orçamento de erros em caminhos críticos (login, depósito, taxa, conclusão).
KRI: indicadores de risco iniciais (queda auth-sucess em PSP por banco/GEO, crescimento consumer-lag, p99↑).
Eventos: flaps de dependências, failover, alternações manuais, acionamento de bloqueio (rate-limit, WAF).
Segurança/Complacência: aumento de operações sensíveis, exportação de PII, violações de SoD.

3) Níveis e alertas SLA

4) Fontes e correlação de contexto

Telemetria: métricas/trailers/logs, sintéticos e RUM.
Diretórios: CMDB/serviço-mapa, proprietários, dependentes.
Mudanças: lançamentos, fichflags, migrações, trabalho programado.
Provedores externos PSP/KYC/estúdios de jogos/CDN/WAF estatais.
Cada alert enriquece, o que mudou por perto? (lançamento/fichflag), quais dependências são vermelhas? Qual segmento será afetado? (GEO/PSP/banco/tenante).

5) Regras de alerting SLO (núcleo)

Burn-rate: duas janelas (rápido 1h e lento 6-24h). O pager é só com excesso simultâneo.
Guardrails: liminares p99/erro-rate servem apenas como desencadeadores de análise contextual, não substituem o SLO.
Impacto: avaliação «proporção de público x dinheiro/min x regulatório» → nível P1-P4.

6) Supressão de ruídos

Deduplicação: agrupamento por serviço/tenante/causa; um incidente em vez de dezenas de sinais.
Histeresis: N-de-M confirmações, duração mínima da anomalia.
Silens/motes, trabalhos de rotina, incidentes conhecidos, janelas «follow-the-sun».
Limites de rate e quotas: por fonte/editora/tenante; protecção contra a tempestade.
Redução da radicalidade, proibida de userId/sessionId em alert.

7) Rotação e escalação

Roteiro por contexto: domínio (Payments/Games/Core), ambiente (prod/estágio), região, peso.
Escaladas: t0 - on-call L1; t0 + X - L2/dono de domínio; t0 + Y - IC/manual. O tempo X/Y depende de P1-P3.
Duplicação em canais: pager + bate-papo em P1; bate-papo/tíquete para P3.
Mudança de mudança: transmissão de contexto automático (timeline, ações executadas, hipóteses).

8) Ação automática (auto-remediação)

Pagamentos: Alterna PSP por health x fee x conversion, limitação de bancos/métodos, retrai com jitter.
Jogos/apostas: ativar o dinheiro-wedge/limitar operações write, queue-page/waiting-room na frente.
Infra: evacuação do tráfego, restruturamento de workers degradados, escala por lag.
Segurança/Complacência: fechar temporariamente a exportação do PII, inserir dual-controle para as operações P1.
Qualquer ação automática - com política de reversão e critérios de retorno.

9) Runbook-primeira experiência

Cada alert está associado ao runbook: alvo, diagnóstico rápido (3-5 verificações), etapas de fix/revezamento, contatos, links para dashboards e status-página. No bate-paper, mostramos um breve cartão de acção.

10) Ele-call política

Rotação 24 x 7, revestimento de domínios (Payments/Game Core/SRE).
«Segundo on-call» para P1, regra de duas pessoas no circuito de war.
Quiet-hours e janelas de serviço por zona (follow-the-sun).
Treinamento: Exercícios trimestrais (tabletop/game-day), turnos shadow.
Créditos pós-incidente (cop-time) para evitar queimadas.

11) Integração

Gerenciamento de incidentes, criação de cartões automáticos, fitas de update, papel IC/CL, temporizadores.
Página de status: publicação de P1/P2 (via Comms Lead) com modelos e localização.
Release-gates por SLI, auto-stop/rollback por alertas.
Diretórios: Proprietários, CMDB, contatos de provedores.

12) Exemplos de alertas (iGaming)

1. Auth-sucess do PSP-1 em TR↓ em 25% em 10 min

P2→P1 na cobertura> 30% transações.
Ação automática: redistribuir o tráfego PSP-2/3; incluir o 3DS simplificado; Um alert de Sócio.

2. p99 «stavka→settl»> 3 x normas em EU

Motivos: lag replication, fila de workers.
Ação Auto: scale-out worker, warmup cachê, desligar temporariamente fitas não-críticas.

3. Export PII spikes

P1 sem tíquete/aprovação.
Ação automática: unidade de descarga, notificação Compliance, verificação de SoD.

13) Métricas de qualidade de alerting (KPI/KRI)

MTTA-Comms/MTTA-Ops: tempo até a reação/primeira ação.
Precision/Recall (alert ↔ incidente), Falso Alarm Rate.
Lead-time antes da violação do SLO, TTD (hora de detecção).
Pager fatigue: alertas/pessoas/ned, chamadas noturnas, porcentagem de «vazios».
Auto-fix rate: proporção de problemas fechados por uma resposta automática sem uma pessoa.
Aging: P3/P4> X dias pendentes.

14) Gerenciamento de custo

Quotas de alertas/fontes, recorte de editoras redundantes.
Downsampling e agregação de métricas, trilhas de sempling; Reticências de classe.
Rotineira: $/alert, $/SLI-dashboard, série «pesada».

15) Privacidade e complacência

Sem PII no texto de alertas e editoras; Tocinização de identificadores.
Políticas de acesso (RBAC/ABAC) SoD na configuração de alertas.
Auditoria de alterações de regras, versionização, testes e diff.

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

Ned. 1-2: catálogo SLI/KRI, mapa de proprietários, níveis P1-P4, primeiras regras SLO (burn-rate).
Ned. 3-4: Deadup/histerese/silens, integração com sistema de incidente e bate-papos, ligas de runbook.
Ned. 5-6: Ação automática para Payments/Queues, release-gates, status-página fid.
Ned. 7-8: contexto (lançamentos/fichflags/provedores), placas de calor PSP x banco x GEO, exercícios P1/P2.
Ned. 9-10: FinOps de alerting, dashboards KPI, revisão de liminares e quotas, formação de coll.

17) Artefatos e modelos

Alert Spec: métrica/condição, janelas, supressão, proprietário, runbook, ação automática.
Roting Map: domen→kanal→eskalatsii, contatos de reserva.
Silêncio Policy: As regras do muto (incidentes programados/conhecidos), quem pode incluir.
On-call Handbook: rotações, mudança de turno, folha de cheque P1/P2, canais.
Post-Invident Pack: descarga de alertas/linhas de tempo, análise da qualidade dos sinais.

18) Antipattern

Pager «crus» p95/p99 sem SLO → ruído e fadiga.
Dezenas de sinais sobre a mesma coisa (sem dedução/correlação).
Nenhum runbook ou dono do alert.
Limiar «na pedra» sem sazonalidade/segmentação (GEO/PSP/banco/hora).
Sem retorno após ação automática (sem critérios roll-back).
As editoras PII e userId → os riscos e a explosão da radicalidade.

Resultado

Um alerting realmente útil é uma linha de montagem SLO-central: regras contextuais com burn-rate, supressão inteligente do ruído, roteamento claro e escalação, runbook-primeira experiência e ação auto segura. Este tipo de circuito capta eventos críticos antes dos usuários, reduz o MTTR, protege os lucros e, ao mesmo tempo, poupa-o da rotina infernal «pager».