Métricas de DevOps
Por qué, qué y cómo medir el éxito en la metodología DevOps
TOM HALL
Defensor y profesional de DevOps
El viejo dicho "Si no lo puedes medir, no lo podrás mejorar" se aplica tanto al modelo DevOps como a cualquier otro. Para cumplir la promesa de DevOps (es decir, lanzar productos de mayor calidad más rápido), los equipos deben recoger, analizar y medir varias métricas. Estas métricas de DevOps proporcionan a los equipos de DevOps los datos fundamentales que necesitan para poder ver qué ocurre en su canalización de desarrollo y controlarla.
Qué son las métricas de DevOps
Las métricas de DevOps son puntos de datos que muestran al instante el rendimiento de una canalización de desarrollo de software de DevOps y ayudan a identificar y eliminar rápidamente cualquier cuello de botella que pueda surgir. Estas métricas se pueden utilizar para hacer un seguimiento tanto de las capacidades técnicas como de los procesos de los equipos.
En esencia, DevOps se centra en difuminar la frontera entre los equipos de desarrollo y los de operaciones, lo que favorece una mayor colaboración entre desarrolladores y administradores de sistemas. Las métricas permiten a los equipos de DevOps medir y evaluar los flujos de trabajo colaborativos y hacer un seguimiento del progreso de objetivos de alto nivel, como una mayor calidad, ciclos de publicación más rápidos y un mejor rendimiento de las aplicaciones.
Cuatro métricas clave de DevOps
Aunque se utilizan varias métricas para medir el rendimiento en la metodología DevOps, hay cuatro métricas clave que todo equipo de DevOps debería medir y son las que se muestran a continuación.
1. Plazo para modificaciones
Una de las métricas clave de DevOps que hay que supervisar es el plazo para modificaciones (no debe confundirse con la duración del ciclo, que se describe más adelante). El plazo para modificaciones es el tiempo transcurrido entre el momento en que se confirma un cambio de código en la rama troncal y el momento en que se encuentra listo para implementar (por ejemplo, cuando el código supera todas las pruebas necesarias previas a la publicación).
2. Tasa de errores por modificaciones
La tasa de errores por modificaciones es el porcentaje de cambios realizados en el código que requieren una corrección inmediata u otras soluciones tras haber pasado a producción. Esta tasa no mide los errores que se detectan en las pruebas y se corrigen antes de que se implemente el código.
3. Frecuencia de implementación
Es fundamental saber con qué frecuencia se implementa código nuevo en la fase de producción para poder medir el éxito de DevOps. Muchos profesionales utilizan el término "entrega" para referirse a los cambios de código que se publican en un entorno de ensayo de preproducción y reservan el concepto "implementación" para aquellos cambios de código que se publican en producción.
4. Tiempo medio de recuperación (MTTR)
El tiempo medio de recuperación (MTTR) mide el tiempo que se tarda en recuperarse de una interrupción parcial del servicio o de un fallo total. Es importante hacer un seguimiento de esta métrica, independientemente del motivo de la interrupción (ya sea por una implementación reciente o por un error puntual del sistema).
Ver la solución
Herramientas para un equipo de DevOps de élite
Material relacionado
La importancia de la estructura del equipo en la metodología DevOps
Cómo medir, utilizar y mejorar las métricas de DevOps
Al igual que ocurre con otros elementos del ciclo de vida de DevOps, se aplica una cultura de mejora continua a las métricas de DevOps. Algunas de las señas de identidad de los equipos de alto rendimiento son su capacidad de recibir comentarios rápidos en cada fase de desarrollo y su habilidad y autoridad para implementarlos. En el libro de DevOps "Accelerate", los autores señalan que las cuatro métricas principales mencionadas anteriormente están respaldadas por 24 capacidades que adoptan los equipos de software de alto rendimiento. A continuación explicamos la mayoría de estas capacidades (CI/CD, automatización de pruebas, trabajo en lotes pequeños, monitorización y aprendizaje continuo), pero vale la pena leer "Accelerate" para profundizar en la investigación que respalda estas prácticas.
Plazo para modificaciones
Los equipos de alto rendimiento suelen medir los plazos en horas, a diferencia de los equipos de medio y bajo rendimiento, que los miden en días, semanas o incluso meses.
La automatización de pruebas, el desarrollo basado en troncos y el trabajo en lotes pequeños son elementos clave para mejorar los plazos. Estas prácticas permiten a los desarrolladores recibir comentarios rápidamente sobre la calidad del código que confirman para así poder detectar y corregir cualquier defecto. Los plazos prolongados son prácticamente un hecho si los desarrolladores tienen que realizar grandes cambios en ramas independientes y necesitan realizar pruebas manualmente para llevar a cabo el control de calidad.
Tasa de errores por modificaciones
Los equipos de alto rendimiento tienen una tasa de errores por modificaciones de entre un 0 % y un 15 %.
Las mismas prácticas que contribuyen a acortar los plazos (como la automatización de pruebas, el desarrollo basado en troncos y el trabajo en lotes pequeños) se asocian a una reducción de las tasas de errores por modificaciones. Todas estas prácticas permiten que los defectos sean mucho más fáciles de detectar y solucionar.
El seguimiento y registro de las tasas de errores por modificaciones no solo son importantes para detectar y corregir errores, sino también para garantizar que las nuevas publicaciones de código cumplan los requisitos de seguridad.
Frecuencia de implementación
Los equipos de alto rendimiento pueden implementar cambios bajo demanda y, a menudo, lo hacen muchas veces al día. Los equipos de menor rendimiento suelen limitarse a implementar cambios una vez a la semana o al mes.
La capacidad de implementar bajo demanda requiere una canalización de implementación automatizada que incorpore los mecanismos automatizados de pruebas y comentarios a los que se hace referencia en las secciones anteriores y que minimice la necesidad de intervención humana.
Tiempo medio de recuperación (MTTR)
Los equipos de alto rendimiento se recuperan de los errores del sistema en seguida (normalmente, en menos de una hora), mientras que los equipos de bajo rendimiento pueden tardar hasta una semana en recuperarse de un error.
La capacidad de recuperarse rápidamente de un error depende de la capacidad de identificar rápidamente cuándo se produce un error e implementar una corrección o reversión de los cambios que han provocado ese error. Por lo general, esto se lleva a cabo supervisando continuamente el estado del sistema y alertando al equipo de operaciones en caso de que se produzca algún error. El equipo de operaciones debe contar con los procesos, herramientas y permisos necesarios para resolver los incidentes.
La transición al MTTR supone dejar atrás la antigua práctica de centrarse en el tiempo medio entre errores (MTBF). Refleja la creciente complejidad de las aplicaciones modernas y, por consiguiente, una mayor probabilidad de que se produzcan errores. También refuerza la práctica del aprendizaje y la mejora continuos: los equipos, en vez de esperar a que la implementación sea perfecta para evitar cualquier posible error (y así reiniciar el antiguo marcador del MTBF), hacen implementaciones continuamente. Asimismo, el MTTR, en vez de buscar culpables por arruinar un récord de MTBF "perfecto", anima a hacer análisis retrospectivos sin acusaciones para ayudar a los equipos a mejorar sus procesos y herramientas iniciales.
Otras métricas relacionadas
Otra métrica relevante es la duración del ciclo, que es el tiempo que un equipo dedica a trabajar en un elemento hasta que está listo para lanzarse. En el mundo del desarrollo, la duración del ciclo es el tiempo que transcurre entre que los desarrolladores confirman un cambio hasta que lo implementan en producción. Esta métrica clave de DevOps ayuda a los responsables de proyecto y a los directores de ingeniería a comprender mejor qué funciona bien en la canalización de desarrollo. De este modo, pueden sincronizar mejor su trabajo con las expectativas de las partes interesadas y los clientes, lo que garantiza que su equipo lance más rápido.
Los informes de duración del ciclo permiten a los responsables de proyectos establecer una referencia en la canalización de desarrollo que pueda servir para evaluar procesos futuros. Cuando los equipos optimizan la duración del ciclo, los desarrolladores suelen tener menos trabajo en curso y menos flujos de trabajo ineficientes.
La gestión de productos lean se centra en el mapa de flujo de valor, una visualización que muestra el flujo desde la concepción de un producto o función hasta su entrega. Las métricas de DevOps proporcionan muchos de los datos necesarios para una gestión y un mapa de flujo de valor efectivos, pero deben mejorarse con otras métricas empresariales y de productos para lograr una evaluación completamente integral. Por ejemplo, los gráficos de trabajos pendientes de los sprints dan información sobre la eficacia de los procesos de estimación y planificación, mientras que Net Promoter Score indica si la entrega final satisface las necesidades de los clientes.
En conclusión...
La mejora continua es un principio fundamental de los equipos que utilizan la metodología DevOps. La capacidad de medir y supervisar el rendimiento mediante las métricas Plazo para modificaciones, Tasa de errores por modificaciones, Frecuencia de implementación y MTTR permite a los equipos acelerar en velocidad y aumentar su calidad.
Open DevOps de Atlassian ofrece todo lo que los equipos necesitan para el desarrollo y las operaciones de software. Los equipos pueden crear la cadena de herramientas de DevOps que quieran gracias a las integraciones con los principales proveedores y aplicaciones de Marketplace. Pruébalo gratis ahora.
Compartir este artículo
Tema siguiente
Lecturas recomendadas
Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.
La comunidad de DevOps
Ruta de aprendizaje de DevOps
