Por qué la observabilidad dejó de ser opcional en 2026
Durante años, "monitorización" significaba un puñado de gráficas de CPU y una alerta que saltaba cuando ya era demasiado tarde. En 2026 ese enfoque se ha quedado corto. Las arquitecturas actuales (microservicios, funciones sin servidor, colas de eventos, modelos de IA llamados en caliente) generan sistemas distribuidos donde un fallo rara vez tiene una única causa visible. Cuando algo se rompe, la pregunta no es solo "¿está caído?", sino "¿por qué, dónde exactamente y a cuántos clientes afecta ahora mismo?".
A esta presión técnica se suma la regulatoria. DORA, el reglamento europeo de resiliencia operativa digital, ya obliga a las entidades financieras y a sus proveedores tecnológicos a demostrar que pueden detectar, resistir y recuperarse de incidentes. La transposición de NIS2 eleva las exigencias de gestión de riesgos y notificación de incidentes para sectores esenciales, con plazos de reporte de horas, no de días. Y si tu software incorpora IA, el Reglamento de IA de la UE empieza a exigir trazabilidad y registro de eventos de los sistemas de alto riesgo. Todo esto tiene un denominador común: no puedes cumplir lo que no puedes observar.
La observabilidad, entendida bien, es la capacidad de responder preguntas nuevas sobre tu sistema sin desplegar código nuevo. No es un dashboard: es una propiedad de ingeniería que se diseña desde el principio.
OpenTelemetry: el estándar que por fin unifica las señales
El gran cambio de los últimos años es la consolidación de OpenTelemetry (OTel) como estándar abierto para instrumentar aplicaciones. En 2026 es, de facto, el lenguaje común de la observabilidad: un único conjunto de SDK y un protocolo (OTLP) para emitir las tres señales fundamentales.
- ▸Trazas: el viaje completo de una petición a través de todos los servicios, con tiempos por cada salto. Son la herramienta más potente para entender latencias y cascadas de errores en sistemas distribuidos.
- ▸Métricas: agregados numéricos (peticiones por segundo, percentiles de latencia, tasa de errores) que revelan tendencias y disparan alertas.
- ▸Logs: el detalle contextual, ahora correlacionado con trazas mediante identificadores compartidos, para pasar de "algo va mal" a "esta línea, en este servicio, con este cliente".
La ventaja estratégica de OTel es que desacopla la instrumentación del backend. Instrumentas una vez con un estándar abierto y decides después dónde envías los datos: una solución autoalojada como Prometheus con Grafana y Tempo, o un proveedor gestionado. Si mañana cambian los precios o los requisitos de soberanía del dato, migras el destino sin reescribir la aplicación. Para una empresa europea preocupada por el RGPD y por la dependencia de proveedores, esa portabilidad no es un detalle técnico: es control real sobre tus datos y tu factura.
SLO, SLI y presupuesto de error: la fiabilidad como decisión de negocio
Instrumentar es la mitad del trabajo. La otra mitad es decidir qué significa "estar bien". Aquí entran los SLO (objetivos de nivel de servicio), la práctica que popularizó la ingeniería de fiabilidad y que en 2026 es sentido común.
La idea es simple y transformadora. Primero defines un SLI (indicador de nivel de servicio): una medida honesta de la experiencia del usuario, como el porcentaje de peticiones que responden correctamente por debajo de 300 milisegundos. Luego fijas un SLO: por ejemplo, que ese indicador se cumpla el 99,9 % del tiempo en 28 días. La diferencia entre el 100 % y ese objetivo es tu presupuesto de error: cuánto puedes fallar antes de incumplir tu promesa.
Ese presupuesto convierte discusiones eternas en decisiones cuantificables. ¿Desplegamos una función nueva un viernes? Si queda presupuesto de error, adelante. ¿Se ha agotado por una semana turbulenta? Se congela lo arriesgado y se dedica esfuerzo a estabilizar. La fiabilidad deja de ser una opinión y pasa a ser un número que negocio y tecnología comparten. Y algo clave: perseguir el 100 % de disponibilidad es un error caro. Cada nueve adicional multiplica el coste; el objetivo correcto es el que tus usuarios notan, no el máximo teórico.
Checklist: cómo montar observabilidad que aguante producción
Si vas a poner (o revisar) un sistema en serio, este es el orden que funciona:
- ▸Instrumenta con OpenTelemetry desde el día uno, no como parche posterior. Propaga el contexto de traza entre todos los servicios y colas.
- ▸Define de 2 a 4 SLI por servicio crítico centrados en la experiencia real: disponibilidad, latencia (usa percentiles p95 y p99, nunca la media), y corrección de datos.
- ▸Fija SLO realistas y un presupuesto de error acordado con negocio, no impuesto por operaciones en solitario.
- ▸Alerta sobre síntomas, no sobre causas: notifica cuando el usuario sufre (SLO en riesgo), no por cada pico de CPU. Menos ruido, menos fatiga de alertas.
- ▸Correlaciona logs, trazas y métricas con identificadores comunes para investigar en minutos, no en horas.
- ▸Prepara la respuesta a incidentes: guardias claras, runbooks, y plazos de notificación alineados con NIS2 y DORA si te aplican.
- ▸Practica el caos de forma controlada: inyecta fallos en preproducción para validar que las alertas y la recuperación funcionan de verdad.
- ▸Haz post-mortem sin culpables tras cada incidente y convierte cada aprendizaje en una mejora medible.
Cómo lo construimos en TuniCyberLabs
En TuniCyberLabs somos una empresa de ingeniería de software con matriz en Estonia (Tallin), oficina en Chipre (Limasol) y equipo de ingeniería en Túnez (Susa). Ofrecemos nearshore europeo real: trabajamos en el mismo huso horario que España, con contratos y garantías de RGPD a través de la matriz estonia, y en inglés, francés y árabe. Calidad de producción a coste nearshore, sin las fricciones del offshore lejano.
Nuestra forma de construir sistemas fiables sigue cuatro fases. Entender: analizamos tu negocio y definimos, contigo, qué SLI y SLO reflejan de verdad la experiencia de tus clientes. Diseñar: proyectamos la arquitectura con la observabilidad y la resiliencia incorporadas, no añadidas al final; elegimos OpenTelemetry para no atarte a ningún proveedor. Construir y desplegar: entregamos software de producción con instrumentación completa, alertas basadas en síntomas, canalizaciones de despliegue seguras y cumplimiento de NIS2, DORA o el Reglamento de IA según tu sector. Soportar y evolucionar: operamos, medimos el presupuesto de error y mejoramos de forma continua a partir de datos reales, no de intuiciones.
El resultado es software que se mantiene en pie porque está diseñado para que sepas, en todo momento, cómo está y por qué. En 2026, esa certeza es la diferencia entre un incidente que gestionas en minutos y una crisis que aparece en los titulares.
De la alerta al aprendizaje
La observabilidad madura no consiste en tener más pantallas, sino en apagar menos incendios. Cuando cada petición cuenta su historia, cuando los SLO traducen la fiabilidad a un idioma que entiende negocio y cuando cada incidente deja una mejora, tu equipo pasa de reaccionar a anticipar. Ese es el objetivo real: no prometer que nunca fallarás, sino demostrar que, cuando algo pase, lo verás primero, lo entenderás rápido y lo resolverás antes de que tus clientes lo noten. Si quieres construir sistemas así, esa conversación es justo donde empezamos.