Definición: Conjunto de cuatro metricas clave que miden el rendimiento de los equipos de ingenieria en entrega de software: frecuencia de despliegue, lead time, MTTR y tasa de fallos.
— Fuente: NERVICO, Consultoría de Desarrollo de Producto
Que son las DORA metrics
Las DORA metrics (DevOps Research and Assessment) son un conjunto de cuatro metricas clave identificadas por el equipo de investigacion DORA de Google para medir el rendimiento de los equipos de ingenieria de software. Las cuatro metricas son: frecuencia de despliegue (con que frecuencia se despliega a produccion), lead time for changes (tiempo desde que se hace commit hasta que el codigo esta en produccion), tiempo de recuperacion ante fallos (MTTR, cuanto tarda en restaurarse el servicio tras una incidencia) y tasa de fallos en cambios (porcentaje de despliegues que causan un fallo en produccion).
Como funcionan
Las metricas se clasifican en cuatro niveles de rendimiento: elite, alto, medio y bajo. Los equipos elite despliegan multiples veces al dia, tienen un lead time inferior a una hora, se recuperan de fallos en menos de una hora y su tasa de fallos es inferior al 5%. Los equipos de bajo rendimiento despliegan menos de una vez al mes, su lead time es superior a seis meses, tardan mas de una semana en recuperarse y mas del 46% de sus despliegues causan fallos. Las metricas se recopilan automaticamente a traves de herramientas de CI/CD, sistemas de monitorizacion y registros de incidentes.
Por que importan
Las DORA metrics proporcionan evidencia empirica de que velocidad y estabilidad no estan reñidas: los equipos elite son mas rapidos y mas fiables que los equipos de bajo rendimiento. Esto contrarresta la creencia comun de que ir rapido implica mas errores. Ademas, ofrecen un benchmark objetivo para que los equipos evaluen su rendimiento, identifiquen areas de mejora y midan el impacto de los cambios en sus practicas de ingenieria.
Ejemplo practico
Un equipo de desarrollo mide sus DORA metrics y descubre que despliega una vez por semana (rendimiento medio), pero su lead time es de 10 dias (rendimiento bajo) porque el proceso de code review tarda una media de 5 dias. Implementan un acuerdo de equipo para revisar pull requests en menos de 4 horas y adoptan trunk-based development con feature flags. Tres meses despues, despliegan dos veces al dia, el lead time baja a 3 horas, el MTTR se reduce de 4 horas a 30 minutos y la tasa de fallos se mantiene estable en el 8%.