Sistema de alertas y notificaciones

(Sección: Operaciones y Gestión)

1) Nombramiento y principios

El objetivo es entregar poco, pero acertadamente: sólo señales relevantes, oportuno y responsable persona/robot con un next-step comprensible.

• Actuable por default: cada alerta tiene un propietario, prioridad, fecha límite de reacción y botón de acción.
• SLO-first: las alertas se construyen alrededor de SLI/SLO, no alrededor de métricas arbitrarias.
• Noise-control: dedoop, correlaciones, supresión de tormentas.
• Context-rich: metadatos (región, tenant, versión, trace_id) y referencia al runbook.
• Audit-ready: todas las alertas y reacciones son acuñadas y guardadas en un diario inmutable.

2) Fuentes de señal

Esos. telemetría: disponibilidad, p95/p99, error-rate, valor de cola, límites de recursos.
Eventos de negocios: PriceMismatch, WebhookLag, RTP Drift, señales de frod.
Seguridad/cumplimiento: infracciones SoD, acceso PII, expiración de claves/certificados.
Planificador: tareas SLA caducadas, avalanchas DLQ, retroexcavadoras.

3) Clasificación y prioridades

Guardrails: las alertas se formulan con respecto a SLO/presupuesto de error (tasa de burn).

4) Enrutamiento y escalamiento 24 × 7

Routing por contexto: 'region/tenant/product/provider/severity'.
Escalera de escalada: ingeniero en llamada → líder de comando → Duty Manager → Exec/Legal (para PII/finanzas).
Funciones: rotaciones por roles (SRE, App, Data, Security, Payments), contactos de respaldo (chat/voz/SMS).
Ventanas de silencio: nocturna, de lanzamiento, de marketing; excepciones para P1.

5) Cancelación de ruido y correlaciones

Deduplicación: por '(fingerprint, region, tenant, route)' y 'trace _ id'.
Supresión de «tormenta»: supresión temporal de duplicados en P1 activo.
Correlaciones: agrupar las señales alrededor de la causa raíz (liberación/ficha/proveedor).
Histéresis: la entrada/salida del umbral es diferente para evitar la «sierra».

6) Contenido de alerta (plantilla)

Título: breve y sustantivo - «EU/Checkout: p95> 250ms (SLO breach)».
Los campos clave son: prioridad, tiempo, región, tenant, versión, trace_id, afectado%,. la razón.
Qué hacer ahora: primeros 1-3 pasos + referencia a runbook/botones (Re-route, Rollback, Pause Promo).
Siguiente comunicación: En N minutos, propietario (IC/on-call).

7) Canales de envío

Chat/mensajero: canal principal de triaje (tarjetas bot con botones).
Pager/voz/SMS: para P1.
Correo: informes y no residentes (P3/Info).
Webhooks: integraciones con tiketing/orquestadores.
Status Page: notificación externa a clientes y socios.

8) Integraciones y «botones de acción»

Incidente-bot: crea una tarjeta, asigna un IC, abre un mostrador de vídeo, inicia los temporizadores.
Руны (auto-actions): Re-route, Rollback, Raise Limit, Flush Cache, Disable Webhooks, Enable Safe Mode.
Derechos: el lanzamiento de runas está limitado a los roles; todas las acciones están firmadas y lógicas.

9) Multirregión y multi-tenant

SLO independientes/umbrales por región; los incidentes locales no «pintan» al mundo entero.
Filtros de visibilidad: los socios/tenantes solo ven los suyos.
Requisitos jurisdiccionales: textos de notificación, idiomas, zonas horarias.

10) Políticas, horarios, ventanas de silencio

Política de alertas: propietarios, umbrales, canales, escaladas, plantillas.
Calendarios: horas de trabajo/no laborables, ventanas de lanzamiento/marketing.
Cambiar freeze: suavizar los umbrales o suprimir el «no P1» durante las grandes acciones.

11) Auditoría y fijación legal

Recibos: para alertas críticas - 'receipt _ hash' y firma DSSE.
Registros WORM: almacenamiento inmutable de eventos y reacciones (quién confirmó lo que hizo).
Cadena de custodia: seguimiento de escalaciones y soluciones.

12) Métricas y sistemas de notificación SLO

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

Page rate/On-call load: señales de reemplazo - en el rango de destino.
False Positive%: ≤ del umbral de destino (generalmente <10-15%).
Eficacia de corrección: porcentaje de señales agrupadas ≥ 80%.
Delivery SLO: chat en vivo ≥ 99. 9%, SMS/voto ≥ 99. 5%.
Time-to-Action: p95 para lanzar una runa de alerta.

13) Dashboards y reporteros

Operativo: incidentes activos, burn-rate, mapa de regiones/tenantes, cola de alertas.
Calidad de alertas: ruido, FP, retestas de rápidos, «zonas mudas».
Carga on-call: frecuencia de pages, tiempo de reacción, «out of hours».
Post-incidente: la eficacia de las runas, la repetibilidad de las causas.

14) Especificidad de iGaming/fintech

Payments/PSP: P1 - Fallo del proveedor, aumento de denegaciones de autorización; auto-root en PSP de respaldo.
RTP & Limits: alertas a la deriva del RTP observado, superación de límites, patrones sospechosos de ganancias.
Afiliados/Webhooks: Maga entrega, aumento de tomas, caída de recibos confirmados.
Price/FX/Tax: no coincidencia de vitrina↔checkout, versiones de artefactos Rassincrone.
Juego responsable: RG-desencadenantes y su escalada oportuna en soporte/Compliance.

15) RACI

16) Lista de verificación de implementación

• Definir North-Star y SLI/SLO; asociar alertas a burn-rate.
• Introducir directorio de políticas: umbrales, canales, escaladas, ventanas de silencio.
• Realizar dedoup, correlaciones, histéresis, supresión de la tormenta.
• Configurar reglas de visibilidad multirregional y multi-tenant.
• Conectar «botones de acción» y runbooks; restringir los derechos de inicio.
• Habilitar WORM/recibos, rastreo de trace_id y auditoría de rutina.
• Construir dashboards de calidad (noise, FP, MTTA, page rate).
• Провести GameDay: PSP outage, WebhookLag, PriceMismatch, RTP Drift.
• Revisar periódicamente los umbrales; A/B umbrales en métricas «mudas».
• El informe sobre la carga de llamadas y las mejoras es mensual.

17) Playbucks (referencia)

PSP Outage (P1): auto-enganche en la reserva, downtime de los clientes, cuarentena de las transacciones «grises», status-update después de 15 min.
WebhookLag (P2): aumentar los workers/batch, priorizar las colas, pausar temporalmente los endpoints opcionales.
PriceMismatch (P1/P2): memoria caché con discapacidad de fuerza, conciliación 'fx _ version/tax _ rule _ version', retroceso del artefacto, compensación.
RTP Drift (P2): pausa de bonificaciones/promociones, auditoría de perfiles, ampliación de la ventana de vigilancia.
Seguridad: SoD/MFA fail (P1/P2): operación de bloqueo, revisiones JIT, forenzika y Legal si es necesario.

18) FAQ

¿Cómo reducir los falsos positivos?
Reglas orientadas a SLO, correlaciones, histéresis, ventanas de entrenamiento y revisiones regulares de umbrales.

¿Qué es más importante, el alcance o la precisión?
Para P1, precisión y velocidad (mejor menos, pero crítica). Para P3 - cobertura de tendencias y costo.

¿Necesitas una paginación telefónica?
Sí, para P1; el chat puede ser inaccesible o «sofisticado».

¿Cómo no «quemar» al equipo?
Los límites de la tasa de page, la redistribución de cargas, el «follow-the-sun», el rugido mensual de ruidos.

Resumen: El sistema de notificaciones y alertas es un transportador controlado de señal a acción. Construirlo en SLO, apagar el ruido, enrutar por contexto, vamos a botones de acción y arreglar todo legalmente. Por lo tanto, reduce la MTTA, elimina la carga de trabajo en línea y mejora la sostenibilidad del negocio, incluso con picos bruscos y fallas en los proveedores.