Midiendo la fiabilidad - Introducción a SLIs y SLOs
El Problema del “Está Caído”
Como ingenieros, a menudo nos enfrentamos a la difícil tarea de responder a la pregunta: ¿está el servicio funcionando correctamente? La respuesta no siempre es un simple “sí” o “no”. Un servicio puede estar lento, dar errores intermitentemente o funcionar para unos usuarios pero no para otros.
Los Site Reliability Engineers (SREs) abordan este problema de una forma cuantitativa y centrada en el usuario. En lugar de basarse en percepciones subjetivas, utilizan métricas concretas para definir y medir la fiabilidad. Aquí es donde entran en juego los SLIs y SLOs.
SLI: El Indicador del Nivel de Servicio
Un SLI (Service Level Indicator) es una medida cuantitativa de algún aspecto del nivel de servicio que se proporciona. Es, simplemente, una métrica. Pero no una métrica cualquiera, sino una que refleja la experiencia del usuario.
Algunos ejemplos comunes de SLIs son:
- Disponibilidad: El porcentaje de peticiones que se completan con éxito. Por ejemplo,
(peticiones_exitosas / peticiones_totales) * 100. - Latencia: El porcentaje de peticiones que son lo suficientemente rápidas. Por ejemplo,
(peticiones_rapidas / peticiones_totales) * 100, donde “rápida” podría ser “por debajo de 300ms”. - Calidad: El porcentaje de datos que se procesan sin errores.
La clave de un buen SLI es que sea una métrica representativa de la felicidad del usuario. Monitorizar el uso de CPU del servidor no es un buen SLI, porque un uso del 100% no importa si el usuario recibe respuestas rápidas y sin errores.
SLO: El Objetivo del Nivel de Servicio
Un SLO (Service Level Objective) es el objetivo que nos marcamos para un SLI durante un período de tiempo. Es la promesa que hacemos a nuestros usuarios.
Un SLO se compone de tres partes:
- El SLI: La métrica que vamos a medir.
- El Objetivo: El porcentaje deseado (ej. 99.9%).
- El Período: El intervalo de tiempo sobre el que se mide (ej. “los últimos 30 días”).
Ejemplo de un SLO:
El 99.9% de las peticiones a la home de nuestro blog (
SLI: disponibilidad) deben completarse con éxito (Objetivo: 99.9%) durante los últimos 30 días (Período).
Este SLO es claro, medible y está directamente relacionado con la experiencia del usuario. Si no lo cumplimos, sabemos que tenemos un problema.
¿Y el 100%? El Concepto de “Error Budget”
¿Por qué no apuntar al 100% de disponibilidad? Porque la fiabilidad total es imposible y, además, muy cara. Perseguir el 100% nos impediría lanzar nuevas funcionalidades o hacer cambios por miedo a romper algo.
El Error Budget (Presupuesto de Error) es el complemento a nuestro SLO. Si nuestro SLO de disponibilidad es del 99.9%, nuestro Error Budget es del 0.1%.
Error Budget = 100% - SLO
Este 0.1% es el nivel de “infelicidad” aceptable que nos permitimos. Es el tiempo que el servicio puede fallar sin que incumplamos nuestra promesa. Este presupuesto nos da permiso para innovar, desplegar nuevo código, hacer mantenimientos… y asumir riesgos calculados.
Conclusión
Los SLIs y SLOs transforman la conversación sobre la fiabilidad de un debate subjetivo a una discusión basada en datos. Nos permiten alinear al equipo de desarrollo y operaciones en un objetivo común y tomar decisiones informadas sobre cuándo es el momento de centrarse en la fiabilidad y cuándo podemos permitirnos innovar.