2. Implementando SLOs

Por Steven Thurgood y David Ferguson con Alex Hidalgo y Betsy Beyer

Los objetivos de nivel de servicio (SLO) especifican un nivel objetivo para la fiabilidad de su servicio. Dado que los SLO son la clave para tomar decisiones basadas en datos sobre la fiabilidad, son el núcleo de las prácticas de SRE. En muchos sentidos, este es el capítulo más importante de este libro.

Una vez que esté equipado con algunas directrices, establecer los SLO iniciales y un proceso para refinarlos puede ser sencillo. El capítulo 4 de nuestro primer libro introducía el tema de los SLO y los SLI (indicadores de nivel de servicio) y daba algunos consejos sobre cómo utilizarlos.

Tras hablar de la motivación de los SLO y los presupuestos de errores, este capítulo ofrece una receta paso a paso para empezar a pensar en los SLO, así como algunos consejos sobre cómo iterar a partir de ahí. A continuación, veremos cómo utilizar los SLO para tomar decisiones empresariales eficaces y exploraremos algunos temas avanzados. Por último, le daremos algunos ejemplos de SLO para diferentes tipos de servicios y algunos consejos sobre cómo crear SLO más sofisticados en situaciones específicas.¹⁾

Los ingenieros son un recurso escaso incluso en las organizaciones más grandes. El tiempo de ingeniería debe invertirse en las características más importantes de los servicios más importantes. Es difícil encontrar el equilibrio adecuado entre invertir en funcionalidades que ganen nuevos clientes o retengan a los actuales, e invertir en la fiabilidad y la escalabilidad que mantengan a esos clientes satisfechos. En Google, hemos aprendido que un SLO bien pensado y adoptado es clave para tomar decisiones basadas en datos sobre el costo de oportunidad del trabajo de fiabilidad, y para determinar cómo priorizar adecuadamente ese trabajo.

Las principales responsabilidades de los SRE no se limitan a automatizar “todas las cosas” y sujetar el localizador. Sus tareas y proyectos cotidianos están impulsados por las SLO: garantizar que las SLO se defienden a corto plazo y que pueden mantenerse a medio y largo plazo. Se podría incluso afirmar que sin SLO no hay necesidad de SRE.

Los SLO son una herramienta que ayuda a determinar qué trabajo de ingeniería hay que priorizar. Por ejemplo, consideremos las compensaciones de ingeniería para dos proyectos de fiabilidad: automatizar las reversiones y pasar a un almacén de datos replicado. Calculando el impacto estimado en nuestro presupuesto de errores, podemos determinar qué proyecto es más beneficioso para nuestros usuarios. Consulte la sección “Toma de decisiones mediante SLO y presupuestos de errores” para obtener más detalles al respecto, y “Gestión de riesgos” en Site Reliability Engineering.

Como punto de partida para establecer un conjunto básico de SLO, supongamos que su servicio es algún tipo de código que ha sido compilado y liberado y que se ejecuta en una infraestructura en red a la que los usuarios acceden a través de la web. El nivel de madurez de su sistema podría ser uno de los siguientes:

• Un desarrollo greenfield, sin nada desplegado actualmente

• Un sistema en producción con algún tipo de supervisión para notificarle cuando las cosas van mal, pero sin objetivos formales, sin concepto de presupuesto de errores y con un objetivo tácito de tiempo de actividad del 100%.

• Un despliegue en marcha con un SLO por debajo del 100%, pero sin un entendimiento común sobre su importancia o sobre cómo aprovecharlo para tomar decisiones de mejora continua; en otras palabras, un SLO sin dientes.

Con el fin de adoptar un enfoque basado en el presupuesto de errores para la Ingeniería de Fiabilidad del Sitio, es necesario llegar a un estado en el que lo siguiente sea cierto:

• Existen SLO que todas las partes interesadas de la organización han aprobado como adecuados para el producto.

• Las personas responsables de garantizar que el servicio cumple su SLO han acordado que es posible cumplir este SLO en circunstancias normales.

• La organización se ha comprometido a utilizar el presupuesto de errores para tomar decisiones y establecer prioridades. Este compromiso se formaliza en una política de presupuesto de errores.

• Existe un proceso para perfeccionar el SLO.

De lo contrario, no podrá adoptar un enfoque de la fiabilidad basado en el presupuesto de errores. El cumplimiento de la SLO será simplemente otro KPI (indicador clave de rendimiento) o métrica de información, en lugar de una herramienta de toma de decisiones.

El primer paso para formular unos SLO adecuados es hablar de lo que debe ser un SLO y de lo que debe abarcar.

Un SLO establece un nivel objetivo de fiabilidad para los clientes del servicio. Por encima de este umbral, casi todos los usuarios deberían estar satisfechos con el servicio (suponiendo que, por lo demás, estén satisfechos con la utilidad del servicio).²⁾ Por debajo de este umbral, es probable que los usuarios empiecen a quejarse o dejen de utilizar el servicio. En última instancia, la felicidad del usuario es lo que importa: los usuarios satisfechos utilizan el servicio, generan ingresos para su organización, exigen poco a sus equipos de atención al cliente y recomiendan el servicio a sus amigos. Mantenemos la fiabilidad de nuestros servicios para que nuestros clientes estén contentos.

La felicidad del cliente es un concepto bastante difuso; no podemos medirlo con precisión. A menudo tenemos muy poca visibilidad sobre ella, así que ¿cómo empezamos? ¿Qué utilizamos para nuestro primer SLO?

Nuestra experiencia nos ha demostrado que una fiabilidad del 100% es un objetivo equivocado:

• Si su SLO está alineado con la satisfacción del cliente, el 100% no es un objetivo razonable. Incluso con componentes redundantes, comprobación de estado automatizada y conmutación por error rápida, existe una probabilidad distinta de cero de que uno o más componentes fallen simultáneamente, lo que se traduce en una disponibilidad inferior al 100%.

• Incluso si pudiera lograr una fiabilidad del 100% en su sistema, sus clientes no experimentarían una fiabilidad del 100%. La cadena de sistemas entre usted y sus clientes suele ser larga y compleja, y cualquiera de estos componentes puede fallar.³⁾ Esto también significa que a medida que se pasa del 99% al 99.9% y al 99.99% de fiabilidad, cada nueve extra tiene un coste mayor, pero la utilidad marginal para sus clientes se acerca progresivamente a cero.

• Si consigue crear una experiencia 100% fiable para sus clientes y quiere mantener ese nivel de fiabilidad, nunca podrá actualizar o mejorar su servicio. La principal fuente de interrupciones es el cambio: la introducción de nuevas funciones, la aplicación de parches de seguridad, la instalación de nuevo hardware y la ampliación para satisfacer la demanda de los clientes afectarán a ese objetivo del 100%. Tarde o temprano, su servicio se estancará y sus clientes se irán a otra parte, lo que no es bueno para los resultados de nadie.

• Un SLO del 100% significa que sólo tiene tiempo para reaccionar. Literalmente, no puedes hacer otra cosa que reaccionar ante una disponibilidad < 100%, lo que está garantizado que ocurra. La fiabilidad del 100% no es un SLO de la cultura de ingeniería, es un SLO del equipo de operaciones.

Una vez que tenga un objetivo de SLO por debajo del 100%, debe ser propiedad de alguien de la organización que esté facultado para hacer concesiones entre la velocidad de las características y la fiabilidad. En una organización pequeña, puede ser el director de tecnología; en organizaciones más grandes, suele ser el propietario del producto (o el gestor del producto).

Una vez acordado que el 100% es una cifra errónea, ¿cómo se determina la cifra correcta? ¿Y qué se mide? Aquí entran en juego los indicadores de nivel de servicio: un SLI es un indicador del nivel de servicio que se está prestando.

Aunque muchas cifras pueden funcionar como un SLI, generalmente recomendamos tratar el SLI como el cociente de dos cifras: el número de incidencias buenas dividido por el número total de incidencias. Por ejemplo:

• Número de solicitudes HTTP completadas con éxito / total de solicitudes HTTP (tasa de éxito)

• Número de llamadas gRPC que se completaron con éxito en < 100 ms / total de solicitudes gRPC

• Número de resultados de búsqueda que utilizaron todo el corpus / número total de resultados de búsqueda, incluidos los que se degradaron con elegancia

• Número de solicitudes de “recuento de comprobación de existencias” de búsquedas de productos que utilizaron datos de existencias más recientes de 10 minutos / número total de solicitudes de comprobación de existencias

• Número de “buenos minutos de usuario” según alguna lista ampliada de criterios para esa métrica / número total de minutos de usuario

Los SLI de esta forma tienen un par de propiedades especialmente útiles. El SLI oscila entre el 0% y el 100%, donde 0% significa que nada funciona y 100% que nada está roto. Esta escala nos ha parecido intuitiva, y este estilo se presta fácilmente al concepto de presupuesto de errores: el SLO es un porcentaje objetivo y el presupuesto de errores es el 100% menos el SLO. Por ejemplo, si se tiene un SLO del 99.9% de índice de éxito, entonces un servicio que recibe 3 millones de peticiones durante un periodo de cuatro semanas tiene un presupuesto de 3.000 (0.1%) errores durante ese periodo. Si una sola interrupción es responsable de 1,500 errores, ese error cuesta el 50% del presupuesto para errores.⁴⁾

Además, hacer que todos sus SLI sigan un estilo coherente le permite aprovechar mejor las herramientas: puede escribir la lógica de alerta, las herramientas de análisis de SLO, el cálculo del presupuesto de errores y los informes para esperar las mismas entradas: numerador, denominador y umbral. La simplificación es una ventaja.

Cuando intente formular SLIs por primera vez, puede resultarle útil dividirlos en especificación SLI e implementación SLI:

Especificación SLI

La evaluación del resultado del servicio que usted considera importante para los usuarios, independientemente de cómo se mida.

Por ejemplo: Índice de solicitudes de páginas de inicio que se cargan en < 100 ms

Implementación de SLI

La especificación SLI y una forma de medirla.

Por ejemplo:

• Tasa de solicitudes de páginas de inicio que se cargan en menos de 100 ms, medida a partir de la columna Latencia del registro del servidor. Esta medición no tendrá en cuenta las peticiones que no lleguen al backend.

• Tasa de solicitudes de páginas de inicio que se cargan en < 100 ms, medida por sondas que ejecutan JavaScript en un navegador que se ejecuta en una máquina virtual. Esta medición detectará errores cuando las solicitudes no puedan llegar a nuestra red, pero puede pasar por alto problemas que afecten sólo a un subconjunto de usuarios.

• Tasa de solicitudes de páginas de inicio que se cargan en menos de 100 ms, medido mediante la instrumentación de JavaScript en la propia página de inicio y comunicado a un servicio de grabación telemétrica dedicado. Esta medición reflejará con mayor precisión la experiencia del usuario, aunque ahora tenemos que modificar el código para obtener esta información y crear la infraestructura para registrarla, una especificación que tiene sus propios requisitos de fiabilidad.

Como se puede ver, una única especificación SLI puede tener múltiples implementaciones SLI, cada una con su propio conjunto de pros y contras en términos de calidad (con qué precisión capturan la experiencia de un cliente), cobertura (qué tan bien capturan la experiencia de todos los clientes) y costo.

Su primer intento de SLI y SLO no tiene por qué ser correcto; el objetivo más importante es poner algo en marcha y medirlo, y establecer un bucle de retroalimentación para poder mejorar. (Profundizamos en este tema en “Mejora continua de los objetivos SLO”).

En nuestro primer libro, desaconsejamos elegir un SLO basado en el rendimiento actual, porque esto puede comprometerte a SLO innecesariamente estrictos. Aunque este consejo es cierto, el rendimiento actual puede ser un buen punto de partida si no se dispone de más información y si se cuenta con un buen proceso de iteración (del que hablaremos más adelante). Sin embargo, no deje que el rendimiento actual le limite a medida que refina su SLO: sus clientes también esperarán que su servicio funcione a su SLO, por lo que si su servicio devuelve con éxito el 99.999% de las solicitudes en menos de 10 ms, cualquier regresión significativa de esa línea de base puede hacerlos infelices.

Para crear su primer conjunto de SLOs, necesita decidir sobre unas pocas especificaciones SLI clave que sean importantes para su servicio. Los SLO de disponibilidad y latencia son bastante comunes; los SLO de frescura, durabilidad, corrección, calidad y cobertura también tienen su lugar (hablaremos más sobre ellos más adelante).

Si tiene problemas para saber con qué tipo de SLI empezar, le resultará útil empezar por lo más sencillo:

• Elija una aplicación para la que desee definir los SLI. Si su producto comprende muchas aplicaciones, puede añadirlas más adelante.

• Decida claramente quiénes son los “usuarios” en esta situación. Son las personas cuya felicidad está optimizando.

• Tenga en cuenta las formas habituales en que los usuarios interactúan con el sistema: tareas habituales y actividades críticas.

• Dibuje un diagrama de arquitectura de alto nivel de su sistema; muestre los componentes clave, el flujo de peticiones, el flujo de datos y las dependencias críticas. Agrupe estos componentes en las categorías que se enumeran en la sección siguiente (puede haber cierto solapamiento y ambigüedad; utilice su intuición y no deje que lo perfecto sea enemigo de lo bueno).

Debe pensar detenidamente qué es exactamente lo que selecciona como SLI, pero tampoco debe complicar demasiado las cosas. Especialmente si acaba de iniciar su andadura en el SLI, elija un aspecto de su sistema que sea relevante pero fácil de medir: siempre puede iterar y perfeccionar más adelante.

Tipos de componentes

La forma más sencilla de empezar a configurar los SLI es dividir el sistema en unos cuantos tipos de componentes comunes. A continuación, puede utilizar nuestra lista de SLI sugeridos para cada componente para elegir los más relevantes para su servicio:

Dirigido por peticiones
El usuario crea algún tipo de evento y espera una respuesta. Por ejemplo, podría tratarse de un servicio HTTP en el que el usuario interactúa con un navegador o una API para una aplicación móvil.

Tubería
Un sistema que toma registros como entrada, los muta y coloca la salida en otro lugar. Puede tratarse de un proceso sencillo que se ejecuta en una única instancia en tiempo real, o de un proceso por lotes de varias etapas que tarda muchas horas. Algunos ejemplos son:

• Un sistema que lee periódicamente datos de una base de datos relacional y los escribe en una tabla hash distribuida para un servicio optimizado.

• Un servicio de procesamiento de vídeo que convierte vídeo de un formato a otro.

• Un sistema que lee archivos de registro de varias fuentes para generar informes.

• Un sistema de monitorización que extrae métricas de servidores remotos y genera series temporales y alertas.

Almacenamiento
Un sistema que acepta datos (por ejemplo, bytes, registros, archivos, vídeos) y los pone a disposición para ser recuperados en una fecha posterior.

Considera una arquitectura simplificada para un juego de celular, ilustrada en la Figura 2-1.

Figura 2-1. Arquitectura de un ejemplo de juego para teléfonos celulares

La aplicación que se ejecuta en el teléfono del usuario interactúa con una API HTTP que se ejecuta en la nube. La API escribe los cambios de estado en un sistema de almacenamiento permanente. Periódicamente se ejecuta un proceso sobre estos datos para generar tablas de clasificación que proporcionan las puntuaciones más altas de hoy, de esta semana y de todos los tiempos. Estos datos se escriben en un almacén de datos de tablas de clasificación independiente, y los resultados están disponibles a través de la aplicación móvil (para puntuaciones en el juego) y de un sitio web. Los usuarios pueden subir a la tabla de datos de usuario avatares personalizados, que se utilizan tanto en el juego a través de la API como en el sitio web de puntuaciones más altas.

Con esta configuración, podemos empezar a pensar en cómo interactúan los usuarios con el sistema y qué tipo de SLI mediría los distintos aspectos de la experiencia de un usuario.

Algunos de estos SLIs pueden solaparse: un servicio basado en peticiones puede tener un SLI de corrección, un pipeline puede tener un SLI de disponibilidad, y los SLIs de durabilidad pueden verse como una variante de los SLIs de corrección. Recomendamos elegir un número reducido (cinco o menos) de tipos de SLI que representen la funcionalidad más crítica para sus clientes.

Con el fin de capturar tanto la experiencia típica del usuario como la larga cola, también recomendamos utilizar múltiples grados de SLI para algunos tipos de SLI. Por ejemplo, si el 90% de las peticiones de los usuarios vuelven en 100 ms, pero el 10% restante tarda 10 segundos, muchos usuarios estarán descontentos. Un SLI de latencia puede captar esta base de usuarios estableciendo varios umbrales: el 90% de las peticiones son más rápidas de 100 ms, y el 99% de las peticiones son más rápidas de 400 ms. Este principio se aplica a todos los SLI con parámetros que miden el descontento de los usuarios.

La Tabla 2-1 proporciona algunos SLI comunes para diferentes tipos de servicios.

Tabla 2-1. Posibles SLI para distintos tipos de componentes

Ahora que ya conocemos nuestras especificaciones SLI, tenemos que empezar a pensar en cómo implementarlas.

Para sus primeros SLI, elija algo que requiera un mínimo de trabajo de ingeniería. Si ya dispones de los registros de tu servidor web, pero configurar las sondas te llevaría semanas e instrumentar tu JavaScript te llevaría meses, utiliza los registros.

Necesita información suficiente para medir el SLI: para la disponibilidad, necesita el estado de éxito/fracaso; para las peticiones lentas, necesita el tiempo que se tarda en servir la petición. Es posible que tenga que reconfigurar su servidor web para registrar esta información. Si utiliza un servicio basado en la nube, es posible que parte de esta información ya esté disponible en un panel de control de supervisión.

Existen varias opciones de implementación de SLI para nuestra arquitectura de ejemplo, cada una con sus propios pros y contras. Las siguientes secciones detallan SLIs para los tres tipos de componentes en nuestro sistema.

Disponibilidad y latencia de la API y el servidor HTTP

Para todas las implementaciones de SLI consideradas, basamos el éxito de la respuesta en el código de estado HTTP. Las respuestas 5XX cuentan para el SLO, mientras que todas las demás solicitudes se consideran correctas. Nuestro SLI de disponibilidad es la proporción de solicitudes con éxito, y nuestros SLI de latencia son la proporción de solicitudes que son más rápidas que los umbrales definidos.

Sus SLI deben ser específicos y mensurables. Para resumir la lista de posibles candidatos proporcionada en “Qué medir: uso de los SLI”, sus SLI pueden utilizar una o más de las siguientes fuentes:

• Registros del servidor de aplicaciones

• Supervisión del equilibrador de carga

• Monitorización de caja negra

• Instrumentación del lado del cliente

Nuestro ejemplo utiliza la monitorización del balanceador de carga, ya que las métricas ya están disponibles y proporcionan SLI más cercanos a la experiencia del usuario que los de los registros del servidor de aplicaciones.

Frescura, cobertura y corrección de las tuberías

Cuando nuestro pipeline actualiza la tabla de clasificación, registra una marca de agua que contiene la fecha y hora de actualización de los datos. Algunos ejemplos de implementación de SLI:

• Ejecutar una consulta periódica a través de la tabla clasificatoria, contando el número total de registros nuevos y el número total de registros. Esto tratará cada registro antiguo como igual de importante, independientemente de cuántos usuarios vieron los datos.

• Haga que todos los clientes de la tabla de clasificación comprueben la marca de agua cuando soliciten datos frescos e incrementen un contador métrico diciendo que se solicitaron datos. Incrementa otro contador si los datos son más recientes que un umbral predefinido.

De estas dos opciones, nuestro ejemplo utiliza la implementación del lado del cliente, ya que proporciona SLI que están mucho más estrechamente correlacionados con la experiencia del usuario y son fáciles de añadir.

Para calcular nuestro SLI de cobertura, nuestra canalización exporta el número de registros que debería haber procesado y el número de registros que ha procesado correctamente. Esta métrica puede omitir registros de los que nuestro pipeline no tenía conocimiento debido a una configuración incorrecta.

Tenemos un par de enfoques potenciales para medir la corrección:

• Inyectar datos con salidas conocidas en el sistema y contar la proporción de veces que la salida coincide con nuestras expectativas.

• Utilizar un método para calcular los resultados correctos a partir de datos de entrada distintos de los de nuestra canalización (y probablemente más caros, por lo que no son adecuados para nuestra canalización). Utilizarlo para muestrear pares de entrada/salida y contar la proporción de registros de salida correctos. Esta metodología presupone que la creación de un sistema de este tipo es posible y práctica.

Nuestro ejemplo basa su SLI de corrección en algunos datos curados manualmente en la base de datos del estado del juego, con buenas salidas conocidas que se prueban cada vez que se ejecuta la tubería. Nuestro SLI es la proporción de entradas correctas para nuestros datos de prueba. Para que este SLI sea representativo de la experiencia real del usuario, tenemos que asegurarnos de que nuestros datos curados manualmente son representativos de los datos del mundo real.

La Figura 2-2 muestra cómo nuestro sistema de monitorización de caja blanca recopila métricas de los distintos componentes de la aplicación de ejemplo.

Figura 2-2. Cómo recoge nuestro sistema de monitorización las métricas SLI

Veamos un ejemplo de cómo utilizar las métricas de nuestro sistema de monitorización para calcular nuestros SLO iniciales. Aunque nuestro ejemplo utiliza métricas de disponibilidad y latencia, los mismos principios se aplican a todos los demás SLO potenciales. Para obtener una lista completa de las métricas que utiliza nuestro sistema, consulte el Apéndice A. Todos nuestros ejemplos utilizan la notación Prometheus.

Métricas del balanceador de carga

Peticiones totales por backend (“api” o “web”) y código de respuesta:

http_requests_total{host=“api”, status=“500”}

Latencia total, como histograma acumulativo; cada cubo cuenta el número de solicitudes que tardaron menos o igual que ese tiempo:

http_request_duration_seconds{host=“api”, le=“0.1”} http_request_duration_seconds{host=“api”, le=“0.2”} http_request_duration_seconds{host=“api”, le=“0.4”}

En general, es mejor contar las peticiones lentas que aproximarlas con un histograma. Pero, como no disponemos de esa información, utilizamos el histograma proporcionado por nuestro sistema de monitorización. Otro enfoque sería basar el recuento explícito de peticiones lentas en los distintos umbrales de lentitud de la configuración del balanceador de carga (por ejemplo, para umbrales de 100 ms y 500 ms). Esta estrategia proporcionaría cifras más precisas pero requeriría más configuración, lo que dificultaría el cambio retroactivo de los umbrales.

http_request_duration_seconds{host=“api”, le=“0.1”} http_request_duration_seconds{host=“api”, le=“0.5”}

Calcular los SLI

Utilizando las métricas anteriores, podemos calcular nuestros SLI actuales durante los siete días anteriores, como se muestra en la Tabla 2-2.

Tabla 2-2. Cálculos de los SLI de los siete días anteriores

Podemos redondear estos SLI a números manejables (por ejemplo, dos cifras significativas de disponibilidad, o hasta 50ms⁵⁾ de latencia) para obtener nuestros SLO iniciales.

Por ejemplo, a lo largo de cuatro semanas, las métricas de la API muestran:

• Peticiones totales: 3,663,253

• Total de solicitudes realizadas con éxito: 3,557,865 (97.123%)

• Latencia percentil 90: 432 ms

• Latencia percentil 99: 891 ms

Repetimos este proceso para los demás SLI y creamos un SLO propuesto para la API, que se muestra en la Tabla 2-3.

Table 2-3. SLOs propuestos para el API

El Apéndice A proporciona un ejemplo completo de un documento SLO. Este documento incluye implementaciones de SLI, que omitimos aquí por brevedad.

Basándonos en este SLI propuesto, podemos calcular nuestro presupuesto de errores durante esas cuatro semanas, como se muestra en la Tabla 2-4.

Tabla 2-4. Presupuesto de errores durante cuatro semanas

Los SLO pueden definirse a lo largo de varios intervalos de tiempo, y pueden utilizar una ventana móvil o una ventana alineada con el calendario (por ejemplo, un mes). Hay varios factores que debe tener en cuenta a la hora de elegir la ventana.

Las ventanas rotativas se ajustan más a la experiencia del usuario: si se produce una interrupción importante el último día de un mes, el usuario no se olvida de repente de ella el primer día del mes siguiente. Recomendamos definir este periodo como un número entero de semanas para que siempre contenga el mismo número de fines de semana. Por ejemplo, si utiliza una ventana de 30 días, algunos periodos pueden incluir cuatro fines de semana mientras que otros incluyen cinco fines de semana. Si el tráfico de los fines de semana difiere significativamente del de los días laborables, sus SLI pueden variar por razones poco interesantes.

Las ventanas de calendario están más en consonancia con la planificación empresarial y el trabajo en proyectos. Por ejemplo, puede evaluar sus SLI cada trimestre para determinar dónde concentrar el personal de proyectos del trimestre siguiente. Las ventanas de calendario también introducen cierto elemento de incertidumbre: a mediados del trimestre, es imposible saber cuántas solicitudes recibirá durante el resto del trimestre. Por lo tanto, las decisiones tomadas a mitad de trimestre deben especular sobre cuánto presupuesto para errores gastará en el resto del trimestre.

Las ventanas de tiempo más cortas le permiten tomar decisiones más rápidamente: si no cumplió su SLO para la semana anterior, entonces las pequeñas correcciones del curso - priorizar los errores relevantes, por ejemplo - pueden ayudar a evitar violaciones de SLO en semanas futuras.

Los periodos de tiempo más largos son mejores para tomar decisiones más estratégicas: por ejemplo, si pudiera elegir sólo uno de tres grandes proyectos, ¿le convendría más pasar a una base de datos distribuida de alta disponibilidad, automatizar su procedimiento de rollout y rollback o desplegar una pila duplicada en otra zona? Se necesita más que una semana de datos para evaluar grandes proyectos de varios trimestres; la cantidad de datos necesaria es aproximadamente proporcional a la cantidad de trabajo de ingeniería que se propone para solucionarlo.

Hemos comprobado que una ventana rotativa de cuatro semanas es un buen intervalo de uso general. Complementamos este marco temporal con resúmenes semanales para priorizar las tareas e informes resumidos trimestrales para planificar los proyectos.

Si la fuente de datos lo permite, se puede utilizar esta SLO propuesta para calcular su rendimiento SLO real durante ese intervalo: si establece su SLO inicial basado en mediciones reales, por diseño, cumplió su SLO. Pero también podemos recopilar información interesante sobre la distribución. ¿Hubo algún día durante las últimas cuatro semanas en que nuestro servicio no cumplió su SLO? ¿Estos días se corresponden con incidentes reales? ¿Se tomó (o debería haberse tomado) alguna medida en esos días en respuesta a los incidentes?

Si no dispone de registros, métricas o cualquier otra fuente de rendimiento histórico, deberá configurar una fuente de datos. Por ejemplo, como solución de baja fidelidad para los servicios HTTP, puedes configurar un servicio de monitorización remota que realice algún tipo de comprobación periódica de la salud del servicio (un ping o un HTTP GET) e informe del número de peticiones realizadas con éxito. Varios servicios en línea pueden implementar fácilmente esta solución.

Para que un SLO propuesto sea útil y eficaz, tendrá que conseguir que todas las partes interesadas estén de acuerdo con él:

• Los jefes de producto tienen que estar de acuerdo en que este umbral es lo suficientemente bueno para los usuarios: un rendimiento por debajo de este valor es inaceptablemente bajo y merece la pena dedicar tiempo de ingeniería a solucionarlo.

• Los desarrolladores del producto tienen que acordar que, si se agota el presupuesto de errores, tomarán algunas medidas para reducir el riesgo para los usuarios hasta que el servicio vuelva a estar dentro del presupuesto (como se explica en “Establecimiento de una política de presupuesto de errores”).

• El equipo responsable del entorno de producción encargado de defender esta SLO ha acordado que es defendible sin un esfuerzo hercúleo, un trabajo excesivo y el agotamiento, todo lo cual es perjudicial para la salud a largo plazo del equipo y del servicio.

Una vez acordados todos estos puntos, lo más difícil ya está hecho.⁶⁾ Ha comenzado su viaje hacia la SLO, y los pasos restantes implican iterar a partir de este punto de partida.

Para defender su SLO tendrá que configurar la supervisión y las alertas (véase el capítulo 5) para que los ingenieros reciban notificaciones oportunas de las amenazas al presupuesto de errores antes de que esas amenazas se conviertan en déficits.

Una vez que tenga un SLO, puede utilizarlo para derivar un presupuesto de errores. Para utilizar este presupuesto de errores, necesita una política que describa qué hacer cuando su servicio se quede sin presupuesto.

Conseguir que la política de presupuesto de errores sea aprobada por todas las partes interesadas clave -el gestor de producto, el equipo de desarrollo y los SRE- es una buena prueba para comprobar si los SLO son adecuados para el propósito:

• Si los SRE consideran que el SLO no es defendible sin una cantidad excesiva de trabajo pesado, pueden argumentar a favor de relajar algunos de los objetivos.

• Si el equipo de desarrollo y el director de producto creen que el aumento de recursos que tendrán que dedicar a solucionar la fiabilidad hará que la velocidad de publicación de características caiga por debajo de niveles aceptables, también pueden argumentar a favor de relajar los objetivos. Recuerde que reducir los SLO también disminuye el número de situaciones a las que responderán los SRE.

• Si el gestor de producto cree que el SLO dará lugar a una mala experiencia para un número significativo de usuarios antes de que la política de presupuesto de errores haga que alguien aborde un problema, es probable que los SLO no sean lo suficientemente estrictos.

Si las tres partes no están de acuerdo en aplicar la política de presupuesto de errores, debe repetir los SLI y SLO hasta que todas las partes interesadas estén satisfechas. Decida cómo avanzar y qué necesita para tomar la decisión: ¿más datos, más recursos o un cambio en el SLI o SLO?

Cuando hablamos de hacer cumplir un presupuesto de errores, nos referimos a que una vez que se agota el presupuesto de errores (o se está a punto de agotarlo), se debe hacer algo para restaurar la estabilidad del sistema.

Para tomar decisiones sobre la aplicación del presupuesto de errores, es necesario empezar con una política escrita. Esta política debe cubrir las acciones específicas que deben tomarse cuando un servicio ha consumido todo su presupuesto de errores durante un periodo de tiempo determinado, y especificar quién las tomará. Los propietarios y las acciones más comunes podrían incluir:

• El equipo de desarrollo da la máxima prioridad a los fallos relacionados con problemas de fiabilidad de las últimas cuatro semanas.

• El equipo de desarrollo se centra exclusivamente en los problemas de fiabilidad hasta que el sistema esté dentro de la SLO. Esta responsabilidad va acompañada de una aprobación de alto nivel para dar marcha atrás a las peticiones y mandatos de características externas.

• Para reducir el riesgo de más interrupciones, una congelación de la producción detiene ciertos cambios en el sistema hasta que haya suficiente presupuesto de errores para reanudar los cambios.

A veces, un servicio consume la totalidad de su presupuesto de errores, pero no todas las partes interesadas están de acuerdo en que sea apropiado aplicar la política de presupuesto de errores. Si esto ocurre, hay que volver a la fase de aprobación de la política de presupuesto de errores.

Un SLO adecuadamente definido debe documentarse en un lugar destacado donde otros equipos y partes interesadas puedan revisarlo. Esta documentación debe incluir la siguiente información:

• Los autores del SLO, los revisores (que comprobaron su exactitud técnica) y los aprobadores (que tomaron la decisión empresarial sobre si es el SLO correcto).

• La fecha en que se aprobó y la fecha en que debería revisarse de nuevo.

• Una breve descripción del servicio para contextualizar al lector.

• Los detalles del SLO: los objetivos y las implementaciones SLI.

• Los detalles de cómo se calcula y se consume el presupuesto de errores.

• La justificación de las cifras y si se han obtenido a partir de datos experimentales o de observación. Incluso si los SLO son totalmente ad hoc, este hecho debe documentarse para que los futuros ingenieros que lean el documento no tomen malas decisiones basadas en datos ad hoc.

La frecuencia con la que revise un documento de SLO depende de la madurez de su cultura de SLO. Al principio, probablemente debería revisar los SLO con frecuencia, quizás cada mes. Una vez que la idoneidad del SLO esté más consolidada, es probable que pueda reducir las revisiones a trimestrales o incluso menos frecuentes.

La política de presupuesto de errores también debe documentarse, y debe incluir la siguiente información:

• Los autores, revisores y aprobadores de la política

• La fecha en que se aprobó y la fecha de la próxima revisión.

• Una breve descripción del servicio para contextualizar al lector.

• Las medidas que deben tomarse en caso de agotamiento del presupuesto

• Una ruta de escalada clara a seguir en caso de desacuerdo sobre el cálculo o si las acciones acordadas son apropiadas dadas las circunstancias.

• Dependiendo del nivel de experiencia y conocimientos de la audiencia, puede ser beneficioso incluir una visión general de los presupuestos de errores.

Véase en el Apéndice A un ejemplo de documento de SLO y de política de presupuesto de errores.

Además de los documentos publicados sobre SLO y política presupuestaria de errores, es útil disponer de reportes y tableros que ofrezcan instantáneas en tiempo real del cumplimiento de los SLO por parte de sus servicios, para comunicarse con otros equipos y detectar áreas problemáticas.

El reporte de la figura 2-3 muestra el cumplimiento general de varios servicios: si cumplieron todos sus objetivos de nivel de servicio trimestrales del año anterior (los números entre paréntesis indican el número de objetivos que se cumplieron y el número total de objetivos), y si sus SLI tendían al alza o a la baja en relación con el trimestre anterior y el mismo trimestre del año anterior.

Figura 2-3. Reporte de cumplimiento de SLO

También es útil disponer de tableros que muestren las tendencias del SLI. Estos tableros indican si está consumiendo presupuesto a un ritmo superior al habitual, o si hay patrones o tendencias que deba tener en cuenta.

El tablero de la Figura 2-4 muestra el presupuesto de errores para un solo trimestre, a mitad de ese trimestre. Aquí vemos que un solo evento consumió alrededor del 15% del presupuesto de errores en el transcurso de dos días.

Figura 2-4. Tablero del presupuesto de errores

Los presupuestos de errores pueden ser útiles para cuantificar estos eventos, por ejemplo, “esta interrupción consumió el 30% de mi presupuesto trimestral de errores”, o “estos son los tres incidentes más importantes de este trimestre, ordenados por la cantidad de presupuesto de errores que consumieron”.

Todos los servicios pueden beneficiarse de la mejora continua. Este es uno de los objetivos centrales del servicio en ITIL, por ejemplo.

Antes de poder mejorar sus objetivos de SLO, necesita una fuente de información sobre la satisfacción de los usuarios con su servicio. Hay una gran variedad de opciones:

• Puedes contar las interrupciones descubiertas manualmente, los mensajes en foros públicos, los tickets de soporte y las llamadas al servicio de atención al cliente.

• Puede intentar medir el sentimiento de los usuarios en las redes sociales.

• Puede añadir código a su sistema para muestrear periódicamente la felicidad de los usuarios.

• Puede realizar encuestas y muestreos cara a cara con los usuarios.

Las posibilidades son infinitas, y el método óptimo depende de su servicio. Recomendamos empezar con una medición que sea barata de recopilar e iterar desde ese punto de partida. Pedir a su jefe de producto que incluya la fiabilidad en sus conversaciones con los clientes sobre precios y funcionalidades es un excelente punto de partida.

Cuente las interrupciones detectadas manualmente. Si tiene tickets de soporte, cuéntelos también. Fíjese en los periodos en los que ha tenido una interrupción o incidencia conocida. Compruebe que estos periodos se correlacionan con descensos pronunciados en el presupuesto de errores. Del mismo modo, fíjese en los periodos en los que sus SLI indican un problema, o en los que su servicio se sale de SLO. ¿Estos periodos de tiempo se correlacionan con interrupciones conocidas o con un aumento de los tickets de soporte? Si está familiarizado con el análisis estadístico, el coeficiente de correlación de Spearman puede ser una forma útil de cuantificar esta relación.

La Figura 2-5 muestra un gráfico del número de tickets de soporte generados por día frente a la pérdida medida en nuestro presupuesto de errores en ese día. Aunque no todas las incidencias están relacionadas con problemas de fiabilidad, existe una correlación entre las incidencias y la pérdida de presupuesto para errores. Vemos dos valores atípicos: un día con sólo 5 tickets, en el que perdimos el 10% de nuestro presupuesto para errores, y un día con 40 tickets, en el que no perdimos presupuesto para errores. Ambos justifican una investigación más detallada.

Figura 2-5. Gráfico que muestra el número de tickets de soporte por día frente a la pérdida de presupuesto en ese día

Si algunas de sus interrupciones y picos de tickets no se capturan en ningún SLI o SLO, o si tiene caídas de SLI y fallos de SLO que no se corresponden con problemas de cara al usuario, esto es una fuerte señal de que su SLO carece de cobertura. Esta situación es totalmente normal y es de esperar. Sus SLI y SLO deben cambiar con el tiempo a medida que cambien las realidades sobre el servicio que representan. No tema examinarlos y perfeccionarlos con el tiempo.

Hay varias medidas que puede tomar si su SLO carece de cobertura:

Cambie su SLO
Si sus SLI indicaron un problema, pero sus SLO no hicieron que nadie se diera cuenta o respondiera, es posible que necesite reforzar su SLO.

• Si el incidente en esa fecha fue lo suficientemente grande como para tener que abordarlo, observe los valores de SLI durante los periodos de interés. Calcule qué SLO habría dado lugar a una notificación en esas fechas. Aplique ese SLO a sus SLI históricos, y vea qué otros eventos habría capturado este ajuste. No tiene sentido mejorar la recuperación de su sistema si reduce la precisión de tal manera que el equipo debe responder constantemente a eventos sin importancia.7

• Del mismo modo, para los días de falsos positivos, considere la posibilidad de relajar la SLO.

• Si al cambiar el SLO en cualquier dirección se obtienen demasiados falsos positivos o falsos negativos, también hay que mejorar la implementación del SLI.

Cambie su implementación del SLI
Hay dos formas de cambiar su implementación de SLI: o bien acercar la medición al usuario para mejorar la calidad de la métrica, o bien mejorar la cobertura para capturar un mayor porcentaje de interacciones del usuario. Por ejemplo:

• En lugar de medir el éxito/latencia en el servidor, mídalo en el equilibrador de carga o en el cliente.

• En lugar de medir la disponibilidad con una simple solicitud HTTP GET, utilice un controlador de comprobación de estado que ejercite más funcionalidades del sistema, o una prueba que ejecute todo el JavaScript del lado del cliente.

Instituir un SLO aspiracional
A veces determinas que necesitas un SLO más estricto para contentar a tus usuarios, pero mejorar tu producto para cumplir ese SLO te llevará algún tiempo. Si implementa el SLO más estricto, estará permanentemente fuera del SLO y sujeto a su política de presupuesto de errores. En esta situación, puede hacer que el SLO refinado sea un SLO aspiracional, medido y seguido junto con su SLO actual, pero explícitamente indicado en su política de presupuesto de errores como que no requiere acción. De este modo, podrá hacer un seguimiento de su progreso hacia el cumplimiento del objetivo estratégico de rendimiento al que aspira, pero no se encontrará en un perpetuo estado de emergencia.

Iterar
Hay muchas formas diferentes de iterar, y tus sesiones de revisión identificarán muchas mejoras potenciales. Elija la opción que tenga más probabilidades de ofrecer el mayor rendimiento de la inversión. Especialmente durante las primeras iteraciones, opte por la opción más rápida y barata; de este modo reducirá la incertidumbre de sus métricas y podrá determinar si necesita métricas más costosas. Itere tantas veces como sea necesario.

Una vez que tenga los SLO, puede empezar a utilizarlos para la toma de decisiones.

Las decisiones obvias empiezan por qué hacer cuando no se está cumpliendo el SLO, es decir, cuando se ha agotado el presupuesto de errores. Como ya se ha comentado, el curso de acción adecuado cuando se agota el presupuesto de errores debe estar cubierto por la política de presupuesto de errores. Las políticas comunes incluyen detener el lanzamiento de características hasta que el servicio esté de nuevo dentro del SLO o dedicar parte o todo el tiempo de ingeniería a trabajar en errores relacionados con la fiabilidad.

En circunstancias extremas, un equipo puede declarar una emergencia con aprobación de alto nivel para quitar prioridad a todas las demandas externas (peticiones de otros equipos, por ejemplo) hasta que el servicio cumpla los criterios de salida, normalmente que el servicio esté dentro de SLO y que se hayan tomado medidas para reducir las posibilidades de un fallo de SLO posterior. Estos pasos pueden incluir la mejora de la supervisión, la mejora de las pruebas, la eliminación de dependencias peligrosas o la reestructuración del sistema para eliminar tipos de fallos conocidos.

Puede determinar la escala del incidente según la proporción del presupuesto de errores que consumió, y utilizar estos datos para identificar los incidentes más críticos que merecen una investigación más detallada.

Por ejemplo, imaginemos que el lanzamiento de una nueva versión de la API provoca un 100% de NullPointerExceptions hasta que el sistema puede revertirse cuatro horas más tarde.⁷⁾ La inspección de los registros sin procesar del servidor indica que el problema provocó 14,066 errores. Utilizando las cifras de nuestro SLO del 97% anterior, y nuestro presupuesto de 109,897 errores, este único evento utilizó el 13% de nuestro presupuesto de errores.

O puede que falle el servidor en el que se almacena nuestra base de datos de estado individual y la restauración a partir de las copias de seguridad tarde 20 horas. Estimamos (basándonos en el tráfico histórico durante ese periodo) que esta interrupción nos causó 72,000 errores, o el 65% de nuestro presupuesto de errores.

Imaginemos que nuestra empresa de ejemplo sólo ha tenido un fallo de servidor en cinco años, pero que normalmente experimenta dos o tres lanzamientos erróneos que requieren rollbacks al año. Podemos estimar que, de media, los lanzamientos defectuosos cuestan el doble del presupuesto para errores que los fallos de las bases de datos. Las cifras demuestran que abordar el problema de las liberaciones proporciona muchos más beneficios que invertir recursos en investigar el fallo del servidor.

Si el servicio funciona a la perfección y necesita poca supervisión, puede que haya llegado el momento de pasarlo a un nivel de asistencia menos práctico. Es posible que siga proporcionando gestión de respuesta a incidentes y supervisión de alto nivel, pero ya no necesita estar tan estrechamente involucrado con el producto en el día a día. Por lo tanto, puede centrar sus esfuerzos en otros sistemas que necesiten más apoyo de SRE.

En la Tabla 2-5 se sugieren líneas de actuación basadas en tres dimensiones clave:

• Rendimiento con respecto a los objetivos estratégicos

• La cantidad de trabajo pesado (toil) que requiere el funcionamiento del servicio

• El nivel de satisfacción del cliente con el servicio

Tabla 2-5. Matriz de decisión SLO

Una vez que cuente con una cultura sana y madura de SLO y presupuesto de errores, podrá seguir mejorando y perfeccionando la forma de medir y debatir la fiabilidad de sus servicios.

Aunque todas las técnicas discutidas en este capítulo serán beneficiosas para su organización, en última instancia, los SLO deben centrarse en la mejora de la experiencia del cliente. Por lo tanto, debe escribir los SLO en términos de acciones centradas en el usuario.

Puede utilizar los viajes críticos del usuario para ayudar a capturar la experiencia de sus clientes. Un recorrido crítico del usuario es una secuencia de tareas que constituye una parte fundamental de la experiencia de un usuario determinado y un aspecto esencial del servicio. Por ejemplo, para una experiencia de compra en línea, los recorridos críticos del usuario podrían incluir:

• Buscar un producto

• Añadir un producto a la cesta de la compra

• Completar una compra

Cada tarea requiere varios pasos complejos que pueden fallar en cualquier momento, y deducir el éxito (o fracaso) de estas acciones a partir de los registros puede ser extremadamente difícil. (Por ejemplo, ¿cómo determinar si el usuario falló en el tercer paso, o si simplemente se distrajo viendo vídeos de gatos en otra pestaña). Sin embargo, tenemos que identificar lo que le importa al usuario antes de empezar a asegurarnos de que ese aspecto del servicio es fiable.

Una vez identificados los eventos centrados en el usuario, se puede resolver el problema de medirlos. Puedes medirlos uniendo distintos eventos de registro, utilizando sondeo avanzado de JavaScript, utilizando instrumentación del lado del cliente o utilizando algún otro proceso. Una vez que puede medir un evento, se convierte en otro SLI, que puede seguir junto con sus SLI y SLO existentes. Los recorridos críticos de los usuarios pueden mejorar la recuperación sin afectar a la precisión.

Calificación de la importancia de las interacciones

No todas las solicitudes se consideran iguales. La solicitud HTTP de una aplicación móvil que comprueba las notificaciones de la cuenta (donde las notificaciones son generadas por un pipeline diario) es importante para su usuario, pero no es tan importante como una solicitud relacionada con la facturación de su cliente.

Necesitamos una forma de distinguir ciertas clases de solicitudes de otras. Usted puede utilizar la agrupación para lograr esto, es decir, la adición de más etiquetas a sus SLIs, y luego aplicar diferentes SLOs a esas diferentes etiquetas. La Tabla 2-6 muestra un ejemplo.

Tabla 2-6. Distribución por niveles Nivel de cliente

Puede dividir las peticiones según la capacidad de respuesta esperada, como se muestra en la Tabla 2-7.

Tabla 2-7. Clasificación por capacidad de respuesta prevista

Si dispone de los datos necesarios para aplicar su SLO a cada cliente de forma independiente, puede hacer un seguimiento del número de clientes que se encuentran en SLO en un momento dado. Tenga en cuenta que este número puede ser muy variable: los clientes que envíen un número muy bajo de solicitudes tendrán una disponibilidad del 100% (porque tuvieron la suerte de no experimentar ningún fallo) o una disponibilidad muy baja (porque el único fallo que experimentaron fue un porcentaje significativo de sus solicitudes). Los clientes individuales pueden incumplir su SLO por razones poco interesantes, pero en conjunto, el seguimiento de los problemas que afectan al cumplimiento del SLO de un amplio número de clientes puede ser una señal útil.

Los grandes sistemas tienen muchos componentes. Un único sistema puede tener una capa de presentación, una capa de aplicación, una capa de lógica de negocio y una capa de persistencia de datos. Cada una de estas capas puede constar de muchos servicios o microservicios.

Si bien su principal preocupación es implementar un SLO centrado en el usuario que cubra toda la pila, los SLO también pueden ser una forma útil de coordinar e implementar los requisitos de fiabilidad entre los diferentes componentes de la pila.

Por ejemplo, si un solo componente es una dependencia crítica⁸⁾ para una interacción particularmente valiosa, su garantía de fiabilidad debe ser al menos tan alta como la garantía de fiabilidad de la acción dependiente. El equipo que ejecuta ese componente en particular debe poseer y gestionar el SLO de su servicio del mismo modo que el SLO general del producto.

Si un componente concreto tiene limitaciones de fiabilidad inherentes, el SLO puede comunicar esa limitación. Si el viaje del usuario que depende de él necesita un nivel de disponibilidad superior al que ese componente puede proporcionar razonablemente, hay que diseñar en torno a esa condición. Puede utilizar un componente diferente o añadir defensas suficientes (almacenamiento en caché, procesamiento de almacenamiento y reenvío fuera de línea, degradación gradual, etc.) para gestionar los fallos de ese componente.

Puede ser tentador intentar salir de estos problemas a base de matemáticas. Si tiene un servicio que ofrece una disponibilidad del 99.9% en una sola zona, y necesita una disponibilidad del 99.95%, simplemente desplegando el servicio en dos zonas debería resolver ese requisito. La probabilidad de que ambos servicios sufran una interrupción al mismo tiempo es tan baja que dos zonas deberían ofrecer una disponibilidad del 99.9999%. Sin embargo, este razonamiento asume que ambos servicios son totalmente independientes, lo que casi nunca es el caso. Las dos instancias de su aplicación tendrán dependencias comunes, dominios de fallo comunes, destino compartido y planos de control globales, todo lo cual puede causar una interrupción en ambos sistemas, independientemente del cuidado con el que se diseñe y gestione. A menos que cada una de estas dependencias y patrones de fallo se enumere y contabilice cuidadosamente, cualquier cálculo de este tipo será engañoso.

Hay dos escuelas de pensamiento con respecto a cómo una política de presupuesto de errores debe abordar un SLO perdido cuando el fallo es causado por una dependencia que es manejada por otro equipo:

• Su equipo no debe detener los lanzamientos ni dedicar más tiempo a la fiabilidad, ya que su sistema no causó el problema.

• Lo que debe hacer es congelar los cambios para minimizar las posibilidades de futuras interrupciones, independientemente de la causa de la interrupción.

El segundo enfoque hará más felices a sus usuarios. Tiene cierta flexibilidad para aplicar este principio. Dependiendo de la naturaleza de la interrupción y de la dependencia, congelar los cambios puede no ser práctico. Decida qué es lo más apropiado para su servicio y sus dependencias, y registre esa decisión para la posteridad en su presupuesto documentado de errores. Para ver un ejemplo de cómo puede funcionar esto en la práctica, consulte el ejemplo de política de presupuesto de errores en el Apéndice B.

Puede que quiera experimentar con la fiabilidad de su aplicación y medir qué cambios en la fiabilidad (por ejemplo, añadir latencia a los tiempos de carga de la página) tienen un impacto adverso medible en el comportamiento del usuario (por ejemplo, porcentaje de usuarios que completan una compra). Recomendamos realizar este tipo de análisis sólo si está seguro de que dispone de presupuesto para errores. Hay muchas interacciones sutiles entre latencia, disponibilidad, clientes, dominios de negocio y competencia (o falta de ella). Tomar la decisión de reducir deliberadamente la experiencia percibida por el cliente es un Rubicón que hay que cruzar con sumo cuidado, si es que hay que hacerlo.

Aunque este ejercicio pueda parecer aterrador (¡nadie quiere perder ventas!), los conocimientos que puede adquirir realizando este tipo de experimentos le permitirán mejorar su servicio de maneras que podrían conducir a un rendimiento aún mejor (¡y a mayores ventas!) en el futuro. Este proceso puede permitirle identificar matemáticamente una relación entre una métrica empresarial clave (por ejemplo, las ventas) y una métrica técnica medible (por ejemplo, la latencia). Si es así, habrá obtenido un dato muy valioso que podrá utilizar para tomar decisiones de ingeniería importantes para su servicio en el futuro.

Este ejercicio no debe ser una actividad puntual. A medida que su servicio evolucione, también lo harán las expectativas de sus clientes. Asegúrese de revisar periódicamente la validez continua de la relación.

Este tipo de análisis también es arriesgado porque puede malinterpretar los datos que obtenga. Por ejemplo, si ralentiza artificialmente sus páginas 50 ms y observa que no se produce la correspondiente pérdida de conversiones, podría concluir que su SLO de latencia es demasiado estricto. Sin embargo, sus usuarios podrían estar descontentos, pero simplemente carecen de una alternativa a su servicio en este momento. En cuanto aparezca un competidor, sus usuarios se irán. Asegúrese de que está midiendo los indicadores correctos y tome las precauciones adecuadas.

Todos los temas tratados en este libro pueden relacionarse con las SLO. Ahora que ha leído este capítulo, esperamos que esté de acuerdo en que incluso los SLO parcialmente formalizados (que establecen claramente sus promesas a los usuarios) ofrecen un marco para discutir el comportamiento del sistema con mayor claridad, y pueden ayudar a identificar soluciones prácticas cuando los servicios no cumplen las expectativas.

En resumen:

• Los SLO son la herramienta con la que se mide la fiabilidad del servicio.

• Los presupuestos de errores son una herramienta para equilibrar la fiabilidad con otros trabajos de ingeniería, y una gran manera de decidir qué proyectos tendrán el mayor impacto.

• Debería empezar a utilizar los SLO y los presupuestos de errores hoy mismo.

Para ver un ejemplo de documento SLO y un ejemplo de política de presupuesto de errores, consulte los Apéndices A y B.

Volver al índice