Sistema de señales y notificaciones

1) Función y objetivos

El sistema de señales no es un «envío de mensajes», sino un circuito de toma de decisiones: resalta las desviaciones a tiempo, ofrece acciones y mantiene un equilibrio entre puntualidad y silencio.

• Reducir MTTD/MTTR mediante la priorización y los playbooks claros.
• Reducir el alert fatigue (cansancio de las alertas) a través de la cancelación de ruido.
• Dar acciones directamente de la notificación (ack, snooze, runbook, autocaravana).
• Respetar la privacidad y el consentimiento (opt-in/opt-out, almacenamiento del registro).

2) Taxonomía de eventos y niveles

2. 1 Tipos de eventos

Métricas/anomalías (ERE, producto, finanzas).
Reglas de negocio (límites, frod, KYC, pagos).
Sistemas (deploy, degradación, licencias).
Personalizado (disparadores de comportamiento, RG/juego responsable).

2. 2 Niveles de importancia (Severity)

Critical - reacción inmediata, riesgo de pérdida/seguridad.
High es un deterioro significativo de KPI/SLO.
Medium: se requieren acciones durante las horas de trabajo.
Low/Info - Observación/Contexto, Auto-Convolución a los digestos.

2. 3 Prioridad

La matriz 'Impact × Urgency' → P1..P4. Enlace a los canales y SLA de la reacción.

3) Arquitectura y flujos

Fabricantes de señales → Bus de eventos → Normalización (enrich, dedoup) → Correlación → Reglas (policy engine) → Enrutamiento → Canales de entrega → Centro de preferencias → Logs/Analytics.

• Enricher: agrega tenant, rol, región, enlaces a playbucks.
• Deduper: agrupar los eventos recurrentes por clave.
• Correlator: pegar señales relacionadas en un incidente.
• Motor de políticas: reglas YAML/DSL, quiet hours, escaladas.
• Delivery: en-app, email, push, SMS, webhook, integración de chat.

4) Reglas y políticas (ejemplo 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) Deduplicación, correlación, supresión de flapping

Dedoup: ID de grupo 'dedup _ key = hash (servicio' metric 'dim)'; TTL ≥ una ventana de flapping.
Correlación: combine las señales relacionadas por topología (servis→zavisimost), tiempo (± N min) y contexto (liberación, incidente).
Flapping: los umbrales de «N eventos en M minutos» → una señal «flapping detected» con la sugerencia de levantar histéresis o suppress.

6) Enrutamiento y RACI

Responsable: quién recibe la primera notificación/task.
Accountable: quién está escalando después del SLA.
Consultado: a quién mencionar en el hilo/canal de chat.
Informed: ¿a quién irá el resumen/los resultados.
Asignar por función y contexto (tenant, región, producto-stream).

7) Canales de envío y matices

Retrai: 5xx/429/timaut → backoff + jitter; 'Retry-After' respetar. Idempotencia: 'X-Notification-Id' en webhooks.

8) Centro de preferencias (Preferences Center)

Opt-in/Opt-out por tipo de evento, niveles, canales.
Gráfico de silencio (quiet hours), snooze manual a 15/30/60 minutos.
Umbral/sensibilidad (por ejemplo, anomalía ≥ 3 σ).
Idioma/local, formato de tiempo/moneda.
Referencia a roles: presets para SRE/Product/Finance.
Transparencia: muestra por qué el usuario recibió la señal (referencia a la regla).

9) Diseño de contenido: estructura de mensajes

• Título: breve, con desencadenante: «[P1] [PSP _ TR] Fuerte aumento de fallas de 3DS (+ 12%)».
• Contexto: período, segmentos/región afectados, origen de datos.
• Razón/Hipótesis: «Relacionado con el lanzamiento de PSP_X 18:20 UTC».
• SLA/deadline: «Escalada en 10 min».
• CTA: "Abrir playbook", "Activar fallback PSP_Y", "Ack (30 min)".
• Enlaces: gráfico, incidente-tred, métricas, runbook.
• Metadatos: 'trace _ id', 'incident _ id', 'dedup _ key'.

Tono: hechos, sin dramatización; números y unidades; evitar las siglas sin descifrar.
Localización: variables → playsholder, las transferencias se almacenan en recursos; números/fechas - por localidad.

10) Acciones de notificaciones (Actionable)

Ack/Snooze con parámetros de tiempo.
Assign/Invite en el límite del incidente.
Runbook: abre los pasos de la solución autocompletando el contexto.
Remediación de un clic (donde es seguro): cambiar de ruta, elevar el límite, reiniciar el joba (con confirmación y auditoría).
Crear un ticket (Jira/GitHub) con relleno automático de campos.

11) Calidad de las señales: métricas y objetivos

Precision (porcentaje relevante entre los enviados) ≥ 80% para P1/P2.
Recall (porcentaje de todas las incidencias detectadas) ≥ el 70%.
Noise: señales medias/hora por usuario (techo objetivo).
Ack-time p50/p95, Escalation rate, Snooze rate (como indicador de ruido).
MTTD/MTTA/MTTR (en el corte de dominios y canales).
Silenced-but-should-alert (pases debido a las reglas) es un dashboard separado.

12) Control de ruido: recepciones

Histéresis y «ventanas deslizantes» para los umbrales.
Suavizado (EWMA) antes de la detección.
Agregación: en lugar de 30 pequeños - un batch/digest con los mejores contributores.
Límites contextuales: no más de N notificaciones/hora/canal/usuario.
Retroalimentación automática: si el usuario presiona Snooze 3 × seguidas → sugerir subir el umbral/cambiar el canal.

13) Seguridad, privacidad, cumplimiento

Firma HMAC para webhooks, rotación de secretos, 'X-Key-Id'.
RBAC/ABAC: visibilidad de señales por roles/tenantes.
Minimización PII, máscaras en los logs, auditoría de acciones (ack/assign/runbook).
Consentimiento (consent) y razones de la notificación (regla/política) - en payload.
Retention/TTL registros de notificaciones, Legal Hold sobre incidentes.

14) Esquemas y 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 }
}

Notificación (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) Patrones UX en el producto

Inbox: fichas Critical/High/Other, etiquetas de cantidad.
Cinta del incidente: señales correlacionadas, tiempo de acción, «qué se hizo».
Filtros: rol, dominio, región, tiempo, «sólo sin respuesta».
Acciones rápidas en la lista (ack/snooze/assign).
Explain: «por qué lo ves» (regla, umbrales, datos).
Digestos: matutino/vespertino, localizado por TZ.

16) Plan de prueba

Unidad: llaves de dedoup, histéresis, flapping, serialización de payload's.
Integración: enrutamiento, quiet hours, escaladas, retransmisiones de canales.
E2E: escenario P1 desde la anomalía hasta el cierre del ticket; P2 en quiet hours → digest.
Chaos: pérdida de canal (SMTP/SMS), latencia, avalancha de señales, clock-skew.
A11y/i18n: screen-readers, teclado ack/snooze, localización de números/fechas.

17) Dashboards de calidad

Precision/Recall por dominios.
Ack time p50/p95 y la proporción confirmada a tiempo.
Noise per user/hour y las reglas más ruidosas.
Escalation rate y «falsas escaladas».
Suppressed vs Delivered (cuánto se suprime/reduce a un resumen).
User feedback :/mensajes, comentarios de ruido.

18) Hojas de cheques

Diseño

• Los niveles y la taxonomía de los eventos están acordados
• Las políticas de quiet hours/escalaciones se describen
• Dedoup/correlación/flapping configurados
• Canales, retraídas, idempotencia de webhooks
• Centro de preferencias (opt-in/out, snooze)
• Plantillas de contenido y localización
• Playbucks y acciones de un solo clic (con auditoría)
• Métricas de calidad y dashboards

Operación

• Optimización del umbral una vez al trimestre
• Reglas A/B (umbral, ventanas, digest)
• Revisiones regulares del «ruido superior» y CAPA
• Rotación de secretos de canal (HMAC, SMTP, SMS)
• Prueba de alarma (días de juego) programada

19) Plan de implementación (3 iteraciones)

Iteración 1 - Bucle básico (2-3 semanas)

Taxonomía, severity/priority, centro de preferencias (in-app + email).
Dedoup, correlación simple por clave/tiempo, quiet hours.
Plantillas de mensajes, playbooks, ack/snooze/assign.

Iteración 2 - Fiabilidad y cancelación de ruido (3-4 semanas)

Flapping/histéresis, digestos, integración de chat y webhooks (HMAC, retraídas).
Escaladas por SLA, dashboards de calidad (precision/recall, noise).
Remisión de un clic (con confirmación y auditoría).

Iteración 3 - Optimización y escala (continua)

Correlación por topología/lanzamientos, auto-oferta de umbrales.
A/B del reglamento, pronóstico «cuando el umbral funcione».
Reseñas de ruido y días de juego regulares.

20) Mini preguntas frecuentes

¿Cómo lidiar con el alert fatigue?
Dedoup, correlación, histéresis, digestos y centros de preferencias + revisiones regulares del ruido y umbrales A/B.

¿Se necesita un LM para anomalías?
Útil, pero comience con reglas deterministas y umbrales explicables. ML - como un complemento, necesariamente con Explain.

¿Por qué los usuarios reciben correos electrónicos «extra»?
Compruebe los partidos de reglas, quiet hours, auditar «por qué se entrega», configurar los límites de canal/hora y digestos.

Un sistema de señal fuerte es el filtrado inteligente y la priorización correcta + acciones de un solo clic. Formalice la taxonomía y las políticas, implemente el dedoup/correlación/histéresis, dé a los usuarios el control (preferencias, snooze), proporcione una entrega confiable y transparencia «por qué lo recibí». Entonces las señales se convertirán en una herramienta de control, no en una fuente de ruido.