Descripción general

En esta sección, se revisa el concepto de los indicadores de nivel de servicio (SLI), se define qué hace para un SLI bueno o útil y se proporcionan ejemplos de implementaciones de SLI para servicios seleccionados. Esta página está dirigida a las personas que desean ejemplos que implementen SLI específicos del servicio.

Introducción a los SLI

La confiabilidad de un servicio es una noción abstracta. lo que significa la confiabilidad depende del servicio y las necesidades de los usuarios. Un indicador de nivel de servicio (SLI) es una medida de esa confiabilidad que se usará para comunicarse la comunicación con la confiabilidad del servicio y tomar decisiones sobre él.

Los SLI se miden durante un período. Por lo general, el tamaño de la ventana depende de la decisión que se use para tomar la información. Por ejemplo, puedes medir un solo SLI de las siguientes maneras:

  • En la hora más reciente, para crear políticas de alertas
  • Durante las semanas para tomar decisiones tácticas
  • Durante los meses, para tomar decisiones estratégicas

Recomendamos 28 días como punto de partida para medir su SLI. Este valor proporciona un buen equilibrio entre los casos de uso estratégicos y tácticos.

Para obtener más información, consulta los siguientes capítulos en la Guía de ingeniería de confiabilidad de sitios:

Propiedades de un SLI correcto

Consideramos que los SLI “correctos” son aquellos que cumplen con los siguientes criterios:

  • Los SLI son buenas medidas de proxy para la satisfacción del usuario.

    Un buen SLI se relaciona estrechamente con la satisfacción del usuario. Puedes usar el SLI como base para un objetivo de nivel de servicio (SLO), un límite establecido en el SLI. Establece el SLO para que, cuando el SLI esté dentro de un rango definido, la mayoría de tus usuarios estén satisfechos. Para que esta relación se mantenga, el SLI debe ser una buena medida de proxy para la satisfacción del usuario.

    Si el SLI es un buen proxy para la satisfacción del usuario, cuando hay un evento que afecta la satisfacción del usuario, el SLI cambia en cierta dirección. Del mismo modo, cuando no hay eventos que afecten la satisfacción del usuario, el SLI no cambiará.

  • Los SLI escalan de forma monotónica y de manera lineal con la satisfacción del usuario.

    Un SLI correcto escala de forma monotónica, y, de manera lineal, con la satisfacción del usuario. Si el SLI mejora, la satisfacción del usuario mejora y viceversa. La cantidad de mejora en el valor de un buen SLI corresponde a la cantidad de mejoras de satisfacción del usuario.

  • Los SLI producen mediciones que van del 0% al 100%.

    Un SLI correcto produce una medición de rendimiento que va del 0% al 100%: este rango es intuitivo y fácil de usar. Por ejemplo, el rendimiento de SLI del 100% significa que todo funciona y el rendimiento del SLI de 0% significa que no hay nada en funcionamiento.

    Tener un SLI que varía de 0% a 100% facilita la configuración de un SLO en el SLI: asigna un objetivo de porcentaje como el 99.9% y el rendimiento del SLI debe ser igual o mayor que el objetivo de la para cumplir con su SLO.

Procesos

Una forma de implementar un SLI que tenga estas propiedades es pensar en el SLI en términos de las promesas que se le realizan a sus usuarios. Con el conteo de las promesas que realizaste y decidiste mantener un período, puedes derivar de una cantidad de 0% a 100%. Estos SLI también se traducen bien en porcentajes de error aceptables: para un SLO determinado, tu porcentaje de error aceptable es la cantidad de promesas que puedes dejar de mantener durante un período y, al mismo tiempo, cumplir con tu SLO.

Algunos ejemplos de promesas son:

  • Para mostrar una respuesta con un código de estado HTTP 200 a la solicitud de un cliente
  • Para responder a una solicitud de gRPC en menos de 100 ms.
  • Para completar el flujo de trabajo “Crear máquina virtual” de manera correcta.
  • Para entregar datos que se actualizaron en los últimos 10 minutos
  • Para comenzar a ejecutar el trabajo por lotes programado en 1 minuto a partir de la hora de inicio objetivo.

Las promesas pueden ser de bajo nivel, como los ejemplos de HTTP y gRPC, o niveles superiores, como el ejemplo del flujo de trabajo.

Implementaciones y especificaciones de SLI

Una especificación de SLI es lo que deseas medir. La especificación no incluye los detalles técnicos exactos sobre cómo medirás el archivo. Por ejemplo, la siguiente es una especificación de un SLI para el tiempo de carga de la página:

  • Porcentaje de solicitudes a la página principal que se cargan en menos de 100 ms.

Hay muchas maneras de medir un SLI, cada uno con compensaciones y beneficios. Las formas de medir el SLI son los implementaciones de SLI. Por ejemplo, podrías implementar la especificación de carga de páginas como una de las siguientes:

  • El campo de latencia del registro de solicitudes del servidor de la aplicación
  • Métricas exportadas por el servidor de aplicaciones.
  • Métricas exportadas por un balanceador de cargas frente a los servidores de aplicaciones.
  • Un servicio de supervisión de caja negra que envía solicitudes artificiales al sistema y el tiempo que se tarda en recibir las respuestas válidas.
  • Código específico de la aplicación que se ejecuta en el navegador del cliente que registra información de sincronización y la envía de vuelta a un servicio de colección.

Cada una de estas opciones implica compensaciones entre las siguientes características:

  • Fidelidad: Exacta la exactitud de la experiencia del usuario.
  • Cobertura: qué proporción de las interacciones del usuario se miden.
  • Costo: la cantidad de tiempo de ingeniería y dinero necesaria para compilar y mantener la solución

La fidelidad a la experiencia del 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 más precisa de la latencia que el usuario admite en realidad que las otras opciones de implementación.

La desventaja es que la medición basada en el navegador también incluye cualquier latencia que haya ingresado la conexión del usuario a tu servicio. En el caso de un servicio usado a través de la Internet pública, esta latencia puede variar de manera significativa con las condiciones geográficas o la ubicación de la red.

El resultado es que, mientras que la señal basada en el navegador es un buen proxy para la satisfacción del usuario, es posible que la señal no proporcione información práctica que puedas usar para mejorar la confiabilidad de tu servicio.

Si deseas obtener información sobre cómo combinar varias mediciones para equilibrar esta compensación, consulta esta publicación del Thegraph.

Agrupamiento

Es posible que necesites varios SLI para un servicio si tu servicio realiza diferentes tipos de trabajo para diferentes usuarios o si realiza una tarea en particular con diferentes resultados posibles.

Diferentes tareas

Un tipo de servicio que beneficia a varios SLI es uno que realiza varios tipos de trabajo para diferentes categorías de usuarios y en las que cada tipo de trabajo tiene potencialmente impactos en la satisfacción del usuario.

Por ejemplo, si tu servicio maneja solicitudes de lectura y escritura, los usuarios que realizan esas tareas podrían tener requisitos diferentes:

  • Las solicitudes de lectura deben ser rápidas.
  • Las solicitudes de escritura deben realizarse con éxito.

Para capturar estos requisitos diferentes, tu SLI debe poder distinguir entre estos dos casos. Por lo general, esto significa que la métrica de SLI tiene una etiqueta que puedes usar para clasificar valores en uno de varios depósitos.

Una tarea con diferentes resultados

Otro tipo de servicio que beneficia a varios SLI es uno que realiza un solo tipo de trabajo, pero donde las expectativas del usuario difieren según la respuesta.

Por ejemplo, si tu servicio solo ofrece acceso de lectura a los datos, los usuarios podrían tener tolerancia de latencia diferente según el resultado de la solicitud:

  • Los usuarios pueden tolerar errores que se muestren rápidamente, ya que los usuarios pueden reintentar la solicitud de inmediato.
  • Es posible que los usuarios sean menos tolerantes a las solicitudes exitosas que tardan mucho tiempo.
  • Los usuarios serán menos tolerantes a la peor de las situaciones: las solicitudes que tardan mucho en mostrar un error.

En este caso, tu SLI de latencia debe poder distinguir entre solicitudes exitosas y fallidas.

¿Qué sigue?

A fin de obtener información sobre cómo implementar los SLI para los servicios de Google Cloud con métricas de Google Cloud, consulta lo siguiente:

Para obtener información sobre cómo implementar los SLI específicos de la aplicación, consulte los siguientes vínculos: