SLI, SLO, SLA y presupuestos de errores

Tres términos, una idea

El Capítulo 2 presentó los objetivos de disponibilidad y los nueves (Sección 2.5) y mostró que un 99.9% en 30 días deja 43.2 minutos. Esta sección convierte esa aritmética en una disciplina operativa. El vocabulario procede del libro de Google Site Reliability Engineering (Beyer, Jones, Petoff y Murphy, O'Reilly, 2016) y de su complemento, The Site Reliability Workbook (2018), y hoy se usa mucho más allá de Google.

Un indicador de nivel de servicio (SLI) es una medida cuantitativa, definida con cuidado, de algún aspecto del servicio que reciben los usuarios. La forma más útil es una proporción: eventos buenos divididos entre eventos válidos. La proporción de solicitudes del proceso de pago que devuelven una respuesta correcta en menos de 800 ms, medida en el balanceador de carga es un SLI. Va del 0% (nada funciona) al 100% (nada está roto), y la forma de proporción permite leer, comparar y usar para alertas cualquier SLI de la misma manera.

Un objetivo de nivel de servicio (SLO) es una meta para un SLI durante una ventana establecida: el 99.9% de las solicitudes del proceso de pago son buenas, medido durante 28 días móviles. Es una promesa interna que acuerdan el equipo, el product owner y las personas que dependen del servicio. Un acuerdo de nivel de servicio (SLA) es un contrato con los clientes que establece consecuencias, normalmente créditos de servicio, si no se alcanza un nivel. Muchos servicios tienen SLO pero no SLA; las plataformas internas casi nunca tienen SLA.

La idea que une los tres es el presupuesto de errores. Si el objetivo es el 99.9%, el 0.1% de los eventos puede ser malo sin que nadie haya fallado. Ese 0.1% no es un desperdicio; es el margen que tiene el equipo para asumir riesgos: lanzar funcionalidades, ejecutar migraciones, experimentar con la configuración. El presupuesto convierte una discusión sobre sensaciones (¿es el servicio lo bastante fiable?) en una discusión sobre números (¿hemos gastado nuestro presupuesto?), y da a producto y a ingeniería una regla compartida para saber cuándo avanzar rápido y cuándo frenar.

Elegir buenos SLI

Un SLI es útil en la medida en que se acerca a lo que experimentan los usuarios. El Workbook ofrece un menú breve que cubre la mayoría de los servicios. Los servicios basados en solicitudes (API, páginas web) necesitan disponibilidad (la proporción de solicitudes válidas atendidas correctamente), latencia (la proporción atendida más rápido que un umbral) y, a veces, calidad (la proporción atendida sin degradación, como una carta mostrada sin recomendaciones personalizadas porque esa dependencia estaba caída). Los pipelines de datos necesitan frescura (la proporción de datos actualizados más recientemente que un umbral), corrección (la proporción de la salida que es correcta) y cobertura (la proporción de la entrada que se procesa). Los sistemas de almacenamiento añaden durabilidad (la proporción de los datos escritos que aún pueden leerse).

Los SLI de latencia se escriben como proporciones, no como promedios: el 99% de las solicitudes de la carta, en menos de 300 ms. Esto conecta directamente con los percentiles de la Sección 2.4: decir que el 99% de las solicitudes debe tardar menos de 300 ms equivale a decir que el p99 debe ser inferior a 300 ms, pero la forma de proporción se suma limpiamente a lo largo del tiempo y entre servidores (se cuentan las buenas y las válidas), mientras que los percentiles no. Es habitual fijar dos umbrales de latencia, por ejemplo el 90% por debajo de 200 ms y el 99% por debajo de 800 ms, para captar tanto la experiencia típica como la de la cola.

Dónde mides importa tanto como qué mides. El Workbook separa la especificación del SLI (el resultado relevante para el usuario, como pedidos realizados correctamente) de la implementación del SLI (cómo lo cuentas: logs del servidor, métricas del balanceador de carga, sondas sintéticas o instrumentación en la app móvil). Medir dentro del servidor de aplicaciones pasa por alto las solicitudes que nunca llegaron a él porque falló el DNS, la red de distribución de contenidos o el balanceador de carga. Medir en el cliente lo ve todo, pero incluye las malas conexiones móviles de los usuarios y llega con retraso. La mayoría de los equipos empieza con las métricas del balanceador de carga, que son baratas y están cerca del borde, y añade sondas sintéticas para las rutas con poco tráfico.

Define con precisión qué cuenta como válido y qué cuenta como bueno, porque los casos límite deciden si el número significa algo. ¿Es malo un 404 por una URL mal escrita? Normalmente no: es una respuesta correcta. ¿Es mala una respuesta 429 por limitación de tasa? Depende de si el cliente estaba dentro de su cuota acordada. ¿Son eventos válidos las comprobaciones de estado y las pruebas de carga? No; exclúyelas, o diluirán la proporción. Escribe estas reglas junto al SLO.

Fijar el objetivo

Un objetivo es una decisión de negocio, no técnica. El costo de cada nueve adicional sube abruptamente, mientras que los usuarios dejan de notar las mejoras a partir de cierto punto, porque su propia red telefónica, su wifi y sus dispositivos fallan con más frecuencia que eso. El libro de SRE de Google lo dice sin rodeos: aspirar al 100% es un error para casi todo, porque no deja presupuesto para el cambio, cuesta una fortuna y, de todos modos, no se puede conseguir. Un objetivo del 100% también convierte cada fallo en un incumplimiento de la política, lo que enseña a la gente a ignorar el SLO.

Buenos puntos de partida son el rendimiento pasado (¿qué logró el servicio durante el último trimestre, y estaban contentos los usuarios?), los objetivos de los servicios de los que dependes (no puedes prometer un 99.99% sobre una base de datos del 99.9%, como mostró la Sección 6.1 para las cadenas) y el costo de negocio de la falta de fiabilidad. En la plataforma de reparto de comida, los pedidos fallidos a la hora de comer cuestan ingresos y confianza de los clientes, así que un 99.9% en la realización de pedidos es defendible; las actualizaciones de la posición del repartidor son menos críticas y basta un 99%. Empieza un poco por debajo del rendimiento actual, para que el equipo no incumpla el objetivo de inmediato, y endurécelo más adelante con datos.

Elige la ventana a conciencia. Una ventana móvil, como los últimos 28 días, se ajusta a cómo recuerdan los usuarios las caídas (no las olvidan el día uno del mes), y 28 días contienen exactamente cuatro veces cada día de la semana, lo que mantiene justos los patrones semanales. Los meses naturales son adecuados para los informes y los contratos. Los servicios basados en eventos, como una puesta a la venta de entradas, pueden necesitar un SLO por evento, porque una hora de fallos durante la puesta a la venta importa mucho más que una semana tranquila.

Los presupuestos de errores en números

El presupuesto de errores puede contarse en tiempo o en eventos. Los presupuestos basados en tiempo son adecuados para servicios que o están disponibles o están caídos; los basados en solicitudes son más justos para servicios con tráfico irregular, porque una caída a las 03:00 afecta a menos usuarios que una a mediodía.

Políticas de presupuesto de errores

Un presupuesto no significa nada si no ocurre algo cuando se agota. Una política de presupuesto de errores es un documento breve, acordado de antemano por ingeniería, producto y dirección, que dice qué hará el equipo. La política de ejemplo del Workbook mide el presupuesto durante las cuatro semanas anteriores; si el servicio supera su presupuesto, se detienen todos los cambios y lanzamientos salvo las correcciones urgentes (incidencias P0) y las de seguridad hasta que el servicio vuelva a estar dentro de su SLO. También exige un postmortem con al menos una acción de máxima prioridad siempre que un solo incidente consuma más del 20% del presupuesto de cuatro semanas, y eleva los desacuerdos al director de tecnología.

El valor de una política está en que se acuerda antes de que haga efecto. En plena carrera por un lanzamiento, nadie quiere congelar los cambios; con una política firmada, la congelación es una regla acordada de antemano y no una pelea entre un SRE y un product manager. Las buenas políticas también dicen qué no cuenta en contra del equipo: una caída de red de toda la empresa, una dependencia que también está congelada, o tráfico fuera del alcance del SLO, como una prueba de carga.

Los profesionales no se ponen de acuerdo sobre lo mecánica que debe ser la política. Algunos equipos la aplican de forma estricta, porque las excepciones erosionan la confianza en todo el sistema. Otros tratan el presupuesto como información para una conversación y sostienen que una congelación rígida puede retrasar justo las correcciones que restaurarían la fiabilidad. Es habitual un camino intermedio: congelar automáticamente los lanzamientos de funcionalidades arriesgadas, seguir entregando las correcciones de fiabilidad y permitir que un directivo designado conceda excepciones documentadas. El caso contrario también importa: un equipo que nunca gasta su presupuesto probablemente es demasiado prudente y podría entregar más rápido, hacer más experimentos o reducir sus costos.

La tasa de consumo y las alertas basadas en SLO

Alertar sobre tasas de error brutas (avisar si falla más del 1% de las solicitudes durante 5 minutos) genera mucho ruido: los picos breves despiertan a la gente por la noche por problemas que nunca amenazarían el SLO, mientras que una tasa de fallos constante del 0.5% puede agotar el mes en silencio sin cruzar nunca el umbral. La respuesta del Workbook es alertar sobre la tasa de consumo (burn rate): la rapidez con que se gasta el presupuesto comparada con el ritmo que lo agotaría justo al final de la ventana.

Tasa de consumo = proporción de errores observada / proporción de errores permitida. Con un SLO del 99.9%, la proporción permitida es el 0.1%, así que una proporción de errores del 0.1% es una tasa de consumo de 1 (el presupuesto dura exactamente la ventana), el 1% es una tasa de consumo de 10 y el 100% (una caída total) es una tasa de consumo de 1000. La fracción del presupuesto de la ventana que se gasta durante una ventana de alerta es tasa de consumo x ventana de alerta / ventana del SLO. Para una ventana de 30 días (720 horas), una tasa de consumo de 14.4 mantenida durante una hora gasta 14.4 × 1 / 720 = 0.02, es decir, el 2% del presupuesto del mes; a ese ritmo, todo el presupuesto se agotaría en 720 / 14.4 = 50 horas.

El Workbook recomienda una alerta multiventana y de múltiples tasas de consumo como opción razonable por defecto para un SLO del 99.9%: avisar a la persona de guardia (page) si se gasta el 2% del presupuesto en una hora (tasa de consumo 14.4) o el 5% en seis horas (tasa de consumo 6), y abrir un ticket si se gasta el 10% en tres días (tasa de consumo 1). Cada condición debe cumplirse en una ventana larga y en una corta, siendo la corta una duodécima parte de la larga (5 minutos, 30 minutos y 6 horas, respectivamente). La ventana larga garantiza que el problema es significativo; la corta, que sigue ocurriendo, de modo que la alerta deja de dispararse a los pocos minutos de una corrección en lugar de seguir en rojo durante una hora.

SLO = 0.999                 # 99.9% of requests good
PERIOD_H = 30 * 24          # 720-hour SLO window

def burn_rate(bad, total, slo=SLO):
    """Observed error ratio divided by the ratio the SLO allows."""
    if total == 0:
        return 0.0
    return (bad / total) / (1 - slo)

def budget_spent(rate, window_h, period_h=PERIOD_H):
    """Fraction of the whole window's budget used in window_h hours."""
    return rate * window_h / period_h

def page(w1h, w5m, w6h, w30m):
    """Each argument is (bad, total) for that window."""
    fast = burn_rate(*w1h) >= 14.4 and burn_rate(*w5m) >= 14.4
    slow = burn_rate(*w6h) >= 6 and burn_rate(*w30m) >= 6
    return fast or slow

print(round(burn_rate(bad=288, total=20_000), 1))   # 14.4
print(budget_spent(14.4, window_h=1))               # 0.02, i.e. 2%

Los umbrales también fijan el tiempo de detección. Si la API de pedidos falla por completo (proporción de errores del 100%, tasa de consumo de 1000), la proporción de errores de una hora supera el 1.44% al cabo de 0.0144 × 60 = unos 0.9 minutos, así que el aviso salta en menos de un minuto. Si falla el 2% de las solicitudes (tasa de consumo 20), la proporción de una hora llega al 1.44% al cabo de 0.72 × 60 = unos 43 minutos. Los problemas graves avisan rápido; los leves solo avisan si persisten, que es exactamente el comportamiento que se quiere a las tres de la madrugada.

Los servicios con poco tráfico rompen esta aritmética: con 10 solicitudes por hora, un solo fallo es una proporción de errores del 10% y una tasa de consumo de 100. Los remedios del Workbook son el tráfico sintético para añadir señal, agrupar servicios relacionados de poco tráfico bajo un mismo SLO, hacer que los fallos aislados importen menos mediante reintentos y alternativas, o aceptar una ventana más larga. Para el sistema de venta de entradas, que está casi inactivo entre puestas a la venta y luego extremadamente ocupado, funcionan mejor los SLO por evento con alertas de tasa de consumo durante la ventana del evento que una cifra mensual.

Los SLA y los créditos de servicio

Un SLA traslada el objetivo de la ingeniería al derecho contractual. Define el servicio cubierto, cómo se mide la disponibilidad, las exclusiones (mantenimiento programado, uso indebido por parte del cliente, fuerza mayor), la compensación y cómo la reclama el cliente. La compensación habitual es un crédito de servicio: un porcentaje de la cuota mensual que se devuelve, escalonado según cuánto se haya incumplido el nivel. Los créditos suelen ser pequeños en comparación con la pérdida real del cliente, y por eso los SLA se leen mejor como una señal de la confianza del proveedor que como un seguro; los clientes cuyas pérdidas serían grandes necesitan su propia resiliencia, no un crédito mayor.

Considera un SLA ilustrativo que la plataforma de reparto de comida podría ofrecer a los restaurantes asociados para su API de recepción de pedidos: 99.5% de disponibilidad mensual, con un crédito del 10% sobre la cuota de la plataforma de ese mes por debajo del 99.5% y del 25% por debajo del 99.0%. El SLO interno es el 99.9%. El hueco entre ambos es deliberado: el equipo debería agotar el presupuesto de su SLO, aplicar su política y recuperarse mucho antes de que el contrato esté en riesgo. Nunca fijes el SLO igual al SLA; solo te enterarías de los problemas cuando ya debieras dinero.

De ahí se derivan dos consecuencias arquitectónicas. Primera: un SLA solo puede ser honesto si conoces los SLA de tus propias dependencias (proveedor de nube, procesador de pagos, proveedor de mapas) y cómo se combinan. Segunda: los SLA necesitan pruebas: el método de medición del contrato debe ser uno que puedas obtener de tu propia telemetría, lo que constituye un requisito para el diseño de la observabilidad.

Errores comunes

Demasiados SLO. Un servicio con treinta SLO no tiene ninguno, porque nadie puede razonar sobre ellos ni actuar en consecuencia. Empieza con dos o tres por cada recorrido crítico del usuario: normalmente un SLO de disponibilidad y uno o dos de latencia. Medir lo que no es. La utilización de CPU, la profundidad de las colas y el retraso de las réplicas son causas útiles que vigilar, pero no son SLI, porque los usuarios no las experimentan directamente. Medir en el lugar equivocado. Las tasas de éxito del lado del servidor parecen perfectas mientras la CDN devuelve errores. Promediar. Un SLO de latencia media oculta la cola lenta de la que se quejan los usuarios.

Objetivos sin consecuencias. Un SLO sin política de presupuesto ni alertas de tasa de consumo es un adorno del panel. Objetivos fijados solo por ingenieros. El product owner debe estar de acuerdo, porque el SLO intercambia funcionalidades por fiabilidad. No revisarlos nunca. Revisa los SLO cada uno o dos trimestres: si los usuarios se quejan mientras el SLO está en verde, el SLI o el objetivo están mal; si el presupuesto nunca se toca, puede que el objetivo sea demasiado laxo o el equipo demasiado prudente. Un solo SLO para recorridos muy distintos. Meter la exploración de la carta y el pago en una sola proporción permite que las abundantes solicitudes baratas oculten los fallos de las escasas y valiosas.

Los SLO conectan con el resto de este capítulo. Las alertas de tasa de consumo son las alertas basadas en síntomas que se recomiendan en observabilidad; los incidentes que consumen presupuesto alimentan las revisiones posteriores al incidente; y la medida de la respuesta de un SLO es una función de aptitud natural para la arquitectura.