SRE herramientas

SLI, SLO y SLA son tres números distintos

Un SLI es una medición: eventos buenos sobre eventos válidos — las peticiones respondidas en menos de 300 ms con un estado que no sea 5xx, sobre todas las peticiones que llegaron al balanceador de carga. Un SLO es un objetivo para esa proporción a lo largo de una ventana, por ejemplo 99,9 % sobre 30 días móviles. Un SLA es un contrato que ata dinero a un objetivo normalmente más laxo. Confundirlos es la razón por la que un equipo despierta a alguien a las 3 de la madrugada por un número que nadie acordó defender.

La parte difícil es la definición del SLI, no el porcentaje. Dos equipos que declaran un 99,9 % pueden estar hablando de cosas distintas según si 429 cuenta como error, si las comprobaciones de salud están en el denominador y si la medición ocurre en el borde del CDN o dentro del servicio. Fija numerador y denominador antes de discutir sobre nueves.

El SLO produce después el único número que cambia comportamientos: el presupuesto de error, 100 % − SLO. Con un 99,9 % sobre 30 días puedes fallar en el 0,1 % de las peticiones, o estar completamente caído durante 43,2 minutos. Es una moneda: los despliegues y las migraciones la gastan, una ventana nueva la repone, y un mes que termina al 100 % suele significar que has desplegado demasiado despacio.

Objetivos de disponibilidad en minutos reales

Los nueves son poco intuitivos; los minutos no. Cada nueve adicional divide por diez la caída permitida.

Hasta el 99,9 %, una persona puede darse cuenta, diagnosticar y arreglar dentro del presupuesto. Con un 99,99 % la asignación mensual son 4,32 minutos: es una afirmación sobre conmutación automática, no sobre guardias.

Tasa de consumo: del SLO al umbral de alerta

La tasa de consumo es la tasa de error observada dividida por la que permite el SLO. La identidad que importa es presupuesto consumido = tasa de consumo × (ventana ÷ periodo del SLO): convierte una observación corta en una afirmación sobre el mes entero.

Empareja cada umbral rápido con una ventana de confirmación más corta (5 min a 14,4×, 30 min a 6×) para que la alerta se cierre cuando termine el incidente. Los consumos lentos van a un ticket, no a un aviso.

Qué herramienta responde a cada pregunta

Recurre a la Calculadora SLA cuando tengas un porcentaje y necesites su equivalente en tiempo: convierte cualquier valor de 0 a 100 en caída permitida por año, por mes de 30 días, por semana y por día, con ajustes predefinidos del 90 % al 99,999 %. Es la herramienta para revisar contratos.

Usa Error Budget en cuanto el número deba guiar decisiones de ingeniería. Dale un SLO, una ventana en días y el tráfico esperado; devuelve el presupuesto como porcentaje, como caída permitida y como número de peticiones que pueden fallar — 1.000 de un millón con un 99,9 % sobre 30 días, la cifra que sobrevive a una degradación parcial donde un número de caída no lo hace.

Primero, decide qué respuestas son «malas». Los Códigos HTTP son una consulta código → significado — nombre, clase y una descripción de una línea por código, filtrable por número o palabra clave — así que 400 («no pudo entender la petición») frente a 422 («bien formado pero semánticamente no válido») se zanja al momento. Marcan 307 y 308 como preservadores del método, pero no dicen nada de lo que 301 hace con un POST: los clientes pueden reescribirlo como GET y descartar el cuerpo, y por eso un endpoint POST movido de forma permanente necesita 308. Para ver qué devuelve un endpoint en producción, Cabeceras HTTP solicita desde api.sitekits.dev e informa del estado final, los saltos de redirección, el tiempo de respuesta y todos los encabezados; el cuerpo nunca se recupera, y los destinos privados o localhost los rechaza su protección SSRF. ¿Necesitas un cuerpo, encabezados de autenticación o un POST? El Probador REST API dispara desde tu navegador directo al destino, así que se aplica su política CORS. Más en el hub de HTTP, cuya matriz de redirecciones compara 301, 302, 303, 307 y 308 una al lado de la otra.

Para pruebas de latencia, abre una exportación de DevTools en el Visor HAR: método, estado, tipo, tamaño y tiempo por petición, con los 4xx/5xx resaltados. Sanéala con el Sanitizador HAR antes de adjuntarla a un ticket: authorization, cookie, x-api-key, los parámetros con aspecto de token y todos los cuerpos pasan a [REDACTED].

Programaciones, ventanas y relojes

Cron es donde el trabajo de fiabilidad se rompe sin hacer ruido. El Editor Crontab analiza una expresión de cinco campos y lista los ocho próximos disparos en la zona horaria local de tu navegador. Lee la tabla como dos cosas a la vez: los rangos de campo que comparte todo cron, y la gramática más estrecha que este editor analiza de verdad — enteros combinados con *, listas, rangos y pasos, y nada más.

Todo lo que aparece en esa última columna falla con un único mensaje — Invalid cron expression (expected 5 fields) — incluso cuando hay cinco campos presentes, así que 0 3 * * 7 parece un error de conteo cuando en realidad es un error de vocabulario. Escribe domingo como 0. Las macros de línea (@daily, @reboot) y los dialectos de seis campos con segundos se rechazan igual, y también los rangos invertidos: escribe 22-2 como 22-23,0-2. Una forma, en cambio, falla en silencio: 5/15 se lee como el valor único 5, mientras que los analizadores de estilo Kubernetes lo expanden a 5-59/15, así que escribe el rango completo.

Tres cosas que la tabla no puede mostrar. En la combinación de días, el editor aplica la regla POSIX de coincidencia alternativa — con día del mes y día de la semana ambos restringidos, 0 0 1 * 1 significa el día 1 y todos los lunes — pero decide qué es restringido por el texto, contando como no restringido cualquier campo de día que empiece por *. Un paso se escapa de esa prueba: */3 en día del mes se lee como no restringido, así que 0 0 */3 * 1 se combina con Y y solo se dispara los lunes que caen el día 1, 4, 7 y así sucesivamente. Escribe esos días como 1-31/3 para recuperar la regla de coincidencia alternativa. Los pasos dividen el campo, no el reloj: */7 en los minutos se ejecuta de :00 a :56 y reinicia después con un hueco de 4 minutos. Y la vista previa usa la zona horaria de tu navegador mientras que el reloj de la máquina suele estar en UTC.

Las cronologías de incidentes exigen el mismo rigor: Unix Time lee los valores inferiores a 1e12 como segundos y los mayores como milisegundos, y el Convertidor de Zona Horaria fija un mismo instante en 12 zonas IANA con el desplazamiento de horario de verano correcto antes de que anuncies una ventana de mantenimiento. El resto del kit de guardia: herramientas para SRE.

Errores habituales

El mes del contrato no es el mes de la calculadora

La calculadora usa un mes fijo de 30 días y un año de 365. Por mes natural, un SLO del 99,9 % permite 40,32 minutos en un febrero de 28 días y 44,64 en julio: un 10 % de variación con una redacción idéntica.

La disponibilidad se multiplica a lo largo de la cadena de dependencias

Tres dependencias duras al 99,9 % cada una, en serie, dan 0,999³ = 99,70 %: unas 2,16 horas de caída mensual, no 43,2 minutos. Sin redundancia no puedes prometer más que el producto de la ruta crítica.

Los presupuestos por tiempo y por peticiones no son intercambiables

La cifra de caída permitida asume una tasa de error del 100 % mientras está caído. Una degradación que falla en el 5 % de las peticiones consume un presupuesto de peticiones del 99,9 % a 50× mientras apenas mueve un reloj de disponibilidad basado en sondas sintéticas.

Tu intervalo de sondeo es el suelo de tu resolución

Una comprobación sintética de 60 segundos no puede ver una caída de 20 segundos, y cada sonda perdida registra aproximadamente un minuto: ya el 23 % de un presupuesto mensual del 99,99 %. Por encima de tres nueves, mide desde los registros de peticiones, no sondeando.