Monitoreo de SLA y SLO

1) Términos y roles

SLA (Service Level Agreement) es una obligación contractual externa con el cliente (cláusulas de penalización, préstamos).
SLO (Service Level Objective) es un nivel de servicio interno de destino que admite la ejecución de SLA.
SLI (Service Level Indicator) es un indicador medible en base al cual se evalúan los SLO/SLA.
Error Budget - Proporción válida de «inaccesibilidad/error» para el período: 'Budget = 1 − SLO'.
Scope: medido por los ojos del usuario (fin a fin). En microservicios, tanto a nivel de componente como de vía de acceso.

2) Selección de SLI: qué medir exactamente

El criterio es la correlación con la experiencia del usuario y el valor empresarial.

• Disponibilidad: porcentaje de solicitudes exitosas. 'SLI = exitosas/todas'.
• Latencia: la proporción de consultas es más rápida que el umbral T. 'SLI = P (latencia ≤ T)'.
• Calidad: proporción de respuestas correctas (sin 5xx/functz. errores).
• Relevancia de los datos: retardo de replicación/ETL ≤ X minutos.
• Rendimiento del proceso empresarial: porcentaje de pagos/registros exitosos.

Anti-patrones: considerar sólo 200 ki como «éxito», ignorando los errores empresariales; medir en una red de prueba en lugar de una red personalizada.

3) Fórmulas y ventanas de observación

• `Availability = (OK_requests / All_requests) × 100%`.

• 'P95 ≤ T' → se articula mejor como una fracción:' SLI =% de las solicitudes ≤ T'.
• Ejemplo: «99% de las consultas de búsqueda ≤ 300 ms en 28 días».
• Ventana deslizante: 28 o 30 días (equilibrio de sensibilidad y estabilidad). Para incidentes - ventanas adicionales: 1 h, 6 h, 24 h.

4) Error Budget y control de velocidad de cambio

Cálculo: bajo 'SLO = 99. 9% 'presupuesto =' 0. 1% 'de errores/inaccesibilidad durante el período.

• Presupuesto> 50%: lanzamientos y experimentos según el plan.
• Presupuesto del 10-50%: solo lanzamientos de bajo riesgo, endurecimiento de Canarias.
• Presupuesto <10%: congelación de versiones, causa raíz, mejora de la confiabilidad.
• Relación con los lanzamientos progresivos: canary/feature-flags «comer» presupuesto dosificado, con auto-descarga en la degradación.

5) Políticas de alerta: desde los umbrales hasta la tasa de burn

¿Por qué no «dupal SLO - suben la alerta»: demasiado tarde. Se necesita proactividad.

• 'BR = (error observado por ventana corta/error permitido por esta ventana)'.
• Si 'BR> 1' - el presupuesto se gasta más rápido de lo normal.

• Alerta rápida (el ruido es sensible, atrapa desastres): ventana 5-10 min, umbral BR 14-20 ×.
• Alerta lenta (captura degradaciones deslizantes): ventana 1-6 h, umbral BR 2-4 ×.
• Condiciones de combinación: funcionó rápido o lento - paginación on-call.
• Niveles: Buscapersonas para SLOs personalizados, tickets/notificaciones para degradaciones grises de SLIs internos.

6) Observabilidad y fuentes de la verdad

Los registros son diagnósticos de causas.
Métricas - SLI numéricos (éxito/error, percentili de latencia, share, contadores).
Los tracks son rutas end-to-end, localización de segmentos «hot».
Sintética: muestras activas de la periferia (región-aware).
Eventos reales: RUM/telemetría de clientes, métricas de negocio (conversiones, pagos exitosos).

Requisitos: una sola imagen en los dashboards de lanzamientos e incidentes, anotaciones «versión/canario/bandera».

7) Diseño de SLO: plantilla paso a paso

1. Describa el camino crítico (por ejemplo, «depositar con tarjeta»).
2. Identificar SLI: éxito/error, umbral de latencia, plenitud.
3. Acordar SLO: objetivo para 28 días + excepciones (ventanas programadas).
4. Póngase en contacto con SLA: obligación legal de ≦ el SLO real.
5. Asigne un propietario (service owner), un RACI y un canal de alertas.
6. Defina las políticas de alerta (BR de dos ventanas) y las revisiones automáticas.
7. Implemente informes: revisiones semanales del presupuesto, revisiones posteriores a incidentes.
8. Revise el SLO trimestralmente (cambio de carga/arquitectura).

8) Ejemplos de SLO (plantillas)

• Disponibilidad: '≥ 99. 95% '(28d, excluyendo las ventanas declaradas ≤ 30 min/mes).
• Latencia: '≥ 99%' de las respuestas '≤ 400 ms'.
• Éxito de las operaciones comerciales: '≥ 98. 5% 'de autorizaciones exitosas (se han tenido en cuenta los filtros de fraud).

• Latencia: '≥ 99%' de las consultas '≤ 300 ms'.
• Relevancia del caché: '≤ 5 min' rezagado en el 99% de los casos.

• Entrega: '≥ 99. 9% 'durante el' ≤ 60 '(end-to-end, con retrés).
• Pérdida: '≤ 0. 01% 'de los mensajes (idempotencia/deduplicación habilitada).

9) Multi-región y multi-tenant

SLO «por cohorte»: país, proveedor de pagos, segmento VIP, dispositivo.
SLO locales en el borde: métricas de los puntos más cercanos al usuario (edge/PoP).
Agregación: el SLO general no debe ocultar fallas en cohortes importantes.
Conmutación de proveedores: rutas de fallback automáticas a nivel de las puertas de SLO.

10) Dashboards y presentación de informes

Dashboard de lanzamiento: versión, canario (% de tráfico), SLI (éxito/latencia), BR, anotaciones de bandera.
Dashboard operativo: presupuesto burn-down por día, incidentes principales, MTTR, cohortes problemáticas.
Informes semanales: saldo presupuestario, tendencias BR, deuda técnica (cuellos de botella), plan de mejoras.

11) Procesos: incidencias, RCA y mejoras

Gestión de incidentes: alerta → puntuación BR → escala de Canarias/banderas → retroceso/fix.
RCA (causa raíz): hechos/línea de tiempo/hipótesis/correcciones/verificación de efectos por SLI.
Lecciones aprendidas: post-mortem no-tarately, items de acción obligatorios con los propietarios y los plazos.
Cierre de ciclo: cambios en las pruebas, banderas de fichas, límites, cachés, retiros, cuotas.

12) Cumplimiento y auditoría

SLO/SLI como artefactos de control (policy-as-code, registros inmutables).
Vinculación a requisitos (por ejemplo, disponibilidad de transacciones de pago).
Pruebas: registros de alertas, informes de presupuesto, registros de lanzamientos/revisiones.

13) Errores frecuentes y cómo evitarlos

“99. 99% o muerte": objetivos inalcanzables → ruido de alerta constante. Elegir SLO realistas.
Los promedios globales ocultan fallas locales → introducir cohortes.
Métricas no e2e: los SLO altos con degradación real en el cliente → añadir RUM/sintética.
Las alertas de un umbral → cambiar a una tasa de burn de dos ventanas.
No hay relación con los cambios → las versiones no están anotadas, no hay retroceso automático.

14) Mini check-list de implementación

• Se describen las rutas críticas y sus SLI/SLO.
• Se ha establecido una ventana de observación y exclusión.
• Alertas BR de dos ventanas personalizadas (rápidas y lentas).
• Dashboards de lanzamientos y operaciones con anotaciones de versiones/banderas.
• La política error budget afecta a las versiones.
• Revisiones periódicas del presupuesto y RCA post-incidente.
• Documentación y titulares de indicadores.

15) Ejemplo de cálculo (específico)

SLO de disponibilidad API: 99. 9% en 28 días → presupuesto = 0. 1%.
Se acumuló 0 en 7 días. El 06% de los errores → consumido el 60% del presupuesto semanal.
Hay un 2% de errores en la ventana corta de 15 minutos. Válido en esta ventana: '0. 1% × (15 min/40320 min) ≈ 0. 000037%`.
Burn Rate ≫ 1 (decenas de ×) → se activa el buscapersonas rápido, el canario retrocede hasta el 1%, se incluye la bandera de ficha «degrade-payments-UX», se inicia RCA.

16) Resultado

El monitoreo de SLA/SLO no es solo una cifra en el informe, sino un mecanismo para gestionar el riesgo de cambios y la calidad del servicio. Los SLIs adecuados, los SLOs realistas, el control de error budget, las alertas de doble ventana burn-rate y la e2e-observabilidad convierten las métricas en soluciones de trabajo: liberan valor más rápido y mantienen la experiencia del usuario predecible.