Skip to main content

SLI, SLO, SLA y Error Budget

Al hablar de DevOps, el objetivo es entregar los proyectos de la mejor forma posible y crear la mejor experiencia para el usuario. Pero para saber si estamos alcanzando ese objetivo es necesario medir.

No siempre lo que pensamos que está bien realmente está bien.

SLI, SLO, SLA y Error Budget ayudan a alinear las expectativas con tu usuario. Son los pilares para medir la entrega y la calidad de cualquier servicio de TI.

Es necesario alinear con tu equipo estos niveles de servicio para tener éxito. Se usan para medir y establecer metas para la calidad de la aplicación y de su infraestructura, además de alinear con el usuario el rendimiento y la disponibilidad del producto que vamos a entregar.

Eficiencia y Confiabilidad son piezas clave en el mundo DevOps siendo el diferencial entre el servicio bueno y el excelente.

Aprender sobre estas siglas involucra la mejora continua de la aplicación.

SLI (Service Level Indicator)​

El indicador de nivel de servicio son las métricas que definen el buen funcionamiento del sistema. Todo depende de qué tipo de sistema estamos hablando, pero poniéndose en el lugar del usuario, ¿qué sería un buen sistema funcionando? Algunas métricas que podrían ser consideradas para medir un rendimiento. No es necesario usar todas, solo como idea, pues cada sistema es un sistema diferente.

  • Tiempo de carga de la página. Una espera de más de 3 segundos puede hacer que un cliente desista de una compra. Podríamos crear una métrica para medir el porcentaje de veces que la página carga en menos de 2 segundos. ¿Qué podríamos hacer para mejorar ese porcentaje?
    • ¿Mejorar el tamaño de las imágenes?
    • ¿Mejorar la infraestructura del servidor?

Ejemplos:

  • Disponibilidad: Porcentaje de tiempo que el servicio estuvo disponible (uptime).
    • Ejemplo de valor de métrica: 99.9%.
  • Latencia: Tiempo medio de respuesta de una API (en milisegundos).
    • Ejemplo de valor de métrica: p95 ≤ 200ms.
  • Error/Tasa de Éxito: Porcentaje de peticiones exitosas.
    • Ejemplo de valor de métrica: HTTP 2xx / Total Peticiones.
  • Tasa de Fallos/Porcentaje de errores: (HTTP 4xx y 5xx) en relación al total de peticiones. Ejemplo: Errores ≤ 1%.
  • Throughput: Número de peticiones procesadas por segundo (RPS).
    • Ejemplo de valor de métrica: 500 RPS.
  • Capacidad: Utilización media de recursos, como CPU, memoria o base de datos.
    • Ejemplo: Uso de CPU ≤ 75%.
  • Saturación: Porcentaje de uso de colas o conexiones simultáneas.
    • Ejemplo: ≤ 90% de conexiones simultáneas.
  • Retención: Porcentaje de usuarios que retornan al servicio.
    • Ejemplo de valor de métrica: ≥ 70% de los usuarios retornan en 30 días.

SLO (Service Level Objective)​

Es la meta de rendimiento que queremos alcanzar en los indicadores SLIs. Podríamos definir que el SLO para el SLI de carga de la página principal fuese 90%, es decir, se carga 90% de las veces en menos de 2 segundos.

¡100% no existe, es utopía! Picos de tráfico existen, problemas en el hardware ocurren, ataques ocurren, etc. Seamos realistas, ni AWS garantiza 100%, qué decir nosotros.

Ejemplos de SLOs:

  • Disponibilidad: El sistema debe estar disponible al menos 99.95% del tiempo en un mes.
  • Latencia: 95% de las peticiones deben tener latencia menor o igual a 200ms.
  • Error/Tasa de Éxito: Al menos 99.9% de las peticiones deben retornar códigos 2xx.
  • Tasa de Fallos: El porcentaje de errores 5xx debe ser menor o igual a 0.5% por semana.
  • Throughput: El sistema debe procesar al menos 10.000 RPS durante picos de uso.
  • Capacidad: La utilización de CPU/memoria no debe exceder 80% durante 99% del tiempo.
  • Saturación: Las colas de mensajes no deben exceder 90% de utilización por más de 5 minutos consecutivos.
  • Retención: Al menos 75% de los usuarios deben volver a usar el servicio en un plazo de 30 días.

SLA (Service Level Agreements)​

Los SLA son acuerdos de niveles de servicio. Son contratos formales entre proveedores de servicio y sus clientes que detallan todo el servicio prometido, los estándares de rendimiento y las consecuencias si lo prometido no se cumple.

En la mayoría de las veces cuando el objetivo no se alcanza involucra pago de multa, descuento en la factura y hasta ruptura de contrato.

Es común que el SLA no sea el mismo valor del SLO para que exista un margen para trabajar y un margen de error.

Error Budget​

El Error Budget es la cantidad de fallos o indisponibilidades aceptables que un sistema puede tener en un determinado período de tiempo sin violar el SLO.

Por ejemplo:

  • SLO de disponibilidad: 99.9%.
  • Tiempo total en un mes: 30 días = 43.200 minutos.
  • Tiempo permitido de indisponibilidad (Error Budget): 43.200 x (1 - 0.999) = 43.2 minutos.

En este caso, el sistema puede estar indisponible por hasta 43.2 minutos en el mes sin romper el SLO. Es decir, es el margen que tenemos.

Este valor incentiva el equilibrio entre innovación y estabilidad. Cuando hay posibilidad, se puede priorizar la entrega de nuevas funcionalidades aunque aumente el riesgo de inestabilidad. Es una forma de ayudar a tomar decisiones basadas en datos y definir límites operacionales.

Saber definir SLIs y SLOs es importante en el papel de DevOps y puede ser un gran diferencial.

No sirve empezar con muchos SLIs y SLOs, define pocos y aquellos que son más importantes para el proyecto, los stakeholders y los clientes. A lo largo del camino, conociendo mejor la capacidad del equipo, los números deben ser cada vez más desafiantes y deben ser responsabilidad de TODOS.

El consejo es intentar iniciar con SLOs menores e ir ajustando y nunca prometer un SLA que no puedas cumplir.