Con una cuenta desbloqueas el cuestionario, el foro de dudas y el tutor con IA de esta lección, además del registro de progreso y el certificado verificable al terminar «Sistemas Distribuidos para Misiones Espaciales».
Saber que un servicio "está arriba en este instante" es útil, pero insuficiente: la pregunta que de verdad importa para operar un clúster de misión es cómo se ha comportado en el tiempo. La observabilidad de este clúster se construye sobre sondas periódicas (cada cierto intervalo, un chequeo automatizado llama a cada servicio y registra si respondió y en cuánto tiempo) y tres métricas derivadas: el % de uptime, las latencias en percentiles (p50, p95) y el MTTR (mean time to recovery, tiempo medio hasta la recuperación tras una caída).
Por qué percentiles y no promedio
El promedio de latencia esconde exactamente lo que un operador necesita ver: si 99 de cada 100 peticiones tardan 20 ms y una tarda 5 segundos, el promedio (≈70 ms) sugiere que todo va razonablemente bien, cuando en realidad 1 de cada 100 usuarios sufre una espera inaceptable. Los percentiles resuelven esto directamente: p50 (la mediana) dice cómo es la experiencia típica, y p95 dice cómo es la experiencia del 5% peor — que es, en la práctica, la señal que primero detecta que algo se está degradando, mucho antes de que el promedio se mueva de forma perceptible.
Histéresis: no aletear ante el ruido
Si una alerta se disparara con la primera sonda fallida y se resolviera con la primera sonda exitosa, un servicio con una latencia de red simplemente ruidosa generaría decenas de alertas de "caído/recuperado" por hora — una alarma que nadie toma en serio termina siendo ignorada, incluida la vez que sí importa. La solución es la histéresis: el servicio se marca caído solo tras un número configurable de sondas fallidas consecutivas (por ejemplo, 3), y se marca recuperado solo tras el mismo número de sondas exitosas consecutivas. Ese estado — cuántas fallidas o exitosas seguidas lleva acumuladas — se persiste (no vive solo en memoria), precisamente para sobrevivir a un reinicio del propio servicio de monitoreo sin perder la cuenta a mitad de camino.
Retención por capas
Guardar cada sonda individual para siempre no es sostenible ni útil: la observabilidad de este clúster retiene datos en capas decrecientes de resolución: los datos crudos (cada sonda, con su timestamp exacto) se guardan 48 horas, después de las cuales se agregan a resolución horaria (promedio, p95, conteo de fallos de esa hora) y se conservan indefinidamente a esa resolución reducida, y finalmente los datos crudos ya agregados se purgan para no acumular volumen sin beneficio. El resultado: detalle fino para depurar un incidente reciente, tendencia agregada para el historial de largo plazo.
Presupuestos de rendimiento como tests automatizados
Una idea que separa la observabilidad "seria" de la meramente decorativa: una afirmación como "la consulta del catálogo científico responde en menos de 50 ms con 100.000 filas" no debería ser una esperanza informal del equipo — debe ser un test automatizado que corre en CI, con datos de tamaño representativo, y que falla la build si el presupuesto se incumple. A esto se le llama un presupuesto de rendimiento (performance budget): una cifra concreta, verificable por máquina, que convierte una expectativa de rendimiento en una regla que el propio pipeline hace cumplir.
Los eventos de salud son eventos de primera clase del bus
Cuando la histéresis conmuta el estado de un servicio, ese cambio no se queda encerrado en el sistema de monitoreo: se publica como un evento más en el bus de la lección 3 (service-down, service-recovered), con su propio contrato JSON Schema, su source, y disponible tanto por webhook como por polling para cualquier app del clúster que quiera reaccionar (por ejemplo, el plano de gobernanza registrando un incidente, o un canal de alertas). La observabilidad no es un silo aparte: es un productor más de eventos del mismo bus que ya conoces.
Ejemplo resuelto: uptime y MTTR de una semana
Un servicio estuvo caído dos veces durante una semana de monitoreo continuo: una caída de 52 minutos y otra de 32 minutos, sumando 84 minutos de indisponibilidad total. Una semana tiene 7×24×60=10,080 minutos. El uptime porcentual es:
Si el MTTR se calcula como el tiempo promedio de recuperación por incidente, con dos incidentes de 52 y 32 minutos: MTTR=(52+32)/2=42 minutos. Nótese que un uptime del 99.17% suena alto en aislamiento, pero equivale a más de hora y media de indisponibilidad en una sola semana — es exactamente el tipo de cifra que un presupuesto de rendimiento y un umbral de alerta deberían capturar antes de que se acumule silenciosamente mes tras mes.
Repasa el vocabulario de esta lección:
1 de 5
¿Por qué se usa p95 de latencia en vez del promedio para vigilar la salud de un servicio?
El laboratorio de esta lección es un panel SRE simulado: provoca caídas con un slider de inestabilidad, ajusta la ventana de histéresis (de 1 a 5 sondas) y observa en vivo cómo con 1 sola sonda las alertas aletean sin control, mientras que con 3 el sistema se estabiliza — con el uptime, el MTTR y los eventos service-down/service-recovered calculándose en tiempo real.
Laboratorio: Panel SRE: histéresis, percentiles y uptime en vivo
8. Custodia de datos: un backup no probado no es backup