En esta sección se repasa el concepto de indicadores de nivel de servicio (SLIs), se define qué hace que un SLI sea bueno o útil y se proporcionan ejemplos de implementaciones de SLIs para determinados servicios. Esta página está dirigida a usuarios que quieren ver ejemplos de implementación de SLIs específicos de un servicio.
Introducción a los SLIs
La fiabilidad de un servicio es un concepto abstracto. Lo que significa fiabilidad depende del servicio y de las necesidades de sus usuarios. Un indicador de nivel de servicio (SLI) es una medida de esa fiabilidad que se usa tanto para comunicar la fiabilidad del servicio como para gestionarlo.
Los SLIs se miden durante un periodo. El tamaño de la ventana suele depender de la decisión que se tome con la información. Por ejemplo, puedes medir un único SLI de las siguientes formas:
- En la última hora, para crear políticas de alertas.
- Durante semanas, para tomar decisiones tácticas.
- Durante meses, para tomar decisiones estratégicas.
Te recomendamos que uses un periodo de 28 días como punto de partida para medir tu SLI. Este valor ofrece un buen equilibrio entre los casos de uso estratégicos y tácticos.
Para obtener más información, consulta las siguientes secciones del libro de ejercicios de ingeniería de fiabilidad de sitios:
Propiedades de un buen indicador de nivel de servicio
Consideramos que los SLIs son "buenos" cuando cumplen los siguientes criterios:
Los SLIs son buenas medidas indirectas de la satisfacción de los usuarios.
Un buen SLI está estrechamente relacionado con la satisfacción de los usuarios. El SLI se usa como base para un objetivo de nivel de servicio (SLO), que es un umbral definido en el SLI. Defines el SLO de forma que, cuando el SLI se encuentre dentro de un intervalo definido, la mayoría de tus usuarios estén satisfechos. Para que esta relación se mantenga, el SLI debe ser una buena medida indirecta de la satisfacción de los usuarios.
Si el SLI es un buen indicador de la satisfacción de los usuarios, cuando se produce un evento que afecta a la satisfacción de los usuarios, el SLI cambia en alguna dirección. Del mismo modo, si no hay eventos que afecten a la satisfacción de los usuarios, el SLI no cambia.
Los SLIs aumentan de forma monótona y lineal con la satisfacción de los usuarios.
Un buen SLI se escala de forma monótona y lineal con la satisfacción de los usuarios. Si el SLI mejora, la satisfacción de los usuarios también lo hace. Del mismo modo, si el SLI disminuye, la satisfacción de los usuarios también lo hará. El grado de mejora del valor de un buen SLI se corresponde con el grado de mejora de la satisfacción de los usuarios.
Los indicadores de nivel de servicio producen mediciones que van del 0% al 100%.
Un buen SLI produce una medición del rendimiento que va del 0% al 100 %, un intervalo intuitivo y fácil de usar. Por ejemplo, un rendimiento de SLI del 100% significa que todo funciona correctamente, mientras que un rendimiento del 0% significa que nada funciona.
Si un indicador de nivel de servicio tiene un intervalo del 0% al 100 %, es fácil y claro definir un objetivo de nivel de servicio para ese indicador: asigna un porcentaje objetivo, como el 99,9%, y el rendimiento del indicador de nivel de servicio debe ser igual o superior a ese objetivo para que el servicio cumpla su objetivo de nivel de servicio.
Promesas
Una forma de implementar un indicador de nivel de servicio que tenga estas propiedades es pensar en él en términos de promesas hechas a los usuarios. Si cuentas las promesas que has hecho y cumplido en un periodo determinado, puedes obtener un número que va del 0% al 100%. Estos indicadores de nivel de servicio también se traducen bien en presupuestos de errores: para un objetivo de nivel de servicio determinado, el presupuesto de errores es el número de promesas que puedes incumplir durante un periodo determinado sin dejar de cumplir el objetivo de nivel de servicio.
Por ejemplo:
- Para devolver una respuesta con un código de estado HTTP
200a la solicitud de un cliente. - Para responder a una solicitud de gRPC en menos de 100 ms.
- Para completar correctamente el flujo de trabajo "Crear máquina virtual".
- Para publicar datos que se hayan actualizado en los últimos 10 minutos.
- Para iniciar la tarea de lote programada en el plazo de un minuto a partir de la hora de inicio.
Especificaciones e implementaciones de SLI
Una especificación de un SLI es lo que quieres medir. La especificación no incluye los detalles técnicos exactos de cómo vas a medirlo. Por ejemplo, a continuación se muestra una especificación de un SLI para el tiempo de carga de la página:
- Porcentaje de solicitudes de página principal que se cargan en menos de 100 ms.
Hay muchas formas de medir un SLI, cada una con sus ventajas e inconvenientes. Las formas de medir el SLI son las implementaciones del SLI. Por ejemplo, puede implementar la especificación de carga de páginas de una de las siguientes formas:
- El campo de latencia del registro de solicitudes del servidor de aplicaciones.
- Métricas exportadas por el servidor de aplicaciones.
- Métricas exportadas por un balanceador de carga situado delante de los servidores de aplicaciones.
- Un servicio de monitorización de caja negra que envía solicitudes artificiales al sistema y mide el tiempo que tarda en recibir respuestas válidas.
- Código específico de la aplicación que se ejecuta en el navegador del cliente, registra información sobre los tiempos y la envía a un servicio de recogida.
Cada una de estas opciones implica un equilibrio entre las siguientes características:
- Fidelidad: cómo captura la experiencia de usuario.
- Cobertura: qué proporción de las interacciones de los usuarios se mide.
- Coste: la cantidad de dinero y tiempo de ingeniería necesarios para crear y mantener la solución.
La fidelidad a la experiencia de usuario suele mejorar cuando el SLI se mide más cerca del usuario. Por ejemplo, la implementación que usa código en el navegador del usuario da como resultado una medición de la latencia más precisa que la latencia percibida por el usuario o por otras opciones de medición.
La desventaja es que la medición basada en el navegador también incluye cualquier latencia introducida por la conexión del usuario a su servicio. Por ejemplo, cuando se usa un servicio a través de Internet público, esta latencia puede variar significativamente en función de la ubicación geográfica o de las condiciones de la red.
Por lo tanto, la señal basada en el navegador es una buena aproximación de la satisfacción de los usuarios. Sin embargo, es posible que esta señal no proporcione información útil que puedas usar para mejorar la fiabilidad de tu servicio.
Para obtener información sobre cómo combinar varias mediciones para equilibrar esta compensación, consulta esta publicación de The Telegraph.
Agrupación
Es posible que necesites varios SLIs para un servicio cuando este realice diferentes tipos de trabajo para distintos usuarios o cuando lleve a cabo una tarea concreta con diferentes resultados posibles.
Tareas diferentes
Los servicios que realizan varios tipos de trabajo para diferentes categorías de usuarios y en los que cada tipo de trabajo influye de forma diferente en la satisfacción de los usuarios se benefician de varios SLIs.
Por ejemplo, si tu servicio gestiona solicitudes de lectura y escritura, los usuarios que realicen esas tareas pueden tener requisitos diferentes:
- Las solicitudes de lectura deben ser rápidas.
- Las solicitudes de escritura deben completarse correctamente.
Para reflejar estos requisitos, tu SLI debe poder distinguir entre estos dos casos. Normalmente, la métrica de SLI tiene una etiqueta que puedes usar para clasificar los valores en uno de los varios contenedores.
Una tarea con resultados diferentes
Los servicios que realizan un solo tipo de trabajo, pero en los que las expectativas de los usuarios varían en función de la respuesta, se benefician de varios SLIs.
Por ejemplo, si tu servicio solo ofrece acceso de lectura a los datos, los usuarios pueden tener una tolerancia diferente a la latencia en función del resultado de la solicitud:
- Los usuarios pueden tolerar los errores que se devuelven rápidamente, ya que pueden volver a intentar la solicitud inmediatamente.
- Los usuarios pueden ser menos tolerantes con las solicitudes que se completan correctamente, pero que tardan mucho tiempo.
- Los usuarios son menos tolerantes con el peor de los casos: las solicitudes que tardan mucho en devolver un error.
En este caso, tu SLI de latencia debe poder distinguir entre las solicitudes correctas y las incorrectas.
Siguientes pasos
Para obtener información sobre cómo implementar SLIs para servicios de Google Cloud con métricas deGoogle Cloud , consulta lo siguiente:
Para obtener información sobre cómo implementar SLIs específicos de una aplicación, consulta lo siguiente:
Para ver un ejemplo de cómo crear un indicador de nivel de servicio para servicios que registran métricas personalizadas, consulta Definir objetivos de nivel de servicio: observabilidad con métricas personalizadas.