SLO, SLA y monitoreo de confiabilidad

(Sección: Tecnologías e Infraestructura)

Resumen breve

SLO es un objetivo de calidad interno, SLA es un compromiso externo con el cliente, SLI - cómo medimos la calidad. En iGaming, los SLI clave son: disponibilidad de API y pago, p95/p99 latencia de rutas críticas, Time-to-Wallet (TTW), conversión de pagos, lanzamiento de juegos y métricas de colas. La gestión de la fiabilidad se construye en torno al presupuesto de errores, alertas multi-burn, gates de lanzamientos claros y dashboards visuales con anotaciones.

1) Términos y diferencias

SLI (Service Level Indicator) es un indicador a medir (por ejemplo, la proporción de solicitudes exitosas por ventana de tiempo).
SLO (Service Level Objective) es el valor objetivo de SLI (por ejemplo, "disponibilidad 99. 9% en 30 días").
SLA (Service Level Agreement) - Contrato/compromiso con indemnizaciones; se basa en SLO reales, pero incluye cláusulas legales y ventanas de excepciones (mantenimiento planificado, fuerza mayor).

Regla: primero estabilice el SLI/SLO dentro, y solo después fije el SLA hacia afuera.

2) Marco SLI para iGaming

TexSLO

Disponibilidad: 2xx/3xx/todas las solicitudes exitosas.
Latency: p95/p99 por routs clave ('/deposite ', '/bet', '/game/init ').
Errors: una fracción de 5xx/Timaut.
Saturation/Queues: retrasos en las colas de pagos/transacciones.

SLI de negocios

Payment conversion: `success/attempt`.
TTW p95: tiempo desde la solicitud de retiro hasta la inscripción.
Game start success: sesiones de juegos, inicialización del proveedor.
Éxito de flujo KYC/AML: finalización exitosa de la ruta.

3) Presupuesto de errores: cómo contar

Error Budget = 1 − SLO.
Ejemplo: SLO de disponibilidad 99. 9 %/30d ⇒ presupuesto de errores = 0. 1% del tiempo ≈ 43min 12s en la ventana de 30 días.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

SLO cuenta en la ventana deslizante (30/7/1 día) y es visible en los dashboards.

• Rápida «combustión» del presupuesto → freeze lanzamientos, Canarias parado, trabajando en la estabilidad.
• El stock del presupuesto → permitimos cambios más frecuentes (controlables).

4) Ejemplos de SLO para subprocesos clave

• Availability ≥ 99. 9 %/30d
• Latency p95 `/deposit` ≤ 250 ms / 30д
• Payment conversion ≥ baseline − 0. 3 %/24h
• TTW p95 (salida) ≤ 3 min/24h

• Game init success ≥ 99. 5% / 7д p95 game init ≤ 600 ms / 7д

• Job success ≥ 99 %/7d, lag <5 min (ventanas pico por separado).

5) Medición: fórmulas y PromQL (ideas)

promql sum(rate(http_requests_total{status=~"2..    3..",service="payments-api"}[5m]))
/
sum(rate(http_requests_total{service="payments-api"}[5m]))

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))

promql histogram_quantile(0. 95,
sum by (le) (rate(ttw_seconds_bucket{flow="withdrawal"}[15m])))

promql sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m]))

6) alertas Burn-rate (multi-window)

Idea: Comparamos la tasa de gasto actual del presupuesto con la permitida.

• Fast burn: 14 × de presupuesto en 1 hora → page en 5-15 minutos.
• Slow burn: 6 × de presupuesto en 24 horas → ticket, análisis de causa.

yaml recording rule: job:http:success_ratio — заранее alert: SLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page" }

alert: SLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

7) Dashboards «tarjeta SLO» y operación

• Tarjetas por servicio: Availability, p95, Error-rate, Burn-rate, resto Error Budget.
• Filtros: 'env', 'region', 'tenant', 'version'.
• Anotaciones de lanzamiento: Git SHA, tipo (canario/azul-verde), tiempo de conmutación.

• Comparación de stable vs canary.
• Corte por PSP/proveedores de juegos.
• Ir a exemplars (trace_id) y logs relacionados.
• Queue lag and saturation (métricas USE).

8) Procesos SLO: gates, freeze, escaladas

Gates en CD: la promoción canaria sólo se permite cuando se realiza un proxy SLO (availability, p95, amb).
Freeze: con fast-burn o cero remanente de presupuesto - stop releases antes de la recuperación.
Escaladas: Matriz SEV (pagos/depósitos SEV1, juegos de SEV2, SEV3 backofis).
RCA: examen sin cargos, actualización de pruebas/límites/fichflags.

9) Data/ML-SLO (para recomendadores/LLM)

Latency: p95 respuesta del modelo ≤ 300 ms (o tokens/s ≥ N).
Calidad proxy: proporción de respuestas válidas/baja toxicidad, compartir de helpful.
Freshness: edad de fichas/datos ≤ X horas.
Costo por 1k eventos: gastos en el presupuesto.
Las gates SLO se integran en los lanzamientos de los modelos (A/B/canario rollout).

10) Diseño de SLA basado en SLO

Elija SLOs conservadores como base de SLAs.
Defina excepciones (trabajos programados, proveedores dependientes externos, reglamento de incidentes).
Introduzca indemnizaciones por niveles de infracción (crédito/descuento), mecanismos de denuncia y verificación.

11) Errores frecuentes y anti-patrones

No hay SLO, sólo «uptime 100%» - no es realista, desmotiva y esconde riesgos.
Las alertas de «cada métrica» en lugar de burn-rate son alert-fatig e ignore.
Mezcla de PII en métricas/logs para SLO: riesgos de cumplimiento.
La cardinalidad explota: 'user _ id/session _ id' como etiquetas.
No hay anotaciones de lanzamientos - es difícil asociar la degradación con los cambios.
Presupuesto de error opaco: el equipo no entiende cuándo «se puede» arriesgar.
SLO no está ligado a los negocios - los «verdes» tecnétricos, los ingresos son «rojos».

12) Lista de verificación de implementación

1. Apruebe los SLI básicos (Disponibilidad, p95/p99, Error-rate, TTW, Conversión).
2. Configure SLO en las ventanas de 30/7/1 día y cuente Error Budget.
3. Agregue las reglas de grabación y las alertas burn-rate (fast/slow).
4. Construye una tarjeta SLO con anotaciones de lanzamientos y comparaciones canario/stable.
5. Incluye las gates en el CD: sin SLO-ok - sin promoción.
6. Introduzca los procedimientos freeze y la matriz de escalamiento SEV.
7. Vincule SLO con métricas de negocio (amb, TTW) y rutas de pago.
8. Para Data/ML, defina latency/quality/freshness-SLO.
9. RCA regulares y revisión de SLO/umbrales (trimestral).
10. Documente el SLA sólo después de estabilizar el SLO.

13) Ejemplos de objetivos «listos» (como el comienzo)

API generales: Disponibilidad 99. 9 %/30д; p95 ≤ 250 ms/30d; Error-rate ≤ 0. 3 %/30д.
Payments: Conversion ≥ baseline − 0. 3 %/24ч; TTW p95 ≤ 3 min/24h.
Games init: Success ≥ 99. 5 %/7д; p95 ≤ 600 ms/7d.
Backoffice jobs: Success ≥ 99%/7д; lag ≤ 5 min/7d.
LLM/Reco: tokens/s ≥ N, toxicity viol. ≤ 0. 5 %/7d, freshness ≤ 6h.

Resultados

El enfoque SLO/SLA transforma la fiabilidad de «mejor que ayer» a una disciplina medible: SLI transparentes, presupuesto de error comprensible, alertas de velocidad de combustión, dashboards comprensibles y gates de calidad incorporados en los lanzamientos. Este circuito le da a la plataforma iGaming un p95/p99 predecible, pagos estables y TTW, lo que significa mejores ingresos y menos incidentes en las horas más calurosas.