Indicadores de nivel de servicio (SLI) y objetivos de nivel de servicio (SLO)
Hasta ahora, hemos aprendido a mejorar el conocimiento de las operaciones, ampliar nuestro entendimiento y planteamiento de confiabilidad y hemos visto las herramientas de Azure Monitor que necesitamos para nuestro trabajo. Ahora exploraremos una de las ideas más importantes de este módulo y los procesos para implementarla.
Vamos a responder a la pregunta "¿cómo puedo usar todo esto para mejorar la confiabilidad en mi organización?".
Introducir el bucle de comentarios
Esta es la gran idea que puede desbloquear nuestro problema:
los bucles de comentarios adecuados mejoran la confiabilidad de la organización.
Mejorar la confiabilidad de la organización es un proceso iterativo. En esta unidad se examinará un procedimiento muy eficaz del mundo de la ingeniería de confiabilidad de sitios para crear y alimentar el tipo de bucle de comentarios en una organización que permite mejorar la confiabilidad. Como mínimo, surgirán determinadas conversaciones en la organización sobre la confiabilidad basada en datos objetivos.
En este módulo hemos mencionado esto como una definición de ingeniería de confiabilidad de sitios:
La ingeniería de confiabilidad de sitios es una disciplina de ingeniería que permite a una organización lograr el nivel adecuado de confiabilidad en sus sistemas, servicios y productos de manera sostenible.
Aquí es donde entra en juego el concepto de nivel de confiabilidad adecuado.
Indicadores de nivel de servicio (SLI)
Los indicadores de nivel de servicio (SLI) están relacionados con la descripción anterior sobre la comprensión de la confiabilidad. ¿Recuerda este diagrama?
Los SLI son nuestro intento de especificar solamente cómo vamos a medir la confiabilidad del sistema. ¿Cuál es el indicador de que nuestro servicio se comporta de forma confiable (es decir, funciona según lo esperado)? ¿Qué se puede medir para responder a esto?
Ejemplo: disponibilidad y latencia del servidor web
Supongamos que estamos trabajando con un servidor web y su disponibilidad. Es posible que nos interese el número de solicitudes HTTP recibidas y el número de solicitudes HTTP que respondió correctamente. Concretamente, queremos saber si ha funcionado bien como servidor web. Para ello, necesitamos conocer la proporción de solicitudes correctas con respecto al número total de solicitudes.
Si dividimos el número total de solicitudes por el número de solicitudes correctas, obtenemos una relación. Podemos multiplicar esta proporción por 100 para obtener un porcentaje. Para ver un ejemplo con números redondeados, si nuestro servidor web ha recibido 100 solicitudes y ha respondido correctamente a 80 de ellas, tendremos una proporción de 0,8. Si la multiplicamos por 100, podemos indicar que ha estado disponible un 80 %.
Vamos a ver otro ejemplo. Esta vez vamos a especificar una medida asociada a la latencia de nuestro servicio web. Puede interesarnos conocer la proporción entre el número de operaciones que se completaron en menos de 10 milisegundos con respecto al número total de operaciones. Si hacemos el mismo cálculo (total de 100 solicitudes divididas entre 80 solicitudes que se devolvieron más rápido que nuestro umbral), obtenemos de nuevo una proporción de 0,8. Si la multiplicamos por 100, podemos decir también que habremos superado el 80 % de los requisitos de latencia con esta medida.
Para ser claros: esto no es solo un tema del sitio web. Si hubiera un servicio de canalización que procesara datos, se podría decir que es necesario medir la cobertura (por ejemplo, qué proporción de los datos se han procesado). Es un sistema muy diferente, pero se trata del mismo cálculo básico.
SLI: dónde medir
Para que los SLI sean útiles en análisis concretos basados en datos objetivos, hay otro elemento que debemos especificar más allá de lo que se esté midiendo. Al crear un SLI, tenemos que apuntar no solo lo que se midió, sino también dónde se midió.
Por ejemplo, cuando especificamos que estábamos midiendo la disponibilidad del servidor web mencionado antes, no indicamos de dónde habíamos obtenido las cifras de solicitud HTTP correctas y totales. Si intenta tener una conversación sobre la confiabilidad de este servidor web con algunos compañeros y se fija en las estadísticas de solicitud recopiladas en un equilibrador de carga delante del servidor, pero ellos observan las estadísticas del propio servidor, es posible que esta conversación no vaya por buen camino. Las cifras podrían ser totalmente diferentes porque el equilibrador de carga puede que vea todas las solicitudes que entran en la red, pero si hubiera un problema con la red o el propio equilibrador de carga, es posible que no todas las solicitudes lleguen al servidor. Estaríamos sacando conclusiones basadas en dos conjuntos de datos diferentes.
La forma más sencilla de solucionarlo es especificar claramente el origen de los datos en el SLI. En el caso del servidor web, lo expresaríamos así para la disponibilidad: "la proporción de solicitudes realizadas correctamente con respecto al total de solicitudes según la medición del equilibrador de carga". Para la latencia, sería algo así como "la proporción del número de operaciones que se completaron en menos de 10 milisegundos con respecto al total de operaciones según la medición del cliente".
Esto nos plantea esta pregunta lógica: ¿cuál es el mejor sitio para medir SLI? Por desgracia, no hay una respuesta "correcta" universal. Se trata de una decisión que debe tomar sabiendo que, de que cualquier manera, existen soluciones intermedias. Una de las recomendaciones que podemos ofrecer no es otra cosa que repetir nuestra explicación anterior sobre la confiabilidad: intente medir las cosas en un lugar que refleje con la mayor precisión posible la experiencia del cliente.
Objetivos de nivel de servicio (SLO)
Decidir qué medir (y dónde) es un buen comienzo, pero solo nos permite avanzar hasta la mitad de nuestro objetivo. Supongamos que recuperamos las métricas que necesitamos para el SLI de disponibilidad de nuestro servidor web y vemos que realmente tuviera una disponibilidad del 80 %.
¿Esto es algo bueno o malo? ¿Es el "nivel adecuado de confiabilidad"?
Para responder a estas preguntas, será necesario establecer un objetivo para ese SLI: un objetivo de nivel de servicio (SLO). Este objetivo indicará claramente nuestro objetivo para ese servicio.
La receta básica para crear un SLO se compone de estos ingredientes:
Lo que se va a medir: número de solicitudes, comprobaciones de almacenamiento, operaciones; lo que se está midiendo.
La proporción que quiera: por ejemplo, "operaciones correctas el 50 % del tiempo", "puede leer el 99,9 % del tiempo" y "devuelve resultados en 10 ms del 90 % del tiempo".
El horizonte temporal: ¿cuál es el período de tiempo que se va a considerar para el objetivo, los últimos 10 minutos, el último trimestre o un período móvil de 30 días? Con frecuencia, los SLO se especifican con un período móvil, en lugar de una unidad del calendario, como por ejemplo "un mes", para que podamos comparar datos de distintos períodos.
Al agrupar estos componentes e incluir la información importante sobre dónde, un SLO de ejemplo podría ser similar a este:
El 90 % de las solicitudes HTTP detectadas por el equilibrador de carga se realizaron correctamente en un período de los últimos 30 días.
Del mismo modo, una latencia de medición de SLO básica podría ser similar a esta:
El 90 % de las solicitudes HTTP detectadas por el cliente han devuelto resultados en menos de <20 ms en un período de los últimos 30 días.
Empiece usando SLO básicos y sencillos como estos cuando introduzca esta práctica en la organización. Si es necesario, puede crear SLO más complejos.
SLI y SLO en Azure Monitor
Como parte final de esta unidad, veamos cómo podemos representar un simple SLI/SLO en Azure Monitor mediante Log Analytics. Para mantener las cosas coherentes, volveremos al ejemplo del servidor web.
En la última unidad ha visto que se pueden crear consultas en Log Analytics mediante el lenguaje de consulta de Kusto (KQL). Esta una consulta de KQL en la que se muestra un SLI de disponibilidad para un servicio web:
requests
| where timestamp > ago(30d)
| summarize succeed = count (success == true), failed = count (success == false), total = count() by bin(timestamp, 5m)
| extend SLI = succeed * 100.00 / total
| project SLI, timestamp
| render timechart
Como antes, primero se especifica el origen de los datos: la tabla requests. Después limitaremos los datos con los que trabajaremos a los últimos 30 días de información. Después, se recopilan (en cubos de cinco minutos) el número de solicitudes correctas, el número de solicitudes con error y el número total de solicitudes. El SLI se crea con la aritmética sencilla que vimos antes. Indicamos a KQL que nos gustaría trazar ese SLI junto con marcas de tiempo y, después, crear un gráfico que tenga un aspecto similar a este:
Ahora, vamos a mostrar una representación simple de un SLO:
requests
| where timestamp > ago(5h)
| summarize succeed = count (success == true), failed = count (success == false), total = count() by bin(timestamp, 5m)
| extend SLI = succeed * 100.00 / total
| extend SLO = 80.0
| project SLI, timestamp, SLO
| render timechart
En este ejemplo han cambiado dos líneas con respecto al ejemplo anterior. La primera define el número que se usará para el SLO; la segunda indica a KQL que el SLO debería incluirse en el gráfico. El resultado tiene el aspecto siguiente:
En este gráfico es fácil ver el tiempo que estuvimos por debajo de nuestro objetivo de disponibilidad.
Usar SLI/SLO
Invariablemente, habrá que realizar un cierto ajuste con los SLI y los SLO (después de todo, se trata de un proceso iterativo). Pero después de hacerlo, ¿qué hay que hacer con la información?
La buena noticia es que probablemente notará que solo con crear los SLI y los SLO conseguirá efectos positivos en la organización. Será necesario analizarlo con las partes implicadas y tratar otros aspectos para llevar las cosas por buen camino. La siguiente ronda de análisis sobre qué hacer con ellos también puede resultar útil.
En última instancia, los SLI y los SLO son herramientas de planificación del trabajo. Pueden ayudarle a tomar decisiones técnicas del tipo "¿se debería trabajar para introducir nuevas características al servicio o mejor centrarse en la confiabilidad?". Pueden ser útiles con el tipo de bucles de comentarios descritos anteriormente.
Otro uso secundario pero bastante común de los SLI y los SLO es como parte de un sistema de supervisión y respuesta más inmediato. Además del aspecto de la planificación del trabajo (en el que debería centrarse primero), muchos usuarios los utilizan como una señal de operaciones. Por ejemplo, podrían optar por avisar al personal si el servicio cayera por debajo de su SLO durante un período de tiempo prolongado. Ese tipo de alerta nos lleva a la siguiente unidad de este módulo.