Sistema de sinais e notificações

1) Papel e objetivos

O sistema de sinalização não é «enviar mensagens», mas sim o caminho da tomada de decisões, que ilumina os desvios a tempo, oferece ações e respeita o equilíbrio entre o tempo e o silêncio.

• Reduzir o MTTD/MTTR por meio da priorização e playbooks claros.
• Reduzir alert fatiguue (fadiga de alertas) através do som.
• Dar ações diretamente a partir da notificação (ack, snoose, runbook, automático).
• Manter privacidade e consentimento (opt-in/opt-out, armazenamento de logs).

2) Taxonomia de eventos e níveis

2. 1 Tipos de evento

Métricas/anomalias (SRE, produto, finanças).
Regras de negócios (limites, frod, KYC, pagamentos).
Sistema (deplom, degradação, licenças).
Personalizado (Triggers comportamentais, RG/jogo responsável).

2. 2 Níveis de Importância (Severity)

Critical - reação imediata, risco de perdas/segurança.
High é uma deterioração significativa do KPI/SLO.
Medium - precisa de ações durante o horário de trabalho.
Low/Info - observação/contexto, auto-encanamento em mergulhos.

2. 3 Prioridade (Priority)

Matriz de 'Impact x Urgency' → P1... P4. Alinhamento a canais e reações SLA.

3) Arquitetura e fluxo

Fabricantes de sinais pneus de eventos Normalização (enrich, dedupo) Correlação Regras (policy engine) Rotação Canais de entrega para Centro de Preferência Logi/Analista.

• Enricher: adiciona tenante, papel, região, links para playbooks.
• Deduper: agrupar eventos repetitivos por chave.
• Correlator: colar sinais familiares em um incidente.
• Policy Engine: regras YAML/DSL, quiet hours, escalação.
• Delivery: in-app, email, push, SMS, webhook, integração de bate-papo.

4) Regras e políticas (por exemplo, YAML)

yaml policies:
- id: p_sre_critical match: { domain: "infra", severity: "critical" }
route:
primary: { channel: "pager", targets: ["oncall_sre"] }
fallback: { channel: "sms", delay: "2m" }
suppress:
flapping: {window: "10m," threshold: 5} # suppressing frequent twitching duplicates: {key: ["service, ""cluster,"" error _ code"], ttl: "15m"}
escalate:
after: "10m"
to: ["sre_manager"]
auto_assign: true
- id: p_product_medium match: { domain: "product", severity: "medium", kpi: "conversion" }
route:
primary: { channel: "inapp", audience: "product_owners" }
digest:
window: "1h"
max_items: 10 quiet_hours:
tz: "Europe/Kyiv"
ranges: ["22: 00-07: 00"] # only P1 digests/pager at this time

5) Deduplicação, correlação, supressão de flapping

Deadup: ID do grupo 'dedup _ key = hash (service' metric 'dim') '; A TTL ≥ uma janela de flapping.
Correlação: junte os sinais relacionados por topologia (servis→zavisimost), tempo (£ N min) e contexto (lançamento, incidente).
Flapping: liminares «N eventos em M minutos» → um sinal «flapping detected» com sugestões para elevar a histerese ou supress.

6) Rotação e RACI

Poupível: quem recebe a primeira notificação/tusk.
Accountable: quem é escalado depois do SLA.
Consulted: quem mencionar no trade/bate-papo.
Informed: quem vai precisar de um mergulho/resumo.
Atribua de acordo com o papel e o contexto (tenante, região, produto estrim).

7) Canais de entrega e nuances

Retrai: 5xx/429/timeout → backoff + jitter; 'Retry-After' respeitar. Idempotidade: 'X-Notificação-ID' em webhooks.

8) Centro de preferência (Preference Center)

Opt-in/Opt-out por tipo de evento, nível, canal.

Gráfico de silêncio (quiet hours), snoose manual de 15/30/60 minutos

Limiar/sensibilidade (por exemplo, anomalia ≥ 3g).
Língua/local, formato de tempo/moeda.
Vinculação a papéis: Presetos para SRE/Product/Finance.
Transparência: mostrar por que o usuário recebeu um sinal (referência à regra).

9) Conteúdo-design: estrutura da mensagem

• Título: Resumidamente, com o desencadeador: «[P1] [PSP _ TR] Aumento acentuado de falhas 3DS (+ 12%)».
• Contexto: período, segmentos/região afetados, origem de dados.
• Razão/hipótese: «Ligado ao lançamento PSP _ X 18:20 UTC».
• SLA/Deadline: «Escalação em 10 min».
• CTA: «Abrir playbook», «Ativar fallback PSP _ Y», «Ack (30 min)».
• Links: gráfico, incidente, métricas, runbook.
• Metadados: 'trace _ id', 'invident _ id', 'dedup _ key'.

Tom: factos, sem dramatização; números e unidades de medida; evitar as abreviações sem decifrar.
Localização: variáveis → playsholders, traduções armazenadas em recursos; números/datas por local.

10) Ações de notificação (Actionable)

Ack/Snoose com opções de tempo.
Assign/Invite no triplo incidente.
Runbook: abra os passos de solução com um contexto completo.
One-click remediation (onde é seguro): altera a rota, eleve o limite, reinicie o jobs (com confirmação e áudio).
Criar um tíquete (Jira/GitHub) com a substituição automática dos campos.

11) Qualidade dos sinais: métricas e alvos

Precision (proporção de relevantes entre os enviados) ≥ 80% para P1/P2.
Recall (taxa de detecção de todos os incidentes) ≥ 70%.
Noise: média de sinais/hora por usuário (teto de destino).
Ack-time p50/p95, Escalation rate, Snoose rate (como indicador de ruído).
MTTD/MTTA/MTTR (em corte de domínios e canais).
Silenced-out-should-alert (omissões por regras) é um dashboard separado.

12) Gerenciamento de ruídos: técnicas

Histerese e janelas deslizantes para liminares.
Suavização (EWMA) antes da detecção.
Agregação: em vez de 30 pequenos, um batch/mergulho com os principais contorcionistas.
Limites contextuais: no máximo N notificações/hora/canal/usuário.
Feedback automático: Se um usuário 3 x consecutivo clicar no Snoose → sugerir que você eleve o limite/altere o canal.

13) Segurança, privacidade, complacência

Assinatura HMAC para webhooks, rotação de segredos, 'X-Key-Id'.
RBAC/ABAC: visibilidade de sinais por papéis/tenentes.
Minimização PII, máscaras em logs, auditoria de ações (ack/assign/runbook).
O consentimento (consent) e os motivos da notificação (regra/política) estão no payload.
Retenção/TTL logs de notificação, Legal Hold sobre incidentes.

14) Circuitos e payload's

Evento (interno)

json
{
"id": "sig_01HX",
"domain": "payments",
"severity": "high",
"priority": "P2",
"title": "The 3DS failure graph has grown to 8. 2% (+3. 1 pp), "
"occurred_at": "2025-11-03T17:55:00Z",
"context": { "psp": "PSP_X", "country": "TR", "release_id": "rel_241103_1820" },
"metrics": { "baseline": 5. 1, "current": 8. 2, "delta_pp": 3. 1 },
"dedup_key": "payments    PSP_X    TR    3DS_FAILURE",
"runbook": "rbk_psp_3ds_spike",
"slo": { "ack_deadline_sec": 600 }
}

Notificação (canal agnóstico)

json
{
"notification_id": "ntf_91ab",
"signal_id": "sig_01HX",
"targets": ["oncall_payments"],
"channels": ["inapp","slack","webhook"],
"cta": [
{"id": "ack," "label": "Confirm (30 min)," "payload": {"ttl ":" 30m"}},
{"id": "runbook," "label": "Open playbook," "payload": {"id ": "rbk _ psp _ 3ds _ spike"}},
{"id": "fallback," "label": "Enable fallback, PSP_Y" "confirm": true}
],
"hmac": "sha256=AbCd..."
}

15) Pattern Ux no produto

Inbox: guias Critical/High/Other, crachás de quantidade.
Fita do incidente, sinais correlacionados, temporizações, «o que foi feito».
Filtros: papel, domínio, região, hora, apenas sem resposta.
Ações rápidas na lista (ack/snoose/assign).
Explain: «por que você vê isso» (regra, liminares, dados).
Digestes: manhã/noite, localizados por TZ.

16) Plano de teste

Unit: chaves de dedução, histerese, flapping, seriado payload's.
Integration: Rotação, quiet hours, escalações, retais de canais.
E2E: cenário P1 da anomalia ao fechamento do tíquete; P2 em quiet hours → mergulho.
Chaos: perda de canal (SMTP/SMS), atrasos, avalanche de sinais, clock-skew.
A11y/i18n: screen-readers, teclado ack/snoose, localização de números/datas.

17) Dashboards de qualidade

Precision/Recall para domínios.
Ack time p50/p95 e proporção de confirmados pontualmente.
Noise per user/hour e regras mais barulhentas.
Escalation rate e «escalações falsas».
Supressed vs Delivered (quanto suprimido/reduzido em mergulho).
User feedback :/mensagens, comentários sobre o ruído.

18) Folhas de cheque

Projeto

• Taxonomia de eventos e níveis negociados
• As políticas de quiet hours/escalações são descritas
• Duplicação/correlação/flapping configurados
• Canais, Retraias, Idempotação dos webhooks
• Centro de preferência (opt-in/out, snoose)
• Modelos de conteúdo e localização
• Playbooks e ação one-click (com áudio)
• Métricas de qualidade e dashboard

Operação

• Otimização de limiar uma vez por trimestre
• A/B regras (limiar, janelas, digest)
• Revisões regulares de «som top» e CAPA
• Rotação de segredos de canais (HMAC, SMTP, SMS)
• Teste de alarme (game days) agendado

19) Plano de implementação (3 iterações)

Iteração 1 - Caminho básico (2-3 semanas)

Taxonomia, severity/priority, centro de preferência (in-app + email).
Dedup, simples correlação chave/tempo, quiet hours.
Modelos de mensagens, playbooks, ack/snoose/assign.

Iteração 2 - Confiabilidade e ruído (3-4 semanas)

Flapping/histerese, mergulho, integração de bate-papo e webhooks (HMAC, retrai).
Escaladas por SLA, dashboards de qualidade (precisão/recall, noise).
One-click remediation (com confirmação e áudio).

Iteração 3 - Otimização e zoom (contínuo)

Correlação por topologia/lançamentos, permissões automáticas.
A/B das regras, a previsão é «quando o limiar funcionar».
Revisões de ruído e game days regulares.

20) Mini-FAQ

Como lutar contra alert fatiguue?
Dedup, correlação, histerese, mergulho e centros de preferência + revisões regulares de ruído e liminares A/B.

O ML é necessário para as anomalias?
É útil, mas comece com regras determinadas e liminares explicáveis. O ML é como um complemento, necessariamente com o Exploration.

Porque é que os usuários recebem e-mails extras?
Verifique os jogos de regras, quiet hours, auditoria «porquê entregue», configure os limites de canal/hora e os mergulhos.

Resultado

Um sistema forte de sinais é filtragem inteligente e priorização correta + ação em um clique. Formalize a taxonomia e as políticas, implemente o deadup/correlação/histerese, dê aos usuários o controle (preferências, snoose), garanta uma entrega segura e a transparência «por que eu consegui». Então os sinais serão uma ferramenta de controle, não uma fonte de ruído.