Módulo 7: Fiabilidad y el tradeoff de consistencia

7. SLA, SLO y los nines, ejecutados

Siguiente →

Descripción

Al terminar esta lección vas a saber traducir un porcentaje de disponibilidad a un número de horas de caída —ejecutando la tabla de los nines— y a distinguir los tres términos que casi todos confunden: SLI, SLO y SLA. Vas a ver, corrido en Python, que 99% son 87.6 horas de caída al año, 99.9% son 8.76 horas, 99.99% son 52.6 minutos y 99.999% son 5.3 minutos —cada nueve adicional divide el downtime entre diez—. Vas a calcular el error budget (un SLO de 99.9% mensual te da 43.2 minutos de caída permitida al mes, un presupuesto que se gasta) y el techo de dependencias (no puedes prometer más disponibilidad que el producto de la de tus proveedores). Y vas a proponerle a Enlace un SLO concreto —99.9% en resolve— justificado con sus números, entendiendo por qué prometer "100%" no es ambición sino mentira.

Esto importa porque "disponibilidad" sin un número es un eslogan vacío, y los porcentajes cercanos a 100 engañan a la intuición de forma sistemática: 99% y 99.9% suenan casi idénticos y difieren en un factor de diez —78 horas de caída al año—. Sin la tabla, la gente promete niveles que no puede cumplir, o gasta fortunas persiguiendo un nueve de más que nadie necesitaba. Con la tabla, la disponibilidad se vuelve lo que debe ser: un presupuesto de horas que decides a conciencia, sabiendo lo que cuesta cada nueve (aproximadamente 10× más esfuerzo por cada uno) y lo que te permiten tus dependencias. Esta lección te da esa tabla ejecutada, te enseña a leer un SLA sin dejarte engañar por el porcentaje, y cierra el módulo con la vara que mide todo lo anterior: de nada sirve haber quitado los SPOF (lección 2) y elegido bien la consistencia (lección 6) si no puedes decir, en un número honesto, qué tan confiable es tu sistema.

Conexión con el módulo: esta lección es el tercer bloque —la vara— y le pone número a los dos anteriores. Los cálculos de disponibilidad de la lección 2 (serie, paralelo, cuánto downtime tiene cada configuración) desembocan aquí: aquellos porcentajes se traducen ahora a horas concretas y a un presupuesto. Y el error budget conecta con la consistencia de la lección 6: parte de tu presupuesto de fallo se "gasta" tolerando desfases o ventanas de failover, decisiones que tomaste en las lecciones 3 a 6. La frontera: aquí definimos y calculamos SLI/SLO/SLA y el error budget; la práctica organizacional de usar el error budget para decidir cuándo congelar despliegues, y la cultura SRE alrededor, es más de operaciones y de la guía de decisiones —nosotros nos quedamos en el número y su significado—.

El "casi siempre abierto" de la tienda

Piénsalo así. Dos tiendas cuelgan un letrero. La primera dice "abrimos 99% del año"; la segunda, "abrimos 99.9% del año". A ojo, suenan casi iguales —las dos prometen estar abiertas "casi siempre", y un 0.9% de diferencia parece insignificante—. Pero traduce los porcentajes a días cerrados y la ilusión se rompe. La primera tienda está cerrada 3.65 días al año; la segunda, cerrada apenas 8.76 horas. La "insignificante" diferencia de 0.9 puntos es en realidad una diferencia de diez veces en tiempo cerrado —de casi cuatro días a menos de un día laboral—. El letrero engaña porque la intuición humana no está calibrada para porcentajes tan cerca de 100: no sentimos la diferencia entre 99% y 99.9%, aunque sea un factor de diez.

Ahora imagina que la primera tienda promete algo más fuerte: firma un contrato con sus proveedores que dice "si estoy cerrada más del 1% del año, les pago una multa". Eso cambia todo: ya no es una aspiración, es un compromiso con consecuencias. Y para poder firmarlo con la conciencia tranquila, la tienda necesita saber tres cosas distintas que la gente mezcla: cuánto abre de verdad (el dato medido), cuánto se propone abrir (su meta interna, que se pone un poco más exigente que el contrato para tener margen), y cuánto promete abrir por contrato (la multa). Esos tres —lo medido, la meta, la promesa— son SLI, SLO y SLA, y confundirlos es cómo la gente firma contratos que no puede cumplir.

La lección que quiero que te lleves de la tienda es esta: un porcentaje de disponibilidad no significa nada hasta que lo traduces a tiempo, y no se puede prometer con seriedad sin distinguir lo que mides, lo que apuntas y lo que firmas. Esta lección hace las dos cosas: ejecuta la tabla que traduce porcentajes a horas, y separa con precisión los tres términos.

SLI, SLO, SLA: los tres términos que todos confunden

Definámoslos de menor a mayor compromiso, porque se construyen uno sobre otro.

SLI — Service Level Indicator (indicador). Es el número que mides. Un SLI es una métrica concreta y observada del comportamiento real del servicio: por ejemplo, "el porcentaje de peticiones resolve que se respondieron con éxito en menos de 100 ms durante el último mes". El SLI no es una meta ni una promesa; es el hecho —lo que de verdad pasó, medido—. Todo lo demás se apoya en tener un SLI bien definido: si no mides, no puedes ni apuntar ni prometer.

SLO — Service Level Objective (objetivo). Es la meta que te pones internamente sobre un SLI: por ejemplo, "el SLI de resolve debe ser ≥ 99.9%". El SLO es un objetivo interno de ingeniería —no lo firmas con nadie de afuera—, y por eso se suele poner más exigente que el SLA que prometes al cliente, para tener un colchón. Si tu SLA promete 99.9%, tu SLO interno podría ser 99.95%: así, si empiezas a fallar el SLO, tienes tiempo de reaccionar antes de romper el SLA y pagar la multa.

SLA — Service Level Agreement (acuerdo). Es la promesa contractual con consecuencias: por ejemplo, "garantizamos 99.9% de disponibilidad mensual; si no lo cumplimos, te devolvemos el 10% de la factura". El SLA es hacia afuera, es legal, y tiene un costo si se rompe (créditos, multas, clientes que se van). Por eso es el más conservador de los tres: nunca prometes en el SLA lo mejor que podrías hacer, sino algo que puedes cumplir con holgura incluso en un mal mes.

   SLI  ──►  lo que MIDES        "99.93% de resolves exitosos <100ms este mes"  (el hecho)
   SLO  ──►  lo que APUNTAS      "queremos SLI >= 99.9%"                          (meta interna)
   SLA  ──►  lo que PROMETES     "garantizamos 99.9% o hay multa"                 (contrato)

   regla de oro:   SLA  <=  SLO   (prometes menos de lo que te propones, para tener colchon)

La regla que amarra los tres: SLA ≤ SLO, y los dos se apoyan en el SLI. Prometes (SLA) un poco menos de lo que apuntas (SLO), y apuntas con base en lo que puedes medir (SLI). Confundirlos lleva a errores caros: prometer en el SLA el mejor SLI que has visto (y romperlo el primer mes malo), o poner un SLO sin un SLI que lo mida (y no saber nunca si lo cumples).

Ejemplo trabajado: la tabla de los nines, ejecutada

Aquí está el cálculo central del módulo. Un "nueve" es cada 9 en el porcentaje de disponibilidad: 99% son "dos nueves", 99.9% "tres nueves", etc. La tabla traduce cada nivel a downtime permitido en distintas ventanas de tiempo. La ejecutamos en vez de citarla:

SECONDS_PER_YEAR  = 365 * 24 * 3600      # anio no bisiesto
SECONDS_PER_MONTH = 30  * 24 * 3600      # mes de 30 dias (convencion de SLA)
SECONDS_PER_WEEK  = 7   * 24 * 3600
SECONDS_PER_DAY   = 24 * 3600

def human(seconds):
    """Formatea segundos como el multiplo mas natural."""
    if seconds >= 3600:
        return f"{seconds/3600:.2f} h"
    if seconds >= 60:
        return f"{seconds/60:.1f} min"
    return f"{seconds:.1f} s"

levels = [
    ("90%     (un nueve)",      0.90),
    ("99%     (dos nueves)",    0.99),
    ("99.9%   (tres nueves)",   0.999),
    ("99.99%  (cuatro nueves)", 0.9999),
    ("99.999% (cinco nueves)",  0.99999),
]

header = f"{'Disponibilidad':<24}{'/anio':>12}{'/mes':>12}{'/semana':>12}{'/dia':>12}"
print(header)
print("-" * len(header))
for name, a in levels:
    unavail = 1 - a
    print(f"{name:<24}"
          f"{human(unavail*SECONDS_PER_YEAR):>12}"
          f"{human(unavail*SECONDS_PER_MONTH):>12}"
          f"{human(unavail*SECONDS_PER_WEEK):>12}"
          f"{human(unavail*SECONDS_PER_DAY):>12}")

print()
print("Comprobacion directa de 99.9% al anio:")
segundos = (1 - 0.999) * SECONDS_PER_YEAR
print(f"  (1 - 0.999) x {SECONDS_PER_YEAR:,} s = {segundos:,.0f} s = {segundos/3600:.2f} h/anio")

Qué esperar. Al correrlo:

Disponibilidad                 /anio        /mes     /semana        /dia
------------------------------------------------------------------------
90%     (un nueve)          876.00 h     72.00 h     16.80 h      2.40 h
99%     (dos nueves)         87.60 h      7.20 h      1.68 h    14.4 min
99.9%   (tres nueves)         8.76 h    43.2 min    10.1 min     1.4 min
99.99%  (cuatro nueves)     52.6 min     4.3 min     1.0 min       8.6 s
99.999% (cinco nueves)       5.3 min      25.9 s       6.0 s       0.9 s

Comprobacion directa de 99.9% al anio:
  (1 - 0.999) x 31,536,000 s = 31,536 s = 8.76 h/anio

Esta tabla es una de las que conviene tener grabada, porque desarma para siempre la ilusión del letrero. Léela por columnas y fíjate en el patrón: cada nueve que agregas divide el downtime entre diez. De 99% a 99.9%: de 87.6 h/año a 8.76 h/año. De 99.9% a 99.99%: de 8.76 h a 52.6 min. De 99.99% a 99.999%: de 52.6 min a 5.3 min. Ese factor de diez por nueve es la clave de todo: 99.9% no es "un poquito mejor" que 99%; es diez veces mejor, y cuesta —a grosso modo— diez veces más esfuerzo lograrlo (más redundancia, más automatización de failover, más gente de guardia).

Y ahora la traducción que importa para escribir un SLA: cuando alguien promete "tres nueves" (99.9%), está prometiendo que el sistema puede estar caído hasta 8.76 horas al año —más de una jornada laboral completa— y seguir cumpliendo. "Cinco nueves" (99.999%), el estándar de la telefonía tradicional, permite solo 5.3 minutos al año —tan poco que ninguna intervención humana cabe ahí; tiene que ser todo failover automático—. Cuando leas un SLA, no leas el porcentaje: traduce a la columna que te importe (al año para planear, al mes porque así se factura) y verás lo que de verdad promete.

El error budget: el downtime es un presupuesto que se gasta

De la tabla sale una de las ideas más útiles de la fiabilidad moderna: el error budget (presupuesto de error). Si tu SLO es 99.9% mensual, entonces te permites fallar el 0.1% del mes —y ese 0.1% es un presupuesto que puedes gastar como quieras—. Calculémoslo:

SECONDS_PER_MONTH = 30 * 24 * 3600
slo = 0.999
budget_s = (1 - slo) * SECONDS_PER_MONTH
print(f"error budget de un SLO 99.9% mensual:")
print(f"  (1 - {slo}) x {SECONDS_PER_MONTH:,} s = {budget_s:,.0f} s/mes = {budget_s/60:.1f} min/mes")

Qué esperar. Al correrlo:

error budget de un SLO 99.9% mensual:
  (1 - 0.999) x 2,592,000 s = 2,592 s/mes = 43.2 min/mes

Tienes 43.2 minutos de caída permitida al mes, y la palabra clave es presupuesto: es tuyo para gastarlo. ¿En qué se gasta? En despliegues arriesgados, en experimentos, en las ventanas de failover de la lección 3, en el mantenimiento planeado. Mientras no agotes los 43.2 minutos, estás dentro del SLO y puedes seguir tomando riesgos (desplegar features nuevas). Si te acercas a agotarlo, la señal es clara: deja de arriesgar, congela los cambios, dedica el equipo a estabilizar hasta que el presupuesto se recupere el mes siguiente. El error budget convierte la fiabilidad de una discusión de opiniones ("¿desplegamos el viernes?") en una decisión con número ("¿nos queda presupuesto? sí → adelante; no → esperamos"). Es la idea que hace las paces entre los que quieren mover rápido y los que quieren no caerse: el presupuesto es exactamente cuánto riesgo te puedes permitir.

El techo de dependencias: no puedes prometer más que tus proveedores

Hay un límite duro que mucha gente ignora al fijar un SLA: tu disponibilidad no puede superar la de las cosas de las que dependes. Si Enlace corre sobre un proveedor de cómputo, una base de datos gestionada y un DNS/CDN, y todos están en serie en el camino de una petición (lección 2), tu techo es el producto de sus disponibilidades:

SECONDS_PER_YEAR = 365 * 24 * 3600
deps = {"cloud compute": 0.9995, "managed db": 0.9995, "DNS/CDN": 0.9999}
ceiling = 1.0
for name, a in deps.items():
    ceiling *= a
    print(f"  x {name}: {a}")
print(f"techo de disponibilidad = {ceiling:.6f} ({ceiling*100:.4f}%)")
downtime_h = (1 - ceiling) * SECONDS_PER_YEAR / 3600
print(f"downtime implicito del techo = {downtime_h:.2f} h/anio")

Qué esperar. Al correrlo:

  x cloud compute: 0.9995
  x managed db: 0.9995
  x DNS/CDN: 0.9999
techo de disponibilidad = 0.998900 (99.8900%)
downtime implicito del techo = 9.63 h/anio

Mira el número: aunque cada proveedor promete "cuatro nueves largos", el producto de los tres es 99.89% —por debajo de 99.9%—, con 9.63 h/año de downtime implícito solo por las dependencias. La consecuencia es dura y concreta: Enlace no puede prometer con seriedad un SLA de 99.99% (ni siquiera 99.9% con holgura) mientras dependa de esos tres proveedores en serie, por perfecto que sea su propio código. Cada dependencia en serie te baja el techo, exactamente como la cadena de la lección 2. Para prometer más, tendrías que: hacer redundantes las dependencias (multi-región, multi-proveedor), o quitar dependencias del camino crítico. Este cálculo es el primero que debería hacer cualquiera que vaya a firmar un SLA: ¿mi techo de dependencias me da margen para lo que quiero prometer? Si no, el SLA es una promesa que no controlas.

El SLO que le proponemos a Enlace

Juntemos todo en una recomendación concreta para Enlace.

  • El SLI: el porcentaje de peticiones resolve respondidas con éxito (redirección correcta) en menos de, digamos, 100 ms, medido mensualmente. Elegimos resolve porque es el 99% del tráfico (100:1) y el camino que de verdad le importa al usuario —ser redirigido rápido—. La creación (shorten) puede tener su propio SLO, más laxo.
  • El SLO: 99.9% en resolve. Es un objetivo serio pero alcanzable: da 43.2 min/mes de error budget, suficiente para absorber las ventanas de failover del primary (lección 3, que además solo degradan escrituras, no lecturas) y algún despliegue arriesgado. Perseguir 99.99% (52.6 min/año) multiplicaría el costo —failover automático perfecto, redundancia multi-región— para un acortador de URLs, donde 8.76 h/año de posible caída es perfectamente tolerable.
  • El SLA: algo por debajo del SLO, por ejemplo 99.5% hacia clientes que paguen, para tener colchón: si un mes malo el SLI cae a 99.7%, incumples tu SLO interno (señal de alarma) pero no rompes el SLA (no pagas multa). SLA ≤ SLO, siempre.
  • La verificación de dependencias: antes de prometer 99.9%, el cálculo de arriba dice que el techo de dependencias en serie es 99.89% —peligrosamente cerca—. Conclusión honesta: para sostener 99.9% con holgura, Enlace necesita reducir su dependencia en serie del componente más débil (por ejemplo, cachear en el CDN para no depender de la db en cada resolve, o hacer la db redundante como en la lección 2). El SLO fija la meta; el techo de dependencias dice cuánto trabajo de arquitectura hace falta para cumplirla.

Y la verdad incómoda que cierra el tema: nadie promete 100%, y quien lo hace, miente. 100% significaría cero downtime, jamás, ni para mantenimiento, ni ante el fallo de un proveedor, ni ante un desastre —físicamente imposible en un sistema real—. Los SLA se escriben en nueves justamente porque el 100% no existe; la pregunta nunca es "¿caído o no?", sino "¿cuántos nueves puedo sostener y qué me cuesta cada uno?".

Errores comunes

Confundir SLI, SLO y SLA (de definición). Qué pasa: alguien usa los tres como sinónimos —"nuestro SLA es 99.9%" cuando quiere decir el objetivo interno, o "medimos el SLA" cuando mide el SLI—. Por qué pasa: son tres siglas parecidas para tres capas del mismo tema. Cómo detectarlo: pregúntate "¿esto es lo que mido (SLI), lo que apunto (SLO) o lo que prometo con multa (SLA)?"; si no puedes contestar, los estás mezclando. Cómo corregirlo: recuerda la cadena —el SLI es el hecho medido, el SLO la meta interna, el SLA la promesa contractual— y la regla SLA ≤ SLO.

No traducir el porcentaje a tiempo (de calibración). Qué pasa: alguien promete o exige "99.99%" sin haber calculado que son 52.6 min/año, y luego se sorprende —en cualquier dirección— por lo que eso implica en esfuerzo o en tolerancia. Por qué pasa: los porcentajes cerca de 100 no le dicen nada a la intuición. Cómo detectarlo: si no puedes decir de memoria (o en diez segundos) el downtime al año de un nivel, no lo entiendes de verdad. Cómo corregirlo: memoriza los tres anclas —99% ≈ 87.6 h, 99.9% ≈ 8.76 h, 99.99% ≈ 52.6 min al año— y ten presente que cada nueve es un factor de diez.

Prometer un SLA por encima del techo de dependencias (de arquitectura). Qué pasa: un equipo firma 99.99% mientras sus tres dependencias en serie dan un producto de 99.89%, garantizando que romperá el SLA por causas fuera de su código. Por qué pasa: se mira la disponibilidad del propio servicio y se olvida que las dependencias en serie multiplican hacia abajo. Cómo detectarlo: calcula el producto de las disponibilidades de todo lo que está en el camino crítico; si es menor que tu SLA, ya perdiste. Cómo corregirlo: antes de prometer, haz el cálculo del techo; si no alcanza, reduce dependencias en serie o hazlas redundantes (lección 2) hasta que el techo tenga margen sobre el SLA.

Ejercicios

Ejercicio 1 — Traduce los nueves. Sin correr el código, usando que cada nueve divide el downtime entre diez y que 99% ≈ 87.6 h/año: (a) ¿cuánto downtime al año permite 99.9%? (b) ¿Y 99.99%? (c) Un proveedor promete "cuatro nueves y medio" (99.995%). ¿Aproximadamente cuánto downtime al año es eso?

Ver solución
  • (a) 99.9%: un nueve más que 99%, así que 87.6 / 10 = 8.76 h/año.
  • (b) 99.99%: otro nueve, 8.76 / 10 = 0.876 h = 52.6 min/año.
  • (c) 99.995%: está entre 99.99% (52.6 min/año) y 99.999% (5.3 min/año). "Cuatro nueves y medio" es la mitad del downtime de cuatro nueves: 52.6 / 2 ≈ 26 min/año. (Cálculo exacto: (1 - 0.99995) × 8760 h ≈ 0.438 h ≈ 26.3 min/año.)

Ejercicio 2 — Gasta el error budget. El SLO de resolve es 99.9% mensual (43.2 min/mes de presupuesto). Este mes ya ocurrieron: un failover del primary que degradó el servicio 8 minutos, un despliegue fallido que causó 12 minutos de errores, y una caída del proveedor de DNS de 15 minutos. (a) ¿Cuánto presupuesto queda? (b) ¿Debería el equipo desplegar una feature arriesgada esta semana? (c) ¿Qué decisión toma el error budget por ti?

Ver solución
  • (a) Gastado: 8 + 12 + 15 = 35 min. Queda: 43.2 - 35 = 8.2 min de presupuesto para el resto del mes.
  • (b) No conviene. Con solo 8.2 minutos de margen, un despliegue arriesgado (que históricamente puede costar más de 8 minutos si sale mal) podría romper el SLO. La señal es "estabiliza, no arriesgues".
  • (c) El error budget convierte la pregunta de opinión ("¿desplegamos?") en una regla con número: mientras haya presupuesto, se puede arriesgar; cuando se agota o queda muy poco, se congelan los cambios y el equipo se dedica a fiabilidad hasta que el presupuesto se renueve el mes siguiente. Decide por evidencia, no por discusión.

Ejercicio 3 — El SLA de Enlace, con techo. Enlace quiere prometer un SLA de 99.9% en resolve. Sus dependencias en serie son: cómputo (99.95%), base de datos (99.9%) y CDN (99.99%). (a) Calcula el techo de dependencias. (b) ¿Puede Enlace sostener 99.9% con este techo? (c) Propón un cambio de arquitectura que suba el techo, usando lo que aprendiste en la lección 2.

Ver solución
  • (a) Techo = 0.9995 × 0.999 × 0.9999 = 0.998401, o sea 99.84%. Downtime implícito: (1 - 0.998401) × 8760 h ≈ 14 h/año.
  • (b) No con holgura. El techo (99.84%) está por debajo del SLA que quiere prometer (99.9%). Enlace rompería el SLA por culpa de sus dependencias aunque su propio código fuera perfecto —el eslabón débil es la base de datos al 99.9%, que arrastra el producto—.
  • (c) El cambio de la lección 2: hacer redundante la base de datos (el eslabón más débil). Dos instancias al 99.9% en paralelo dan 1 - (1-0.999)^2 = 0.999999, casi 99.9999%. Nuevo techo: 0.9995 × 0.999999 × 0.9999 = 0.999400, o sea 99.94% —ahora sí por encima del SLA de 99.9%, con margen—. Alternativa complementaria: servir muchos resolve desde el CDN para sacar la db del camino crítico de la mayoría de las lecturas, reduciendo su peso en el producto. La regla: redunda o saca del camino el eslabón más débil hasta que el techo tenga margen sobre lo que prometes.

Resumen y siguiente paso

En esta lección le pusiste número a la fiabilidad. Con el letrero de la tienda viste que un porcentaje cerca de 100 engaña —99% y 99.9% suenan iguales y difieren diez veces— y que solo traducirlo a tiempo lo hace honesto. Separaste los tres términos: SLI (lo que mides), SLO (la meta interna que apuntas) y SLA (la promesa contractual con consecuencias), con la regla SLA ≤ SLO. Ejecutaste la tabla de los nines —99% = 87.6 h/año, 99.9% = 8.76 h/año, 99.99% = 52.6 min/año, 99.999% = 5.3 min/año— y viste que cada nueve divide el downtime entre diez y cuesta ~10× más. Calculaste el error budget (99.9% mensual = 43.2 min/mes de caída permitida, un presupuesto que se gasta y que decide cuándo arriesgar) y el techo de dependencias (el producto de las disponibilidades en serie, que no puedes superar por perfecto que seas). Y le propusiste a Enlace un SLO de 99.9% en resolve, justificado con sus números, entendiendo por qué el 100% es una mentira.

Antes de avanzar deberías poder: distinguir SLI, SLO y SLA con un ejemplo de cada uno; reproducir la tabla de nines de memoria (los tres anclas y el factor diez); calcular un error budget y explicar para qué sirve; y calcular el techo de dependencias de un sistema y decir si sostiene un SLA dado.

Lo que sigue es juntarlo todo. Ya recorriste los tres bloques del módulo —fiabilidad (SPOF, redundancia, failover), el tradeoff de consistencia (CAP, PACELC, fuerte contra eventual) y la vara (nines, SLO, error budget)—. En la lección 8, el proyecto, vas a producir una decisión escrita y defendible para Enlace: su plan de fiabilidad (los SPOF y cómo los eliminas, con diagrama), su clasificación CAP/PACELC (PA/EL, justificada), su modelo de consistencia (eventual para resolve, con read-your-writes y la garantía de unicidad), y su SLO completo (el SLI, el objetivo, el error budget ejecutado y la verificación del techo de dependencias). Es donde las seis lecciones se vuelven un documento de diseño.

Recursos

← Anterior6. Consistencia fuerte contra eventual, y la elección de EnlaceSiguiente →8. Proyecto: elige y justifica el modelo de consistencia de Enlace y su SLO