SRE (Site Reliability Engineering) es un enfoque para garantizar la disponibilidad de proyectos web. Se considera un marco para DevOps y habla sobre cómo lograr el éxito en la aplicación de prácticas de DevOps. Traducción en este artículo. libros de Google. Yo mismo preparé esta traducción y me basé en mi propia experiencia para comprender los procesos de seguimiento. En el canal de telegramas и También publiqué una traducción del Capítulo 6 del mismo libro sobre objetivos de nivel de servicio.
Traducción por gato. ¡Disfruta leyendo!
Es imposible gestionar 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 comprensión del deseo de los usuarios de comprender los indicadores de nivel de servicio (SLI), los objetivos de nivel de servicio (SLO) y los acuerdos de nivel de servicio (SLA). Estas dimensiones describen las principales métricas que queremos monitorear y a las que reaccionaremos si no podemos brindar la calidad de servicio esperada. En última instancia, elegir las métricas correctas ayuda a guiar las acciones correctas si algo sale mal y también le da al equipo de SRE confianza en el estado del servicio.
Este capítulo describe el enfoque que utilizamos para combatir los problemas del modelado métrico, la selección de métricos y el análisis de métricos. La mayor parte de la explicación no tendrá ejemplos, por lo que utilizaremos el servicio de Shakespeare descrito en su ejemplo de implementación (búsqueda de obras de Shakespeare) para ilustrar los puntos principales.
Terminología de nivel de servicio
Es probable que muchos lectores estén familiarizados con el concepto de SLA, pero los términos SLI y SLO merecen una definición cuidadosa porque, en general, el término SLA está sobrecargado y tiene varios significados según el contexto. Para mayor claridad, queremos separar estos valores.
Indicadores
El SLI es un indicador del nivel de servicio: una medida cuantitativa cuidadosamente definida de un aspecto del nivel de servicio prestado.
Para la mayoría de los servicios, se considera que el SLI clave es la latencia de solicitud: cuánto tiempo se tarda en devolver una respuesta a una 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 datos sin procesar y luego se convierten en una tasa de cambio, media o percentil.
Idealmente, SLI mide directamente el nivel de servicio de interés, pero a veces sólo está disponible una métrica relacionada para medir porque la 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 hay ocasiones en las que la latencia sólo se puede medir en el servidor.
Otro tipo de SLI que es importante para los SRE es la disponibilidad, o la porción de tiempo durante la cual se puede utilizar un servicio. A menudo se define como la tasa de solicitudes exitosas, a veces denominada rendimiento. (La vida útil, la probabilidad de que los datos se conserven durante un período prolongado, también es importante para los sistemas de almacenamiento de datos). Aunque no es posible una disponibilidad del 100%, a menudo se puede lograr una disponibilidad cercana al 100%; los valores de disponibilidad se expresan como el número de "nueves" » porcentaje de disponibilidad. Por ejemplo, la disponibilidad del 99 % y del 99,999 % podría etiquetarse como "2 nueves" y "5 nueves". El objetivo de disponibilidad actual declarado de Google Compute Engine es "tres nueves y medio" o 99,95%.
Objetivos
Un SLO es un objetivo de nivel de servicio: un valor objetivo o rango de valores para un nivel de servicio que mide el SLI. Un valor normal para SLO es "SLI ≤ Objetivo" o "Límite inferior ≤ SLI ≤ Límite superior". Por ejemplo, podríamos decidir que devolveremos resultados de búsqueda de Shakespeare "rápidamente" configurando el SLO en una latencia promedio de consulta de búsqueda de menos de 100 milisegundos.
Elegir el SLO adecuado es un proceso complejo. En primer lugar, no siempre se puede elegir un valor específico. Para las solicitudes HTTP entrantes externas a su servicio, la métrica de Consulta por segundo (QPS) está determinada principalmente por el deseo de sus usuarios de visitar su servicio y no puede establecer un SLO para eso.
Por otro lado, puedes decir que quieres que la latencia promedio para cada solicitud sea inferior a 100 milisegundos. Establecer tal objetivo puede obligarlo a escribir su interfaz con baja latencia o comprar equipos que proporcionen dicha latencia. (Obviamente, 100 milisegundos es un número arbitrario, pero es mejor tener números de latencia aún más bajos. Hay evidencia que sugiere que las velocidades rápidas son mejores que las velocidades lentas, y que la latencia en el procesamiento de solicitudes de los usuarios por encima de ciertos valores en realidad obliga a las personas a mantenerse alejadas. de su servicio.)
Nuevamente, esto es más ambiguo de lo que podría parecer a primera vista: no se debe excluir completamente el QPS del cálculo. El hecho es que QPS y la latencia están fuertemente relacionados entre sí: un QPS más alto a menudo conduce a latencias más altas, y los servicios generalmente experimentan una fuerte disminución en el rendimiento cuando alcanzan un cierto umbral de carga.
La selección y publicación de un SLO establece las expectativas del usuario sobre cómo funcionará el servicio. Esta estrategia puede reducir las quejas infundadas contra el propietario del servicio, como el rendimiento lento. Sin un SLO explícito, los usuarios suelen crear sus propias expectativas sobre el rendimiento deseado, que pueden no tener nada que ver con las opiniones de las personas que diseñan y gestionan el servicio. Esta situación puede generar expectativas infladas respecto del servicio, cuando los usuarios creen erróneamente que el servicio será más accesible de lo que realmente es, y generar desconfianza cuando los usuarios creen que el sistema es menos confiable de lo que realmente es.
Acuerdos
Un acuerdo de nivel de servicio es un contrato explícito o implícito con sus usuarios que incluye las consecuencias de cumplir (o no cumplir) 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 SLO y SLA es preguntar "¿qué sucede si no se cumplen los SLO?" Si no hay consecuencias claras, es casi seguro que se trata de un SLO.
Por lo general, el SRE no participa en la creación de SLA porque los SLA están estrechamente vinculados a las decisiones comerciales y de productos. La SRE, sin embargo, participa en ayudar a mitigar las consecuencias de los SLO fallidos. También pueden ayudar a determinar el SLI: obviamente, debe haber una forma objetiva de medir el SLO en el acuerdo o habrá desacuerdo.
La Búsqueda de Google es un ejemplo de un servicio importante que no tiene un SLA público: queremos que todos utilicen la Búsqueda de la manera más eficiente posible, pero no hemos firmado un contrato con el mundo. Sin embargo, todavía hay consecuencias si la búsqueda no está disponible: la falta de disponibilidad da como resultado una caída en nuestra reputación, así como una reducción de 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 definir el SLI y el SLO y utilizarlos para gestionar el servicio.
Tanta teoría, ahora a experimentar.
Indicadores en la práctica
Dado que hemos concluido que es importante seleccionar métricas apropiadas para medir el nivel de servicio, ¿cómo se sabe ahora qué métricas son importantes para un servicio o sistema?
¿Qué les importa a usted y a sus usuarios?
No es necesario utilizar todas las métricas como SLI que pueda rastrear en un sistema de monitoreo; Comprender lo que los usuarios quieren de un sistema le ayudará a seleccionar varias métricas. Elegir demasiados indicadores dificulta centrarse en indicadores importantes, mientras que elegir un número pequeño puede dejar grandes partes de su sistema desatendidas. Normalmente utilizamos varios indicadores clave para evaluar y comprender el estado de un sistema.
Los servicios generalmente se pueden dividir en varias partes en términos de SLI que sean relevantes para ellos:
- Sistemas front-end personalizados, como las interfaces de búsqueda para el servicio Shakespeare de nuestro ejemplo. Deben estar disponibles, no tener retrasos y tener suficiente ancho de banda. En consecuencia, se pueden hacer preguntas: ¿podemos responder a la solicitud? ¿Cuánto tiempo tardó en responder a la solicitud? ¿Cuántas solicitudes se pueden procesar?
- Sistemas de almacenamiento. Valoran la baja latencia de respuesta, la disponibilidad y la durabilidad. Preguntas relacionadas: ¿Cuánto tiempo se tarda en leer o escribir datos? ¿Podemos acceder a los datos previa solicitud? ¿Están los datos disponibles cuando los necesitamos? Consulte el Capítulo 26 Integridad de los datos: lo que lee es lo que escribe para obtener una discusión detallada de estos temas.
- Los sistemas de big data, como las canalizaciones de procesamiento de datos, dependen del rendimiento y la latencia del procesamiento de consultas. Preguntas relacionadas: ¿Cuántos datos se procesan? ¿Cuánto tiempo tardan los datos en viajar desde que se recibe una solicitud hasta que se emite una respuesta? (Algunas partes del sistema también pueden tener retrasos en determinadas etapas).
Colección de indicadores
Muchos indicadores de nivel de servicio se recopilan de forma más natural en el lado del servidor, utilizando un sistema de monitoreo como Borgmon (ver más abajo). ) o Prometheus, o simplemente analizando periódicamente los registros, identificando respuestas HTTP con estado 500. Sin embargo, algunos sistemas deben estar equipados con recopilación de métricas del lado del cliente, ya que la falta de monitoreo del lado del cliente puede llevar a pasar por alto una serie de problemas que afectan usuarios, pero no afectan las métricas del lado del servidor. Por ejemplo, centrarse en la latencia de respuesta del backend de nuestra aplicación de prueba de búsqueda de Shakespeare puede generar latencia en el lado del usuario debido a problemas de JavaScript: en este caso, medir cuánto tiempo le toma al navegador procesar la página es una mejor métrica.
Agregación
Por simplicidad y facilidad de uso, a menudo agregamos medidas sin procesar. Esto debe hacerse con cuidado.
Algunas métricas parecen simples, como las solicitudes por segundo, pero incluso esta medición aparentemente sencilla agrega implícitamente datos a lo largo del tiempo. ¿La medición se recibe específicamente una vez por segundo o se promedia la medición sobre el número de solicitudes por minuto? La última opción puede ocultar un número mucho mayor de solicitudes instantáneas que sólo duran 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 valor promedio de 100 solicitudes por segundo y el doble de carga instantánea no son lo mismo. De manera similar, promediar las latencias de las consultas puede parecer atractivo, pero oculta un detalle importante: es posible que la mayoría de las consultas sean rápidas, pero habrá muchas consultas que serán lentas.
La mayoría de los indicadores se consideran mejor como distribuciones que como promedios. Por ejemplo, para la latencia SLI, algunas solicitudes se procesarán rápidamente, mientras que otras siempre tardarán más, a veces mucho más. Un simple promedio puede ocultar estos largos retrasos. La figura muestra un ejemplo: aunque una solicitud típica tarda aproximadamente 50 ms en atenderse, ¡el 5 % de las solicitudes son 20 veces más lentas! El monitoreo y las alertas basados únicamente en la latencia promedio no muestran cambios en el comportamiento a lo largo del día, cuando en realidad hay cambios notables en el tiempo de procesamiento de algunas solicitudes (línea superior).
Latencia del sistema percentil 50, 85, 95 y 99. El eje Y está en formato logarítmico.
El uso de percentiles para los indicadores permite ver la forma de la distribución y sus características: un nivel percentil alto, como 99 o 99,9, muestra el peor valor, mientras que el percentil 50 (también conocido como mediana) muestra el estado más frecuente de la métrica. Cuanto mayor sea la dispersión del tiempo de respuesta, más afectarán las solicitudes de larga duración a la experiencia del usuario. El efecto se potencia con una carga elevada y en presencia de colas. La investigación sobre la experiencia del usuario ha demostrado que las personas generalmente prefieren un sistema más lento con una alta variación en el tiempo de respuesta, por lo que algunos equipos de SRE se centran solo en puntuaciones percentiles altas, basándose en que si el comportamiento de una métrica en el percentil 99,9 es bueno, la mayoría de los usuarios no experimentarán problemas. .
Nota sobre errores estadísticos
Generalmente preferimos trabajar con percentiles en lugar de con la media (media aritmética) de un conjunto de valores. 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 de las métricas a menudo están sesgados, 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 mayores. que el tiempo de espera. Como resultado, no podemos aceptar que la media y la mediana puedan ser iguales o cercanas entre sí.
Sin pruebas previas, y a menos que se cumplan ciertos supuestos y aproximaciones estándar, tenemos cuidado de no concluir que nuestros datos se distribuyen normalmente. Si la distribución no es la esperada, el proceso de automatización que soluciona el problema (por ejemplo, cuando ve valores atípicos, reinicia el servidor con altas latencias de procesamiento de solicitudes) puede estar haciéndolo con demasiada frecuencia o no con la suficiente frecuencia (ambas no son adecuadas). muy bien).
Estandarizar indicadores
Recomendamos estandarizar las características generales de SLI para que no tengas que especular sobre ellas cada vez. Cualquier característica que satisfaga patrones estándar puede excluirse de la especificación de un SLI individual, por ejemplo:
- Intervalos de agregación: "promediados durante 1 minuto"
- Áreas de agregación: "Todas las tareas del clúster"
- Con qué frecuencia se toman las mediciones: “Cada 10 segundos”
- Qué solicitudes se incluyen: "HTTP GET de trabajos de monitoreo de caja negra"
- Cómo se obtienen los datos: “Gracias a nuestro seguimiento medido en el servidor”
- Latencia 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 comprendan lo que significa un determinado SLI.
Objetivos en la práctica
Empiece por pensar (¡o descubrir!) lo que les importa a sus usuarios, no lo que usted puede medir. A menudo, lo que les importa a los usuarios es difícil o imposible de medir, por lo que terminas acercándote a sus necesidades. Sin embargo, si comienza con lo que es fácil de medir, terminará con SLO menos útiles. Como resultado, a veces hemos descubierto que identificar inicialmente los objetivos deseados y luego trabajar con indicadores específicos funciona mejor que elegir indicadores y luego alcanzar los objetivos.
Definir metas
Para mayor claridad, se debe definir cómo se miden los SLO y las condiciones bajo las cuales son válidos. Por ejemplo, podríamos decir lo siguiente (la segunda línea es igual que la primera, pero usa los valores predeterminados de SLI):
- El 99 % (en promedio, más de 1 minuto) de las llamadas Get RPC se completarán en menos de 100 ms (medido en todos los servidores backend).
- 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 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 de trabajo heterogéneas: procesamiento masivo (para el cual el rendimiento es importante) y procesamiento interactivo (para el cual la latencia es importante), puede valer la pena definir objetivos separados para cada clase de carga:
- El 95% de las solicitudes de los clientes requieren rendimiento. Establezca el recuento de llamadas RPC ejecutadas <1 s.
- Al 99% de los clientes les importa la latencia. Establezca el recuento de llamadas RPC con tráfico <1 KB y en ejecución <10 ms.
No es realista ni deseable insistir en que los SLO se cumplan el 100 % del tiempo: esto puede reducir el ritmo de introducción de nuevas funcionalidades e implementación, y requerir soluciones costosas. En su lugar, es mejor permitir un presupuesto de error (el porcentaje de tiempo de inactividad del sistema permitido) y monitorear este valor diaria o semanalmente. La alta dirección puede querer evaluaciones mensuales o trimestrales. (El presupuesto de error es simplemente un SLO para compararlo con otro SLO).
El porcentaje de violaciones de SLO se puede comparar con el presupuesto de errores (consulte el Capítulo 3 y la sección ), y el valor de diferencia se utiliza como entrada para el proceso que decide cuándo implementar nuevas versiones.
Seleccionar valores objetivo
La selección de valores de planificación (SLO) no es una actividad puramente técnica debido al producto y los intereses comerciales que deben reflejarse en los SLI, SLO (y posiblemente SLA) seleccionados. Asimismo, es posible que sea 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. La SRE debería ser parte de esta conversación y ayudar a comprender los riesgos y la viabilidad de las diferentes opciones. Hemos planteado algunas preguntas que podrían ayudar a garantizar una discusión más productiva:
No elija una meta basada en el desempeño actual.
Si bien es importante comprender las fortalezas y los límites de un sistema, adaptar las métricas sin razonamiento puede impedirle mantener el sistema: requerirá esfuerzos heroicos para lograr objetivos que no se pueden lograr sin un rediseño significativo.
Mantenlo simple
Los cálculos SLI complejos pueden ocultar cambios en el rendimiento del sistema y dificultar la búsqueda de la causa del problema.
Evite los absolutos
Si bien resulta tentador tener un sistema que pueda manejar una carga en crecimiento indefinido sin aumentar la latencia, este requisito no es realista. Un sistema que se acerque a tales ideales probablemente requerirá mucho tiempo para diseñarlo y construirlo, será costoso de operar y será demasiado bueno para las expectativas de los usuarios que preferirían menos.
Utilice la menor cantidad de SLO posible
Seleccione una cantidad suficiente de SLO para garantizar una buena cobertura de los atributos del sistema. Proteja los SLO que elija: si nunca puede ganar una discusión sobre prioridades especificando un SLO específico, probablemente no valga la pena considerar ese SLO. Sin embargo, no todos los atributos del sistema son susceptibles de SLO: es difícil calcular el nivel de satisfacción del usuario utilizando SLO.
No persigas la perfección
Siempre puede refinar las definiciones y los objetivos de los SLO a lo largo del tiempo a medida que aprende más sobre el comportamiento del sistema bajo carga. Es mejor comenzar con una meta flotante que irás perfeccionando con el tiempo que elegir una meta demasiado estricta que tengas que relajar cuando descubras que es inalcanzable.
Los SLO pueden y deben ser un factor clave a la hora de priorizar el trabajo de los SRE y los desarrolladores de productos porque reflejan una preocupación por los usuarios. Un buen SLO es una herramienta de cumplimiento útil para un equipo de desarrollo. Pero un SLO mal diseñado puede generar un desperdicio de trabajo si el equipo hace esfuerzos heroicos para lograr un SLO demasiado agresivo, o un producto deficiente si el SLO es demasiado bajo. SLO es una palanca poderosa, úsela sabiamente.
Controla tus medidas
SLI y SLO son elementos clave utilizados para gestionar sistemas:
- Monitorizar y medir sistemas SLI.
- Compare SLI con SLO y decida si es necesario tomar medidas.
- Si se requiere acción, averigüe qué debe suceder para lograr el objetivo.
- Completa esta acción.
Por ejemplo, si el paso 2 muestra que la solicitud está agotando el tiempo de espera y romperá el SLO en unas horas si no se hace nada, el paso 3 podría implicar probar la hipótesis de que los servidores están vinculados a la CPU y agregar más servidores distribuirá la carga. Sin un SLO, no sabría si (o cuándo) tomar medidas.
Establezca SLO: luego se establecerán las expectativas del usuario
La publicación de un SLO establece las expectativas del usuario sobre el comportamiento del sistema. Los usuarios (y usuarios potenciales) a menudo quieren saber qué esperar de un servicio para saber si es adecuado para su uso. Por ejemplo, las personas que deseen utilizar un sitio web para compartir fotografías tal vez quieran evitar el uso de un servicio que promete longevidad y bajo costo a cambio de una disponibilidad ligeramente menor, aunque el mismo servicio podría ser ideal para un sistema de gestión de registros de archivos.
Para establecer expectativas realistas para sus usuarios, utilice una o ambas de las siguientes tácticas:
- Mantener un margen de seguridad. Utilice un SLO interno más estricto que el que se anuncia a los usuarios. Esto le dará la oportunidad de reaccionar ante los problemas antes de que se vuelvan visibles externamente. El búfer SLO también le permite tener un margen de seguridad al instalar versiones que afectan el rendimiento del sistema y garantiza que el sistema sea fácil de mantener sin tener que frustrar a los usuarios con el tiempo de inactividad.
- No exceda las expectativas del usuario. Los usuarios se basan en lo que ofreces, no en lo que dices. Si el rendimiento real de su servicio es mucho mejor que el SLO indicado, los usuarios confiarán en el rendimiento actual. Puede evitar la dependencia excesiva apagando intencionalmente el sistema o limitando el rendimiento bajo cargas ligeras.
Comprender qué tan bien un sistema cumple con las expectativas ayuda a decidir si se debe invertir en acelerar el sistema y hacerlo más accesible y resiliente. Alternativamente, si un servicio está funcionando demasiado bien, parte del tiempo del personal debería dedicarse a otras prioridades, como pagar la deuda técnica, agregar nuevas funciones o introducir nuevos productos.
Acuerdos en la práctica
La creación de un SLA requiere que los equipos comerciales y legales definan las consecuencias y sanciones por violarlo. El papel de la SRE es ayudarlos a comprender los posibles desafíos para cumplir los SLO contenidos en el SLA. La mayoría de las recomendaciones para crear SLO también se aplican a los SLA. Es aconsejable ser conservador en lo que promete a los usuarios porque cuanto más tenga, más difícil será cambiar o eliminar SLA que parezcan irrazonables o difíciles de cumplir.
Gracias por leer la traducción hasta el final. Suscríbete a mi canal de Telegram sobre monitoreo. и .
Fuente: habr.com