¿Qué son las métricas DORA?

Desarrolladas por el equipo de Investigación y Evaluación de DevOps (DORA) de Google, las métricas DORA proporcionan referencias estándar del sector para la entrega de software y la madurez de DevOps.

En esencia, las métricas DORA se centran en dos dimensiones:

1. Rendimiento: la rapidez con la que los equipos de DevOps pueden lanzar software.
   
   
2. Estabilidad: la fiabilidad y seguridad con las que los equipos de DevOps pueden lanzar software.

Las métricas orientadas al rendimiento revelan la rapidez con la que los cambios en el código avanzan a lo largo del ciclo de vida del desarrollo de software (desde la ideación hasta la producción), mientras que las métricas orientadas a la estabilidad muestran la frecuencia con la que se producen fallos en las implementaciones y la rapidez con la que los equipos se recuperan. En conjunto, proporcionan a los responsables empresariales y a los equipos de DevOps perspectivas fundamentadas en datos y reproducibles sobre el rendimiento de DevOps. Las empresas no tienen que basarse en medidas de rendimiento subjetivas ni en indicadores de vanidad, como las “líneas de código escritas” o las “horas trabajadas”.

El seguimiento de las métricas DORA permite a los equipos de DevOps comparar su rendimiento con los niveles de rendimiento reconocidos en el sector (bajo, medio, alto y de élite) y comprobar si están alineados con los objetivos de toda la empresa. Ayuda a las empresas a identificar de forma objetiva los cuellos de botella en las canalizaciones de integración continua/entrega continua (CI/CD), en las pruebas de software y en la gestión de incidencias.   

Las métricas DORA también facilitan a la dirección la tarea de comunicar el estado de los departamentos de ingeniería a las partes interesadas de la empresa y justifican las inversiones en herramientas avanzadas de automatización, observabilidad e ingeniería de fiabilidad del sitio (SRE) que ayudan a optimizar las prácticas de DevOps.

En el ámbito de DevOps, DORA hace referencia al equipo de Investigación y Evaluación de DevOps que popularizó las métricas de rendimiento organizativo para los equipos de desarrollo de software.

DORA (que ahora forma parte de Google Cloud) comenzó como un proyecto de investigación independiente que estudiaba cómo los procesos de entrega de software afectan a los resultados empresariales. El equipo de DORA estaba interesado en responder a una pregunta clave: ¿qué diferencia a los equipos de software de alto rendimiento de los de bajo rendimiento?

Recopilaron datos de encuestas y telemetría de miles de equipos y descubrieron que un pequeño conjunto de métricas relacionadas con la implementación y las operaciones resultaba un indicador muy fiable del rendimiento general. Concretamente, esas métricas son la frecuencia de implementación, el tiempo de respuesta ante los cambios, la tasa de fallos en los cambios y el tiempo de recuperación tras una implementación fallida. Los resultados también demostraron que la velocidad de lanzamiento y la estabilidad del software pueden ir de la mano, por lo que los equipos no tienen que dar prioridad a una sobre la otra.

Con el tiempo, estos cuatro indicadores se convirtieron en las métricas estándar de DORA, que proporcionaron referencias estándar del sector para el rendimiento en la entrega de software. En 2024, el equipo de investigación de DORA añadió una quinta métrica (el índice de reelaboración de implementaciones) al marco.  

Las cinco métricas DORA pueden agruparse en dos categorías generales: “rendimiento” y “estabilidad”.

Las métricas de rendimiento incluyen frecuencia de implementación, el plazo de ejecución de los cambios y el tiempo de recuperación tras un fallo en la implementación, que en conjunto describen cuántos cambios puede manejar una aplicación y la rapidez con la que los cambios fluyen a producción.

Las métricas de estabilidad incluyen el índice de fallos en los cambios y el índice de reelaboración de la implementación, que miden la proporción de implementaciones que causan fallos y la proporción de implementaciones no planificadas o provocadas por incidentes de producción.

La frecuencia de implementación mide la frecuencia con la que un equipo implementa con éxito el código en producción durante un periodo de tiempo (por día, por semana, por mes).

La frecuencia de implementación es una de las señales más visibles de la agilidad y la confianza que un equipo de software tiene en su proceso de entrega. Cuando un equipo implementa código en producción muchas veces al día, normalmente significa que los procesos automatizados de compilación, prueba e implementación funcionan sin problemas y que existen mecanismos sólidos de observabilidad. Estas condiciones permiten a los equipos de desarrollo lanzar software sin temor a que el sistema deje de funcionar correctamente.

Por el contrario, los equipos que implementan solo una vez al mes (o incluso con menos frecuencia) suelen recurrir a ramas de código de larga duración, pruebas manuales, protocolos de aprobación complejos y grandes jornadas de lanzamiento. Todos estos factores ralentizan el ciclo de feedback de los usuarios y aumentan el coste de la corrección de defectos.

Cabe destacar que una alta frecuencia de implementación no es sinónimo de buen funcionamiento si va acompañada de interrupciones frecuentes o reversiones. Los equipos de alto rendimiento combinan una alta frecuencia de implementación con prácticas sólidas de control de calidad (pruebas automatizadas multinivel, implementaciones escalonadas, indicadores de características y prácticas de monitorización en tiempo real) que les ayudan a realizar lanzamientos con frecuencia, minimizando al mismo tiempo el riesgo para los usuarios.

Desde una perspectiva de liderazgo, el seguimiento de la frecuencia de implementación a lo largo del tiempo puede revelar cuellos de botella en la canalización entrega de software. Por ejemplo, una caída en la frecuencia de implementación tras la introducción de un nuevo comité de aprobación podría indicar que el proceso es demasiado engorroso. Por el contrario, un aumento constante de la frecuencia de implementación (acompañado de una mejora en las métricas de fiabilidad) es un claro indicador de que las inversiones en procesos de CI/CD y en prácticas de DevOps están dando sus frutos.

El plazo de ejecución de los cambios (también denominado plazo de ejecución) mide el tiempo que tarda un cambio en el código en llegar a la fase de implementación y ejecutarse con éxito en el entorno de producción activo, una vez que dicho cambio se ha incorporado a la rama principal del código en un sistema de control de versiones.

Este intervalo de tiempo de principio a fin abarca todo el proceso, incluyendo el tiempo de compilación, la ejecución de pruebas, la revisión del código, las aprobaciones, las etapas de la canalización y la implementación propiamente dicha. Revela la rapidez con la que un sistema puede convertir una decisión en un cambio tangible para los usuarios finales.

Cuando el plazo de ejecución es breve (menos de una hora), las organizaciones pueden responder a los incidentes casi en tiempo real. Por ejemplo, si un equipo de seguridad detecta una vulnerabilidad, el equipo de ingeniería puede implementar una corrección, validarla mediante comprobaciones automatizadas y ponerla en producción en un plazo muy breve. Este rápido ciclo de feedback vincula directamente el trabajo de desarrollo con los resultados empresariales, ya que los equipos pueden medir rápidamente el impacto de los cambios y realizar los ajustes necesarios.

Reducir el tiempo de respuesta ante los cambios casi siempre requiere que los equipos de DevOps automaticen y simplifiquen la canalización de entrega. Este proceso suele incluir la inversión en herramientas de integración continua (CI), de modo que cada confirmación se compile y se pruebe rápidamente, así como la optimización de los procesos de aprobación para que estas se integren en los flujos de trabajo de desarrollo.  

El tiempo de recuperación tras un fallo en la implementación, también denominado tiempo medio de recuperación (MTTR) o tiempo medio de restablecimiento del servicio, evalúa cuánto tiempo se tarda en restablecer el servicio a la normalidad tras un fallo relacionado con la implementación.

La corrección del servicio puede requerir que los desarrolladores reviertan un cambio erróneo, implementen una corrección urgente (un pequeño cambio de código urgente lanzado al margen del ciclo de lanzamiento habitual) o mitiguen de otro modo el impacto del problema, de modo que los usuarios puedan volver a utilizar el sistema con normalidad.

Cuando el tiempo de recuperación es breve (una cuestión de minutos), suele significar que varios componentes de DevOps están funcionando bien en conjunto.

La observabilidad es sólida. Los datos de telemetría en tiempo real (métricas, registros y trazas) se agregan y centralizan por completo en paneles de control. Los incidentes se detectan rápidamente (a menudo de forma automática) y sin esperar a que los usuarios presenten quejas.

Las alertas están ajustadas adecuadamente para que los ingenieros reciban notificaciones de forma inmediata, pero sin verse abrumados por el exceso de información.

Los equipos de DevOps se basan en los “runbooks” (guías tácticas paso a paso para llevar a cabo tareas técnicas), las guías de estrategias (guías estratégicas de nivel superior que describen cómo deben responder los equipos ante una situación) y los procedimientos de reversión documentados. Estos marcos eliminan las conjeturas a la hora de determinar qué hacer en medio de una interrupción del servicio.

Los tiempos de recuperación prolongados (horas o incluso días) suelen indicar prácticas operativas deficientes. Es posible que la detección sea deficiente, por lo que los fallos en producción persisten hasta que los clientes los notifican. El diagnóstico es un proceso lento, ya que la recopilación de datos está dispersa, los mensajes de error son poco claros o los equipos carecen de una visión común sobre cómo se comporta el sistema en modos de fallo. En estos entornos, cada incidente se convierte en un suceso de gran estrés y alto riesgo, en lugar de un ejercicio sencillo de resolución de problemas con un protocolo de resolución claro.

Cuando se combinan con el resto de métricas de DORA, los tiempos de recuperación tras una implementación fallida reducidos contribuyen a garantizar que, incluso si las implementaciones fallan ocasionalmente, el fallo quede contenido y los tiempos de respuesta sean breves.

El índice de fallos en los cambios (CFR) es una métrica de “calidad de la entrega” que indica a los equipos de DevOps con qué frecuencia fallan las implementaciones en entornos de producción en vivo. Cualquier implementación problemática en producción que obligue al equipo a intervenir de inmediato (en lugar de esperar hasta la siguiente versión planificada para resolver el problema) se considera una implementación “fallida”.

El seguimiento del CFR a lo largo del tiempo ayuda a los equipos a comprender el grado de fiabilidad con el que están implementando los cambios y sirve de contrapeso a las métricas de rendimiento (frecuencia de implementación, tiempo de ejecución de los cambios) que dan prioridad a la velocidad.

El CFR suele expresarse como un porcentaje y se calcula dividiendo el número de implementaciones fallidas entre el número total de implementaciones realizadas durante el mismo periodo y multiplicando el resultado por 100.

Un índice de fallos en los cambios bajo indica que un equipo está implementando cambios que, en general, se comportan según lo esperado en producción. Cuando el CFR es bajo y estable, los equipos pueden aumentar con seguridad la frecuencia de implementación y acortar el plazo de ejecución de los cambios sin perjudicar la experiencia del usuario.

Sin embargo, un índice de fallos en los cambios elevado sugiere que un número excesivo de cambios está desestabilizando el sistema. Entre las causas pueden figurar pruebas incompletas o poco fiables, entornos de prueba y de desarrollo que difieren de los de producción, implementaciones demasiado grandes o una monitorización y un sistema de alertas lentos. Un CFR elevado indica que la organización debería dar prioridad a cambios más pequeños e incrementales, así como a prácticas de implementación más seguras (como los lanzamientos “canario”, en los que una nueva aplicación o característica se pone a disposición de un pequeño grupo de usuarios antes del lanzamiento general), de modo que se reduzca el número de cambios que se convierten en incidentes en producción.

El índice de reelaboración de la implementación es una métrica de estabilidad que mide qué proporción de las implementaciones de un equipo requiere reelaboración. Por “reelaboración” se entiende cualquier implementación que se active a raíz de un error o incidente que afecte a los usuarios en producción y que no forme parte del ciclo de lanzamiento original y planificado.

El índice de reelaboración de la implementación complementa las cuatro métricas originales de DORA al hacer visible el trabajo reactivo. Revela qué parte del esfuerzo de desarrollo de un equipo se dedica a subsanar errores pasados en lugar de hacer avanzar el producto.

Un índice de reelaboración bajo suele indicar que los equipos de DevOps detectan la mayoría de los problemas antes de que lleguen a los usuarios finales y dedican la mayor parte de su tiempo a tareas que generan valor (optimizaciones y refactorizaciones planificadas). Un índice de reelaboración elevado significa que los equipos dedican demasiado tiempo a tareas de resolución de problemas urgentes.

Los índices de reelaboración resultan especialmente valiosos cuando se combinan con otras métricas clave. Por ejemplo, si un equipo presenta una alta frecuencia de implementación y un bajo índice de reelaboración, ello indica que el equipo está lanzando nuevas iteraciones de software con rapidez sin sacrificar la calidad. Sin embargo, si el equipo muestra una alta frecuencia de implementación junto con un alto índice de reelaboración, ello sugiere que está lanzando una gran cantidad de código, pero también dedicando mucho tiempo a corregirlo.

Es importante destacar que un índice de reelaboración distinto de cero es normal (y, a menudo, saludable). Incluso los mejores equipos de desarrollo pueden cometer errores, y las aplicaciones de software bien diseñadas seguirán requiriendo mejoras y actualizaciones de características con el paso del tiempo. El objetivo no es alcanzar un 0 % de reelaboración, sino mantenerla en un porcentaje reducido y predecible del total de implementaciones.

Para cada métrica DORA, los equipos se clasifican en uno de los cuatro niveles de rendimiento —élite, alto, medio o bajo— y cada nivel se basa en umbrales establecidos para la métrica. Los umbrales son:

Dado que el índice de reelaboración de la implementación es una métrica relativamente nueva, aún no cuenta con umbrales ni niveles de rendimiento establecidos. No obstante, muchas empresas y equipos de DevOps realizan un seguimiento de sus propios valores de referencia en materia de reelaboración y se fijan como objetivo reducir dicho índice con el paso del tiempo. El uso de los datos sobre el índice de reelaboración, junto con el índice de fallos en los cambios y otras métricas de fiabilidad, ayuda a los equipos a mejorar los índices de reelaboración de la implementación sin llegar a corregir en exceso basándose únicamente en una cifra concreta. 

Las métricas DORA respaldan el enfoque más amplio de DevOps en el desarrollo de software, que da prioridad a la colaboración continua entre equipos multidisciplinares que abarcan las funciones de desarrollo de aplicaciones y operaciones. El éxito de los entornos DevOps depende en gran medida del éxito de los equipos que los componen.

Las métricas DORA permiten a las empresas cuantificar el rendimiento de los equipos según criterios estrechamente alineados con flujos de valor más amplios y resultados empresariales. Por ejemplo, los equipos con un alto rendimiento y los de élite tienen más probabilidades de cumplir los objetivos de rentabilidad, tiempo de comercialización y satisfacción del cliente.

Las culturas DevOps también se caracterizan por un compromiso con la comunicación fluida y la responsabilidad compartida entre las partes interesadas en la entrega de software, todas las cuales colaboran para crear software de alta calidad y acelerar la innovación de productos. Por lo tanto, muchas organizaciones utilizan las métricas DORA para crear un ciclo de feedback de mejora continua. Las métricas miden el rendimiento de cada equipo. Los equipos pueden debatir oportunidades de mejora basadas en las mediciones, experimentar con nuevos enfoques y volver a medir el rendimiento para comprobar qué cambios mejoran realmente las prácticas de entrega.

Es importante destacar que las métricas DORA son de carácter diagnóstico, no punitivo. Ayudan a revelar patrones sistémicos en los procesos de desarrollo, en lugar de centrarse en el trabajo de los desarrolladores a título individual.