- 01Entender
- 02Priorizar
- 03Actuar
Una empresa puede tener cinco herramientas y seguir sin encontrar la causa de un incidente. La madurez de observabilidad y APM no se mide por licencias: se mide por la capacidad de pasar de un síntoma a una acción con evidencia.
Este checklist permite obtener una primera fotografía en 15 minutos. No reemplaza un assessment técnico, pero descubre prioridades.
Cómo puntuar
Respondé cada afirmación con:
- 0: no existe o se desconoce.
- 1: existe parcialmente o depende de personas.
- 2: está documentado, probado y medido.
Son 20 preguntas y un máximo de 40 puntos.
1. Cobertura y objetivos
- Los servicios críticos están identificados y tienen owner.
- Cada servicio crítico posee un SLO o expectativa medible.
- La experiencia del usuario se observa además de la infraestructura.
- Las dependencias externas y rutas críticas están documentadas.
Señal de riesgo: el equipo monitorea servidores, pero desconoce qué transacción afecta al negocio.
2. Instrumentación y calidad
- Métricas, logs y trazas comparten nombres de servicio, entorno y versión.
- Los logs son estructurados y contienen contexto de correlación.
- Las trazas atraviesan los servicios críticos sin cortes relevantes.
- Existen controles para datos sensibles y cardinalidad.
Señal de riesgo: cada equipo etiqueta producción de una manera diferente o aparecen secretos en logs.
3. Detección y alertas
- Las alertas urgentes representan impacto o riesgo inminente.
- Cada alerta tiene owner, severidad y playbook.
- Se utilizan percentiles y SLOs en lugar de promedios aislados.
- Se mide ruido, falsos positivos y alertas sin acción.
Señal de riesgo: el canal de guardia recibe cientos de avisos y los incidentes importantes se descubren por usuarios.
4. Investigación y respuesta
- Es posible navegar desde una alerta hasta logs y trazas relacionadas.
- Los despliegues y cambios aparecen en la línea de tiempo.
- Desarrollo, operaciones y seguridad comparten identificadores de incidente.
- Se mide tiempo para detectar, diagnosticar y recuperar por severidad.
Señal de riesgo: cada incidente comienza pidiendo capturas de diferentes dashboards.
5. Gobierno y costos
- El volumen y costo de telemetría puede atribuirse a equipos o servicios.
- Retención y muestreo dependen de criticidad y uso.
- Dashboards, alertas y pipelines tienen owner y revisión periódica.
- Las lecciones de incidentes generan cambios verificables en instrumentación.
Señal de riesgo: la factura crece, pero nadie sabe qué dato puede eliminarse.
Resultado
| Puntaje | Nivel | Lectura |
|---|---|---|
| 0–10 | Reactivo | La visibilidad depende de personas y herramientas aisladas |
| 11–20 | Instrumentado | Hay datos, pero poca correlación y gobierno |
| 21–30 | Operable | Los servicios críticos se investigan con procesos repetibles |
| 31–36 | Gestionado | SLOs, costos y calidad se miden regularmente |
| 37–40 | Adaptativo | La telemetría mejora con incidentes, cambios y objetivos de negocio |
El puntaje total es orientativo. Un cero en protección de datos o cobertura de una transacción crítica puede ser más urgente que varios puntos en dashboards.
Evidencia que debería acompañar el puntaje
No asignes un “2” sólo porque una persona afirma que la práctica existe. Pedí una evidencia verificable:
| Capacidad | Evidencia mínima |
|---|---|
| SLO | definición, ventana y tablero activo |
| Correlación | una traza conectada con sus logs |
| Alertas | owner, playbook y registro de ejecución |
| Costos | consumo atribuido por servicio o equipo |
| Mejora | cambio cerrado después de un incidente |
La evidencia evita que el assessment mida percepción. También permite repetirlo: si una práctica depende de una sola persona o de un dashboard que nadie mantiene, debería puntuarse como parcial. Guardá enlaces, responsables y fecha de verificación junto a cada respuesta.
Qué priorizar según el nivel
Reactivo: crear una línea base
Elegí una experiencia crítica, definí owner y cuatro señales: tráfico, errores, latencia y saturación. Documentá el flujo de escalamiento.
Instrumentado: correlacionar
Normalizá service.name, entorno y versión. Agregá trace_id a logs e instrumentá el recorrido principal con OpenTelemetry.
Operable: gestionar SLOs y costos
Reemplazá alertas de infraestructura sin impacto por síntomas. Aplicá presupuestos de error, muestreo por criticidad y atribución de consumo.
Gestionado: automatizar con controles
Automatizá enriquecimiento, tickets y acciones reversibles. Medí si la automatización reduce tiempos sin aumentar riesgo.
Adaptativo: conectar con negocio y seguridad
Relacioná telemetría con conversión, operación y riesgo. Compartí contexto con el SOC y revisá cobertura ante cambios de arquitectura.
Hoja de ruta de 90 días
Primeros 30 días
- Baseline de servicios, herramientas y costos.
- Selección de una experiencia crítica.
- Definición de SLO y owner.
- Prueba de una falla conocida.
Días 31 a 60
- Instrumentación y correlación.
- Rediseño de alertas.
- Convenciones de recursos y logs.
- Tablero de servicio orientado a decisiones.
Días 61 a 90
- Muestreo, retención y presupuesto.
- Playbooks y guardias.
- Medición de tiempos por etapa.
- Plantilla para incorporar el siguiente servicio.
Cómo evitar que el assessment quede en un PDF
Convertí cada brecha prioritaria en una hipótesis medible. Ejemplo: “Si correlacionamos logs y trazas del checkout, el tiempo para localizar la causa bajará de 45 a 15 minutos”. Probalo con un ejercicio controlado y registrá el resultado.
La madurez crece cuando el ciclo se repite: observar, aprender, cambiar y volver a medir.
Próximo paso
CTL puede realizar un assessment de observabilidad y APM con arquitectura, operación, seguridad y costos. Completá el diagnóstico SOC o agendá una reunión.
Preguntas frecuentes
¿El puntaje debe ser igual en toda la empresa?
No. La profundidad debe seguir criticidad y riesgo. Conviene comparar servicios similares y priorizar los que sostienen experiencias críticas.
¿La madurez depende de usar una plataforma única?
No. Varias herramientas pueden funcionar si comparten identidad, procesos y gobierno. Una plataforma única tampoco resuelve datos de mala calidad.
¿Cada cuánto debe repetirse el checklist?
Trimestralmente o después de cambios relevantes. También conviene revisarlo luego de incidentes para verificar si las mejoras se implementaron.