Descripción general

En esta sección, se revisa el concepto de indicadores de nivel de servicio (SLI), se define qué hace que un SLI sea bueno o útil, y se proporcionan ejemplos de implementaciones de SLI para 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 de las necesidades de sus usuarios. Un indicador de nivel de servicio (SLI) es una medida de esa confiabilidad que se usará para comunicar 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 Cuaderno 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 fuertemente con la satisfacción del usuario. Usas el SLI como base para un objetivo de nivel de servicio (SLO), un umbral establecido en el SLI. Estableces el SLO de modo que, cuando el SLI esté dentro de un rango definido, la mayoría de tus usuarios estén conformes. 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 se escalan de forma monótona y lineal con la satisfacción del usuario.

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

  • Los SLIs producen mediciones que oscilan entre el 0% y el 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, un rendimiento de SLI del 100% significa que todo funciona, y un rendimiento de 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 tenga estas propiedades es pensar en él en términos de promesas hechas a los 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.
  • 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 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 una con ventajas y desventajas. 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:

  • Es el campo de latencia del registro de solicitudes del servidor de aplicaciones.
  • Métricas que exporta el servidor de aplicaciones.
  • Métricas que exporta 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 mide el tiempo que tarda en recibir respuestas válidas.
  • Es un código específico de la aplicación que se ejecuta en el navegador del cliente y que registra la información de tiempo y la envía 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 qué proporción de interacciones de los usuarios se mide.
  • Costo: Es la 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 genera una medición de latencia más precisa que la que percibe 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 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 de la satisfacción del usuario. Sin embargo, es posible que este indicador 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 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 de manera diferente en la satisfacción del usuario se benefician de varios SLI.

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

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

Para capturar estos diferentes requisitos, 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

Los servicios que realizan un solo tipo de trabajo, pero en los que las expectativas de los usuarios difieren según la respuesta, se benefician de varios SLI.

Por ejemplo, si tu servicio solo ofrece acceso de lectura a los datos, es posible que los usuarios tengan una tolerancia diferente a 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.
  • Es posible que los usuarios sean menos tolerantes con las solicitudes correctas que tardan mucho tiempo.
  • Los usuarios son menos tolerantes a la peor situación posible: solicitudes que tardan mucho tiempo en devolver un error.

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

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 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.