Operaciones y Gestión → Predicción de incidentes

Predicción de incidentes

1) Por qué es necesario

Los incidentes rara vez «estallan de la nada». Antes del fallo, la plataforma da señales: crecimiento acelerado del p99, agotamiento lento del error-presupuesto, retraso de las colas, crecimiento de los retraídos en el downstream específico, aproximación de las cuotas del proveedor. La predicción sistémica de incidentes traduce la respuesta de la «extinción de incendios» en una «intervención temprana», reduciendo el MTTR, la Tasa de Fallos de Cambio y la pérdida de ingresos.

• Identificar patrones de precursores e iniciar automáticamente acciones preventivas.
• Reducir la proporción de P1/P2 al desplazarse a la izquierda (tasa de detección previa al incidente).
• Incrustar predicciones en los procesos de liberación, failover y capacity-proactive.

2) Mapa de señales (lead indicators)

• Aceleración p95/p99 (gradiente), «colas» de latencia, aumento de variación.
• Colas/estribos: crecimiento del 'lag' y derivado positivo del lag; HPA en el máximo.
• BD/caché: 'active _ conns/max _ conns',' replication _ lag ',' evictions ', caída' cache _ hit '.
• Red: errores mTLS/handshake, crecimiento 5xx/timeout hacia fuera.

• 'outbound _ error _ rate '/' retry _ rate' al proveedor específico, 'circuit _ open', 'quota _ usage> 0. 9`.
• SLA del proveedor: ventanas planificadas, degradación.

• Carga anormal (campañas/partidos), saltos de RPS/TPS, mezclas inusuales de regiones/canales.
• Las conversiones de depósitos/apuestas caen cuando aumenta el p99 → un incidente cuasi-proxy.

• Burn-rate error-presupuesto> umbral (por ejemplo,> 4 × durante 10-15 min).
• Frecuentes alteraciones menores del SLO (micro-degradación) como marcador de un fallo que se aproxima.

3) Fuentes y vitrinas de datos

Telemetría online: Prometheus/OTel (métricas, registros, tracks).
Eventos de incidentes: tickets/estados/postmortemas (verdad para el target).
Plan/hechos de cambios: lanzamientos, fichflags, migraciones, ventanas de proveedores.
Manuales: mapa de dependencias, cuotas, propietarios.
Imágenes DWH: agregados para aprendizaje/validación (¡ventana sincrónica!).

Requisitos de calidad: plenitud ≥99%, alineación hora/minuto TZ, definiciones uniformes p95/p99.

4) Enfoques de predicción

4. 1 Reglas/no paramétricas (inicio rápido)

Alertas de umbral para la velocidad de cambio: 'deriv (p99)', 'z-score' para ventanas cortas.
Condiciones compuestas: 'lag↑ + HPA = max + circuit_open (to = «PSP-X»)'.
SLO-burn-gates: restos de lanzamiento/canario en burn-rate> X.

4. 2 Detección de anomalías

Baselines de temporada (STL/ideas similares a Prophet), rolling mediana + MAD.
Multivariate: anomalía conjunta 'p99 + retry + open_circuit + quota'.
Detección de puntos de cambio: CUSUM/BOCPD para cambios de tendencia.

4. 3 modelos ML (supervisados)

Clasificación «incidente en T + K?» por la ventana de signos (por ejemplo, 10-30 minutos antes).
Señales: estadísticas, derivados, residuos estacionales, proveedores/regiones de uno-hot, banderas de lanzamientos.
Etiquetas: 'incident{severity∈[P1,P2]}' en el intervalo [t, t + K].
Explainability: SHAP/Permutation importance para la confianza y la operatividad.

4. 4 SRE-first híbrido

Modelo → puntuación de riesgo (0-1) → política de acción (fichflags/feilover/pre-skale), con HITL para la crítica.

5) Diseño de características (ingeniería de características)

Ventanas deslizantes (1/5/15 min): mean, p95/p99, std, max, slope.
Indicadores relativos: 'p99/baseline _ 1d',' error _ rate _ delta '.
Fiches de cohorte: proveedor, región, tipo de juego/partido, canal del dispositivo.
Fiches de «carga»: RPS, tamaño de pago, número de WS abiertos.
Sistemas: 'hpa _ desired/max', 'db _ conn _ ratio', 'redis _ evictions> 0'.
Banderas del evento: «ahí va la liberación», «el canario 10%», «la ventana del proveedor».

6) Mecánica de predicciones y acciones

1. Puntuación de riesgo cada N segundos por dominio (Pagos/Apuestas/Juegos/KYC).

• riesgo ≥ 0. 8 + señales de confirmación → página del propietario del dominio;
• 0. 6–0. 8 → advertencia + preparación de medidas.

• pre-skale (HPA minReplicas↑), habilitar cachés, limitar funciones pesadas;
• conmutación/ruta del proveedor de respaldo;
• pausa/rollback canario;
• el límite de retraídas al «estrecho» downstream.

4. HITL: una persona confirma medidas de nivel de «cambio de comportamiento empresarial».

7) Integración en procesos diarios

Lanzamientos: gates predictivos en Canarias (comparación «antes/después» y puntuación de riesgo).
Feilover: preparación automática/calentamiento de la ruta de respaldo en caso de riesgo del proveedor.
Capacity: "early uplift' cuando el headroom cae y los lags crecen.
Alertas: cinta separada «pre-incidente» + anotaciones en dashboards.

8) Observabilidad y dashboards

Risk Overview: el riesgo por dominios y proveedores, las tendencias, la contribución de los signos.
Lead Signals: top-N de los precursores (gradiente p99, lag, breakers abiertos).
Actions & Outcomes: lo que se encendió, el efecto en p95/error, incidentes cancelados.
Model Health: precision/recall/latency, características de conducción, frecuencia de las autocaravanas.

9) Métricas de la calidad de las predicciones

Recall @ P1/P2 (sensibilidad en incidentes críticos).
Precision (menos «páginas falsas»).
Lead Time (mediana de «cuántos minutos antes del hecho»).
Intervencion Win-rate (porcentaje de casos donde la acción ha reducido el riesgo/costo).
Alert Fatigue Index (alertas/cambio/persona).
Drift Score (stat. diferencias en las distribuciones de los signos vs del período de aprendizaje).

Objetivos predeterminados: Recall (P1) ≥ 0. 7, Precision ≥ 0. 6, Lead Time mediana ≥ 8-10 min.

10) Gestión de riesgos del modelo (ML Ops/Governance)

Versificación de datos/código/artefactos, reproducibilidad.
Champion/Challenger: el nuevo modelo va en paralelo, la comparación fuera de línea/en línea.
Deriva: divergencia PSI/KL, umbral de lista automática, alert «modelo obsoleto».
Explainability: para cada decisión, almacenar la importancia de los signos y la referencia a los datos.
Seguridad/ética: accesos, enmascaramiento PII, control de autocaravanas por parte de las políticas.

11) Ejemplos de reglas y políticas

policy:
if slo_burn_rate{service="payments"} > 4 for 10m and release_phase in ["canary", "post-deploy_30m"]:
action: pause_release_and_rollback notify: squad-payments

risk_psp_x = sigmoid(
1. 2z(outbound_p99_ms) +
1. 5z(outbound_error_rate) +
0. 8z(retry_rate) +
1. 0I(quota_usage>0. 9) +
0. 7I(circuit_open=1)
)
if risk_psp_x > 0. 8 for 5m -> route_to_psp_y + reduce_features

if (consumer_lag > 5e6 and deriv(consumer_lag) > 5e4) and hpa_desired == hpa_max:
action: scale_consumers + throttle_producers + enable_batching

12) Lista de verificación de implementación (30-60 días)

• Catálogo de señales y «verdad» sobre incidentes (severity, timelines).
• Líneas de base y estacionalidad para métricas clave (antes/después del lanzamiento).
• Reglas de las señales tempranas (gradientes p99, lag, burn-rate).
• Dashboards Risk/Lead Signals/Actions.
• Integración con fichflags/canarios, pre-skale HPA.
• Piloto del clasificador ML en un solo dominio (por ejemplo, Pagos).
• Las políticas HITL y el registro de autocaravanas.
• Métricas de calidad y alertas a la deriva/modelo de salud.

13) Anti-patrones

«Bolas de cristal»: un sofisticado modelo ML sin líneas básicas y reglas sencillas.
No hay actionability: predecimos «malo», pero no hacemos nada automáticamente.
Ignorar la estacionalidad/calendario de eventos (partidos/torneos) → falsas alarmas.
Mezcla de zonas de tiempo → ventanas de métricas/incidentes incorrectas.
Falta de explainabilidad → desconfianza, desactivación del predicto por parte de los equipos.
Un umbral global único para todos los dominios/regiones → baja precisión.

14) Especificidad de los dominios (iGaming)

Payments: proveedores/cuotas, crecimiento de 'retry _ rate' y 'circuit _ open' → failover temprano.
Bets: retardo en la actualización de coeficientes, crecimiento de WS-fan-out → límite de difusión.
Juegos/Live: ráfagas de conexiones, límites de estudio → degradación de UI/caché.
KYC/AML: retrasos en webhook, colas de verificación → HITL y procesamiento diferido.

15) Ejemplos de métricas y alertas (ideas)

ALERT PreIncidentRiskHigh
IF risk_score{domain="payments"} > 0. 8 FOR 5m
LABELS {severity="critical", team="payments"}

ALERT LeadSignalP99Slope
IF deriv(api_p99_ms{service="bets"}[5m]) > 15 AND api_p99_ms > baseline_1d 1. 2 FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderEarlyQuota
IF usage_quota_ratio{provider="psp_x"} > 0. 85 FOR 10m
LABELS {severity="info", team="integrations"}

ALERT StreamLagStorm
IF (kafka_consumer_lag{topic="ledger"} > 5e6 AND rate(kafka_consumer_lag[5m]) > 5e4)
AND hpa_desired == hpa_max FOR 10m
LABELS {severity="critical", team="streaming"}

16) KPI del programa de predicciones

Tasa de detección previa al incidente (porcentaje de incidentes evitados/mitigados).
Avg Lead Time antes del incidente.

Reducción en P1/P2 de QW/Q2

MTTR (esperado ↓ debido al contexto temprano).
False Alarm Rate/Alert Fatigue (estable ↓).
Costa Avoidance (estimación de pérdidas evitadas/multas/sobremesa).

17) Inicio rápido (receta)

1. Habilite las reglas de degradado en p99/lag y SLO-burn;

2. Agregue condiciones compuestas para los proveedores;

3. Asocia el predicto con los fichflags y el pre-skale;

4. Informe «predicción → acción → efecto»;

5. Piloto de ML en el mismo dominio; escalar después del crecimiento de Precision/Recall.

18) FAQ

P: ¿Por qué empezar sin ML?
R: Líneas de base estacionales + gradientes + reglas compuestas. Esto da un aumento notable de Recall sin complicaciones.

P: ¿Cómo no ahogarse en los positivos de folios?
R: Combine señales, introduzca histéresis y tiempo de confirmación, configure umbrales por dominio/región, evalúe Precision y Alert Fatigue.

P: ¿Qué acciones automatizar primero?
R: Seguro y reversible: pre-skale, activación de cachés/degradación, pausa/rollback canario, conmutación del proveedor con señales confirmadas.