Plantilla de Evaluación de Madurez de Observabilidad

Overview

La madurez de observabilidad describe qué tan bien un equipo puede responder preguntas sobre su sistema sin desplegar código nuevo. El espectro va desde “revisamos los logs cuando algo se rompe” hasta “detectamos anomalías proactivamente antes de que los usuarios lo noten”. Esta plantilla te da una evaluación estructurada de logging, métricas, tracing, alertas y cultura.

When to Use

• Para alternativas, consulta la Plantilla de Runbook de Alertas. Usa la Plantilla de Diseño de Dashboards para planificar dashboards que soporten cada nivel de madurez, y la Plantilla de Postmortem de Incidente para rastrear action items de la dimensión de cultura.

• Revisiones trimestrales de confiabilidad

• Incorporación de un equipo nuevo a estándares de observabilidad

• Preparación para engagement SRE o migración de plataforma

• Justificación de inversión en herramientas de observabilidad ante stakeholders

• Establecimiento de una línea base antes de iniciativas de mejora

Flujo de Evaluación

Solution

# Evaluación de Madurez de Observabilidad — `<Equipo / Servicio>`

## Información de Evaluación

| Campo | Valor |
|-------|-------|
| Evaluado por | <Nombre> |
| Fecha | 2026-07-05 |
| Equipo / Servicio | Equipo de Pagos |
| Puntaje actual | 2.4 / 5.0 |
| Puntaje objetivo | 4.0 / 5.0 |
| Fecha objetivo | 2026-10-05 |

## Niveles de Madurez

| Nivel | Nombre | Descripción |
|-------|--------|-------------|
| 1 | Reactivo | Los logs existen pero no estructurados. Sin métricas ni traces. El debugging es manual. |
| 2 | Básico | Logs estructurados. Métricas clave recopiladas. Sin tracing. Las alertas son ruidosas. |
| 3 | Proactivo | Logs estructurados + dashboards + tracing distribuido. SLOs definidos. Las alertas son accionables. |
| 4 | Predictivo | Detección de anomalías. Alertas basadas en SLO. Error budgets rastreados. Runbooks para todas las alertas. |
| 5 | Autónomo | Remediación automatizada. Profiling continuo. Sistemas self-healing. Observabilidad como código. |

## 1. Evaluación de Logging

| Criterio | Nivel | Puntaje | Evidencia | Brecha |
|-----------|-------|---------|----------|-------|
| Estructura de logs | JSON estructurado | 3 | Todos los servicios usan `pino` con salida JSON | — |
| Niveles de log | Usados correctamente | 2 | Logs de debug dejados en producción, ruidosos | Añadir políticas de nivel de log |
| IDs de correlación | Presentes en todos los requests | 3 | `X-Request-ID` propagado via middleware | — |
| Retención de logs | 30 días hot, 90 cold | 3 | ELK stack con políticas ILM | — |
| Buscabilidad de logs | Consultable por campo | 3 | Elasticsearch con campos estructurados | — |
| Datos sensibles | Limpiados antes de logging | 2 | Algunos endpoints loggean bodies completos | Añadir filtro de redacción PII |
| **Promedio de Logging** | | **2.7** | | |

### Brechas de Logging

| Brecha | Actual | Objetivo | Acción | Esfuerzo |
|-----|---------|--------|--------|--------|
| Logs de debug en producción | Nivel 2 | Nivel 3 | Poner nivel de log de producción en `info`, remover debug statements | 1 día |
| PII en logs de requests | Nivel 2 | Nivel 4 | Añadir filtro de redacción para email, phone, SSN | 2 días |
| Sin alertas basadas en logs | Nivel 2 | Nivel 3 | Crear alertas para picos de logs de error por servicio | 1 día |

## 2. Evaluación de Métricas

| Criterio | Nivel | Puntaje | Evidencia | Brecha |
|-----------|-------|---------|----------|-------|
| Métricas RED (Rate, Errors, Duration) | Recopiladas para todos los servicios | 3 | Prometheus + exporters custom | Añadir histogramas de duración para 2 servicios |
| Métricas USE (Utilization, Saturation, Errors) | Recopiladas para infraestructura | 3 | Node exporter, cAdvisor | — |
| Métricas de negocio | Order count, revenue, conversion | 2 | Algunas métricas en Mixpanel, no en Prometheus | Exponer métricas de negocio desde la app |
| Cardinalidad de métricas | Controlada | 2 | Algunas etiquetas de alta cardinalidad (user_id) | Remover user_id, usar exemplars |
| Dashboards | Dashboards por servicio | 3 | Dashboards de Grafana para cada servicio | Añadir dashboard de métricas de negocio |
| Dashboards de SLO | Definidos y rastreados | 1 | Sin SLOs definidos | Definir SLOs para el servicio de pagos |
| **Promedio de Métricas** | | **2.3** | | |

### Brechas de Métricas

| Brecha | Actual | Objetivo | Acción | Esfuerzo |
|-----|---------|--------|--------|--------|
| Sin SLOs | Nivel 1 | Nivel 4 | Definir SLOs: 99.9% disponibilidad, p95 < 500ms | 3 días |
| Etiquetas de alta cardinalidad | Nivel 2 | Nivel 3 | Remover user_id de métricas, usar traces para análisis per-user | 1 día |
| Métricas de negocio faltantes | Nivel 2 | Nivel 3 | Exponer order_count, revenue_total, conversion_rate desde la app | 2 días |
| Sin histogramas de latencia | Nivel 2 | Nivel 3 | Reemplazar duración basada en counter con histogramas de Prometheus | 1 día |

## 3. Evaluación de Tracing

| Criterio | Nivel | Puntaje | Evidencia | Brecha |
|-----------|-------|---------|----------|-------|
| Tracing distribuido | Implementado | 2 | OpenTelemetry SDK en 3 de 8 servicios | Instrumentar servicios restantes |
| Propagación de traces | W3C trace context | 3 | Header `traceparent` propagado | — |
| Atributos de span | Estandarizados | 2 | Algunos servicios tienen spans ricos, otros mínimos | Añadir atributos de span para queries de DB |
| Sampling de traces | Head-based + tail-based | 2 | Head-based al 10%, sin tail-based | Añadir tail-based sampling para errores |
| Correlación de traces | Linkeados a logs y métricas | 2 | trace_id en logs, pero no en métricas | Añadir exemplars linkeando traces a métricas |
| Service maps | Auto-generados | 3 | Service mesh genera dependency map | — |
| **Promedio de Tracing** | | **2.3** | | |

### Brechas de Tracing

| Brecha | Actual | Objetivo | Acción | Esfuerzo |
|-----|---------|--------|--------|--------|
| 5 servicios sin instrumentar | Nivel 2 | Nivel 4 | Añadir OpenTelemetry SDK a los 5 servicios restantes | 5 días |
| Sin tail-based sampling | Nivel 2 | Nivel 4 | Desplegar OpenTelemetry Collector con tail-based sampling | 2 días |
| Atributos de span de DB faltantes | Nivel 2 | Nivel 3 | Añadir atributos db.system, db.statement, db.operation | 1 día |
| Sin exemplars trace-to-metric | Nivel 2 | Nivel 4 | Configurar exemplars de Prometheus linkeando a trace IDs | 2 días |

## 4. Evaluación de Alertas

| Criterio | Nivel | Puntaje | Evidencia | Brecha |
|-----------|-------|---------|----------|-------|
| Ruido de alertas | Tasa baja de falsos positivos | 2 | ~40% de las alertas son accionables | Afinar umbrales, remover alertas ruidosas |
| Routing de alertas | Routeadas al equipo correcto | 3 | Alertmanager routea por etiqueta de servicio | — |
| Runbooks | Linkeados a alertas | 1 | La mayoría de alertas no tienen runbook | Crear runbooks para las top 20 alertas |
| Alertas basadas en SLO | Multi-window burn rate | 1 | Sin alertas basadas en SLO | Implementar alertas SLO una vez definidos los SLOs |
| Escalación de alertas | Política de escalación definida | 3 | PagerDuty con escalación de 3 niveles | — |
| Contexto de alertas | Incluye links a dashboards, logs | 2 | Algunas alertas incluyen links de Grafana | Añadir runbook y links de logs a todas las alertas |
| **Promedio de Alertas** | | **2.0** | | |

### Brechas de Alertas

| Brecha | Actual | Objetivo | Acción | Esfuerzo |
|-----|---------|--------|--------|--------|
| Sin runbooks | Nivel 1 | Nivel 4 | Escribir runbooks para las top 20 alertas | 5 días |
| 60% falsos positivos | Nivel 2 | Nivel 4 | Auditar todas las alertas, afinar o remover las ruidosas | 3 días |
| Sin alertas basadas en SLO | Nivel 1 | Nivel 4 | Implementar alertas multi-window burn rate | 3 días |
| Contexto de alertas faltante | Nivel 2 | Nivel 3 | Añadir URL de runbook, URL de dashboard, query de log a las anotaciones | 1 día |

## 5. Evaluación de Cultura y Proceso

| Criterio | Nivel | Puntaje | Evidencia | Brecha |
|-----------|-------|---------|----------|-------|
| Ownership de observabilidad | Cada equipo mantiene sus dashboards | 3 | Los equipos crean y mantienen sus propios dashboards | — |
| Revisión de incidentes | Postmortems para todos los incidentes | 3 | Postmortems blameless dentro de 48 horas | — |
| Tracking de action items | Rastreados hasta completación | 2 | Action items creados pero ~40% vencidos | Añadir revisión mensual de action items |
| Cultura on-call | Rotación sostenible | 3 | Rotación de 1 semana, 3 ingenieros, follow-the-sun | — |
| Entrenamiento de observabilidad | Nuevos hires entrenados | 1 | Sin onboarding formal para herramientas de observabilidad | Crear guía de onboarding de observabilidad |
| **Promedio de Cultura** | | **2.4** | | |

### Brechas de Cultura

| Brecha | Actual | Objetivo | Acción | Esfuerzo |
|-----|---------|--------|--------|--------|
| Sin onboarding de observabilidad | Nivel 1 | Nivel 3 | Crear guía de onboarding para herramientas de logging, métricas, tracing | 2 días |
| Action items vencidos | Nivel 2 | Nivel 4 | Revisión mensual de action items de postmortems, asignar dueños | 0.5 días |

## 6. Puntaje Agregado

| Dimensión | Puntaje | Objetivo | Brecha |
|-----------|---------|--------|-------|
| Logging | 2.7 | 4.0 | 1.3 |
| Métricas | 2.3 | 4.0 | 1.7 |
| Tracing | 2.3 | 4.0 | 1.7 |
| Alertas | 2.0 | 4.0 | 2.0 |
| Cultura | 2.4 | 4.0 | 1.6 |
| **Agregado** | **2.3** | **4.0** | **1.7** |

## 7. Hoja de Ruta de Mejora

| Trimestre | Iniciativa | Dimensión | Nivel objetivo | Esfuerzo | Dueño |
|---------|-----------|-----------|-------------|--------|-------|
| Q3 2026 | Definir SLOs para todos los servicios críticos | Métricas | 3→4 | 3 días | SRE |
| Q3 2026 | Instrumentar 5 servicios restantes con OTel | Tracing | 2→4 | 5 días | Platform |
| Q3 2026 | Escribir runbooks para las top 20 alertas | Alertas | 1→4 | 5 días | Cada equipo |
| Q3 2026 | Auditar y afinar alertas ruidosas | Alertas | 2→4 | 3 días | SRE |
| Q4 2026 | Implementar tail-based sampling | Tracing | 2→4 | 2 días | Platform |
| Q4 2026 | Añadir redacción PII a logs | Logging | 2→4 | 2 días | Platform |
| Q4 2026 | Crear guía de onboarding de observabilidad | Cultura | 1→3 | 2 días | SRE |
| Q4 2026 | Implementar alertas basadas en SLO | Alertas | 1→4 | 3 días | SRE |
| Q1 2027 | Añadir métricas de negocio a Prometheus | Métricas | 2→3 | 2 días | Backend |
| Q1 2027 | Proceso de revisión mensual de action items | Cultura | 2→4 | 0.5 días | Eng Manager |

Explanation

La evaluación usa un modelo de madurez de 5 niveles en cinco dimensiones: logging, métricas, tracing, alertas y cultura. Cada dimensión se puntúa de forma independiente, luego se promedia para obtener una puntuación agregada. La puntuación se basa en evidencia: cada puntaje debe incluir evidencia concreta (herramientas usadas, políticas implementadas, métricas recopiladas). El Google SRE Workbook te da la base para alertas basadas en SLO en Nivel 3-4, mientras que OpenTelemetry es el estándar para instrumentación de tracing distribuido.

El análisis de brechas es el resultado accionable. Para cada criterio por debajo del objetivo, la plantilla identifica qué falta, qué necesita hacerse y el esfuerzo estimado. Esto alimenta directamente la hoja de ruta de mejora. Prometheus es el backend de métricas más común para equipos de Nivel 2+.

La hoja de ruta secuencia las mejoras por trimestre, equilibrando victorias rápidas (afinar alertas, añadir niveles de log) con iniciativas más grandes (definición de SLOs, instrumentación completa de tracing). Cada item tiene un dueño y una estimación de esfuerzo, haciéndolo accionable para sprint planning.

Definiciones de Niveles de Madurez

=== Nivel 1: Ad Hoc ===
  Logging:    No estructurado, ad-hoc, sin centralización
  Métricas:   Métricas básicas de infra (CPU, memoria, disco)
  Tracing:    Ninguno o correlación basada en logs
  Alertas:    Basadas en umbrales, alta tasa de falsos positivos
  Cultura:    Reactiva, sin postmortems, sin SLOs

=== Nivel 2: Básico ===
  Logging:    Centralizado pero no estructurado (ELK, CloudWatch)
  Métricas:   Métricas RED para algunos servicios, dashboards Grafana
  Tracing:    Algunos servicios instrumentados, propagación básica
  Alertas:    Basadas en umbrales, algunos runbooks, routing PagerDuty
  Cultura:    Postmortems para incidentes mayores, on-call básico

=== Nivel 3: Estructurado ===
  Logging:    JSON estructurado, centralizado, correlation IDs
  Métricas:   Métricas RED para todos, SLOs definidos
  Tracing:    OpenTelemetry en todos, propagación de traces
  Alertas:    Alertas basadas en SLO, runbooks para todas
  Cultura:    Postmortems blameless, tracking de action items, capacitación on-call

=== Nivel 4: Proactivo ===
  Logging:    Estructurado, PII redacted, alertas basadas en logs
  Métricas:   USE + RED + métricas de negocio, alertas SLO
  Tracing:    Tail-based sampling, exemplars trace-to-metric
  Alertas:    Multi-window burn rate, detección de anomalías
  Cultura:    Mejora proactiva, onboarding de observabilidad, revisiones trimestrales

=== Nivel 5: Autónomo ===
  Logging:    Análisis automatizado de logs, detección de patrones
  Métricas:   Alertas predictivas, forecast de capacidad
  Tracing:    Análisis automatizado de causa raíz desde traces
  Alertas:    Self-healing, remediación automatizada
  Cultura:    Optimización continua, observabilidad como código

Variants

Contexto	Enfoque	Notas
Equipo pequeño (< 10)	Simplifica a 3 dimensiones: logs, métricas, alertas	Omite tracing si es un solo servicio
Enterprise	Evalúa por equipo, agrega para la organización	Compara equipos para identificar brechas compartidas
Startup	Enfócate en lo básico: logs estructurados + métricas clave	Apunta a Nivel 2 primero
Industria regulada	Añade audit trail y dimensión de compliance	Requisitos FDA, SOX, GDPR
Microservicios	Enfatiza tracing y service maps	Los sistemas distribuidos necesitan tracing distribuido

What Works

1. Exige evidencia para cada puntaje — “tenemos métricas” no es evidencia; “Prometheus recopila métricas RED para los 8 servicios” sí lo es
2. Puntúa independientemente por dimensión — un equipo puede ser Nivel 4 en logging pero Nivel 1 en tracing
3. Involucra al equipo en la puntuación — la autoevaluación revela problemas que los externos no ven
4. Reevalúa trimestralmente — rastrea el progreso en el tiempo, no solo una vez
5. Prioriza por tamaño de brecha y esfuerzo — arregla las brechas más grandes con el menor esfuerzo primero
6. Asigna dueños a los items de la hoja de ruta — las mejoras sin dueño no se hacen
7. Comparte resultados entre equipos — las brechas de un equipo pueden ser las fortalezas de otro

Common Mistakes

1. Puntuar aspiracionalmente — puntuando dónde quieres estar, no dónde estás
2. Sin evidencia — puntajes sin prueba no significan nada
3. Evaluación única — sin reevaluación, no puedes medir el progreso
4. Enfocarse solo en herramientas — cultura y proceso son igualmente importantes
5. Ignorar la calidad de las alertas — tener alertas no es lo mismo que tener buenas alertas
6. Sin action items — evaluación sin plan de mejora es esfuerzo desperdiciado
7. Comparar equipos públicamente sin contexto — diferentes servicios tienen diferentes necesidades

Troubleshooting

• Fatiga de alertas: si tu equipo ignora las alertas, estás en Nivel 2, no en Nivel 4. Audita cada alerta: ¿tiene runbook? ¿Requiere acción? Elimina las alertas que no cumplan ambos criterios. Apunta a < 5 alertas accionables por turno on-call.
• Dashboards que nadie mira: revisa las estadísticas de visualización de Grafana. Si un dashboard tiene 0 visualizaciones en 30 días, elimínalo. Los dashboards deben responder preguntas específicas (“¿está saludable el servicio de pagos?”), no mostrar todas las métricas que recopilas.
• Brechas en tracing: si solo 3 de 8 servicios tienen tracing, no puedes ver la ruta completa del request. Prioriza instrumentar los servicios del viaje crítico del usuario primero (checkout, login, search), luego expande.
• Explosión de cardinalidad de métricas: si Prometheus está lento o se queda sin memoria, revisa las etiquetas de alta cardinalidad (user_id, session_id, email). Elimínalas y usa exemplars en su lugar — los traces te dan detalle por usuario sin inflar las métricas.
• SLOs que no coinciden con la realidad: si tu SLO es 99.99% pero estás en 99.5%, el SLO es aspiracional, no real. Rastrea 2-3 meses de datos, luego pon el SLO ligeramente arriba de la performance actual. Ajústalo trimestralmente, no después de una mala semana.
• Sin correlación entre logs, métricas y traces: añade trace_id a los logs y exemplars a las métricas. Sin correlación, estás depurando con tres herramientas separadas en lugar de una vista unificada.

Puntos Clave

• La madurez de observabilidad es un espectro, no una casilla — un equipo puede ser Nivel 4 en logging pero Nivel 1 en tracing. Puntúa cada dimensión independientemente.
• La puntuación basada en evidencia es el punto — “tenemos métricas” no es evidencia; “Prometheus recopila métricas RED para los 8 servicios” sí lo es. Sin evidencia, los puntajes son aspiracionales, no reales.
• El análisis de brechas impulsa la hoja de ruta — la evaluación es inútil sin un plan de mejora. Cada brecha necesita un dueño, un nivel objetivo y una estimación de esfuerzo.
• La cultura importa tanto como las herramientas — herramientas de Nivel 5 con cultura de Nivel 1 (sin postmortems, sin entrenamiento on-call) no mejorarán la confiabilidad. Invierte en proceso junto con herramientas.
• Reevalúa trimestralmente — sin reevaluación, no puedes medir el progreso. Rastrea el puntaje agregado en el tiempo para mostrar ROI a los stakeholders.

Errores Comunes en Producción

• Dejar campos requeridos en blanco o usar respuestas vagas de una sola palabra.
• Llenar el documento una vez y nunca actualizarlo después de que el alcance o las decisiones cambien.
• Guardar el documento donde el equipo no lo busca durante incidentes o revisiones.
• No asignar un dueño, fecha de vencimiento o cadencia de revisión.
• Copiar boilerplate sin eliminar las secciones que no aplican.
• Omitir el control de versiones, lo que hace imposible el rollback y la responsabilidad.
• No linkear el documento a decisiones relacionadas o acciones de seguimiento.
• Evitar revisiones trimestrales que retirarían secciones obsoletas o sin uso.