Descripción general

En esta sección, se revisa el concepto de los indicadores de nivel de servicio (SLI), se define lo que hace que un SLI sea bueno o útil y se proporcionan ejemplos de implementaciones de SLI para los servicios seleccionados. Esta página está dirigida a personas que deseen 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 confiabilidad depende del servicio y las necesidades de sus usuarios. Un indicador de nivel de servicio (SLI) es una medida de esa confiabilidad que se usa para comunicarse sobre la confiabilidad del servicio y administrarlo.

Los SLI se miden durante un período. El tamaño de la ventana suele depender de la decisión que se usa para la información. Por ejemplo, puedes medir un solo SLI de las siguientes maneras:

  • Durante la hora más reciente, para crear políticas de alertas
  • Durante las semanas para tomar decisiones tácticas
  • En el transcurso de 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 las siguientes secciones del Libro de trabajo de ingeniería de confiabilidad de sitios:

Propiedades de un SLI correcto

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

  • Los SLI son buenos indicadores de la satisfacción del usuario.

    Un buen SLI se correlaciona en gran medida con la satisfacción del usuario. Usas el SLI como la base para un objetivo de nivel de servicio (SLO), un umbral establecido en el SLI. Estableces el SLO para que, cuando el SLI esté dentro de un rango definido, la mayoría de los usuarios estén satisfechos. Para que esta relación se mantenga, el SLI debe ser un buen indicador de la satisfacción del usuario.

    Si el SLI es un buen indicador de la satisfacción del usuario, cuando hay un evento que afecta la satisfacción del usuario, el SLI cambia en alguna dirección. Del mismo modo, cuando no hay eventos que afecten la satisfacción del usuario, el SLI no cambia.

  • Los SLI escalan de forma monótona y lineal con la satisfacción del usuario.

    Un SLI adecuado escala de forma monótona y lineal con la satisfacción del usuario. Si el SLI mejora, la satisfacción del usuario también lo hace. Del mismo modo, si el SLI disminuye, la satisfacción del usuario disminuye. La cantidad de mejoras en el valor de un SLI adecuado corresponde a la mejora de la satisfacción del usuario.

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

    Un SLI adecuado produce una medición del rendimiento del 0% al 100%. Este rango es intuitivo y fácil de trabajar. Por ejemplo, un rendimiento del SLI del 100% significa que todo funciona y un rendimiento del SLI del 0% significa que nada funciona.

    Tener un SLI que va del 0% al 100% hace que la configuración de un SLO en el SLI sea fácil y clara: asigna un objetivo porcentual como el 99.9% y el rendimiento del SLI debe ser igual o mayor que ese objetivo que el servicio cumpla con su SLO.

Procesos

Una forma de implementar un SLI que tenga estas propiedades es pensar en el SLI en términos de promesas realizadas a los usuarios. Si cuentas las promesas que realizaste y conservaste en un período determinado, puedes obtener un número que puede variar del 0% al 100%. Estos SLI también se traducen bien en porcentajes de error aceptable: para un SLO determinado, tu porcentaje de error aceptable es la cantidad de promesas que no puedes cumplir en un período, a la vez que cumples con tu SLO.

Estos son algunos ejemplos de promesas:

  • Para mostrar una respuesta con un código de estado HTTP 200 a la solicitud de un cliente, haz lo siguiente:
  • Para responder a una solicitud de gRPC en menos de 100 ms.
  • Para completar correctamente el flujo de trabajo "Crear máquina virtual".
  • Para entregar los datos que se actualizaron en los últimos 10 minutos,
  • Para comenzar a ejecutar el trabajo por lotes programado en un minuto desde su hora de inicio,

Implementaciones y especificaciones de SLI

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

  • El porcentaje de solicitudes de páginas principales que se cargan en menos de 100 ms.

Puede haber muchas formas de medir un SLI, cada uno con compensaciones y beneficios. Las formas de medir el SLI son las implementaciones de SLI. Por ejemplo, puedes implementar la especificación de carga de la página como una de las siguientes opciones:

  • El campo de latencia del registro de solicitudes del servidor de aplicaciones.
  • Las métricas que exporta el servidor de aplicaciones.
  • Métricas exportadas por un balanceador de cargas frente a los servidores de aplicaciones.
  • Un servicio de supervisión en caja negra que envía solicitudes artificiales al sistema y mide el tiempo que lleva recibir respuestas válidas.
  • Código específico de la aplicación ejecutado en el navegador del cliente que registra la información del tiempo 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: captura la experiencia del usuario.
  • Cobertura: qué proporción de interacciones de los usuarios se miden.
  • Costo: la cantidad de dinero y tiempo de ingeniería necesarios para compilar y mantener la solución.

La fidelidad a la experiencia del usuario por lo general mejora 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 latencia más precisa que la latencia percibida por el usuario o por otras opciones de medición.

La compensación es que la medición basada en el navegador también incluye cualquier latencia que ingrese la conexión del usuario a tu servicio. Por ejemplo, cuando un servicio se usa por Internet pública, esta latencia puede variar de forma significativa con la ubicación geográfica o las condiciones de la red.

El resultado es que la señal basada en el navegador es un buen indicador de la satisfacción del usuario. Sin embargo, esta señal podría no proporcionar información procesable que puedas usar para mejorar la confiabilidad de tu servicio.

Si quieres obtener información sobre cómo combinar varias medidas para equilibrar esta compensación, consulta esta publicación de The Telegraph.

Agrupamiento

Es posible que necesites varios SLI para un servicio cuando este realice diferentes tipos de trabajo para diferentes usuarios o cuando realice una tarea en particular con diferentes resultados posibles.

Diferentes tareas

Los servicios que realizan varios tipos de trabajo, para diferentes categorías de usuarios, y en los que cada tipo de trabajo influye en la satisfacción del usuario de manera diferente a varios SLI.

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

  • Las solicitudes de lectura deben ser rápidas.
  • Las solicitudes de escritura deben realizarse de forma correcta.

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

Una tarea con diferentes resultados

Servicios que realizan un solo tipo de trabajo, pero que las expectativas del usuario difieren según el beneficio de respuesta de varios SLI.

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

  • Los usuarios pueden tolerar errores que se muestran con rapidez, ya que pueden volver a intentar la solicitud de inmediato.
  • Es posible que los usuarios sean menos tolerantes a las solicitudes exitosas que tardan mucho tiempo.
  • Los usuarios son menos tolerantes al peor de los casos: solicitudes que tardan mucho tiempo en mostrar un error.

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

¿Qué sigue?

Si deseas obtener información sobre la implementación de los SLI para los servicios de Google Cloud mediante las métricas de Google Cloud, consulta lo siguiente:

Para obtener información sobre la implementación de los SLI específicos de la aplicación, consulta lo siguiente:

Si deseas ver un ejemplo que ilustra cómo crear un SLI para los servicios que informan métricas personalizadas, consulta Configura los SLO: observabilidad mediante métricas personalizadas.