Descripción general

En esta sección, se revisa el concepto de 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 desean ejemplos que implementen servicios específicos de SLI.

Introducción a los SLI

La confiabilidad de un servicio es una noción abstracta. el significado de 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 usará para comunicarse sobre la confiabilidad del servicio y administrarlo.

Los SLI se miden durante un período. Por lo general, el tamaño del período depende de la decisión para la que se usa 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.
  • Durante 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 estrechamente con la satisfacción del usuario. Usa el SLI como 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 esta relación, el SLI debe ser una buena medida del 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 alguna dirección. Del mismo modo, cuando no hay eventos que afecten la satisfacción del usuario, el SLI no cambia.

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

    Un buen SLI escala de forma monótona y lineal, con satisfacción del usuario. Si el SLI mejora, entonces 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 mejora en el valor de un buen SLI corresponde a la cantidad de mejora en la satisfacción del usuario.

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

    Un SLI adecuado produce una medición de rendimiento que varía del 0% al 100%: este rango es intuitivo y fácil para trabajar. Por ejemplo, el rendimiento del SLI del 100% significa que todo funciona y el rendimiento del SLI del 0% significa que no funciona nada.

    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 tiene estas propiedades es pensar en el SLI en términos de promesas realizadas a tus usuarios. Cuando registras las promesas que realizaste y mantienen durante un período, puedes obtener un número que puede variar de un 0% a 100%. Estos SLI también se traducen bien en porcentajes de error aceptable: para un SLO determinado, el porcentaje de error aceptable es la cantidad de promesas que puedes no cumplir durante un período sin dejar de cumplir con tu SLO.

Estos son algunos ejemplos de promesas:

  • Para devolver 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 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 a partir de la hora de inicio.

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 de cómo la 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 una con compensaciones y beneficios. Las formas de medir el SLI son las implementaciones del 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.
  • Métricas exportadas por el servidor de aplicaciones.
  • Métricas exportadas por un balanceador de cargas frente a los servidores de la aplicación.
  • Un servicio de supervisión de caja negra que envía solicitudes artificiales al sistema y tiempos que demora en recibir respuestas válidas.
  • Código específico de la aplicación que se ejecuta en el navegador del cliente que registra la información del tiempo y la envía de vuelta a un servicio de recopilación.

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

  • Fidelidad: captura la experiencia del usuario.
  • Cobertura: indica la proporción de las interacciones de los usuarios que se miden.
  • Costo: cantidad de dinero y tiempo de ingeniería necesarios 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 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 haya ingresado la conexión del usuario a tu servicio. Por ejemplo, cuando se usa un servicio 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 el indicador basado en el navegador es un buen proxy para la satisfacción del usuario. Sin embargo, es posible que esta señal no proporcione información práctica que puedas usar para mejorar la confiabilidad de tu servicio.

Si deseas obtener información para combinar varias mediciones 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

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

Por ejemplo, si tu servicio controla 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 ser exitosas.

Para capturar estos requisitos diferentes, tu SLI debe poder distinguir entre estos dos casos. Por lo general, la métrica del 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 en los que las expectativas de los usuarios difieren en función de la respuesta se benefician de varios SLI.

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

  • Los usuarios pueden tolerar los errores que se devuelven rápidamente, ya que pueden reintentar la solicitud de inmediato.
  • Los usuarios pueden ser menos tolerantes a las solicitudes exitosas que tardan mucho.
  • Los usuarios son menos tolerantes a la peor situación posible: solicitudes que tardan mucho tiempo en devolver un error.

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

Próximos pasos

Si deseas obtener información sobre la implementación de los SLI para los servicios de Google Cloud a través de 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 Parámetro de configuración SLO: observabilidad con métricas personalizadas.