Conceptos Clave de Site Reliability Engineering: SLI, SLO y Error Budget

Curso de Desarrollo y Despliegue en la Nube con Google Cloud Platform

Contenido del curso

Desarrollo, despliegue y monitoreo en la nube

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0011:24

Conceptos Clave de Site Reliability Engineering: SLI, SLO y Error Budget

Curso de Desarrollo y Despliegue en la Nube con Google Cloud Platform

Clase 3 de 8

Clase 3 / 8

Recursos

Definir correctamente los objetivos de fiabilidad de tus sistemas es lo que separa a las organizaciones que innovan con confianza de las que se paralizan por miedo a fallar. En el marco de Site Reliability Engineering, existen conceptos fundamentales que permiten alinear a los equipos de desarrollo, operaciones y negocio bajo un mismo lenguaje y una misma meta. Aquí se explican los más relevantes: los indicadores y objetivos de nivel de servicio, y el porcentaje de error aceptable.

¿Por qué 100 % de fiabilidad es el objetivo incorrecto?

Puede sonar contradictorio, pero aspirar al 100 % de reliability es probablemente un error para cualquier aplicación [0:44]. Un sistema que nunca puede fallar es un sistema que nunca puede cambiar, nunca puede mejorar y nunca puede experimentar. Salvo excepciones extremas como un marcapasos, prácticamente ningún producto digital necesita ese nivel de exigencia.

Esto significa que necesitas establecer un margen realista que te permita innovar sin comprometer la experiencia de tus usuarios. Para lograrlo, SRE propone tres conceptos clave que funcionan de forma encadenada.

¿Qué es un SLI o service level indicator?

Un SLI es una métrica bien definida de un atributo de tu servicio [2:05]. Puede ser:

La disponibilidad del sistema.
La latencia de las respuestas.
El throughput o capacidad de procesamiento.
El freshness o frescura de los datos.

Estos indicadores son la base sobre la que se construyen los objetivos.

¿Qué diferencia hay entre SLO y SLA?

Un SLO (service level objective) es un objetivo trazado sobre un SLI [2:30]. Si tu indicador es la disponibilidad, podrías definir un SLO del 99.9 % o del 99 %. Es el nivel al cual apuntas y, lo más importante, si se cumple, tus clientes estarán satisfechos.

Por otro lado, el SLA (service level agreement) es un acuerdo contractual y legal entre organizaciones [3:05]. Incluye penalidades y consecuencias de negocio, por lo que su definición corresponde a los equipos comerciales y legales, no a los equipos técnicos.

¿Cómo funciona el error budget o porcentaje de error aceptable?

El error budget es la diferencia entre el 100 % y el SLO que has establecido [5:00]. Si tu objetivo es 99 % de disponibilidad, tu porcentaje de error aceptable es del 1 %. Ese margen de maniobra es el espacio que tienen todos los equipos —desarrollo, operaciones y producto— para realizar cambios, mantenimientos, experimentos y lanzar nuevas versiones.

Este concepto trae beneficios concretos a tu organización:

Incentivos comunes: el error budget es único para todos, lo que alinea a quienes escriben código y a quienes mantienen sistemas en producción [7:18].
Autogestión del riesgo: cada equipo es consciente del margen máximo de indisponibilidad permitido [7:35].
Motivación realista: un objetivo de 100 % es desmotivador porque para que algo nunca falle, la mejor estrategia sería que nunca cambie [8:00].
Responsabilidad compartida: el uptime deja de ser exclusivo de operaciones y se convierte en un compromiso de toda la organización [8:30].

¿Qué hacer cuando el error budget está disponible o se agota?

La clave no es solo definir un error budget, sino establecer consecuencias claras según su estado [9:05].

Cuando tienes margen de maniobra amplio, puedes priorizar la velocidad:

Lanzar nuevas versiones y funcionalidades.
Gestionar fallos inevitables de hardware.
Realizar experimentos arriesgados.

Cuando el error budget se agota, debes priorizar la estabilidad:

Ralentizar o detener lanzamientos de nuevas funciones.
Priorizar las tareas derivadas de los post mortem.
Automatizar los procesos de implementación para reducir errores humanos no intencionales e incrementar velocidad sin sacrificar estabilidad [10:20].

¿Por qué SRE necesita SLOs con consecuencias?

Establecer un SLO sin definir qué ocurre cuando se consume el error budget es como tener un semáforo sin que nadie respete los colores. SRE necesita SLOs con consecuencias [10:50], es decir, procedimientos organizacionales claros que indiquen cuándo es momento de acelerar y cuándo es momento de proteger la estabilidad.

Cuando toda tu organización comparte este lenguaje y actúa en consecuencia, logras un equilibrio saludable entre innovación y confiabilidad. ¿Ya tienes definidos los SLOs de tus servicios? Comparte tu experiencia y cómo ha cambiado la dinámica entre tus equipos.

Tan Zuñiga

Hace 5 años

Service Level Terminology

SLI

Service Level Indicator Un SLI es un indicador de nivel de servicio, una medida cuantitativa cuidadosamente definida de algún aspecto del nivel de servicio que se proporciona.

La mayoría de los servicios consideran la latencia de la solicitud(request latency) (cuánto tiempo se tarda en devolver una respuesta a una solicitud) como un SLI clave.
Otros SLI comunes incluyen la tasa de error(error rate), a menudo expresada como una fracción de todas las solicitudes recibidas.
Por ultimo el rendimiento del sistema(system throughput), tambien es un SLI común, generalmente medido en solicitudes por segundo.
Otro tipo de SLI importante para las SRE es la disponibilidad(availability), o la fracción del tiempo que se puede utilizar un servicio.

SLO

Service Level Objective Un Objetivo de nivel de servicio es un valor objetivo o rango de valores para un nivel de servicio medido por un SLI. El objectivo al que apuntamos es al SLO, mientras que la metrica o indicador es SLI.

La elección y publicación de SLO para los usuarios establece expectativas sobre el rendimiento de un servicio. Esta estrategia puede reducir las quejas infundadas a los propietarios del servicio sobre, por ejemplo, la lentitud del servicio.
Sin un SLO explícito, los usuarios a menudo desarrollan sus propias creencias sobre el desempeño deseado, que pueden no estar relacionadas con las creencias de las personas que diseñan y operan el servicio.

SLA

Service level agreements Un Acuerdo a nivel de servicio es un contrato explícito o implícito con sus usuarios que incluye las consecuencias de cumplir (o no cumplir) los SLO que contienen.

Las consecuencias se reconocen más fácilmente cuando son financieras (un reembolso o una multa), pero pueden adoptar otras formas.

Una manera fácil de distinguir entre un SLO y un SLA es preguntarse "¿qué sucede si no se cumplen los SLO?": Si no hay una consecuencia explícita, es casi seguro que esté mirando un SLO.

Por lo general, los y las SRE no se involucra en la construcción de SLA, porque los SLA están estrechamente vinculados a las decisiones comerciales y de productos.

Sin embargo, SRE se involucra para ayudar a evitar desencadenar las consecuencias de los SLO omitidos. También pueden ayudar a definir los SLI: obviamente, debe haber una forma objetiva de medir los SLO en el acuerdo, o surgirán desacuerdos.

Error Budget

El Porcentaje de error aceptable es la diferencia entre el 100% y nuestro objetivo (SLO) que tenemos como oportunidad para hacer cambios/mejoras/mantenimiento.

El Porcentaje de error aceptable nos permite

Aumentar la velocidad de desarrollo.
Incrementar mejoras.
Inovar en nuestros productos.

Beneficios del porcentaje de error aceptable

Incentivos comunes para desarrolladores y SREs: Encuentra el balance adecuado entre innovación y reliability.
Los equipos de desarrollo pueden gestionar el riesgo por su cuenta: Ellos deciden cómo utilizar el porcentaje de error aceptable.
Los objetivos de reliability poco realistas no son atractivos: Estos objetivos disminuyen la velocidad de la innovación.
Responsabilidad compartida por uptime del sistema: Los fallos de la infraestructura utilizan el porcentaje de error aceptable de los desarrolladores.

Consecuencias del porcentaje de error aceptable

✅ Cuando hay porcentaje de error aceptable: Priorizar la velocidad ● Lanzamiento de nuevas funciones. ● Cambios previstos en el sistema. ● Fallos inevitables en el hardware, las redes, etc. ● Experimentos arriesgados.

❌ Cuando se agota el porcentaje de error aceptable: Priorizar la estabilidad ● Ralentizar o detener los lanzamientos de nuevas funciones. ● Priorizar items del postmortem. ● Automatizar los procesos de implementación.

Víctor Macías Pincay

Hace 5 años

Muchas gracias por el aporte.

Desarrollo, despliegue y monitoreo en la nube

DevOps: Velocidad y Estabilidad en Entrega de Software

Mejores Prácticas de Site Reliability Engineering (SRE)

Conceptos Clave de Site Reliability Engineering: SLI, SLO y Error Budget

Construcción de Imágenes de Contenedores en Google Cloud

Despliegue Continuo en Google Cloud: Integración y Automatización

Gestión Segura de Credenciales con Secret Manager en GCP

Implementación de Infraestructura como Código con Deployment Manager

Despliegue Continuo e Infraestructura como Código en GCP

Conceptos Clave de Site Reliability Engineering: SLI, SLO y Error Budget

Progreso del curso

Desarrollo, despliegue y monitoreo en la nube

Recursos

Recursos