Operaciones y Gestión → Prevención de Incidentes

Prevención de incidentes

1) Por qué es necesario

La mejor respuesta al incidente es su ausencia. Para iGaming/Fintech, cada minuto de inactividad: apuestas/depósitos perdidos, multas de proveedores, riesgos de reputación. La prevención del sistema reduce la Tasa de Fallas de Cambio, estabiliza el SLO y libera tiempo de los equipos para desarrollar, en lugar de apagar, incendios.

• Minimizar la probabilidad de incidentes en rutas críticas (depósito, apuesta, lanzamiento del juego, retirada).
• Interceptar las degradaciones antes de golpear el SLO y la cartera.
• Limite el radio de falla (blast radius) y acelere la recuperación.

2) Principios básicos de prevención

1. SLO-primero y error budget: los cambios no se liberan si se corre el riesgo de derribar el SLO y quemar el presupuesto.
2. Defence in depth: capas de protección: desde esquemas de datos y configuraciones hasta políticas de red y fichflags.
3. Design for failure: rompecabezas, timautas, retraídas con jitter, idempotencia, degradación.
4. Cambios pequeños y reversibles: incrementos pequeños + retroceso rápido (flags feature/canario).
5. Observabilidad por diseño: métricas/registros/tracks para cada paso crítico y comunicación.

3) Mapa de riesgos y rutas críticas

Haz un «mapa del dolor» por dominios: Pagos, Apuestas, Juegos, KYC, Promociones, Jackpots, Contenido.

• Métricas de negocio (conversión, GGR, cheque medio).
• SLO técnico (latency p95/p99, uptime, tasa de éxito).
• Dependencias (internas/externas), límites/cuotas.
• Comportamiento «modo seguro» (que desactivamos/simplificamos).
• Runbook del propietario.

4) Guardrails (barreras de protección)

Taimauts y breakers: el servicio que llama tiene un timaut más corto que la suma de los internos; el rompedor se abre cuando hay un aumento de errores/latencia.
Aislamiento de Bulkhead: grupos individuales de conexiones/workers en downstream.
Rate limit & backpressure: protección contra avalanchas y tormentas retray.
Fichflags de degradación: «modo mínimo»: respuestas fáciles, réplicas de caché, apagado de los fiches pesados.
Multi-vendedor y failover: PSP/KYC alternativos, cambio de ruta.
Validación de confecciones: esquemas/liners/políticas para cambiar de forma segura los límites y los límites.

5) Gestión de cambios (Change Management)

Pre-release gates: pruebas, seguridad, CDC (consumer-driven contracts), compatibilidad de circuitos.
Lanzamiento canario + autogates: 1% → 10% → 100%; auto-parada en crecimiento p99/error rate/presupuesto de combustión.
Flags de función: retroceso/cambio de comportamiento instantáneo sin deboir.
Release calendar: evitamos las ventanas pico de los deportes/torneos y el mantenimiento en los proveedores.
Cheques post-deploy: auto-smock, comparación de métricas «antes/después» con umbrales.

6) Pruebas como medida preventiva

Unidad/contrato/integración: contratos OpenAPI/AsyncAPI, CDC vs proveedor/moc.
Load & stress: perfiles de tráfico para prime time; pruebas de límites de connects/IOPS/cuotas.
Soak/long-haul: fugas de recursos, aumento de retrasos en el horizonte de horas/días.
Chaos/game-days: caída del bróker/PSP/KYC, ruptura de la región, «proveedor lento».
Disaster Recovery Drills: entrenamiento regular para cambiar de región y recuperar la DB.

7) Detección temprana de degradación

Capacity-alerts: headroom, lags de colas, connects DB, eviction en cachés.
SLO-burn-rate: señal a una velocidad peligrosa de «quema» del presupuesto.
Umbrales adaptativos: patrones de estacionalidad/diurnos para reducir los falsos.
Alertas compuestas: «lag ↑ + HPA at max + open circuit» ⇒ alto riesgo.
Vendor health: cuotas/tiempos de espera/errores para cada proveedor + costo de llamadas.

8) Trabajar con proveedores externos

OLA/SLA ↔ SLO: vincular los acuerdos a nuestros objetivos.
Playbooks Feilover: rutas PSP-X ⇆ PSP-Y, caché de tokens, modos de depósito grace.
Sandbox y contratos: prueba flow antes de cada cambio mayor.
Ventanas de proveedores: anotaciones en dashboards y reglas automáticas de suppress.

9) Datos, confecciones y secretos

Políticas de cambio: revisión de código de dos pares de ojos, validación de esquemas/JSON/YAML.
Secretos: KMS/Secrets Manager, rotación, división por entorno/roles.
Banderas/límites: cambiar a través de la API con auditoría y cancelación instantánea.
Migraciones: «dos pasos» (expand → migrate → contract), compatibilidad con retroceso total.

10) Entrenamiento y preparación de los equipos

Formación on-call: simulaciones de incidentes, Shadow-services, runbook centralizado 'i.
Formatos de comunicación únicos: plantillas de estado/hendover/incidente-update.
Cultura segura: postmortem sin cargos, causas mecanicistas y acciones preventivas.

11) Dashboards de prevención (mínimo)

Risk & Readiness: SLO/presupuesto, headroom por capas, «top de conexiones vulnerables».
Cambio Seguridad: porcentaje de canarios, retrocesos, alertas «post-lanzamiento», CTR de autogates.
Vendor Panel: p95/error/cuotas/costo por proveedor, tiempo de respuesta del vendedor de sapport.
Chaos/DR Readiness: frecuencia de ejercicio, tiempo de cambio de región, éxito de recuperación.
Config/SecOps: cambios de banderas/límites/secretos, anomalías.

12) Ejemplos de alertas preventivas

ALERT SLOBurnRateHigh
IF slo_error_budget_burnrate{name="payments_api"} > 4 FOR 10m
LABELS {severity="critical", team="payments"}

ALERT PostDeployRegression
IF (api_p99_ms{service="bets"} > baseline_1d 1. 3) AND (release_window="canary")
FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderQuotaNearLimit
IF usage_quota_ratio{provider="psp_x"} > 0. 9 FOR 5m
LABELS {severity="warning", team="integrations"}

ALERT QueueLagAtRisk
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"}

13) Lista de prevención (diario/antes de los picos)

• Calendario actual de picos (partidos, torneos, campañas, ventanas de proveedores).
• Headroom por API/DB/caché/colas, preparación de HPA/VPA, calentamiento de cachés.
• Estado de los proveedores (cuotas, límites, degradación en 24h), Feilover configurado.
• Las gaitas canarias están incluidas, los flagelos de retroceso están disponibles para los propietarios.
• Las alertas SLO/Capacity están activas, la suppression está prescrita para los trabajos programados.
• Runbook 'y actualizado, on-call confirmado, los canales de escalada son trabajadores.

14) Anti-patrones (qué evitar)

«Grandes lanzamientos nocturnos» sin canario ni banderas.
Grupos de subprocesos compartidos en todos los downstreams (bloqueo principal de línea).
Retraídas a operaciones no idempotentes y a taimautas de cuellos de botella.
La ausencia de histéresis en las alertas → el aserrado a lo largo del umbral.
La fe ciega en el SDK de un vendedor sin supervisión y control de los timautas.
«Lo haremos en venta» sin steage/sandbox y CDC.

15) KPI de prevención

Change Failure Rate (objetivo ≤ 10-15% o su objetivo).
Tasa de detección previa al incidente: proporción de incidentes evitados durante la fase de degradación.
Mean Time Between Incidents (MTBI) и MTTR.
Coverage de las defensas: el % de las vías críticas con flagami/breykerami/taymautami/kanareykoy.
Cadencia Chaos/DR: frecuencia y éxito de las enseñanzas.
Vendor readiness: tiempo medio de conmutación por proveedor de respaldo.

16) Inicio rápido (30 días)

Semana 1: mapa de rutas críticas, SLO y propietarios; incluir alertas SLO-burn y alertas capacity.
Semana 2: Gates canarios + fichflags; scripts de chaos básicos (proveedor/cola).
Semana 3: «Change Safety» y «Vendor Panel» dashboards, Fakebooks.
Semana 4: Enseñanza DR (parcial), retrospectiva y plan de hardening 'a para el trimestre.

17) Plantillas (fragmentos)

canary_policy:
guardrails:
- metric: api_p99_ms threshold: 1. 3 baseline_1d window: 10m action: pause_and_rollback
- metric: error_rate threshold: 2 baseline_1d window: 5m action: pause max_step: 10%
step_interval: 15m required_annotations: [release_notes, feature_flags, runbook_link]

safe_mode:
payments:
- freeze_heavy_providers
- enable_cached_token_flow
- route_to_psp_y_if(psp_x_error_rate > 5%)
games:
- limit_broadcasts
- reduce_lobby_heavy_widgets bets:
- raise_risk_score_threshold
- cache_odds_snapshot

18) FAQ

P: ¿Qué implementar en primer lugar si hay pocos recursos?
R: SLO-burn-alertas en caminos críticos, gates canarios y fichflags de retroceso; a continuación, un mapa de riesgos y un failover de proveedores.

P: ¿Cómo entender que la prevención «funciona»?
R: La tasa de falla de cambio está disminuyendo, la proporción de incidentes prevenidos está aumentando, el MTTR está cayendo y el ruido de alertas está disminuyendo, el número de paginas «nocturnas» está disminuyendo.

P: ¿Se necesitan ejercicios regulares de chaos?
R: Sí. Sin entrenamiento, el feilover y el DR son casi siempre más largos y dolorosos de lo que parece en el papel.