Por que tu SLO te miente: 3 errores que destruyen tu presupuesto de error
La estadistica detras de tu SLI determina si tu presupuesto de error dice la verdad. Tres errores que rompen SLOs silenciosamente, con la matematica y como arreglarlos.
El dashboard verde a las 3am
Tu alarma dice "Average latency <= 15 segundos." El dashboard marca 8.7 segundos. Verde. Te vas a dormir.
A las 3am tu cliente llama. Un usuario espero casi un minuto. Tu dashboard sigue verde.
¿Como paso? Diez data points: 2, 2, 3, 3, 4, 4, 5, 6, 8 y 50 segundos. Average = 8.7. Pero p99 = 50 segundos. La estadistica que elegiste para tu SLI escondio el problema. Tu presupuesto de error se veia saludable mientras el consumo real estaba por las nubes.
Esto no es un caso atipico. Es una falla estructural que ocurre cada vez que la estadistica equivocada alimenta un SLO.
Si el marco SLI/SLO/SLA, los presupuestos de error o el burn rate son nuevos para ti, AWS tiene recursos solidos:
- Improve application reliability with effective SLOs cubre las definiciones de SLI/SLO/SLA y el diseno efectivo de SLOs.
- Alarming on SLOs in Amazon Search with CloudWatch Application Signals cubre la teoria de burn rate y alarmas a escala de Amazon.
- CloudWatch Service Level Objectives cubre como crear SLOs nativamente en AWS.
Este post se enfoca en lo que esos recursos no cubren: como una mala eleccion de estadistica genera un efecto cascada a traves de toda la cadena SLO, y tres errores especificos que lo causan.
Figura 1: De la estadistica a la alarma: la cadena SLO
Como una estadistica equivocada rompe toda la cadena
Para ver como funciona la cascada, tracemos el mismo SLO con una estadistica equivocada versus la correcta.
Configuracion:
- SLO de 99.5% en ventana rolling de 28 dias (40,320 minutos).
- Presupuesto de error = 0.5% x 40,320 = 201.6 minutos.
Tu servicio tiene una mala hora: 40 de 60 minutos son unhealthy.
Con Average como SLI:
Average = 8.7 segundos. Por debajo del umbral de 15 segundos. El SLI reporta "healthy" durante los 60 minutos. Presupuesto consumido: 0 minutos. Burn rate: 0. Ninguna alarma se dispara. Mientras tanto, el p99 era de 50 segundos todo el tiempo. Los usuarios sufrieron. Te enteras cuando el cliente llama.
Con p99 como SLI:
p99 = 50 segundos. Por encima del umbral de 15 segundos. El SLI correctamente reporta "unhealthy" durante 40 de los 60 minutos. Presupuesto consumido: 40 minutos (19.8%). Burn rate:
Plain text
(40/60) x (40,320/201.6) = 0.667 x 200 = 133.3
La alarma de fast burn (umbral 13.44 en ventana de 1 hora) se dispara inmediatamente. Respondes en minutos, no en horas.
Mismos datos. Mismo SLO. Mismo presupuesto de error. La unica diferencia es la estadistica que alimenta el SLI. Una dice la verdad. La otra miente.
Nota: el umbral 13.44 viene de "2% del presupuesto de 28 dias consumido en 1 hora" (2% x 40,320 / 60 = 13.44). El clasico 14.4 del SRE Workbook (Beyer et al.) usa un intervalo de 30 dias. El numero depende de tu intervalo; usa la formula, no una constante memorizada.
Error 1: Alarmar con Average en latencia
Este es el escenario anterior, generalizado. La latencia promedio se ve saludable porque unos pocos valores extremos se diluyen en la mayoria. La AWS Solutions Library lo dice directo:
"Performance metrics reported as averages hide critical information. An average response time of 200ms might mean all requests complete in 200ms, or it might mean 99% complete in 100ms while 1% take 10 seconds." - Defining Success: SLIs, SLOs, and Performance Budgets
A escala: 1 millon de solicitudes por dia con p99 = 1,200ms significa 10,000 solicitudes dolorosamente lentas cada dia.
El impacto en el SLO: si el SLI usa Average, el calculador de burn rate trabaja con el numero equivocado. Cada periodo reporta "healthy" mientras los usuarios reales experimentan la cola. El presupuesto de error se drena invisiblemente.
Arreglalo: usa p99 como SLI de latencia. Si necesitas "que porcentaje de solicitudes cumplieron el objetivo", usa Percentile Rank (
PR(:umbral) ) que se traduce directamente a lenguaje contractual y es facil de auditar.Error 2: No vigilar el tamano de muestra
Un p99 calculado con 3 data points es ruido aleatorio. Una Trimmed Mean de 5 valores no es estadisticamente significativa. Terminas paginando a un ingeniero o tomando decisiones de escalado basadas en jitter.
AWS lo dice explicitamente:
"It is a good idea to keep watch on trimmed count whenever you are using trimmed mean." - CloudWatch statistics definitions
El impacto en el SLO: durante periodos de poco trafico (madrugadas, fines de semana), tu SLI puede reportar un breach porque 2 de 3 data points fueron lentos. El burn rate se dispara. La alarma suena. El on-call investiga y no encuentra nada; fue ruido estadistico por muestra insuficiente.
Esta es la trampa de falsos positivos. Con el tiempo, los equipos empiezan a ignorar las alarmas de burn rate porque "siempre es una falsa alarma de poco trafico." Entonces ocurre un incidente real durante poco trafico y nadie responde.
Arreglalo: acompana siempre percentiles o Trimmed Mean con SampleCount o Trimmed Count. Si el conteo esta por debajo de un umbral significativo para tu servicio, trata el periodo como "datos insuficientes" en vez de "healthy" o "unhealthy." El umbral exacto depende de tu patron de trafico.
El equipo de Amazon Search resuelve esto con una alarma dedicada de Low Traffic que suprime las alertas de burn rate durante periodos con muy pocas solicitudes para producir estadisticas confiables.
Error 3: Poner SLO = SLA
Si ambos son 99%, la primera vez que fallas, el contrato ya esta roto. Cero tiempo de reaccion. Te enteras cuando el cliente pide creditos.
"SLOs are always tighter than SLAs to provide a safety buffer." - Defining Success: SLIs, SLOs, and Performance Budgets
La matematica que lo hace concreto:
| SLO = SLA (mal) | SLO mas estricto (bien) |
|---|---|---|
SLA | 99% | 99% |
SLO | 99% | 99.5% |
Presupuesto SLA | 403 min/28 dias | 403 min/28 dias |
Presupuesto SLO | 403 min/28 dias | 201 min/28 dias |
Margen de reaccion | 0 minutos | ~201 minutos |
Con el SLO mas estricto, tienes 201 minutos de advertencia: la ventana donde tu alarma de SLO se dispara pero el SLA aun no se incumple. Ese es tu tiempo para arreglar el problema antes de que se convierta en un tema contractual.
Sin la brecha, la alarma del SLO y el incumplimiento del SLA ocurren simultaneamente. La alarma no es una advertencia; es un disparador de post-mortem.
Tu industria determina cual SLI va primero
El marco de SLOs no cambia por industria. Lo que cambia es cual SLI pones primero en tu dashboard, porque el costo de equivocarte es diferente.
- Orientada a cumplimiento (Servicios Financieros, Salud, Gobierno): Percentile Rank es el SLI principal. "Que porcentaje de transacciones cumplieron el objetivo?" es la pregunta que hacen los reguladores y auditores.
PR(:umbral)se traduce directamente a ese lenguaje. Disponibilidad viene en segundo lugar: no fallar importa mas que ser rapido. Los presupuestos de error tienden a ser ajustados: 99.9%+.
- Orientada a experiencia (E-Commerce, SaaS, APIs): p99 de latencia es el SLI principal. La cola es donde se abandonan carritos y los clientes de API se van. El volumen de errores (Sum de 5xx) es el foco secundario. Presupuestos de error moderados: 99.5% a 99.9%.
- Tiempo real (Gaming, IoT, Streaming): tanto p99 como Maximum importan. En gaming, un spike de lag pierde la partida. En IoT, una lectura de sensor por encima de un umbral fisico puede significar dano al equipo. Los presupuestos varian: gaming tolera 99.5%, seguridad IoT puede necesitar 99.99%.
El punto clave: en los tres casos, Average no es el SLI principal para ninguna industria. El debate es entre p99, PR(:umbral), Maximum y Disponibilidad; nunca Average para latencia.
Ponlo a trabajar: Amazon CloudWatch Application Signals
Amazon CloudWatch Application Signals te permite crear SLOs sobre cualquier metrica de CloudWatch con seguimiento de cumplimiento, calculo de presupuesto de error y alertas de burn rate integrados:
"You can use any CloudWatch metric or metric expression as an SLI." - CloudWatch Service Level Objectives
Los SLOs miden rendimiento tecnico, pero las fallas tienen consecuencias de negocio tambien. Puedes integrar metricas de negocio personalizadas junto a tus SLIs. Cuando Application Signals detecta una degradacion, ves tanto el impacto tecnico como los ingresos en riesgo en una sola vista. Para un recorrido detallado, ve Investigating Service Issues with Amazon CloudWatch Application Signals Custom Metrics .
Empieza hoy
- Crea tu primer SLO: Abre la consola de Amazon CloudWatch , navega a Application Signals y elige Service Level Objectives. Usa p99 de latencia o Disponibilidad como tu SLI.
- Configura alarmas de burn rate: Al crear el SLO, habilita la opcion de alarma. Configura una alarma de fast burn (ventana de 1 hora, umbral 13.44 para una ventana de 28 dias) y una de slow burn (ventana de 24 horas, umbral 3).
- Audita tus alarmas existentes: Busca cualquier alarma que use Average en una metrica de latencia. Reemplazala con p99 o PR(:umbral) y compara lo que cada una revela durante una semana.
- Revisa la brecha entre tu SLO y tu SLA: Si tu objetivo de SLO es igual a tu compromiso de SLA, ajusta el SLO al menos 0.5% mas estricto. Esa brecha es tu margen de reaccion.
- Aprende las 12 estadisticas de CloudWatch: Para una guia practica de cada estadistica con ejemplos numericos trabajados y un arbol de decision, ve Como leer una estadistica de CloudWatch sin retos en AWS Builder Center.
Conclusiones
- La estadistica que eliges para tu SLI determina si tu presupuesto de error dice la verdad o te miente. Mismos datos, mismo SLO: estadistica diferente, panorama completamente diferente.
- Average esconde la cola de latencia. A escala, la cola escondida son miles de usuarios reales con experiencias terribles. Usa p99 o PR(:umbral) para SLIs de latencia.
- Percentiles sin muestra suficiente son ruido, no senal. Acompanalos con SampleCount. El equipo de Amazon Search usa una alarma de Low Traffic para prevenir falsos positivos en periodos de poco trafico.
- El SLO debe ser mas estricto que el SLA. La brecha entre ambos es tu margen de reaccion: el tiempo que tienes para arreglar un problema antes de que se convierta en un incumplimiento contractual.
- En toda industria, Average nunca es el SLI principal correcto para latencia. La pregunta es cual alternativa (p99, PR, Maximum o Disponibilidad) se alinea con la prioridad de tu negocio.
La estadistica correcta no es la que pone tu dashboard en verde. Es la que te dice la verdad.
Recursos
- CloudWatch Statistics Definitions - referencia oficial de las 12 estadisticas
- Improve Application Reliability with Effective SLOs - definiciones SLI/SLO/SLA y diseno efectivo de SLOs (AWS Blog)
- Alarming on SLOs in Amazon Search - monitoreo de burn rate a escala de Amazon (AWS Blog)
- Defining Success: SLIs, SLOs, and Performance Budgets - por que p99 importa
- CloudWatch Service Level Objectives - documentacion de SLOs en Application Signals
- Como leer una estadistica de CloudWatch sin retos - guia companera de las 12 estadisticas (AWS Builder Center)
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article