SLOs para sistemas de alto rendimiento
· 8 min
Es común que un equipo defina una meta de rendimiento, "p99 por debajo de 200ms", sin distinguir con claridad qué se está midiendo, prometiendo, o presupuestando exactamente. Esa confusión entre términos parecidos es la raíz de la mayoría de los SLOs sobre los que nadie puede actuar.
SLI, SLO y SLA no son la misma cosa
El SLI es el indicador medido de hecho, la latencia de una solicitud, por ejemplo. El SLO es la meta interna para ese indicador, 99% de las solicitudes por debajo de 200ms a lo largo de 30 días. El SLA es la promesa externa, muchas veces contractual, con consecuencias formales en caso de incumplimiento. Confundir los tres lleva a SLAs demasiado conservadores, o a SLOs que nadie puede usar realmente para decidir nada en el día a día.
Error budget: la métrica que decide, no solo describe
El error budget es simplemente 100% menos el SLO, la cantidad de fallo ya aceptada de antemano. Esto convierte una meta estática en una herramienta operativa: con presupuesto disponible, el equipo puede asumir más riesgo en los releases; con el presupuesto agotado, la prioridad pasa a ser la estabilidad hasta que se recupere.
Por qué el percentil equivocado es peor que ningún SLO
Elegir el percentil correcto importa: el p50 esconde justamente los problemas de cola que afectan de forma desproporcionada a una fracción real de usuarios, mientras que el p999 puede ser tan estricto que termine dominado por ruido y valores atípicos sin relación con una degradación real. La elección correcta depende del volumen de solicitudes y de cuánto cuesta al negocio una solicitud lenta aislada.
Definiendo un SLO que sobrevive al primer incidente
Un buen SLO es uno que se puede violar ocasionalmente sin convertirse en emergencia, está atado a una consecuencia real para el usuario, y se revisa con datos de tráfico real en lugar de elegirse una vez y olvidarse.