SLA, SLO y KPI de fiabilidad

1) Términos y diferencias

SLI (Service Level Indicator) es un indicador de calidad medible (por ejemplo, porcentaje de solicitudes exitosas, p95 de latencia).
SLO (Service Level Objective): valor de destino SLI por ventana de tiempo (por ejemplo, "éxito ≥ 99. 9% en 28 días").
Error de presupuesto (Error Budget): porcentaje válido de incumplimiento de SLO: '1 − SLO'.
SLA (Service Level Agreement) - obligaciones contractuales con multas/préstamos (externos).
KPI de fiabilidad: métricas de proceso operativas (MTTD/MTTA/MTTR/MTBF,% de mitigates automáticos, recubrimiento de alertas, etc.).

2) Cómo elegir SLI (basado en Golden Signals)

1. Latency - p95/p99 para endpoints clave.
2. Tráfico - RPS/RPM/flujo de mensajes.
3. Errors es una fracción de 5xx/error empresarial (por ejemplo, «decline» de pago por culpa de PSP excluir).
4. Saturación - saturación de recursos (CPU/RAM/IO/nat).

• Correlaciona con la experiencia del usuario (user-perceived).
• Técnicamente disponible y estable en la medición.
• Controlamos (acciones posibles para mejorar).
• Bajo costo de recaudación.

3) Fórmulas y ejemplos

3. 1 Disponibilidad (disponibilidad)

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

Ejemplo: SLO 99. 9% en 30 días → presupuesto de errores = 0. 1%, equivalente a 43 min 12 segundos de inaccesibilidad.

3. 2 Latencia

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 Pagos (nivel empresarial)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) Presupuesto erróneo y tasa burn-rate

Un error de presupuesto es su «tanque de combustible» para la innovación (lanzamientos, experimentos).

• canal rápido (niño en ~ de 1 hora),
• canal lento (tendencia detrás ~ 6-12 h/24 h).

• Si burn-rate> 14. 4 por 1 hora - SEV-1 (comamos el presupuesto diario por ~ 100 min).
• Si burn-rate> 6 en 6 horas - SEV-2 (degradación rápida).

5) Alerting por SLO (multi-window, multi-burn)

Indicador de error: fracción de 5xx o infracciones de latencia.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) Ejemplos de SLI/SLO por dominios

6. 1 puerta de enlace API/Edge

SLI-Errors: porcentaje de respuestas 5xx <0. 1% (28d).
SLI-Latency: p95 ≤ 250 ms (día).
SLO: Availability ≥ 99. 95% (trimestre).

6. 2 Pagos

SLI-Success: pague con éxito (excluyendo los rechazos de cliente) ≥ 99. 8% (28d).
SLI-Latency: autorización ≤ 2 segundos para 99% (día).
SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6. 3 Bases de datos (PostgreSQL)

SLI-Lag: lag de replicación p95 ≤ 1 segundo (día).
SLI-Errors: porcentaje de errores de consulta ≤ 0. 05% (28d).
SLO: disponibilidad del clúster ≥ 99. 95%.

6. 4 Colas/Streaming (Kafka)

SLI-Lag: p95 ≤ N mensajes (hora).
SLI-Durability: confirmación de registro ≥ 99. 99% (28d).
SLO: disponibilidad de corredores ≥ 99. 9%.

7) KPI del proceso de confiabilidad

MTTD (Mean Time To Detect)

MTTA (… To Acknowledge)

MTTR (… To Restore)

MTBF (… Between Failures)

% de incidentes con mitigación automática

Cobertura de SLO/alertas de tráfico superior (objetivo ≥ 95%)

Porcentaje de lanzamientos con fase canaria

Consumo de presupuesto erróneo por comandos/fichas

8) Cómo poner SLO es realista

1. Mida la fiabilidad básica actual (3-4 semanas).
2. Identificar «sensibles» rutas de usuario (inicio de sesión, depósito, juego).
3. Tenga en cuenta el costo de cada desviación (tiempo, dinero, reputación).
4. Elija un objetivo ambicioso pero alcanzable (una mejora del 10-30% a la base).
5. Revise trimestralmente.

• Inmediatamente «cinco novenas» sin justificación.
• SLO por métricas no visibles para el usuario (por ejemplo, CPU sin comunicación con UX).
• Demasiado SLO → atomizar el foco.

9) Informes sobre SLO y presupuestos

• Ejecución de cada SLO: hecho vs objetivo, tendencias, confidence.
• Resumen del consumo de errores: cuánto presupuesto «quemado» que, por quién (lanzamiento/incidente).
• Las cinco principales causas de degradación, el plan CAPA y el estado de las tareas.
• Impacto en el negocio: conversión, ND, retención, LTV.

10) Relación con la política de lanzamiento

Presupuesto de error <50% → versiones gratuitas.
50-80% → «modo cauteloso»: sólo las colocaciones de bajo riesgo/Canarias.

11) SLA (contractual) - plantillas de cláusulas

Obligación de accesibilidad: por ejemplo, 99. 9 %/mes.
Excepciones (Force Majeure): DDoS fuera de control razonable, proveedores de terceros.
Ventana de medición y área de responsabilidad: fuentes métricas, método de cálculo.
Créditos/multas: tabla de niveles (por ejemplo, inaccesibilidad 60-120 min → crédito X%).
Procedimientos de escalamiento y notificación: plazos, canales.
Datos y privacidad: enmascaramiento, almacenamiento, Legal Hold.
Plan de Trabajo de Prevención de Repeticiones (CAPA) en caso de infracción.

12) Herramientas de medición

Métricas pasivas: Prometheus/Mimir/Thanos, exportadores.
Logs: Loki/ELK para contar aciertos/errores a nivel empresarial.
Sintética: muestras activas (inicio de sesión/depósito/juego) por cron.
Seguimiento: Tempo/Jaeger para «cuellos de botella» p99.
Pago/finanzas: las fuentes de la verdad de tierra para el SLI de pago.

13) Ejemplos de consultas (plantillas)

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

14) FinOps y confiabilidad

Costo por 9: el costo de agregar «nueve» crece exponencialmente.
Curva de beneficios: óptimo donde el aumento de ingresos/reducción de pérdidas ≥ el costo de un «9» adicional.
Cartera de SLO: diferentes niveles para diferentes rutas (pagos críticos «más caros», reporting «más baratos»).

15) Calidad SLO/alertas - lista de verificación

• SLI se correlaciona con UX y métricas de negocio.
• Ventana y agregación acordados (rolling 28d/trimestre).
• Alertas multi-ventana, sin flapping, con routing de rol.
• Documentación: propietario, fórmula, fuentes, runbook.
• El panel de demostración de SLO con el presupuesto erróneo y los indicadores burn.
• Revisión periódica de los objetivos (trimestral).
• Pruebas de sintética en escenarios clave.

16) Plan de implementación (4 iteraciones)

1. Semana 1: inventario de rutas de usuario, borradores de SLI, bases de datos.
2. Semana 2: formalización de SLO, cálculo de presupuestos, alertas (fast/slow burn).
3. Semana 3: integración con el proceso de incidentes/lanzamientos, reglas libres.
4. Semana 4 +: SLA contractual, rugido trimestral, modelo de phinops «costo por 9».

17) Mini preguntas frecuentes

¿Necesitas tener un SLO por servicio?
Mejor 2-3 claves (éxito + latencia) en lugar de decenas de secundarias.

¿Qué pasa si se agota el presupuesto?
Congelación de lanzamientos, enfoque en la estabilización y CAPA, eliminación de fiches experimentales.

¿Cómo evitar un conflicto entre la velocidad de lanzamiento y la fiabilidad?
Planifique lanzamientos «con presupuesto», implemente diseños canarios y flags de características.

Resultado

La fiabilidad no está controlada por un conjunto de métricas dispares, sino por un sistema: SLI → SLO → un error de presupuesto → burn-alerting → el proceso de incidentes → CAPA → SLA. Estandarice las definiciones, las fuentes de datos y los informes, vincule los objetivos a la experiencia del usuario y la economía, y revise periódicamente el nivel de «nueve» en función del ROI real.