SRE (Ingeniería de confiabilidad del sitio): un enfoque para garantizar la disponibilidad de proyectos web. Se considera un marco para DevOps y explica cómo tener éxito en la aplicación de las prácticas de DevOps. Este artículo es una traducción del Capítulo 4 de Objetivos de nivel de servicio de Site Reliability Engineering de Google. Preparé esta traducción yo mismo y confié en mi propia experiencia para comprender los procesos de monitoreo. En el canal de telegramas monitorim_it y en la última publicación sobre Habré , también publiqué una traducción del capítulo 6 del mismo libro sobre monitoreo de sistemas distribuidos.

Traducción por cat. Que tengas una buena lectura!

Es imposible administrar un servicio si no se comprende qué indicadores realmente importan y cómo medirlos y evaluarlos. Con este fin, definimos y brindamos un cierto nivel de servicio a nuestros usuarios, independientemente de si usan una de nuestras API internas o un producto público.

Utilizamos nuestra intuición, experiencia y reconocemos el deseo de los usuarios de tener una idea de los indicadores de nivel de servicio (SLI), los objetivos de nivel de servicio (SLO) y el acuerdo de nivel de servicio (SLA). Estas mediciones describen las principales métricas que queremos controlar y a las que responderemos si no podemos proporcionar la calidad de servicio esperada. En última instancia, elegir los indicadores correctos ayuda a administrar las acciones correctas si algo sale mal, y también brinda confianza al equipo de SRE en la salud del servicio.

Este capítulo describe el enfoque que utilizamos para tratar los problemas de modelado de métricas, selección de métricas y análisis de métricas. La mayoría de las explicaciones serán sin ejemplos, por lo que utilizaremos el servicio de Shakespeare descrito en el ejemplo de su implementación (búsqueda de obras de Shakespeare) para ilustrar los puntos principales.

Nivel de servicio terminología

Muchos lectores probablemente estén familiarizados con el concepto de SLA, pero los términos SLI y SLO merecen una definición cuidadosa, ya que en general el término SLA está sobrecargado y tiene varios significados según el contexto. Para mayor claridad, queremos separar estos valores.

Indicadores

SLI es un indicador del nivel de servicio, una medida cuidadosamente cuantificada de un aspecto del nivel de servicio proporcionado.

Para la mayoría de los servicios, el retraso en la solicitud se considera como el SLI clave: cuánto tiempo se requiere para devolver una respuesta a la solicitud. Otros SLI comunes incluyen la tasa de error, a menudo expresada como una fracción de todas las solicitudes recibidas, y el rendimiento del sistema, generalmente medido en solicitudes por segundo. Las mediciones a menudo se agregan: primero se recopilan los datos sin procesar y luego se convierten a la tasa de cambio, promedio o percentil.

Idealmente, el SLI mide directamente el nivel de servicio de interés, pero a veces solo la métrica asociada está disponible para la medición, porque el original es difícil de obtener o interpretar. Por ejemplo, la latencia del lado del cliente suele ser una métrica más apropiada, pero sucede que medir la latencia solo es posible en el servidor.

Otro tipo de SLI que es importante para SRE es la disponibilidad o parte del tiempo durante el cual se puede utilizar el servicio. A menudo se define como el porcentaje de solicitudes exitosas, a veces llamado generación. (Esperanza de vida: la probabilidad de que los datos se almacenen durante un largo período de tiempo también es importante para los sistemas de almacenamiento de datos). Aunque la accesibilidad es 100% imposible, a menudo se puede lograr una accesibilidad cercana al 100%, los valores de accesibilidad se expresan como el número "nueve" »Disponibilidad porcentual. Por ejemplo, la disponibilidad de 99% y 99.999% puede denominarse "2 nueves" y "5 nueves". El objetivo actual declarado de accesibilidad para Google Compute Engine es "tres nueves y media" o 99.95%.

Objetivos

SLO es el objetivo de un nivel de servicio: un valor objetivo o rango de valores para el nivel de servicio medido por SLI. El valor normal para SLO es "SLI ≤ valor objetivo" o "límite inferior ≤ SLI ≤ límite superior". Por ejemplo, podemos decidir que devolveremos los resultados de búsqueda para los trabajos de Shakespeare "rápidamente", tomando en forma de SLO el valor del retraso promedio de la consulta de búsqueda es inferior a 100 milisegundos.

Elegir el SLO correcto es un proceso complejo. Primero, no siempre puede seleccionar un valor específico. Para las solicitudes HTTP entrantes externas a su servicio, la métrica del número de solicitudes por segundo (QPS) está determinada principalmente por el deseo de sus usuarios de visitar su servicio, y no puede instalar SLO para esto.

Por otro lado, puede decir que desea que el retraso promedio para cada solicitud sea inferior a 100 milisegundos. Establecer ese objetivo puede hacer que escriba su front-end con un retraso bajo o que compre equipos que proporcionen dicho retraso. (100 milisegundos es obviamente un valor arbitrario, pero es mejor tener tasas de latencia aún más bajas. Hay razones para creer que la alta velocidad es mejor que la lenta y que retrasar las solicitudes de los usuarios por encima de ciertos valores en realidad obliga a las personas a mantenerse alejadas de su servicio).

Una vez más, esto es más ambiguo de lo que parece a primera vista: no vale la pena eliminar QPS del cálculo. El hecho es que el paquete QPS y el retraso están fuertemente relacionados entre sí: un QPS más alto a menudo conduce a retrasos más largos, y generalmente los servicios experimentan una fuerte disminución en el rendimiento cuando se alcanza un cierto umbral de carga.

Elegir y publicar SLO establece las expectativas de los usuarios sobre cómo funcionará el servicio. Esta estrategia puede reducir las quejas irrazonables sobre el propietario del servicio, por ejemplo, sobre su lento trabajo. Sin un SLO explícito, los usuarios a menudo crean sus propias expectativas sobre el rendimiento deseado, que puede no estar relacionado de ninguna manera con las opiniones de las personas que diseñan y administran el servicio. Esta alineación puede generar altas expectativas del servicio, cuando los usuarios creen erróneamente que el servicio será más accesible de lo que realmente es y causan desconfianza cuando los usuarios creen que el sistema es menos confiable de lo que realmente es.

Acuerdo

Un acuerdo de nivel de servicio es un contrato explícito o implícito con sus usuarios que incluye las consecuencias del inicio (o ausencia) de los SLO que contienen. Las consecuencias se reconocen más fácilmente cuando son financieras (un descuento o una multa), pero pueden adoptar otras formas. Una manera fácil de hablar sobre la diferencia entre los SLO y los SLA es preguntar: "¿Qué sucede si no se cumplen los SLO?" Si no hay consecuencias obvias, seguramente mirará SLO.

Los SRE no suelen participar en la creación de SLA porque los SLA están estrechamente relacionados con las soluciones comerciales y de productos. SRE, sin embargo, está involucrado en ayudar a prevenir las consecuencias de los SLO fallidos. También pueden ayudar a determinar los SLI: obviamente, debe haber una forma objetiva de medir los SLO en un acuerdo o habrá desacuerdos.

Google Search es un ejemplo de un servicio importante que no tiene un SLA para el público: queremos que todos usen Search de la manera más eficiente posible, pero no hemos firmado un contrato con el mundo entero. Sin embargo, todavía hay consecuencias si la búsqueda no está disponible: la inaccesibilidad conduce a una caída en nuestra reputación, así como a una disminución en los ingresos publicitarios. Muchos otros servicios de Google, como Google for Work, tienen acuerdos explícitos de nivel de servicio con los usuarios. Independientemente de si un servicio en particular tiene un SLA, es importante determinar el SLI y el SLO y usarlos para administrar el servicio.

Tanta teoría, ahora para experimentar.

Indicadores en la práctica

Dado que hemos concluido que es importante seleccionar los indicadores apropiados para medir el nivel de servicio, ¿cómo sabe ahora qué indicadores son relevantes para el servicio o sistema?

Lo que a usted y a sus usuarios les importa

No necesita utilizar cada indicador como un SLI, que puede rastrear en el sistema de monitoreo; Comprender lo que los usuarios quieren del sistema lo ayudará a elegir algunas métricas. Elegir demasiados indicadores hace que sea difícil prestar atención a los indicadores importantes, mientras que elegir muy pocos puede dejar partes importantes de su sistema desatendidas. Usualmente usamos varios indicadores clave para evaluar y comprender el estado del sistema.

Los servicios, como regla, se pueden dividir en varias partes en términos de SLI, que son relevantes para ellos:

• Sistemas frontend personalizados, como las interfaces de búsqueda del servicio Shakespeare de nuestro ejemplo. Deben ser accesibles, no retrasados ​​y tener suficiente ancho de banda. En consecuencia, puede hacer preguntas: ¿podemos responder a la solicitud? ¿Cuánto tiempo tardó en responder la solicitud? ¿Cuántas solicitudes se pueden procesar?
• Sistemas de almacenaje. La baja latencia, disponibilidad y durabilidad son importantes para ellos. Preguntas relacionadas: ¿Cuánto tiempo lleva leer o escribir datos? ¿Podemos acceder a los datos a pedido? ¿Hay datos disponibles cuando los necesitamos? Consulte el capítulo 26 Integridad de los datos: lo que lee es lo que escribió para una discusión detallada de estos temas.
• Los grandes sistemas de datos, como las canalizaciones de procesamiento de datos, dependen del rendimiento y la latencia del procesamiento de solicitudes. Preguntas relevantes: ¿cuántos datos se procesan? ¿Cuánto tardan los datos en pasar de recibir una solicitud a emitir una respuesta? (Algunas partes del sistema también pueden tener retrasos en ciertas etapas).

Colección de indicadores

Es muy natural recopilar muchos indicadores de nivel de servicio en el lado del servidor, utilizando un sistema de monitoreo como Borgmon (consulte el Capítulo 10 Prácticas de alertas de series temporales ) o Prometheus, o simplemente analizando periódicamente los registros, revelando respuestas HTTP con un estado de 500. Sin embargo, algunos sistemas deben estar equipados con una colección de métricas del lado del cliente, ya que la falta de monitoreo en el lado del cliente puede llevar a perder una serie de problemas que afectan a los usuarios pero no afectan a las métricas del lado del servidor. Por ejemplo, centrarse en la respuesta retrasada del back-end de nuestra aplicación de prueba en busca de los trabajos de Shakespeare puede conducir a un retraso en el procesamiento de solicitudes por parte del usuario debido a problemas de JavaScript: en este caso, medir el tiempo que tardará la página en procesarse en el navegador es el mejor indicador.

Agregación

Por simplicidad y facilidad de uso, a menudo agregamos dimensiones en bruto. Esto debe hacerse con cuidado.

Algunos indicadores parecen simples, por ejemplo, el número de consultas por segundo, pero incluso esto, la medición directa y obvia agrega datos implícitamente a lo largo del tiempo. ¿La medición se obtiene específicamente una vez por segundo o se promedia esta medición sobre el número de consultas por minuto? La última opción puede ocultar un número instantáneo mucho mayor de solicitudes que se almacenan durante solo unos segundos. Considere un sistema que atiende 200 solicitudes por segundo con números pares y 0 el resto del tiempo. Una constante en forma de un valor promedio de 100 solicitudes por segundo y el doble de carga instantánea no es lo mismo. Del mismo modo, el promedio de latencias de solicitud puede parecer atractivo, pero esconde un detalle importante: es posible que la mayoría de las solicitudes sean rápidas, pero habrá muchas solicitudes que serán lentas.

La mayoría de los indicadores se ven mejor como distribuciones que como promedios. Por ejemplo, para retrasos de SLI, algunas solicitudes se procesarán rápidamente, mientras que otras siempre tardarán más, a veces mucho más. Un promedio simple puede ocultar estos largos retrasos. La figura muestra un ejemplo: aunque una solicitud típica se sirve durante aproximadamente 50 ms, ¡el 5% de las solicitudes son 20 veces más lentas! El monitoreo y las alertas basadas solo en la latencia promedio no muestran cambios en el comportamiento durante el día, cuando de hecho hay cambios notables en el tiempo de procesamiento de algunas solicitudes (la línea superior).


50, 85, 95 y 99 percentil de retraso del sistema. El eje Y está en formato logarítmico.

El uso de percentiles para indicadores le permite ver la forma de la distribución y sus características: un alto nivel de un percentil, como 99 o 99.9, muestra el peor valor, y en el percentil 50 (también conocido como la mediana), puede ver el estado más frecuente de la métrica. Cuanto mayor es la variación en el tiempo de respuesta, más fuertes son las consultas a largo plazo que afectan la experiencia del usuario. El efecto se mejora a alta carga en presencia de colas. Los estudios de experiencia del usuario han demostrado que las personas generalmente prefieren un sistema más lento con una alta dispersión del tiempo de respuesta, por lo que algunos equipos de SRE se centran solo en valores de percentiles altos, basándose en el supuesto de que si el comportamiento métrico en el percentil 99.9 es bueno, la mayoría de los usuarios no experimentarán problemas

Nota sobre errores estadísticos

Por lo general, preferimos trabajar con percentiles en lugar de con un conjunto de valores promedio (media aritmética). Esto nos permite considerar valores más dispersos, que a menudo tienen características significativamente diferentes (y más interesantes) que el promedio. Debido a la naturaleza artificial de los sistemas informáticos, los valores métricos a menudo están distorsionados, por ejemplo, ninguna solicitud puede recibir una respuesta en menos de 0 ms, y un tiempo de espera de 1000 ms significa que no puede haber respuestas exitosas con valores que excedan el tiempo de espera. Como resultado, ¡no podemos aceptar que la media y las medianas puedan ser iguales o cercanas entre sí!

Sin verificación preliminar, y si no se cumplen algunas suposiciones y aproximaciones estándar, tratamos de no sacar conclusiones de que nuestros datos se distribuyen normalmente. Si la distribución no es la esperada, un proceso de automatización que soluciona el problema (por ejemplo, cuando ve valores atípicos más allá de los valores límite, reinicia el servidor con altas latencias para procesar la solicitud) puede hacer esto con demasiada frecuencia o no lo suficiente (ambas opciones no son muy buenas).

Estandarizar indicadores

Recomendamos estandarizar las características generales de los SLI para que no tenga que hablar de ellos cada vez. Cualquier función que satisfaga las plantillas estándar puede excluirse de la especificación de un SLI individual, por ejemplo:

• Intervalos de agregación: "promedio de más de 1 minuto"
• Áreas de agregación: "Todas las tareas en el clúster"
• Con qué frecuencia se toman las medidas: "Cada 10 segundos"
• Qué solicitudes se incluyen: "HTTP GET de trabajos de monitoreo de recuadro negro"
• Cómo se recibieron los datos: "Gracias a nuestro monitoreo medido en el servidor",
• Retraso de acceso a datos: "Tiempo hasta el último byte"

Para ahorrar esfuerzo, cree un conjunto de plantillas SLI reutilizables para cada métrica común; También facilitan que todos entiendan lo que significa un SLI en particular.

Objetivos de práctica

Comience pensando (o descubra) lo que les importa a sus usuarios, no lo que puede medir. A menudo, lo que molesta a tus usuarios es difícil o imposible de medir, por lo que terminas acercándote a sus necesidades. Sin embargo, si solo comienza con lo que es fácil de medir, obtendrá SLO menos útiles. Como resultado, a veces encontramos que la definición inicial de las metas deseadas y el trabajo adicional con indicadores específicos funciona mejor que elegir indicadores y luego alcanzar las metas.

Definir objetivos

Para mayor claridad, se debe determinar cómo se miden los SLO y las condiciones bajo las cuales son válidos. Por ejemplo, podemos decir lo siguiente (la segunda línea es la misma que la primera, pero usa valores SLI por defecto):

• El 99% (en promedio durante 1 minuto) de las llamadas Get RPC se completará en menos de 100 ms (medido en todos los servidores de fondo).
• El 99% de las llamadas Get RPC se completarán en menos de 100 ms.

Si la forma de las curvas de rendimiento es importante, puede especificar varios objetivos de SLO:

• El 90% de las llamadas Get RPC se completaron en menos de 1 ms.
• El 99% de las llamadas Get RPC se completaron en menos de 10 ms.
• El 99,9% de las llamadas Get RPC se completaron en menos de 100 ms.

Si sus usuarios generan cargas heterogéneas: procesamiento en masa (para el cual el ancho de banda es importante) y procesamiento interactivo (para el cual la cantidad de retraso es importante), puede ser aconsejable definir objetivos separados para cada clase de carga:

• El 95% de las solicitudes de los clientes son de ancho de banda importante. Establezca el recuento de llamadas RPC en progreso <1 s.
• El 99% de los clientes valora la cantidad de retraso. Configure el recuento de llamadas RPC con tráfico <1 kB y en curso <10 ms.

No es realista e indeseable insistir en que los SLO se ejecuten en el 100% de los casos: esto puede ralentizar el ritmo de introducción de nuevas funcionalidades y despliegues, y requerir soluciones costosas. En cambio, es mejor permitir un presupuesto de errores: una fracción del tiempo de inactividad del sistema y controlar este valor diariamente o semanalmente.La alta gerencia puede querer una evaluación mensual o trimestral. (El presupuesto de error es solo un SLO para compararlo con otro SLO).

El porcentaje de violación de SLO se puede comparar con el presupuesto de error (consulte el Capítulo 3 y la sección “Motivación para presupuestos de error” ), y el valor de diferencia se utiliza como una entrada al proceso que decide cuándo implementar nuevas versiones.

Seleccionar valores del plan

La selección de valores planificados (SLO) no es una actividad puramente técnica debido a los intereses del producto y el negocio, que debe reflejarse en el SLI, SLO (y, posiblemente, SLA) seleccionados. Del mismo modo, puede ser necesario intercambiar información sobre cuestiones relacionadas con la dotación de personal, el tiempo de comercialización, la disponibilidad de equipos y la financiación. El SRE debe ser parte de esta conversación y ayudar a lidiar con los riesgos y la viabilidad de las diversas opciones. Resolvimos algunas preguntas que podrían ayudar a proporcionar una discusión más productiva:

no elija un objetivo basado en el rendimiento actual.
Si bien es importante comprender las fortalezas y los límites del sistema, la adaptación de los indicadores sin razonamiento puede impedir que apoye el sistema: se necesitarán esfuerzos heroicos para lograr objetivos que no se pueden lograr sin una reorganización importante.

Hágalo simple
Los cálculos complejos de SLI pueden ocultar los cambios en el rendimiento del sistema y dificultar la búsqueda de la causa del problema.

Evite lo absoluto
Aunque es tentador tener un sistema que pueda asumir una carga de crecimiento ilimitada sin aumentar el valor de retraso, este requisito no es realista. Es probable que un sistema que se acerque a tales ideales obligue a tener mucho tiempo para diseñar y construir, su costo de operación será demasiado bueno para las expectativas de los usuarios que hubieran tenido menos.

Utilice la menor cantidad posible de SLO.
Elija suficientes SLO para proporcionar una buena cobertura de los atributos del sistema. Proteja los SLO que elija: si nunca puede ganar una disputa sobre las prioridades especificando un SLO específico, probablemente no debería considerar este SLO. Sin embargo, no todos los atributos del sistema se prestan a SLO: es difícil calcular el nivel de entusiasmo del usuario con SLO.

No persiga la perfección
Siempre puede refinar sus definiciones y objetivos de SLO con el tiempo cuando aprenda más sobre el comportamiento del sistema bajo carga. Es mejor comenzar con un objetivo flotante, que aclarará con el tiempo, que elegir un objetivo demasiado estricto que debería debilitarse cuando descubra que es inalcanzable.

Los SLO pueden y deben ser el principal impulsor para priorizar el trabajo para SRE y los desarrolladores de productos, ya que reflejan la atención al usuario. Un buen SLO es una herramienta útil para obligar a un equipo de desarrollo. Pero un SLO mal diseñado puede conducir a un trabajo inútil si el equipo hace esfuerzos heroicos para lograr un SLO demasiado agresivo o un producto pobre si el SLO es demasiado bajo. SLO es una palanca poderosa, úsala sabiamente.

Medidas de control

SLI y SLO son los elementos clave utilizados para administrar sistemas:

• Monitorear y medir sistemas SLI.
• Compare SLI con SLO y decida si se necesita una acción.
• Si se requiere acción, averigüe qué debe suceder para lograr el objetivo.
• Realiza esta acción.

Por ejemplo, si el paso 2 muestra que el tiempo de espera de la solicitud está aumentando y romperá el SLO después de unas horas si no se hace nada, el paso 3 puede incluir probar la hipótesis de que la carga del servidor está vinculada a los procesadores y agregar nuevos servidores distribuirá la carga . Sin SLO, no sabría si (o cuándo) tomar medidas.

Establecer SLO: luego se establecen las expectativas del usuario
Publicar un SLO establece las expectativas del usuario para el comportamiento del sistema. Los usuarios (y los usuarios potenciales) a menudo quieren saber qué esperar de un servicio para ver si es adecuado para su uso. Por ejemplo, las personas que desean usar un sitio web para compartir fotos pueden evitar usar un servicio que promete durabilidad y bajo costo a cambio de una disponibilidad ligeramente menor, aunque el mismo servicio puede ser ideal para un sistema de gestión de grabación de archivos.

Para establecer expectativas realistas para sus usuarios, use una o las dos tácticas siguientes:

• . SLO, . , . SLO , .
• . , , . , SLO, . , .

Comprender qué tan bien el sistema cumple con las expectativas ayuda a decidir si acelerar el sistema y hacerlo más accesible y más estable. Alternativamente, si el servicio funciona demasiado bien, se debe dedicar parte del tiempo del personal a otras prioridades, como pagar deudas técnicas, agregar nuevas funciones o poner en funcionamiento nuevos productos.

Convenios de práctica

La creación de un SLA requiere que los equipos comerciales y legales determinen las consecuencias y las sanciones por violarlo. El papel del SRE es ayudarlos a comprender las posibles dificultades para realizar los SLO contenidos en los SLA. La mayoría de las pautas de SLO también son aplicables a los SLA. Es aconsejable ser conservador en lo que promete a los usuarios, porque cuanto más son, más difícil es cambiar o eliminar los SLA que parecen irrazonables o difíciles de implementar.

Gracias por leer la traducción hasta el final. Suscríbase a mi canal de telegramas sobre el monitoreo de monitorim_it y el blog en el Medio .