Estrategia de métricas y observabilidad: medir sin autoengañarte

Publicado el 18 de febrero de 2026  •  16 minutos  • 3309 palabras

En casi todos los equipos hay un momento mágico en el que alguien abre un panel, señala una gráfica verde y dice: “¿Veis? Estamos genial”. Mientras tanto, soporte está en llamas, la API de pagos se cae a ratos y la gente en desarrollo lleva tres semanas durmiendo regular.

La diferencia entre un equipo sano y uno que vive en ese teatro constante suele estar en cómo usa las métricas: como linterna para ver mejor… o como palo para pegarse entre sí.

Este artículo va de la linterna.

Antes del dashboard: para qué medimos (y para qué no)

Imagina que tu sistema es un avión volando de noche. La instrumentación está ahí para que no te comas una montaña en la niebla, no para que el piloto pueda decir por megafonía “mirad qué bonito se ve todo desde aquí”. Las métricas son exactamente eso: instrumentos .

Medimos para cuatro cosas muy concretas:

• Saber si estamos entregando bien software: con qué frecuencia desplegamos, cuánto tardan los cambios en llegar a producción, cuántos despliegues rompen algo. Ahí entran las métricas DORA .
• Saber si el sistema se comporta bien para el usuario: qué tal vamos de errores, de latencias, de disponibilidad. Ahí viven los SLIs y SLOs .
• Saber si somos capaces de arreglar rápido cuando todo se tuerce: MTTR , tiempo de detección, tiempo de respuesta.
• Saber cómo se vive desde dentro del equipo: cuánto tiempo dedicamos a apagar fuegos, cuánto a trabajo planificado, cuánto perdemos esperando builds eternos o approvals absurdos .

Claro que, ciertas empresas, equipos o managers suelen convertir las métricas en otras cosas:

• Un ranking de gladiadores (“el dev con más tickets cerrados”, “el que más commits hace”).
• Un decorado para justificar decisiones que ya estaban tomadas.
• Un numerito simpático que optimizamos aunque no tenga nada que ver con el valor real (hola, story points por sprint).

Si tus métricas no ayudan a tomar decisiones mejores ni a trabajar con menos dolor, no son métricas: son decoración.

Logs, métricas y trazas: el trío que te cuenta la película

La jerga de “observabilidad” puede sonar a un palabro (buzzword) más, pero en el fondo va de tres tipos de señales que responden preguntas distintas .

Logs: qué leches ha pasado

Los logs son el diario del sistema. Ahí apuntas errores, peticiones, cambios de estado, decisiones de negocio. “order_id=1234, status=PAID, payment_provider=stripe” es un buen log: te dice qué ha ocurrido, a quién y en qué contexto.

Un ejemplo muy real que he sufrido: Un usuario jura que le habéis cobrado dos veces. Si en los logs solo ves Error occurred y poco más, estás vendido. Si ves el viaje del pedido, los intentos de pago y los callbacks del proveedor, puedes reconstruir la escena y responder con algo mejor que “hemos abierto un ticket”.

Métricas: cómo de sano está todo a vista de pájaro

Las métricas son números agregados a lo largo del tiempo: CPU, memoria, latencia p95, tasa de errores, número de jobs pendientes en una cola, etc. No te cuentan la historia completa, pero sí te dicen “hay algo raro aquí”.

Una gráfica de http_server_requests_seconds que se dispara en la API de pagos, o un queue_length{queue="emails"} creciendo sin parar, son formas elegantes de que el sistema te grite “ojocuidado! estoy a punto de petar!” antes de que lo hagan los usuarios.

Trazas: quién hizo qué con una petición

Las trazas son el mapa del viaje de una petición a través de tus servicios. En un mundo de microservicios, ver que checkout-api llama a cart-service, luego a pricing-service, luego a payment-gateway y finalmente a email-service, con tiempos y errores, es oro puro.

Cuando un usuario pulsa “comprar” y todo va lento, la traza te deja ver si el problema está en la base de datos, en el gateway de pagos o en ese servicio misterioso que nadie quiere tocar desde 2013.

Si lo juntamos todo:

• Las métricas te dicen “algo va mal aquí”.
• Las trazas te dicen “va mal exactamente en este punto del flujo”.
• Los logs te cuentan “y esto fue lo que pasó cuando explotó”.

Ese es el nivel de observabilidad que quieres, no 200 dashboards bonitos para enseñar en la review trimestral.

SLI, SLO y SLA: ponerle números a “funciona más o menos”

Cuando negocio pregunta “¿esto funciona bien?”, tú puedes contestar con “sí, más o menos” o puedes hablar de SLOs. La segunda opción suele generar menos discusiones y menos correos pasivo-agresivos.

Resumiendo mucho:

• Un SLI es algo que mides: porcentaje de peticiones exitosas, latencia p95, tasa de errores 5xx.
• Un SLO es el objetivo que te marcas sobre ese SLI: “queremos que al menos el 99,9% de los pagos se completen con éxito al mes”.
• Un SLA es lo que prometes al cliente por contrato: “si el uptime mensual baja de 99,5%, te devolvemos dinero”.

La gracia de los SLOs, como insiste el mundo SRE, es que no son adornos: te dan un presupuesto de error. Si tu SLO es 99,9%, estás aceptando explícitamente que un 0,1% de peticiones puede fallar. Ese margen es lo que te dice:

• Cuánto puedes apretar con nuevas features.
• Cuándo deberías levantar el freno y dedicarte a arreglar cosas en serio.

Si en dos semanas te has comido ya el 80% de tu error budget en la API crítica, igual no es el mejor momento para el “gran rediseño” que toca todas las piezas a la vez. O sí… pero al menos sabrás que estás jugando a la ruleta rusa con datos delante.

4. DORA: medir cómo entregas, no si estás “ocupado”

Las métricas DORA son como ese amigo que, cuando le cuentas lo liado que estás, te contesta: “vale, pero… ¿qué has hecho realmente?”. Van de la capacidad de tu sistema para entregar cambios, no de lo mucho que corres por el pasillo.

Son cuatro (más un quinto en las últimas iteraciones ):

• Deployment frequency: cuántas veces pones cambios en producción.
• Lead time for changes: cuánto tarda un cambio desde que se hace hasta que llega a producción.
• Change failure rate: qué porcentaje de despliegues rompe algo (rollback, hotfix, incidente).
• MTTR: cuánto tardas en arreglar el estropicio cuando pasa.
• Y, cada vez más, una noción de reliability general.

Imagina dos equipos:

• El equipo A despliega una vez al mes, tarda 3 semanas en llevar un cambio a producción, rompe el 5% de las releases y tarda un día en recuperarse.
• El equipo B despliega a diario, tarda 1 día en que un cambio llegue a prod, rompe también un 5% de las releases… pero tarda una hora en recuperarse.

¿Quién “trabaja más”? Da igual. El equipo B tiene un sistema de entrega diseñado para absorber cambios frecuentes y fallos baratos: más deploys, más pequeños, más reversibles. Eso es lo que correlaciona con organizaciones de alto rendimiento, no el número de tickets cerrados.

DORA es, en esencia, un antídoto contra el teatro de productividad.

MTTR y amigos: cómo de rápido te levantas del suelo

Más allá de DORA, hay otra familia de métricas que cuentan historias muy humanas: las de incidentes.

• MTTR : cuánto tiempo estás roto de media.
• MTTD: cuánto tardas en darte cuenta de que estás roto (spoiler: a veces te enteras por Twitter).
• MTTA: cuánto tiempo pasa hasta que alguien dice “vale, esto es mío, me ocupo”.

Aquí es donde una buena observabilidad se nota. Sin ella, el flujo es algo así:

Cliente cabreado → Slack/Teams ardiendo → 30 minutos para reproducir el fallo → 1 hora de “a ver qué servicio es” → otra más hasta que alguien encuentra la query asesina.

Con métricas, logs y trazas decentes, el guion cambia:

A los 2 minutos salta una alerta de que la tasa de errores en checkout se ha disparado. Ves que la latencia en payment-service se ha ido a las nubes. Abres una traza y descubres que la llamada al proveedor externo tarda 10 segundos por algo que han cambiado ellos. Puedes mitigar, hacer rollback, degradar funcionalidad, visitar las instalaciones del proveedor con una motosierra… y todo antes de que medio mundo te haya abierto un ticket.

No se trata de que no haya incidentes (eso es fantasía), sino de que no sean siniestros totales cada vez.

Métricas buenas, métricas tóxicas

Una métrica sana cambia tu comportamiento para mejor. Una métrica tóxica, en cambio, solo cambia cómo juegas con el sistema.

Y en ingeniería llevamos años jugando muy bien con sistemas mal diseñados.

Algunos ejemplos de métricas que suelen ayudar serían:

• SLOs centrados en el usuario: “la página de checkout responde en menos de X ms el 99% del tiempo”, “la tasa de errores en login es menor de Y %”.
• Métricas DORA, cuando se usan para ver al equipo, no para competir entre personas.
• Defectos en producción por área funcional, para ver qué parte del sistema necesita más cariño.
• Porcentaje de trabajo no planificado vs planificado.

Y luego tienes ejemplos de métricas que se tuercen en cuanto las miras mal:

• Story points por persona / por sprint.
• Commits por desarrollador.
• Número de PRs cerradas.
• Horas “en la oficina” o “conectado al Slack”.

Si una métrica se puede “trampear” fácilmente sin mejorar nada -por ejemplo, trocear tareas en mil PRs diminutas para parecer más productivo-, alguien acabará haciéndolo. Y si encima la conviertes en KPI, le pones una medalla a ese comportamiento .

Tu estrategia debería ser algo así como:

• Pocas métricas, bien elegidas, a nivel de sistema o equipo.
• Revisarlas con el equipo, no lanzarlas desde una torre de marfil.
• Preguntarte periódicamente: “¿Estamos cambiando algo real gracias a estos datos, o solo perseguimos que el numerito salga bonito?”.

Seguridad y coste: los dos sitios donde más se miente

Hay dos áreas donde las métricas suelen ser especialmente surrealistas.

Seguridad

El clásico: “tenemos 300 vulnerabilidades abiertas, tenemos que bajar ese número”. Sin contexto. Sin prioridades. Sin diferenciar un CVE crítico en internet de un falso positivo en un entorno aislado.

Una aproximación más seria mira cosas como:

• Cuánto tardas en resolver vulnerabilidades críticas que sí te afectan.
• Cuántos incidentes de seguridad reales has tenido.
• Cuántas features pasan por threat modeling o revisiones de seguridad antes de ir a producción.

Y sí, también aquí logs, métricas y trazas importan: es difícil investigar un ataque si no puedes reconstruir qué ha pasado.

Coste (FinOps)

Otra joya: “gastamos demasiado en cloud, hay que bajar el gasto un 30%”. Sin decir qué parte del sistema genera valor, qué parte está infrautilizada o qué significa “demasiado”.

Hablar de coste en serio implica cosas como:

• Coste por servicio, por entorno, por unidad de negocio.
• Coste por transacción, por 1.000 peticiones, por cliente activo.
• Relacionar eso con métricas de valor (clientes que retienes, ingresos, margen).

Una estrategia decente de métricas y observabilidad te deja hablar de “este patrón de acceso a datos nos cuesta X al mes y nos aporta Y; ¿nos compensa?” en vez de limitarte a llorar delante de la factura.

DevEx: medir cómo de horrible es tu día a día

La experiencia del desarrollador (DevEx) no es una cosa etérea; tiene síntomas muy medibles. En lugar de preguntar “¿estás feliz?” y ya, puedes fijarte en cosas concretas:

• Cuánto tardas desde “quiero hacer un cambio” hasta tener un entorno listo.
• Cuánto dura el build y la suite de tests en cada commit.
• Cuántas veces a la semana te bloquea otro equipo, una aprobación manual, un proceso absurdo.
• Cuánta parte de tu tiempo se va a apagar fuegos frente a avanzar trabajo planificado.

Existen informes recientes sobre productividad de desarrolladores que apuntan precisamente a estos factores como determinantes: no es tanto cuántas horas picas código, sino cuántas de esas horas son aprovechables.

Medir DevEx no es terapia de grupo; es una forma elegante de justificar por qué merece la pena invertir en mejores pipelines, mejores herramientas o menos reuniones.

Y entonces… ¿para qué sirve la retro?

Si ya hay métricas de DevEx, DORA, SLOs y medio observatorio montado, la tentación es pensar que la retrospectiva de Scrum sobra. No sobra, pero tampoco funciona como la vendieron.

La idea original es bonita: el equipo se reúne cada sprint, habla de qué fue bien, qué fue mal, y acuerda acciones concretas para mejorar. Sobre el papel, es un motor de mejora continua. En la práctica, la mayoría de las retros siguen un guion bastante predecible:

1. Alguien dice “los deploys tardan mucho”.
2. Otro dice “me bloqueé esperando la respuesta de otro equipo”.
3. Un tercero dice “las reuniones nos comen la vida”.
4. Se apuntan dos o tres “action items” en un post-it.
5. En la siguiente retro, nadie se acuerda de los action items anteriores y se repiten las mismas quejas.

¿El problema de fondo? No hay datos. Es todo percepción. Y las percepciones, aunque sean válidas y reales, tienen dos defectos enormes como motor de cambio:

• No se pueden priorizar con rigor. “Los deploys tardan mucho” puede significar 8 minutos o 45. “Me bloqueé esperando” puede haber sido una vez esa semana o todos los días. Sin números, todo pesa lo mismo, así que se acaba actuando sobre lo que más ruido hace en la sala, no sobre lo que más impacto tiene.
• No se puede verificar si la acción ha servido. Si decidimos “mejorar los deploys”, ¿cómo sabemos en la siguiente retro que lo hemos conseguido? Con otra percepción: “sí, parece que va un poco mejor”. O peor: nadie se acuerda y la acción muere en silencio.

Compara eso con lo que pasa cuando la retro tiene datos reales delante:

De repente, la conversación cambia de raíz. Ya no es “me parece que…”, es “los datos muestran que…, ¿por qué?” Y ese “¿por qué?” es exactamente donde la retro sí brilla: en discutir causas, contexto, matices y posibles soluciones.

Lo que la retro no puede hacer sola -y donde fracasa constantemente- es detectar el problema y medir si la solución ha funcionado. Para eso necesitas métricas.

Dicho de otra forma:

• Las métricas te dicen qué está pasando y cuánto duele.
• La retro te ayuda a discutir por qué pasa y qué vais a hacer.
• Las métricas de la siguiente iteración te confirman si lo que habéis hecho ha servido de algo.

Sin ese ciclo completo, la retro es una sesión de desahogo periódica disfrazada de proceso de mejora. Útil para la moral (a veces), inútil para cambiar nada estructural.

Y hay otro problema que rara vez se menciona: las retros premian las quejas articuladas, no los problemas importantes. El developer senior que habla claro y con carisma consigue que su molestia se convierta en action item; el junior que lleva semanas peleándose con un entorno de desarrollo roto no dice nada porque “bueno, será que soy yo”. Con datos de DevEx (tiempo de setup de entorno, tiempos de build, frecuencia de bloqueos por dependencias externas), ese problema sale a la luz sin necesidad de que nadie se atreva a levantarlo en una sala.

¿Significa esto que hay que eliminar las retros? No. Significa que hay que dejar de pedirles lo que no pueden dar: diagnóstico y seguimiento. La retro funciona cuando llega con los deberes hechos -datos encima de la mesa- y se dedica a lo que sí sabe hacer: generar conversación, contexto y compromiso del equipo con una acción concreta y verificable.

La fórmula que mejor funciona, resumida sin florituras:

• Antes de la retro: prepara 3-4 métricas relevantes del sprint (lead time, change failure rate, % de trabajo no planificado, algún SLO clave). No hace falta un dashboard de la NASA; un par de gráficas simples bastan.
• Durante la retro: presenta los datos, deja que el equipo reaccione y discuta causas. Acuerda una acción concreta (no cinco) con un resultado esperado medible.
• En la siguiente retro: lo primero que miras es si la métrica que motivó la acción ha cambiado. Si sí, celebra. Si no, discute por qué y decide si insistir o cambiar de enfoque.

Eso convierte la retro de un ritual de post-its a un ciclo real de mejora. Y de paso, resuelve el problema más habitual: que las acciones se evaporen entre sprint y sprint porque nadie les hace seguimiento con algo más sólido que la memoria colectiva.

Y si crees que me afecta o cabrea especialmente la ineficacia de las retros, y quizás por eso le he dedicado más espacio a este apartado, estas en lo cierto. El aspecto humano del desarrollo de software, requiere uno o muchos artículos, y pronto te hablaré sobre este Juego de Tronos.

El “mínimo decente” para no ir a ciegas

Como conclusión a este artículo, y para que te lleves un recordatorio útil, si tuviera que definir un paquete básico, algo así como “observabilidad y métricas para equipos normales que no quieren montar un centro de control de la NASA”, sería esto:

• Un puñado de SLOs claros ligados a cosas que le importan al usuario (2-3 operaciones clave, su disponibilidad y latencia).
• Métricas DORA aunque sea de forma aproximada, para ver si vas a mejor o a peor en cómo entregas.
• Logs estructurados , métricas técnicas y de negocio, y trazas al menos en los servicios críticos.
• Una revisión periódica con el equipo donde se pregunte:
  • Qué estamos viendo.
  • Qué vamos a cambiar a raíz de eso.
  • Qué métricas podemos tirar a la basura porque ya no ayudan.

No hace falta empezar con todo automatizado ni con la herramienta más cara del mercado. Hace falta, sobre todo, tener claro que las métricas están al servicio de las decisiones y de la gente, no al revés.

Si tus gráficos no te ayudan a detectar problemas antes que tus usuarios, a entregar mejor y a tomar decisiones más inteligentes sobre diseño, seguridad y coste, entonces sí: son solo dibujitos bonitos para la próxima presentación. Y para eso, francamente, ya está PowerPoint.

Glosario rápido

• SRE (Site Reliability Engineering): disciplina (y rol) que combina ingeniería de software con operaciones de infraestructura. Se centra en construir sistemas escalables y fiables. Popularizada por Google .
• p95 / p99 (percentil 95 / 99): el valor por debajo del cual caen el 95% o 99% de las observaciones. Si la latencia p95 de tu API es 200 ms, el 95% de las peticiones tardan menos que eso; el 5% restante es donde suelen esconderse los problemas.
• Error budget (presupuesto de error): el margen de fallo aceptable que se deriva de tu SLO. Si tu objetivo es 99,9% de disponibilidad, tu error budget es ese 0,1%. Mientras te quede margen, puedes asumir riesgo; cuando se agota, toca parar y estabilizar.
• CVE (Common Vulnerabilities and Exposures): identificador único para vulnerabilidades de seguridad conocidas públicamente (por ejemplo, CVE-2024-12345).
• FinOps: práctica de gestión financiera del gasto en cloud que combina finanzas, tecnología y negocio para tomar decisiones informadas sobre coste e inversión en infraestructura.
• Threat modeling: ejercicio de diseño seguro en el que se identifican amenazas, superficies de ataque y controles necesarios antes de escribir código, no después.

Fuentes y referencias

• The Pillars of Observability - IBM
• DORA Metrics Guide - DORA
• Service Level Objectives - Google SRE Book
• SRE Fundamentals: SLIs, SLAs and SLOs - Google Cloud Blog
• Mastering DORA Metrics: A Practical Guide - FreyaFusion
• The 2024 State of Developer Productivity - Cortex
• DORA Metrics: History - DORA
• Developer Productivity Metrics: Missing the Point - Swarmia
• CVE - Fortinet
• Secure by Design: The Complete Guide - Checkpoint
• Practice Security by Design - Salesforce Trailhead
• How to Implement and Track DORA Metrics - Port