«Vamos bien» no es un dato. Es una sensación, normalmente la del equipo que más cerca está del código y menos cerca de las consecuencias. Cuando entramos en una organización que lleva un par de años invirtiendo en DevOps, la primera pregunta incómoda suele ser esta: ¿en qué se nota, exactamente?
Las métricas DORA existen para responderla. Son cuatro, llevan más de una década validándose sobre decenas de miles de organizaciones, y su virtud principal es que son difíciles de discutir.
Las cuatro, en términos de negocio
Frecuencia de despliegue. Cuántas veces llevas cambios a producción. Traducido: con qué rapidez puedes reaccionar a lo que pide el mercado. Una empresa que despliega una vez al mes no puede responder a un competidor en dos semanas, por buenas que sean sus ideas.
Lead time para cambios. Cuánto tarda una línea de código desde que se confirma hasta que da servicio. Es el que mejor refleja la fricción real del proceso, porque incluye todas las esperas que nadie contabiliza: revisiones paradas, entornos ocupados, ventanas de despliegue.
Tasa de fallos en cambios. Qué porcentaje de despliegues acaba provocando una incidencia. Es tu indicador de calidad, y el contrapeso necesario de los dos anteriores.
Tiempo de restauración del servicio. Cuánto tardas en volver a la normalidad cuando algo se rompe. En la práctica es la métrica que más nota el cliente final y la que menos suele estar medida.
Lo interesante está en la combinación
Ninguna de las cuatro dice gran cosa por separado. Leídas juntas, dibujan un diagnóstico bastante preciso.
- Despliegas mucho y fallas mucho: tienes velocidad pero te falta red de seguridad. El problema no es desplegar tanto, es la cobertura de pruebas y la capacidad de revertir.
- Despliegas poco y aun así fallas: el caso más doloroso. Suele significar lotes de cambios enormes: cuando algo sale mal, nadie sabe cuál de las cuarenta cosas que iban dentro lo rompió.
- Despliegas poco y no fallas: parece bueno y casi nunca lo es. Normalmente hay un proceso de aprobación tan pesado que la organización ha aprendido a no tocar nada. La estabilidad es real; el coste de oportunidad, invisible.
- Despliegas mucho, fallas poco y te recuperas rápido: aquí es donde quieres estar, y llegar no es cuestión de herramientas sino de automatización de pruebas y despliegues progresivos.
Cómo empezar a medirlas sin montar un proyecto
El error clásico es convertir la medición en una iniciativa de seis meses con su propio comité. No hace falta.
Las dos primeras métricas ya están en tus sistemas: tu plataforma de CI/CD sabe cuántos despliegues ha hecho y tu repositorio sabe cuándo se confirmó cada cambio. Con exportar esos dos datos a una hoja de cálculo durante un mes ya tienes una línea base honesta.
Las dos segundas dependen de que registres incidencias con un mínimo de disciplina: cuándo empezó, cuándo se resolvió y si la provocó un despliegue. Si hoy no lo haces, empezar a hacerlo cuesta menos que cualquier herramienta que puedas comprar.
Mide durante un mes antes de intentar mejorar nada. Sin línea base, cualquier mejora posterior es una anécdota.
Las trampas
En cuanto una métrica se convierte en objetivo, deja de ser una buena métrica. Es la ley de Goodhart y con DORA se cumple con una puntualidad casi cómica.
Si premias la frecuencia de despliegue, alguien empezará a partir un cambio en seis para inflar el contador. Si penalizas la tasa de fallos, dejarán de registrarse incidencias menores. Si el objetivo es el tiempo de recuperación, se cerrarán incidencias antes de haberlas resuelto del todo.
Dos reglas que aplicamos siempre: estas métricas se miden a nivel de equipo o de sistema, nunca de persona; y sirven para detectar tendencias y abrir conversaciones, no para evaluar a nadie. En el momento en que aparecen en una revisión de desempeño, los números dejan de ser fiables para siempre.
¿Quieres saber en qué punto está tu equipo? Hablemos de tu proceso de entrega →
Sigue leyendo
- Un pipeline de CI/CD en GitHub Actions listo para producción
- Seguridad en el pipeline sin frenar al equipo
Puedes ver todo lo que hacemos en servicios, o echar un vistazo a los tipos de proyecto que solemos abordar.