Sistema de notificações e alertas

(Seção Operações e Gerenciamento)

1) Atribuição e princípios

O objectivo é entregar pouco, mas de forma simples, apenas sinais relevantes, a um homem/robô responsável e oportuno, com um next-step compreensível.

• Actionable by default: Cada alert tem dono, prioridade, prazo de resposta e botão de ação.
• SLO-first: Os aleres são construídos em torno do SLI/SLO, não em torno de métricas arbitrárias.
• Noise-controlo: Dedups, correlações, supressão de tempestade.
• Context-rick: metadados (região, tenante, versão, trace _ id) e referência para runbook.
• Check-ready: Todas as alertas e reações são recebidas e salvas em um registro imutável.

2) Fontes de sinal

Aqueles. telemetria: disponibilidade, p95/p99, erro-rate, filas, limites de recursos.
Ivents de negócios: PriceMismatch, WebhookLag, RTP Drift, sinais de frod.
Segurança/Complacência: violações SoD, acesso PII, exportação de chaves/certificados.
Planeador: tarefas SLA vencidas, avalanches DLQ, retry-storms.

3) Classificação e prioridades

Guardrails: os alerts são formatados em relação ao orçamento de erro SLO/burn rate.

4) Routing e escalar 24 x 7

Routing por contexto: 'region/tenant/product/provider/severity'.
Escada escalável: on-call engenheiro → Lid de comando → Duty Gerente → Exec/Legal (para PII/finanças).
Roteiros por papel (SRE, App, Data, Security, Payments), contatos de reserva (bate-papo/voz/SMS).
Janelas de silêncio: noturno, lançamento, marketing; exceções para P1.

5) Barulho e correlação

Deduplicação por '(fingerprint, region, tenant, road)' e 'trace _ id'.
Supressão da tempestade, supressão temporária da duplicação do P1 ativo.
Correlações: agrupamento de sinais em torno da causa raiz (lançamento/fichá/provedor).
Histeresis: entrada/saída do limiar - diferentes para evitar a «serra».

6) Conteúdo alert (modelo)

Título: Resumo e objeto - «EU/Checkout: p95> 250ms (SLO breach)».
Campos-chave: prioridade, tempo, região, tenante, versão, trace _ id, affected%, . a razão.
O que fazer agora é: primeiro passo 1-3 + link para runbook/botão (Re-road, Rollback, Intervalo Promo).
Comunicação seguinte: N minutos, dono (IC/On-call).

7) Canais de entrega

Bate-papo: canal principal de triagem (bot cards com botões).
Pager/voz/SMS: para P1.
E-mail: relatórios e não-urbent (P3/Info).
Webhooks: integração com tiketing/orquestradores.
Página de status: notificação externa de clientes e parceiros.

8) Integração e «botões de ação»

Incidente-bot, cria um cartão, atribui um IC, abre um vídeo, e os temporizadores começam.
Руны (auto-actions): Re-route, Rollback, Raise Limit, Flush Cache, Disable Webhooks, Enable Safe Mode.
Direitos: O lançamento de runas está limitado a papéis; todas as ações são assinadas e logadas.

9) Multiregião e multi-tenant

SLO/liminares independentes por região; incidentes locais não «pintam» o mundo.
Filtros de visibilidade: parceiros/tenentes só veem o seu.
Os requisitos jurisdicionais são textos de notificação, idiomas, fusos horários.

10) Políticas, horários, janelas de silêncio

Política de alertas, proprietários, liminares, canais, escalações, modelos.
Calendários: horário de trabalho/fora de horário, janelas de lançamento/marketing.
Mudar freeze: flexibilizar liminares ou suprimir «não-P1» durante grandes promoções.

11) Auditoria e fixação legal

Recibos: para alertas críticos - 'receipt _ hash' e assinatura DSSE.
Registros WORM: armazenamento inalterado de eventos e reações (quem confirmou o que fez).
Chain-of-custody: rastreamento de escalas e soluções.

12) Métricas e SLO do sistema de notificação

MTTA (acknowledge): P1 ≤ 5-10 min; P2 ≤ 30 minutos

Page rate/On-call load: os sinais de mudança estão na faixa de destino.
Falso Positivo%: ≤ limite de destino (normalmente <10-15%).
Correlation efficiency: taxa de sinais agrupados ≥ 80%.
Delivery SLO, bate-papo ≥ 99. 9%, SMS/voz ≥ 99. 5%.
Time-to-Action: p95 para iniciar uma runa de alert.

13) Dashboards e repostos

Operacionais: incidentes ativos, burn-rate, mapa de regiões/tenentes, fila de alertas.
Qualidade de alertas: ruído, FP, retoques de liminares, zonas mudas.
Carga on-call: taxa de pagê, tempo de reação, «out of hours».
Pós-incidente, eficácia das runas, repetência das causas.

14) Especificidades do iGaming/fintech

Payments/PSP: P1 - falha do provedor, aumento das falhas de autorizações; Auto-root em PSP de reserva.
RTP & Limits: Alertas à deriva da RTP observada, excesso de limites, pattern suspeitos de ganho.
Afiliados/webhooks: liga de entrega, crescimento de duplicação, queda de recibos confirmados.
Price/FX/Tax: Inadequação de vitrina↔checkout, rasconsabilidade de versões de artefatos.
Jogo responsável: Triggers RG e escalação oportuna para suporte/Compliance.

15) RACI

16) Folha de cheque de implementação

• Definir North-Star e SLI/SLO; associar as alertas ao burn-rate.
• Digite o diretório de políticas: liminares, canais, escaladas, janelas de silêncio.
• Implementar o Dedup, as correlações, a histerese, a supressão da tempestade.
• Personalizar regras de visibilidade multiregional e multi-tenant.
• Ligar botões de ação e runbooks; limitar as permissões de lançamento.
• Incluir os recibos WORM, rastreamento de trace _ id e auditoria de roda.
• Construir dashboards de qualidade (noise, FP, MTTA, page rate).
• Провести GameDay: PSP outage, WebhookLag, PriceMismatch, RTP Drift.
• Rever as liminares regularmente; A/B liminares em métricas «mudas».
• Relatório de carga on-call e melhorias mensais.

17) Playbooks (árbitro)

PSP Outage (P1): auto-root para reserva, rebaixamento de temporizações de clientes, quarentena de transações cinzentas, status-update em 15 min.
WebhookLag (P2): Aumentar os workers/batch, priorizar as filas e interromper temporariamente os endpoints opcionais.
PriceMismatch (P1/P2): força-deficiência do cachê, confecção 'fx _ versão/tax _ rule _ versão', reversão do artefato, compensação.
RTP Drivt (P2): interrupção de bônus/promoção, auditoria de perfis, extensão da janela de vigilância.
Segurança: SoD/MFA fail (P1/P2): bloqueio de transações, reexame JIT, forense e Legal, se necessário.

18) FAQ

Como reduzir os falsos efeitos?
Regras orientadas pelo SLO, correlações, histerese, janelas de treinamento e revisão regular de liminares.

O que é mais importante, abrangência ou precisão?
Para P1 - Precisão e velocidade (melhor menor, mas crítico). Para P3 - abrangência de tendências e custos.

Precisas de um pager por telefone?
Sim, para P1; o bate-papo pode não estar disponível ou não estar disponível.

Como não queimar um comando on-call?
Limites de page rate, redistribuição de cargas, «follow-the-sun», ruídos mensais.

Resumo: Sistema de notificação e alertas é uma linha de montagem controlada do sinal para a ação. Construa-o em SLO, extingue o barulho, role no contexto, dê-nos os botões de ação e fixe tudo legalmente. Por isso, você reduz o MTTA, alivia a carga on-call e aumenta a resistência do negócio, mesmo com as subidas e falhas dos provedores.