Service Level Objective (SLO)

Continuando con el contenido de la charla sobre Site Reliability Engineering (SRE) que presenté en GDG Vitoria, el siguiente apartado habla de objetivos de nivel de servicio, Service Level Objective (SLO). Vuelvo a insertar las slides por si queréis seguir el artículo acompañándolo de la presentación.

Site Reliability Engineering

¿Qué intentamos solucionar?

Si se trata de medir la fiabilidad del servicio, de comprender si está funcionando correctamente, podríamos argumentar que ya tenemos toda esa información en dashboards con métricas de uso de CPU o de memoria, de usuarios conectados al servicio, latencias, etc… y sí, es cierto. Sin embargo, estos dashboards tienen un problema: ¿alguien se atrevería a asegurar si el sistema está funcionando correctamente con un dashboard como este?

System metrics dashboard

Sin tener un conocimiento en detalle sobre el servicio es difícil decir si tener 2.15M de claves en Redis es o no un comportamiento normal, o cuáles serían las consecuencias de un valor anómalo. Estamos leyendo 76.60M de registros de la base de datos, pero eso tampoco nos dice nada sobre la salud del servicio o cómo de saturado se encuentra. Y parece que ha crecido un poco el throughput desde las 13:30, pero ni idea de si eso está dentro de lo esperable. Tenemos algunos indicadores en verde en la parte superior, así que podemos imaginar que la cosa va bien, pero si estuvieran en rojo tampoco sabríamos cuál es el impacto sobre los usuarios o la gravedad de esa desviación, sólo que algo parece estar mal.

El problema de este dashboard es que no nos habla de la experiencia que los usuarios están teniendo con nuestro servicio, si no que nos da un montón de detalles técnicos para cuya interpretación necesitamos conocer el servicio en profundidad.

Por otro lado, si tenemos configuradas alertas basadas en estas métricas, es posible que recibamos alertas por un incremento del uso de CPU que puede ser normal bajo determinadas circunstancias. Pensemos en un proceso en lote que genera toda la facturación de la empresa a las tres de la mañana, cuando no hay tráfico en el sitio. Ese procesamiento supondrá un pico importante en el uso de CPU y memoria que alertará a quien esté de guardia, cuando en realidad ningún usuario se está viendo afectado por ese proceso que, además, finalizará en un par de horas volviendo al estado normal del sistema.

Buscando un mejor dashboard

Veamos a continuación otro tipo de dashboard, y por qué creemos que es un poco mejor que el anterior.

SLO dashboard

En este dashboard sabemos que estamos hablando del proceso de compra de un e-commerce. Y fijándonos en el lado izquierdo, vemos también que el ratio de peticiones servidas correctamente y la latencia con la que estamos dando respuesta a los usuarios parecen correctas. Además, bajo cada indicador, tenemos una estimación del ratio de error que asumimos como normal que aún no hemos consumido. Incluso sin conocer el servicio, podemos asegurar que todo está funcionando bien y que si hubiera algún error aún estaría dentro del margen operativo normal. Y conoceríamos también la afectación a los usuarios: no están pudiendo completar la compra, o el proceso está siendo tan lento que podría hacer que decidieran llevarse su dinero a otra parte.

Si basamos nuestras alertas en este dashboard despertaremos a quien esté de guardia a las tres de la mañana porque realmente tenemos un problema grave: los usuarios no pueden comprar, o la experiencia de compra que están teniendo es suficientemente frustrante para que decidan irse a otro lado.

Este tipo de dashboards de SLO no sustituyen a los anteriores. Los dashboards de objetivo de nivel de servicio nos hablan de los síntomas y cómo están afectando a los usuarios. Una vez que sabemos que la latencia está por encima del objetivo, podemos recurrir a dashboards más técnicos para comprender las causas raíz de ese mal comportamiento del sistema.

Indicadores, Objetivos, Acuerdos

Indicadores de nivel de servicio (SLI)

Si vamos a establecer un objetivo, tenemos que tener un indicador para ese objetivo. Los indicadores de nivel de servicio, o service level indicators (SLI), son medidas cuantificables de la fiabilidad de una capacidad concreta de nuestro servicio. Los expresamos como el ratio entre eventos correctos frente a eventos válidos, resultando en un valor entre cero y uno.

SLI = \frac{good}{valid}

Especificación de indicadores

Qué es un evento válido depende de lo que estemos tratando de medir: si hablamos de la disponibilidad de un endpoint de una API, un evento válido podría ser cualquier petición a un endpoint existente con un método HTTP correcto. Y, con ese mismo ejemplo, un evento correcto podría ser una respuesta HTTP que no sea un error interno 5xx.

Usando estos valores obtenemos un ratio entre peticiones válidas a nuestra API y respuestas correctas a los clientes que estará siempre entre cero (todos los eventos de respuesta han fallado, todo está caído) y uno (todos los eventos de respuesta han sido correctos, todo está funcionando perfectamente). Que todos los indicadores de la salud de nuestro servicio se encuentren en este rango nos hace más fácil razonar sobre ellos y, además, nos permite automatizar algunas integraciones.

Implementación de indicadores

Si ya sabemos lo que queremos medir, a continuación tenemos que pensar en cómo medirlo: pasar de la especificación a la implementación. A la hora de medir esa latencia, ¿lo hacemos con la instrumentación que ya tenemos en la aplicación? ¿A través de las métricas del balanceador de carga? ¿En el dispositivo del cliente?

Cada una de estas aproximaciones tiene ventajas y desventajas: cuanto más nos alejamos del usuario menos precisas son nuestras métricas, pero resulta algo más sencillo implementarlas. Por otro lado, si nos vamos demasiado cerca del usuario tendremos la mejor precisión, pero estaremos introduciendo otras consideraciones para las que es posible que no podamos hacer nada (disponibilidad o latencia de la red del operador del cliente, por ejemplo). Algunas implementaciones pueden, además, dar una falsa sensación de seguridad: puede que todo esté correcto a nivel de aplicación, pero nuestro balanceador de carga esté caído y el cliente no esté viendo nada.

Podemos establecer varias implementaciones para una misma especificación de SLI para intentar equilibrar la balanza y definir así un SLI compuesto:

  • % de peticiones válidas servidas en menos de 100ms, medidas en la aplicación
  • % de peticiones válidas servidas en menos de 150ms, medidas en el balanceador de carga

¿De dónde hemos sacado esos 100/150ms? De nuestro conocimiento previo sobre el servicio o sobre la satisfacción de nuestros usuarios, o de nuestra aspiración. Revisaremos nuestros SLI con el tiempo, por lo que no importa tanto no acertar a la primera como tener un punto de partida.

Categorías de indicadores

Como pensar en cuáles son los SLI a los que queremos prestar atención puede ser una tarea ardua, definir algunas categorías puede ayudarnos a pensar en ello.

  • Petición/Respuesta
    • Disponibilidad: % de peticiones válidas servidas correctamente
    • Latencia: % de peticiones válidas servidas en menos de X tiempo
    • Calidad: % de peticiones válidas servidas sin degradar la respuesta
  • Datos
    • Cobertura: % de datos válidos procesados correctamente
    • Frescura: % de datos válidos procesados más recientemente que X tiempo
    • Corrección: % de datos válidos que han producido el resultado correcto
  • Almacenamiento:
    • Durabilidad: % de datos escritos que pueden ser leídos correctamente

Algunas de estas categorías pueden ser especialmente difíciles de definir, como la corrección, otras son por lo general mucho más fáciles de determinar como la disponibilidad y la latencia. Como consejo general si empezáis a aplicar SLOs, empezad por los más sencillos hasta que tengáis suficiente soltura para complicaros la vida. Os evitaréis mucha frustración y podréis empezar a ver resultados antes.

Aseguraos de contar siempre con la participación del responsable de producto en la definición de SLI, porque estos deberían ser medidores razonables de la satisfacción de nuestros usuarios.

Objetivos de nivel de servicio (SLO)

Una vez que conocemos los indicadores que vamos a usar, es hora de fijar un objetivo de fiabilidad para ellos. Definimos un SLO, Service Level Objective, como el objetivo para los indicadores definidos agregados a lo largo de una ventana deslizante de tiempo.

  • SLI: % peticiones válidas servidas en menos de 100ms, medidas en el load balancer.
  • SLO: 99.5% peticiones válidas servidas en menos de 100ms, medidas en el load balancer, en una ventana deslizante de 30 días.

El objetivo que fijemos, del 99.5% en este caso, se basa en nuestra experiencia pasada con el servicio o lo que conocemos sobre el límite de satisfacción de nuestros usuarios, balanceado con el coste y esfuerzo que supone alcanzar ese objetivo.

¿Por qué no fijar un objetivo del 100%? ¿No sería lo ideal? Pues el hecho es que no: 100% es el objetivo incorrecto de fiabilidad para prácticamente cualquier cosa.

Valores mayores de fiabilidad suponen invertir más en infraestructura, replicar sistemas, destinar más recursos a la resolución rápida de incidencias… el coste y esfuerzo crecen de manera exponencial con la fiabilidad. Por otro lado, la inmensa mayoría de nuestros usuarios no apreciarán una diferencia entre el 99.9% y el 99.99% de fiabilidad. Nos interesa ser tan fiables como sea necesario, pero no más.

Al igual que con los SLI, debemos involucrar a la gente de producto en esta decisión: los objetivos fijados giran entorno a la satisfacción de los usuarios, y las conclusiones a las que lleguemos constituirán un acuerdo de equipo para el que queremos tener un consenso claro.

Acuerdos de nivel de servicio (SLA)

Un SLA, Service Level Agreement, es un acuerdo con nuestros usuarios sobre el nivel servicio que nos comprometemos a cumplir, y las consecuencias que tendrá incumplir este límite.

Los SLO nos sirven a nosotros para razonar sobre la salud del sistema, son un compromiso interno de fiabilidad. Si fallamos en su cumplimiento revaluamos nuestro trabajo para dedicar más esfuerzo a la fiabilidad. Los SLA, en cambio, son un compromiso externo: si fallamos en su cumplimiento podemos enfrentar consecuencias legales, compensaciones económicas o de algún otro tipo.

No resulta muy difícil imaginar por qué los SLO deberían ser siempre más restrictivos que los SLA: queremos que nuestro sistema nos advierta de cualquier problema de fiabilidad antes de que lleguemos al punto en el que ponemos en peligro el acuerdo de nivel servicio pactado con nuestros usuarios.

  • SLI: % peticiones válidas servidas en menos de 100ms, medidas en el load balancer.
  • SLO: 99.5% peticiones válidas servidas en menos de 100ms, medidas en el load balancer, en una ventana deslizante de 30 días.
  • SLA: 99% peticiones válidas servidas en menos de 100ms, medidas en el load balancer, en una ventana deslizante de 30 días. En caso de incumplimiento, se compensará con créditos de servicio.

Son los usuarios, amigo

Todo en SRE gira entorno a los usuarios y su satisfacción con el uso de nuestro servicio. Los Service Level Indicator (SLI) que fijemos deben medir de forma razonable esta satisfacción. Los Service Level Objective (SLO) que marquemos suponen la diferencia entre tener usuarios felices con el comportamiento del servicio a decepcionarles entregando una calidad de servicio insuficiente. Y si continuamos degradando la fiabilidad, acabaremos con usuarios cabreados al superar el límite fijado por nuestro Service Level Agreement (SLA), y potencialmente enfrentándonos a consecuencias legales o compensaciones de cualquier tipo.

Satisfacción de los usuarios y fiabilidad

Por esto es tan importante tener siempre en mente la experiencia de usuario y contar con la participación de quienes toman más responsabilidad en el enlace con ellos, los responsables de producto.

Y, si decimos que el objetivo no es no tener nunca caídas de servicio si no maximizar la velocidad de desarrollo dentro de los límites de error establecidos, ¿cómo definimos este presupuesto de error? ¡Lo veremos en el siguiente artículo!

Por ahora, si quieres aprender más sobre SRE y cómo definir los objetivos de nivel de servicio, puedes echar un vistazo a estos libros:

Si te ha gustado este artículo, ¿qué te parece ayudarme a seguir escribiendo?


1

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.