Definición: Objetivo interno que define el nivel de fiabilidad deseado para un servicio, mas estricto que el SLA y utilizado como meta operativa por los equipos de ingenieria.
— Fuente: NERVICO, Consultoría de Desarrollo de Producto
Que es un SLO
Un Service Level Objective (SLO) es un objetivo interno de fiabilidad que establece el nivel de servicio que un equipo de ingenieria se compromete a mantener. A diferencia del SLA, que es un compromiso contractual externo, el SLO es una meta operativa interna tipicamente mas estricta. Si el SLA compromete un 99.9% de disponibilidad, el SLO podria fijarse en 99.95% para mantener un margen de seguridad antes de violar el contrato.
Como funciona
Los SLOs se definen a partir de los SLIs (indicadores medibles) y se expresan como un porcentaje objetivo durante un periodo de tiempo. Por ejemplo, “el 99.95% de las peticiones HTTP deben completarse en menos de 200ms durante un periodo de 30 dias”. El concepto clave es el error budget: si el SLO es 99.95%, el equipo tiene un presupuesto de errores del 0.05% que puede consumir sin consecuencias. Mientras haya error budget disponible, el equipo puede priorizar el desarrollo de funcionalidades. Cuando el error budget se agota, la prioridad pasa a la fiabilidad.
Casos de uso principales
- Establecimiento de metas operativas para equipos de ingenieria de plataforma y fiabilidad (SRE)
- Gestion del error budget para equilibrar velocidad de desarrollo con estabilidad del servicio
- Alerta proactiva cuando la tasa de consumo del error budget indica riesgo de violar el SLA
- Negociacion informada de SLAs externos basandose en datos historicos de cumplimiento de SLOs internos
Ventajas y consideraciones
Los SLOs proporcionan un marco objetivo para decidir entre velocidad de desarrollo y fiabilidad. El concepto de error budget transforma la tension entre equipos de producto y operaciones en una decision basada en datos. La principal consideracion es que los SLOs deben ser realistas y revisarse periodicamente. Un SLO demasiado ambicioso consumira recursos excesivos en fiabilidad, mientras que uno demasiado permisivo no protegera al equipo de violar el SLA.