Observabilidad 360°: del incidente a ciegas a un MTTR medible
Monitorear le dice que algo falló. Observar le dice por qué. Cómo pasar de alertas sueltas a una operación que detecta, entiende y resuelve incidentes con datos.
Muchas organizaciones tienen monitoreo, pero siguen enterándose de los incidentes por un cliente o por el área de negocio. El síntoma es conocido: horas reuniendo a varios equipos para entender qué pasó, sin una vista común del recorrido de una transacción. Eso es ceguera operacional, y en sectores regulados también es un riesgo de cumplimiento.
Monitorear no es observar
El monitoreo responde preguntas que ya conocía: ¿está arriba el servicio?, ¿la CPU supera el 80 %? La observabilidad permite responder preguntas nuevas sin desplegar código adicional: ¿por qué solo fallan los pagos de un canal?, ¿en qué paso se pierde el tiempo de esta transacción?
Las tres señales y un estándar abierto
- Métricas: tendencias agregadas y baratas de almacenar.
- Logs: el detalle de cada evento, idealmente estructurados.
- Trazas: el recorrido completo de una solicitud a través de servicios, colas y bases de datos.
Recomendamos instrumentar con OpenTelemetry, el estándar abierto de la CNCF. Le permite cambiar de herramienta de análisis sin reinstrumentar las aplicaciones y evita quedar atado a un proveedor.
Empiece por las señales doradas
La práctica de SRE propone cuatro señales para cada servicio: latencia, tráfico, errores y saturación. Si solo puede medir cuatro cosas, mida esas. Le dirán rápidamente si los usuarios están sufriendo y dónde.
Defina SLO y presupuestos de error
Un objetivo de nivel de servicio traduce la experiencia del usuario en un número: por ejemplo, el 99,9 % de los pagos responde en menos de 800 ms en una ventana de 30 días. Lo que queda por debajo de ese objetivo es el presupuesto de error: mientras exista, el equipo puede priorizar funcionalidades; cuando se agota, la prioridad pasa a la estabilidad.
Alerte sobre síntomas que afectan al usuario (el SLO en riesgo), no sobre cada causa posible. Menos alertas, más relevantes, y cada una con un runbook asociado.
No deje fuera los procesos batch y legados
En retail y servicios financieros, buena parte de la operación crítica sigue siendo batch: cruces de inventario, conciliaciones, cargas nocturnas. Propague identificadores de correlación también en archivos y colas, mida duración y volumen de cada etapa y alerte cuando una ventana de procesamiento esté en riesgo, antes de que se incumpla.
Mida lo que mejora
Dos indicadores muestran si la inversión funciona: el tiempo medio de detección (MTTD) y el tiempo medio de resolución (MTTR). Mídalos desde el primer día y revíselos en cada postmortem.
Una hoja de ruta de 90 días
- Días 1 a 30: instrumentación con OpenTelemetry de los dos o tres flujos más críticos y tableros con señales doradas.
- Días 31 a 60: SLO por flujo, alertas basadas en síntomas y runbooks.
- Días 61 a 90: trazas de punta a punta, incluidos procesos batch, y seguimiento mensual de MTTD y MTTR.
El resultado es una operación que se entera antes que el cliente y que resuelve con datos en lugar de suposiciones.