Publicado originalmente en maturitylab.com. Este texto forma parte de la ruta Madurez.
Un modelo de madurez en observabilidad describe, por niveles, cómo una organización desarrolla la capacidad de entender el comportamiento de sus propios sistemas en producción: desde la alerta que llega por la queja de un cliente hasta la investigación de fallos nuevos con datos recogidos de forma planificada. El modelo sirve para dos fines. Primero, muestra el nivel actual con base en evidencia. Segundo, indica las prácticas que faltan para el siguiente escalón. Este artículo presenta los conceptos de referencia, una escala de niveles, las señales de cada nivel y un paso a paso para la evaluación.
Monitorización y observabilidad no son lo mismo
El programa de investigación DORA, que estudia el desempeño de los equipos de tecnología, separa los dos conceptos. La monitorización es la herramienta que permite al equipo vigilar y entender el estado de los sistemas a partir de condiciones definidas de antemano. La observabilidad es la herramienta que permite depurar el sistema de forma activa, explorando propiedades y patrones no definidos de antemano (dora.dev).
La diferencia decide el nivel de madurez. La monitorización responde a preguntas conocidas: si el servidor está activo, si la cola superó el límite. La observabilidad responde a preguntas que nadie previó: por qué un grupo concreto de clientes sufrió lentitud ayer a las 15 h.
El proyecto OpenTelemetry, alojado por la Cloud Native Computing Foundation, describe la misma idea: la observabilidad permite entender un sistema desde fuera, haciendo preguntas sin conocer su funcionamiento interno. Para ello, la aplicación debe estar instrumentada y emitir señales como trazas, métricas y registros (opentelemetry.io).
Los niveles de un modelo de madurez en observabilidad
No existe una norma internacional única para la madurez en observabilidad. Los modelos publicados por proveedores y comunidades usan escalas propias. La escala siguiente es una síntesis de Maturity Lab, construida sobre los conceptos de DORA, de OpenTelemetry y del libro de ingeniería de fiabilidad de Google. Sigue la lógica de escalones de los modelos de madurez en gestión.
| Nivel | Nombre | Qué caracteriza el nivel |
|---|---|---|
| 1 | Reactivo | El usuario descubre el fallo; cada equipo consulta los registros del servidor cuando algo se rompe |
| 2 | Monitorizado | Paneles y alertas para condiciones conocidas, como disponibilidad y uso de recursos |
| 3 | Instrumentado | Trazas, métricas y registros estandarizados y correlacionados entre los servicios |
| 4 | Orientado a objetivos | Indicadores y objetivos de nivel de servicio acordados con el negocio y usados para priorizar |
| 5 | Observable | El equipo investiga fallos nuevos sin nueva instrumentación y usa el aprendizaje para prevenir incidentes |
Cada nivel presupone el anterior. Una organización no define objetivos de nivel de servicio fiables si todavía no recoge los datos de forma estandarizada entre los servicios.
¿Sabía que…? El libro de ingeniería de fiabilidad de Google define las cuatro señales de oro de la monitorización: latencia, tráfico, errores y saturación. El mismo capítulo recomienda que toda alerta enviada a una persona exija una acción (sre.google).
Señales que indican el nivel actual
Algunas señales observables ya indican el nivel probable antes de cualquier cuestionario:
- Señales de nivel 1: el primer aviso de incidente llega por soporte o por el cliente; no existe un panel compartido; la investigación depende del acceso directo al servidor.
- Señales de nivel 2: existen paneles y alertas, pero cada equipo usa su herramienta; el equipo recibe alertas que no exigen acción y empieza a ignorarlas.
- Señales de nivel 3: los servicios emiten datos con el mismo estándar; una petición se puede seguir de extremo a extremo; correlacionar registro, métrica y traza lleva minutos, no horas.
- Señales de nivel 4 y 5: cada servicio crítico tiene indicador y objetivo de nivel de servicio acordados con el negocio; el consumo del margen de error define la prioridad entre corrección y funcionalidad nueva; el análisis posterior al incidente genera cambios registrados.
La compra de una herramienta no define el nivel. Una plataforma completa, sin estándar de instrumentación y sin responsable de las alertas, mantiene a la organización en el nivel 2. DORA señala como error concentrar la monitorización en una sola persona o en un equipo dedicado que responde solo por el sistema (dora.dev).
Cómo evaluar la madurez en observabilidad
La evaluación convierte la percepción de los equipos en nota por dimensión y en plan de acción.
En la práctica: 6 pasos para la evaluación
- Definir el alcance. Elegir los servicios críticos para el negocio. Evaluar todos los sistemas en la primera ronda produce una media sin utilidad.
- Definir las dimensiones. Usar dimensiones como instrumentación, recogida y almacenamiento, alertas y respuesta a incidentes, objetivos de nivel de servicio, cultura y responsabilidades, y uso de los datos en la decisión.
- Recoger respuestas de distintos roles. Desarrollo, operación, soporte y gestión de producto responden al mismo cuestionario. La divergencia entre roles es un hallazgo.
- Exigir evidencia. Toda respuesta positiva señala un panel, una alerta configurada, un informe posterior al incidente o un objetivo documentado. Sin evidencia, la práctica cuenta como no implantada.
- Calcular la nota por dimensión. El nivel global queda limitado por la dimensión más débil. Una instrumentación avanzada sin responsable de las alertas no sostiene el nivel 3.
- Elaborar el plan del siguiente nivel. Seleccionar de tres a cinco prácticas del escalón siguiente, con responsable y plazo, y repetir la evaluación cuando las prácticas estén en uso.
Errores comunes en la evolución de la observabilidad
El primer error es tratar la observabilidad como un proyecto de herramienta. La herramienta recoge datos; el nivel depende de quién usa los datos, con qué pregunta y para qué decisión.
El segundo error es medirlo todo. El exceso de alertas genera fatiga, y el equipo deja de reaccionar ante la alerta que importa. El criterio del libro de ingeniería de fiabilidad de Google ayuda: una alerta que no exige acción humana no debe despertar a nadie.
El tercer error es evaluar la observabilidad aislada de la gestión. Los objetivos de nivel de servicio dependen de la prioridad definida por la dirección, y el análisis posterior al incidente depende de una cultura sin búsqueda de culpables. El mismo razonamiento aparece en el modelo de madurez de pruebas: cuando la evaluación técnica revela carencias de prioridad y de responsabilidad, un diagnóstico de madurez empresarial ayuda a localizar el origen.
Preguntas frecuentes
¿La observabilidad sustituye a la monitorización?
No. La monitorización sigue siendo necesaria para condiciones conocidas, como disponibilidad y capacidad. La observabilidad amplía la capacidad del equipo para investigar fallos que nadie previó.
¿Hace falta usar OpenTelemetry para llegar al nivel 3?
No. El nivel 3 exige instrumentación estandarizada y correlacionada entre los servicios. OpenTelemetry es un estándar abierto que facilita ese requisito, pero la evaluación verifica la práctica, no la marca de la herramienta.
¿Los equipos pequeños necesitan un modelo de madurez en observabilidad?
Sí, a menor escala. Un equipo pequeño puede empezar por las cuatro señales de oro en los servicios críticos y por una regla simple de alertas accionables. El modelo indica el orden de las prácticas y evita invertir en herramientas antes de tiempo.
