¿Qué son las métricas de DORA?

Desarrolladas por el equipo de Investigación y Evaluación DevOps (DORA) de Google, las métricas de DORA proporcionan puntos de referencia de la industria para la entrega de software y la madurez de DevOps.

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

1. Rendimiento: la rapidez con la que los equipos de DevOps pueden enviar software.
   
   
2. Estabilidad: con qué confiabilidad y seguridad los equipos de DevOps pueden distribuir software.

Las métricas orientadas al rendimiento muestran la rapidez con la que los cambios de 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 con qué frecuencia se averían los despliegues y la rapidez con la que se recuperan los equipos. En conjunto, brindan a los líderes empresariales y a los equipos de DevOps insights reproducibles y basados en evidencia sobre el rendimiento de DevOps. Las empresas no tienen que depender de medidas subjetivas de rendimiento o indicadores de vanidad como “líneas de código escritas” u “horas trabajadas”.

El seguimiento de las métricas de DORA permite a los equipos de DevOps ver cómo se comparan en la pila con los niveles de rendimiento reconocidos por la industria (bajo, medio, alto y élite) y si están alineados con los objetivos de toda la empresa. Ayuda a las empresas a identificar objetivamente cuellos de botella en los pipelines de integración continua/entrega continua (CI/CD), las pruebas de software y la gestión de incidentes.   

Las métricas de DORA también facilitan que el equipo de liderazgo comunique el estado de los departamentos de ingeniería a los stakeholders empresariales y justifican inversiones en las herramientas avanzadas de automatización, observabilidad e ingeniería de confiabilidad del sitio (SRE) que ayudan a optimizar las prácticas DevOps.

En DevOps, DORA se refiere al equipo de Investigación y evaluación de DevOps que popularizó las métricas de rendimiento organizacional para los equipos de desarrollo de software.

DORA, ahora parte de Google Cloud, comenzó como un proyecto de investigación independiente que estudió cómo los procesos de entrega de software afectan los resultados empresariales. El equipo de DORA estaba interesado en responder 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 encontraron que un pequeño conjunto de métricas relacionadas con la entrega y las operaciones era muy predictivo del rendimiento global. A saber, esas métricas son la frecuencia de despliegue, el plazo de entrega de los cambios, la tasa de fallas de cambio y el tiempo de recuperación de despliegue fallido. 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 priorizar uno sobre el otro.

Con el tiempo, los cuatro indicadores se convirtieron en las métricas estándar de DORA, que proporcionaron puntos de referencia estándar de la industria para el rendimiento en la entrega de software. En 2024, el equipo de investigación de DORA agregó una quinta métrica, la tasa de reestructuración del despliegue, al marco.  

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

Las métricas de rendimiento incluyen la frecuencia de despliegue, el plazo de entrega de los cambios y el tiempo de recuperación de despliegue fallido, que en conjunto describen cuántos cambios puede manejar una aplicación y la rapidez con que los cambios fluyen hacia la producción.

Las métricas de estabilidad incluyen la tasa de fallas por cambios y la tasa de reestructuración del despliegue, que miden la proporción de despliegues que causan fallas y la proporción de despliegues no planificados o provocados por incidentes de producción.

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

La frecuencia de despliegue es una de las señales más visibles de cuán ágil y seguro es un equipo de software en su proceso de entrega. Cuando un equipo despliega código en producción muchas veces al día, generalmente significa que los procesos automatizados de compilación, prueba y despliegue se ejecutan sin problemas y que existen mecanismos de observabilidad sólidos. Estas condiciones permiten a los equipos de desarrollo lanzar software sin temor a dañar el sistema.

Por el contrario, los equipos que despliegan solo una vez al mes (o incluso con menos frecuencia) a menudo dependen de ramas de código de larga duración, pruebas manuales, protocolos de aprobación complejos y grandes días de lanzamiento. Todos estos factores ralentizan el ciclo de feedback de los usuarios y aumentan el costo de arreglar los defectos.

En particular, la alta frecuencia de despliegue no es un signo de estado si viene con interrupciones o reversiones frecuentes. Los equipos de alto rendimiento combinan una alta frecuencia de despliegue con prácticas sólidas de garantía de calidad (pruebas automatizadas multinivel, despliegues escalonados, indicadores de características y prácticas de monitoreo en tiempo real) que ayudan a los equipos a realizar envíos con frecuencia y minimizan el riesgo para los usuarios.

Desde una perspectiva de liderazgo, hacer un seguimiento de la frecuencia de despliegue a lo largo del tiempo puede revelar cuellos de botella en el pipeline de entrega del software. Por ejemplo, una disminución en la frecuencia de despliegue después de introducir una nueva junta de aprobación podría indicar que el proceso es demasiado pesado. Por el contrario, un aumento constante en la frecuencia de despliegue, junto con la mejora de las métricas de confiabilidad, es un indicador sólido de que las inversiones en pipelines de CI/CD y las prácticas de DevOps están dando sus frutos.

El plazo o tiempo de entrega de los cambios mide la cantidad de tiempo que tarda un cambio de código en llegar al despliegue y ejecutarse correctamente en producción en vivo después de que el cambio se haya confirmado en la rama de código principal en un sistema de control de versiones.

Esta ventana de principio a fin captura todo, incluido el tiempo de compilación, la ejecución de pruebas, la revisión de código, las aprobaciones, las etapas del pipeline y el despliegue real. Revela la rapidez con la que un sistema puede convertir una decisión en un cambio tangible para los usuarios finales.

Cuando el tiempo de entrega es corto (menos de una hora), las organizaciones pueden responder a los incidentes casi en tiempo real. Por ejemplo, si un equipo de seguridad muestra una vulnerabilidad, el equipo de ingeniería puede implementar un arreglo, validarlo a través de verificaciones automatizadas y ponerlo en marcha en un lapso muy corto. Este rápido ciclo de feedback vincula el trabajo de desarrollo directamente a los resultados del negocio, porque los equipos pueden medir el impacto de los cambios rápidamente y ajustarse en consecuencia.

Reducir el plazo de entrega del cambio casi siempre requiere que los equipos DevOps automaticen y simplifiquen el pipeline de entrega. Este proceso suele incluir invertir en herramientas de integración continua (CI) para que cada commit se construya y pruebe rápidamente, y agilizar los procesos de aprobación para que las aprobaciones se integren con los flujos de trabajo de desarrollo.  

El tiempo de recuperación tras un fallo en el despliegue, también llamado tiempo medio de recuperación (MTTR) o tiempo medio de restauración del servicio, evalúa cuánto tiempo se tarda en restablecer el servicio a la normalidad luego de una falla relacionada con el despliegue.

La corrección del servicio puede requerir que los desarrolladores reviertan un cambio malo, desplieguen un hotfix (un pequeño cambio urgente de código publicado fuera del ciclo normal de versión) o, de otro modo, mitiguen el impacto del problema para que los usuarios puedan volver a usar el sistema con normalidad.

Cuando el tiempo de recuperación es corto (cuestión de minutos), generalmente significa que varios componentes de DevOps funcionan bien juntos.

La observabilidad es fuerte. Los datos de telemetría en tiempo real —métricas, registros y rastros— están completamente agregados y centralizados en los paneles. Los incidentes se detectan rápido (a menudo automáticamente) y sin esperar a que los usuarios se quejen.

El sistema de alertas está configurado adecuadamente para que los ingenieros reciban notificaciones con prontitud, pero sin verse abrumados por el ruido.

Los equipos DevOps confían en runbooks (guías tácticas paso a paso para llevar a cabo tareas técnicas), playbooks (guías estratégicas de nivel superior que describen cómo los equipos deben responder a una situación) y procedimientos de reversión documentados. Estos marcos de trabajo 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) a menudo indican prácticas operativas débiles. La detección puede ser deficiente, por lo que las fallas de producción persisten hasta que los clientes las informan. El diagnóstico es un proceso lento, porque la recopilación de datos está dispersa, los mensajes de error no son claros o los equipos carecen de una comprensión compartida de cómo se comporta el sistema en los modos de falla. En estos entornos, cada incidente se convierte en un evento de alto 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 las otras métricas de DORA, los bajos tiempos de recuperación de despliegues fallidos ayudan a garantizar que, incluso si los despliegues fallan ocasionalmente, la falla se contiene y los tiempos de respuesta son cortos.

La tasa de fallas de cambio (CFR) es una métrica de “calidad de entrega” que indica a los equipos de DevOps con qué frecuencia fallan los despliegues en entornos de producción en vivo. Cualquier despliegue de producción problemático que obligue al equipo a intervenir de inmediato, en lugar de esperar hasta la próxima versión planificada para abordar el problema, se considera un despliegue “fallido”.

El seguimiento de la CFR a lo largo del tiempo ayuda a los equipos a comprender la confiabilidad con la que entregan cambios y sirve como un contrapeso a las métricas de rendimiento (frecuencia de despliegue, plazo de entrega para los cambios) que priorizan la velocidad.

La CFR generalmente se expresa como un porcentaje y se calcula dividiendo el número de despliegues fallidos por el número total de despliegues durante el mismo periodo y luego multiplicándolo por 100.

Una tasa baja de fallas de cambios indica que un equipo está enviando cambios que generalmente se comportan como se espera en producción. Cuando la CFR es baja y estable, los equipos pueden aumentar la frecuencia de despliegue de forma segura y acortar el tiempo de entrega de los cambios sin perjudicar la experiencia del usuario.

Sin embargo, una alta tasa de fallas en los cambios sugiere que demasiados cambios están desestabilizando el sistema. Las causas pueden incluir pruebas incompletas o poco confiables, entornos de fase y pruebas diferentes a los de producción, despliegues demasiado grandes o monitoreo y alerta lentos. Una CFR alta indica que la organización debe priorizar cambios más pequeños e incrementales y prácticas de despliegue más seguras (como versiones canary, donde una nueva aplicación o característica se implementa para un pequeño grupo de usuarios antes del lanzamiento más amplio) para que menos cambios se conviertan en producción incidentes.

La tasa de repetición del trabajo de despliegue es una métrica de estabilidad que mide qué fracción de los despliegues de un equipo corresponde a una reestructuración. “Repetición del trabajo” se refiere a cualquier despliegue que se desencadene por un error o incidente relacionado con el usuario en producción y que no forma parte del tren de lanzamiento planificado original.

La tasa de repetición del trabajo de complementa las cuatro métricas originales de DORA al hacer visible el trabajo reactivo. Revela cuánto del esfuerzo de desarrollo de un equipo se dedica a corregir errores pasados en lugar de hacer avanzar el producto.

Una tasa baja de repetición del trabajo generalmente indica que los equipos de DevOps están detectando la mayoría de los problemas antes de que lleguen a los usuarios finales y dedican la mayor parte de su tiempo a realizar trabajo de creación de valor (optimizaciones planificadas y refactorizaciones). Una tasa alta de repetición del trabajo significa que los equipos dedican demasiado tiempo a las tareas de extinción de incendios.

Las tasas de repetición del trabajo son especialmente valiosas cuando se combinan con otras métricas clave. Por ejemplo, si un equipo tiene una alta frecuencia de despliegue y una tasa baja de repetición del trabajo, indica que el equipo está enviando nuevas iteraciones de software rápidamente sin sacrificar la calidad. Pero si el equipo muestra una frecuencia alta de despliegue junto con una tasa alta de repetición del trabajo, sugiere que están enviando mucho código pero también dedicando mucho tiempo a arreglarlo.

Es importante destacar que una tasa de repetición del trabajo distinta de cero es normal (y a menudo saludable). Incluso los mejores equipos de desarrollo pueden cometer errores, y las aplicaciones de software bien construidas aún requerirán mejoras y actualizaciones de características a lo largo del tiempo. El objetivo no es llegar al 0 % de repetición del trabajo, sino mantenerlo en un porcentaje pequeño y predecible de todos los despliegues.

Para cada métrica de 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:

Debido a que la tasa de repetición del trabajo de despliegue es una métrica más nueva, aún no tiene umbrales o niveles de rendimiento establecidos. Sin embargo, muchas empresas y equipos de DevOps realizan un seguimiento de sus propias referencias de repetición del trabajo y pretenden tener una tendencia a la baja a lo largo del tiempo. El uso de datos de tasa de repetición del trabajo junto con la tasa de fallas de cambios y otras métricas de confiabilidad ayuda a los equipos a mejorar las tasas de repetición del trabajo de despliegue sin sobrecorregir en función de un solo número. 

Las métricas de DORA respaldan el enfoque más amplio de DevOps para el desarrollo de software, que prioriza la colaboración continua entre equipos multidisciplinarios en todas las funciones de desarrollo de aplicaciones y operaciones. Los entornos DevOps solo pueden ser tan exitosos como los equipos que los componen.

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

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

Es importante destacar que las métricas de DORA son de diagnóstico, no punitivas. Ayudan a revelar patrones sistémicos en los procesos de desarrollo, en lugar de centrarse en el trabajo de desarrolladores individuales.