Define SLO

Este documento es la primera de dos partes en las que se muestra cómo los equipos que operan servicios en línea pueden comenzar a compilar y adoptar una cultura de ingeniería de confiabilidad de sitios (SRE) mediante objetivos de nivel de servicio (SLO). Un SLO es un nivel objetivo de confiabilidad para un servicio.

En los modelos de software como servicio (SaaS), existe una tensión natural entre la velocidad del desarrollo del producto y la estabilidad operativa. Cuanto más cambies el sistema, más probable será que se interrumpa. Las herramientas de supervisión y observabilidad pueden ayudarte a mantener la confianza en la estabilidad operativa a medida que aumentas la velocidad de desarrollo. Sin embargo, aunque estas herramientas, conocidas también como herramientas de administración del rendimiento de las aplicaciones (APM), son importantes, una de las aplicaciones más importantes de estas herramientas es configurar los SLO.

Si se define de forma correcta, un SLO puede ayudar a los equipos a tomar decisiones operativas basadas en los datos que aumenten la velocidad de desarrollo sin sacrificar la estabilidad. El SLO también puede hacer que los equipos de desarrollo y operaciones compartan un único objeto acordado, lo que puede aliviar la tensión natural que existe entre sus objetivos: crear e iterar productos (desarrollo) y mantener la integridad del sistema (operaciones).

Los SLO se describen en detalle en El libro de SRE y en El libro de actividades de SRE, junto con otras prácticas de SRE. En esta serie, se busca simplificar el proceso de comprensión y desarrollo de los SLO para que puedas adoptarlos con mayor facilidad. Después de leer y comprender estos artículos, podrás encontrar más información en los libros.

En esta serie, verás un procedimiento claro para implementar los SLO en tu organización:

  • En este documento, se revisa qué son los SLO y se explica cómo definirlos para los servicios.
  • En Adopción de SLO, se describen los diferentes tipos de SLO en función de los tipos de cargas de trabajo, cómo medir esos SLO y cómo desarrollar alertas basadas en ellos.

Esta serie está dirigida a profesionales de SRE, equipos de operaciones y DevOps, administradores de sistemas y otros profesionales responsables de la estabilidad y confiabilidad de un servicio en línea. Se supone que comprendes cómo los servicios de Internet se comunican con los navegadores web y los dispositivos móviles, y que tienes conocimientos básicos sobre cómo se implementan y supervisan los servicios web y cómo se solucionan sus problemas.

Los informes Estado de DevOps identificaron las capacidades que impulsan el rendimiento de la entrega de software. Esta serie te ayudará con las siguientes funciones:

Terminología

En los documentos de esta serie, se usan los siguientes términos y definiciones:

  • Nivel de servicio: Es una medición del rendimiento de un servicio determinado en las tareas previstas para el usuario. Puedes describir esta medición en términos de satisfacción del usuario y medirla según varios métodos, en función de lo que el servicio hace y lo que el usuario espera que haga o se le indique que puede hacer.

    Ejemplo: “Un usuario espera que nuestro servicio esté disponible y sea rápido”.

  • Recorrido crítico del usuario (CUJ): Es un conjunto de interacciones que un usuario tiene con un servicio para lograr un único objetivo, como un solo clic o una canalización de varios pasos.

    Ejemplo: “Un usuario hace clic en el botón de confirmación de compra y espera recibir la respuesta de que se procesó el carrito y que se muestre un recibo”.

  • Indicador de nivel de servicio (SLI): Es un indicador de satisfacción de los usuarios que se puede medir de forma cuantitativa para el nivel de servicio. En otras palabras, para medir un nivel de servicio, debes medir un indicador que represente la satisfacción del usuario con ese nivel de servicio, por ejemplo, la disponibilidad de un servicio. Un SLI puede considerarse como una línea en un gráfico que cambia con el tiempo, a medida que el servicio mejora o se degrada.

    Ejemplo: “Mide la cantidad de solicitudes correctas en los últimos 10 minutos dividida por la cantidad de solicitudes válidas en los últimos 10 minutos”.

  • Objetivo de nivel de servicio (SLO): Es el nivel que esperas que un servicio alcance la mayor parte del tiempo y con el que se mide un SLI.

    Ejemplo: “Las respuestas de los servicios deben ser más rápidas que 400 milisegundos (ms) para el 95% de todas las solicitudes válidas medidas durante 14 días”.

    Gráfico que muestra la relación entre los SLO y los SLI

  • Acuerdo de Nivel de Servicio (ANS): Es una descripción de lo que debe suceder si no se cumple un SLO. Por lo general, un ANS es un acuerdo legal entre proveedores y clientes y hasta puede contener condiciones de compensación. En discusiones técnicas sobre SRE, este término se suele evitar.

    Ejemplo: “Si el servicio no proporciona una disponibilidad del 99.95% durante un mes calendario, el proveedor de servicios compensará al cliente por cada minuto de incumplimiento”.

  • Porcentaje de error aceptable: Es la cantidad de tiempo o de eventos negativos que puedes tolerar antes de infringir el SLO. Esta medición te indica cuántos errores puede esperar o tolerar tu empresa. El porcentaje de error aceptable es fundamental para tomar decisiones que pueden ser riesgosas.

    Ejemplo: “Si nuestro SLO está disponible en un 99.9%, permitimos que el 0.1% de nuestras solicitudes entreguen errores, ya sea a través de incidentes, accidentes o experimentación”.

¿Por qué elegir los SLO?

Cuando compilas una cultura de SRE, ¿por qué debes comenzar con los SLO? En resumen, si no defines un nivel de servicio, es difícil medir si tus clientes están satisfechos con el servicio. Incluso si sabes que puedes mejorar el servicio, la falta de un nivel de servicio definido hace que sea difícil determinar dónde y cuánto invertir en las mejoras.

Puede ser tentador desarrollar SLO independientes para cada servicio, ya sea que estén orientados al usuario o no. Por ejemplo, un error común es medir dos o más servicios por separado, por ejemplo, un servicio de frontend y un almacén de datos de backend, cuando el usuario depende de ambos y no conoce la diferencia. Un mejor enfoque es desarrollar SLO basados en el producto (el conjunto de servicios) y enfocarte en las interacciones más importantes que tienen tus usuarios con él.

Por lo tanto, para desarrollar un SLO efectivo, lo mejor es que comprendas las interacciones de los usuarios con el servicio, que se denominan recorridos críticos del usuario (CUJ). Un CUJ considera los objetivos de tus usuarios y cómo usan tus servicios para alcanzarlos. El CUJ se define desde la perspectiva del cliente sin tener en cuenta los límites del servicio. Si se cumple el CUJ, el cliente estará satisfecho, y los clientes satisfechos son una medida clave del éxito de un servicio.

Un aspecto clave para la satisfacción del cliente con respecto a un servicio es la confiabilidad del servicio. No importa qué hace un servicio si no es confiable. Por lo tanto, la confiabilidad es la característica más importante de cualquier servicio. Una métrica común para la confiabilidad es el tiempo de actividad, que significa, por lo general, la cantidad de tiempo en que un sistema está activo. Sin embargo, preferimos usar una métrica más útil y precisa: la disponibilidad. La disponibilidad también responde a la pregunta sobre si un sistema está activo, pero de una manera más precisa que con la medición del tiempo desde que el sistema estuvo inactivo. En los sistemas distribuidos actuales, los servicios pueden estar inactivos de forma parcial, un factor en el que el tiempo de actividad no evalúa bien.

Por lo general, la disponibilidad se describe con número formados por nueve, como el 99.9% disponible (tres nueves) o el 99.99% (cuatro nueves). Medir un SLO de disponibilidad es una de las mejores formas de medir la confiabilidad del sistema.

Además de ayudar a definir el éxito operativo, un SLO puede ayudarte a elegir dónde invertir los recursos. Por ejemplo, los libros de SRE a menudo indican que cada nueve que agregas al diseño puede generar un costo incremental con utilidad marginal. Por lo general, se reconoce que alcanzar el siguiente valor de nueve en disponibilidad cuenta diez veces más que el anterior.

Elige un SLI

Para determinar si se cumple un SLO (es decir, si la condición es correcta), necesitas una medida. Esa medición se denomina indicador de nivel de servicio (SLI). Un SLI mide el nivel de un servicio en particular que entregas a los clientes. Lo ideal sería que el SLI esté vinculado a un CUJ aceptado.

Selecciona las mejores métricas

El primer paso para desarrollar un SLI es elegir la métrica que se medirá, como las solicitudes por segundo, los errores por segundo, la longitud de la cola, la distribución de los códigos de respuesta durante un período determinado o la cantidad de bytes transmitidos.

Estas métricas suelen ser de los siguientes tipos:

  • Contador. Por ejemplo, la cantidad de errores que se generaron hasta un punto de medición determinado. Este tipo de métrica puede aumentar, pero no disminuir.
  • Distribución. Por ejemplo, la cantidad de eventos que propagan un segmento de medición en particular para un período determinado. Puedes medir cuántas solicitudes tardan de 0 a 10 ms en completarse, cuántas tardan de 11 a 30 ms y cuántas de 31 a 100 ms. El resultado es un recuento de cada depósito, por ejemplo, [0-10: 50], [11-30: 220] y [31-100: 1103].
  • Indicador. Por ejemplo, el valor real de una parte medible del sistema (como la longitud de la cola). Este tipo de métrica puede aumentar o disminuir.

Para obtener más información sobre estos tipos, consulta la documentación del proyecto de Prometheus y los tipos de métricas de Cloud Monitoring ValueType y MetricKind.

Una distinción importante sobre los SLI es que no todas las métricas son SLI. De hecho, el libro de trabajo de SRE indica lo siguiente (se agrega énfasis):

“(…) por lo general, recomendamos considerar al SLI como la proporción entre dos números: la cantidad de eventos correctos dividida por la cantidad total de eventos (…)”.

“El SLI oscila entre el 0% y el 100%. El 0% significa que no funciona nada y el 100% significa que no hay errores. Descubrimos que esta escala es intuitiva y que este estilo se presta fácilmente al concepto de porcentaje de error aceptable”.

Muchas empresas de software realizan un seguimiento de cientos o miles de métricas, y solo unas pocas califican como SLI. Aparte de ser una proporción entre los eventos correctos y el total de eventos, ¿qué hace que una métrica califique como un SLI adecuado? Una métrica de SLI adecuada tiene las siguientes características:

  • La métrica se relaciona directamente con la satisfacción del usuario. Por lo general, los usuarios no están satisfechos si un servicio no se comporta como se espera, falla o es lento. Cualquier SLO basado en estas métricas se puede validar mediante la comparación del SLI con otros indicadores de la satisfacción del usuario. Por ejemplo, la cantidad de tickets de reclamos de los clientes, el volumen de llamadas de asistencia, la opinión en las redes sociales o los escalamientos. Si tu métrica no corresponde a estas otras métricas de satisfacción del usuario, es posible que no sea una métrica adecuada para usar como SLI.
  • El deterioro de la métrica se correlaciona con las interrupciones. Una métrica que se ve bien durante una interrupción es una métrica incorrecta para un SLI. Una métrica que no se ve bien durante el funcionamiento normal también es una métrica incorrecta para un SLI.
  • La métrica brinda una buena proporción de la relación señal/ruido. Cualquier métrica que genere una gran cantidad de falsos negativos o falsos positivos no es un SLI adecuado.
  • La métrica escala de forma monótona y lineal con la satisfacción del cliente. A medida que la métrica mejora, la satisfacción del cliente también lo hace.

Considera los gráficos del siguiente diagrama. Se representan las dos métricas que se pueden usar como SLI para un servicio y se muestra su variación con el paso del tiempo. El período en el que un servicio se degrada está resaltado en rojo, y el período en el que un servicio funciona bien está resaltado en azul.

imagen

En el caso del SLI incorrecto, la falta de satisfacción del usuario no corresponde directamente con un evento negativo (como la degradación, la lentitud o una interrupción del servicio). Además, el SLI fluctúa de forma independiente de la satisfacción del usuario. Con el SLI adecuado, se correlaciona el SLI y la satisfacción del usuario, los diferentes niveles de satisfacción son claros y hay muchas menos fluctuaciones irrelevantes.

Selecciona la cantidad correcta de métricas

Por lo general, un solo servicio tiene varios SLI, en especial si el servicio realiza diferentes tipos de trabajo o entrega a diferentes tipos de usuarios. Por ejemplo, separar las solicitudes de lectura de las solicitudes de escritura es una buena idea, ya que estas solicitudes actúan de diferentes maneras. En este caso, es mejor seleccionar las métricas adecuadas para cada servicio.

Por el contrario, muchos servicios realizan tipos de trabajos similares, que se pueden comparar directamente. Por ejemplo, si tienes un mercado en línea, los usuarios pueden ver una página principal, una subcategoría, una lista de los 10 elementos más destacados y una página de detalles, o buscar elementos. En lugar de desarrollar y medir un SLI diferente para cada una de estas acciones, puedes combinarlos en una sola categoría de SLI, por ejemplo, servicios de navegación.

En realidad, las expectativas de un usuario no cambian mucho entre las acciones de una categoría similar. Su satisfacción no depende de la estructura de los datos que exploran, ya sea que los datos deriven de una lista estática de elementos promocionados o del resultado generado de forma dinámica de una búsqueda asistida por aprendizaje automático en un conjunto de datos masivo. Su satisfacción se puede cuantificar mediante una respuesta a esta pregunta: “¿Visualicé una página completa de elementos rápidamente?”.

Lo ideal es que uses la menor cantidad de SLI posible para representar con precisión las tolerancias de un servicio determinado. Por lo general, un servicio debe tener entre dos y seis SLI. Si tienes muy pocos SLI, puedes perder indicadores valiosos. Si tienes demasiados SLI, tu equipo de guardia tiene demasiada información para hacer un seguimiento solo con la utilidad marginal agregada. Recuerda que los SLI deben simplificar la comprensión del estado de la producción y proporcionar una sensación de cobertura.

Elige un SLO

Un SLO se compone de los siguientes valores:

  • Un SLI. Por ejemplo, la proporción entre la cantidad de respuestas con el código HTTP 200 y la cantidad total de respuestas.
  • Una duración. Es el período en el que se mide una métrica. Este período puede basarse en un calendario (por ejemplo, desde el primer día de un mes hasta el primer día del siguiente) o en un período progresivo (por ejemplo, los últimos 30 días).
  • Un objetivo. Por ejemplo, un porcentaje objetivo de eventos correctos sobre el total de eventos (como el 99.9%) que esperas cumplir durante un período determinado.

A medida que desarrollas un SLO, definir la duración y el objetivo puede ser difícil. Una forma de comenzar el proceso es identificar los SLI y representarlos en el tiempo. Si no puedes decidir qué duración y objetivo usar, recuerda que tu SLO no tiene que ser perfecto de inmediato. Es probable que iteres en el SLO para asegurarte de que se alinee con la satisfacción del cliente y cumpla tus necesidades empresariales. Puedes comenzar con dos nueves (99.0%) durante un mes.

A medida que realizas un seguimiento del cumplimiento del SLO durante eventos como implementaciones, interrupciones y patrones de tráfico diarios, puedes obtener estadísticas sobre qué objetivo es adecuado, erróneo o incluso tolerable. Por ejemplo, en un proceso en segundo plano, puedes definir un éxito del 75% como adecuado. Sin embargo, en el caso de las solicitudes esenciales orientadas al usuario, podrías establecer algo más agresivo, como el 99.95%.

Por supuesto, no hay un único SLO que puedes aplicar para cada caso de uso. Los SLO dependen de varios factores:

  • Las expectativas del cliente
  • El tipo de carga de trabajo
  • La infraestructura para la entrega, la ejecución y la supervisión
  • El dominio del problema

En la parte 2 de esta serie, Adopta SLO, se detallan los SLO independientes del dominio. Los SLO independientes del dominio (como la disponibilidad del servicio) no reemplazan a los indicadores de alto nivel (como los widgets vendidos por minuto). Sin embargo, pueden ayudar a medir si un servicio funciona sin importar el caso de uso empresarial.

Los indicadores independientes del dominio a menudo se pueden reducir a una pregunta. Por ejemplo: “¿El servicio está disponible?” o “¿El servicio tiene la rapidez necesaria?”. La respuesta suele encontrarse en un SLO que tiene en cuenta dos factores: la disponibilidad y la latencia. Puedes describir un SLO de la siguiente manera, en la que X = 99.9% y Y = 800 ms:

El X% de las solicitudes válidas son exitosas y se ejecutan más rápido que Y ms.

Próximos pasos