Alertas en tiempo real

1) Objetivos y principios

Objetivo: notificar a las personas/sistemas correctos, con puntualidad, precisión y dirección, sobre eventos que amenacen SLO, ingresos y cumplimiento, y ejecutar acciones correctas (manuales/automáticas).
Principios: SLO-primero, minimización del ruido, explicabilidad, contexto, priorización por impacto empresarial, «una señal es una acción comprensible».

2) Taxonomía de señales

Señales SLO: burn-rate presupuesto de errores en rutas críticas (inicio de sesión, depósito, tasa, retiro).
KRI: Indicadores de riesgo tempranos (caída de autocuss en PSP por banco/GEO, crecimiento de consumer-lag, p99↑).
Eventos: flaps de dependencia, failover, conmutación manual, activación de defensas (rate-limit, WAF).
Seguridad/cumplimiento: aumento de operaciones sensibles, exportación de PII, infracciones de SoD.

3) Niveles y SLA de alertas

4) Fuentes y correlación del contexto

Telemetría: métricas/trayectos/registros, sintéticos y RUM.
Catálogos: CMDB/servicio de mapeo, propietarios, dependencias.
Cambios: lanzamientos, fichas, migraciones, trabajos programados.
Proveedores externos: PSP/KYC/estudios de juegos/estados CDN/WAF.
Cada alerto se enriquece: ¿qué ha cambiado cerca? (lanzamiento/fichflag), ¿qué dependencias son rojas?, ¿qué segmento se ve afectado? (GEO/PSP/banco/tenant).

5) Reglas de alerta SLO (núcleo)

Burn-rate: dos ventanas (1h rápida y 6-24h lenta). Pager - sólo si se excede al mismo tiempo.
Guardrails: los umbrales de p99/error-rate sólo sirven como desencadenantes del análisis contextual, no reemplazan al SLO.
Impacto: evaluación de «proporción de audiencia × dinero/min × regulaciones» → nivel de P1-P4.

6) Supresión de ruido

Deduplicación: agrupación por servicio/tenante/causa; rompemos un incidente en lugar de docenas de señales.
Histéresis: confirmaciones N-de-M, duración mínima de la anomalía.
Silens/muts: obras programadas, incidentes conocidos, ventanas «follow-the-sun».
Límites y cuotas: por fuente/etiqueta/tenant; protección contra la «tormenta».
Reducción de la cardinalidad: prohibido userId/sessionId en las etiquetas de alerta.

7) Enrutamiento y escalamiento

Routing por contexto: dominio (Payments/Games/Core), entorno (prod/stage), región, gravedad.
Escalaciones: t0 - on-call L1; t0 + X - L2/propietario del dominio; t0 + Y - IC/guía. El tiempo de X/Y depende del P1-P3.
Duplicación a través de los canales: pager + chat en P1; Chat/ticket en P3.
Cambio de turno: transmisión automática del contexto (timeline, acciones realizadas, hipótesis).

8) Auto-acción (auto-remediation)

Pagos: cambio de PSP por health × fee × conversion, restricción de bancos/métodos, retrés con jitter.
Juegos/apuestas: habilitar caché-wedge/restringir operaciones de escritura, queue-page/waiting-room en el frente.
Infra: evacuación del tráfico, restart de los workers degradantes, escalar a lo largo de la lag.
Seguridad/cumplimiento: cierre temporalmente la exportación de PII, introduzca un control dual para las operaciones P1.
Cualquier auto-acción - con política de reversión y criterios de devolución.

9) Runbook-primera experiencia

Cada alerta está relacionada con el runbook: objetivo, diagnóstico rápido (3-5 comprobaciones), pasos de fix/reversión, personas de contacto, enlaces a dashboards y página de estado. En el chat/buscapersonas mostramos una breve tarjeta de acción.

10) Él-call política

Rotación 24 × 7, cobertura de dominios (Payments/Game Core/SRE).
"Second on-call' para P1, la regla de dos personas en una sala de var.
Quiet-hours y ventanas de guardia por zonas (follow-the-sun).
Formación: ejercicios trimestrales (tabletop/game-day), turnos de sombras.
Créditos post-incidente (aprox-time) para evitar burnout.

11) Integración

Gestión de incidentes: auto-creación de tarjetas, cintas apdate, roles IC/CL, temporizadores.
Status page: publique P1/P2 (a través de Comms Lead) con plantillas y localización.
Lanzamientos: release-gates por SLI, auto-stop/rollback bajo alertas.
Catálogos: propietarios, CMDB, contactos de proveedores.

12) Ejemplos de alertas (iGaming)

1. Autocuss en PSP-1 en TR↓ en un 25% en 10 minutos

P2→P1 con cobertura> 30% de las transacciones.
Auto-acción: redistribuir el tráfico de PSP-2/3; incluir 3DS simplificado; alert Partner Manager.

2. p99 «stavka→settl»> 3 normas × en la UE

Razones: Replicación de registro, cola de workers.
Auto-acción: scale-out workers, warmup caché, apagar temporalmente fiches no críticos.

3. Export PII spikes

P1 en ausencia de ticket/aprobación.
Auto-acción: unidad de descarga, notificación de cumplimiento, verificación de SoD.

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

MTTA-Comms/MTTA-Ops: tiempo antes de la reacción/primera acción.
Precision/Recall (alerta ↔ incidente), False Alarm Rate.
Tiempo de respuesta antes de la violación de SLO, TTD (tiempo de detección).
Pager fatigue: alertas/persona/ned., llamadas nocturnas, porcentaje de «chupetes».
Tasa Auto-Fix: una fracción de los problemas cerrados por una reacción automática sin una persona.
Aging: proporción de días colgantes P3/P4> X.

14) Gestión de costos

Cuotas de alertas/fuentes, corte de etiquetas redundantes.
Downsampling y agregación de métricas, sampling de pistas; retenciones por clase.
Coste-revisión regular: $/alerta, $/SLI-dashboard, serie «heavy».

15) Privacidad y cumplimiento

Sin PII en el texto de alertas y sellos; tokenización de identificadores.
Directivas de acceso (RBAC/ABAC), SoD en la configuración de alertas.
Auditoría de cambios de reglas, versionamiento, pruebas y diff.

16) Hoja de ruta para la implementación (6-10 semanas)

Ned. 1-2: catálogo de SLI/KRI, mapa de propietarios, niveles de P1-P4, primeras reglas de SLO (burn-rate).
Ned. 3-4: dedup/histéresis/silens, integración con sistema de incidentes y chats, ligamentos de runbook.
Ned. 5-6: auto-acción para Payments/Queues, release-gates, feed status page.
Ned. 7-8: contexto (lanzamientos/fichas/proveedores), tarjetas PSP × banco × GEO, ejercicios P1/P2.
Ned. 9-10: FinOps de alerta, KPI-dashboards, revisión de umbrales y cuotas, entrenamiento on-call.

17) Artefactos y patrones

Alert Spec: métrica/condición, ventanas, supresión, propietario, runbook, auto-acción.
Mapa de ruta: domen→kanal→eskalatsii, contactos de respaldo.
Política de silencio: reglas de mutación (incidentes planificados/conocidos) que pueden incluir.
On-call Handbook: rotaciones, cambio de turno, listas de cheques de P1/P2, canales.
Paquete posterior: descarga de alertas/líneas de tiempo, análisis de la calidad de las señales.

18) Antipattern

Pager por «crudo» p95/p99 sin SLO → ruido y fatiga.
Docenas de señales sobre lo mismo (sin dedoop/correlación).
La falta de un runbook o propietario de una alerta.
Umbral «en piedra» sin estacionalidad/segmentación (GEO/PSP/banco/hora).
Sin devolución después de las acciones automáticas (no hay criterios roll-back).
Etiquetas con PII y userId → riesgos y una explosión de cardinalidad.

Resultado

Una alerta realmente útil es una cinta transportadora SLO centrada: reglas contextuales con burn-rate, supresión de ruido inteligente, enrutamiento claro y escalada, runbook-primera experiencia y acción automática segura. Este circuito atrapa eventos críticos antes que los usuarios, reduce el MTTR, protege los ingresos y, al mismo tiempo, cuida de la rutina «pager-hell».