SLOs y SLIs: midiendo la calidad de software

Medir bien cambia cómo construyes software: con Site Reliability Engineering (SRE) y sus SLOs y SLIs sabrás si tu producto está sano, si tu latencia es baja y si los errores están bajo control. Esta mirada, adoptada en Auth0 y documentada por Google en un libro open source, permite decidir con seguridad cada deployment y proteger a los clientes.

¿Qué es SRE y por qué medir con SLOs y SLIs?

La práctica de SRE no es nueva: es cómo las empresas evalúan si su producto “está bien”. El valor del libro de Google es que formaliza conceptos aplicables. No todo lo de Google se replica igual, pero sí sus bases.

¿Qué miden los SLIs: latencia, errores y tiempos en API?

Los Service Level Indicators (SLIs) son “qué mides”. Ejemplos directos: - Latencia de respuesta. - Cantidad de errores. - Tiempo de enviar un email. - Tiempo de respuesta en un path específico del API.

¿Cómo se fija un SLO: percentiles y ventanas de tiempo?

El Service Level Objective (SLO) es la meta cuantitativa. Un ejemplo claro: “percentil 99 del response time menor a 50 ms durante el mes, medido en ventanas de 5 minutos”. Así defines el estándar de calidad que quieres sostener de forma continua.

¿Cómo operar con monitoreo continuo en producción?

Medir siempre cambia el juego. Si observas un “blip” o pico donde el p99 supera los 50 ms, puedes relacionarlo con el último deployment y decidir un rollback. Así evitas regresiones y sostienes alta calidad enviando software a producción.

¿Por qué probar en producción con datos reales?

Un ambiente de pruebas no refleja siempre la data real. Monitorear en producción te da señales verdaderas del comportamiento de usuarios y sistema. Si estás bajo tu meta, puedes seguir lanzando con confianza.

• Validación con tráfico real, no simulado.
• Detección rápida de regresiones.
• Decisiones de rollback basadas en datos.

¿Qué hacer cuando rompes la métrica y consumes el error budget?

Define y gestiona error budgets: un margen de “incumplimientos” permitidos. Si lo consumes a mitad de mes por varios deployments que elevaron la latencia, puedes pausar lanzamientos. Depende también de lo que prometes a clientes: si ofreces menos de 75 ms y tu estándar interno es 50 ms, al exceder ambos no deberías lanzar porque arriesgas tus garantías.

• Pausar deployments del servicio afectado.
• Analizar cambios que introdujeron la regresión.
• Reanudar cuando vuelvas a cumplir el SLO.

¿Qué mentalidad y habilidades refuerza SRE con SLOs y SLIs?

Este enfoque impulsa una mentalidad más agresiva para proteger a los clientes y pragmática sobre qué cambios van a producción y cuándo. Mantén un monitoreo constante de todo lo que sale a producción para cumplir tus métricas: las de clientes, las internas y las del equipo.

¿Qué competencias prácticas se ponen en juego?

• Definición de métricas claras: SLIs y SLOs.
• Uso de percentiles (p99) y ventanas temporales.
• Monitoreo continuo y correlación con deployments.
• Gestión de regresiones con rollback oportuno.
• Administración de error budgets y pausas de lanzamiento.
• Alineación con acuerdos de servicio prometidos a clientes.

Si no vas a leer el libro completo, prioriza el capítulo de SLOs y SLIs: es gratuito (open source) y transforma la forma de lanzar software con seguridad. ¿Te gustaría compartir cómo defines tus SLOs o cómo gestionas tu error budget?