El objetivo principal en el desarrollo de software es crear un un producto o aplicación de alta calidad. Durante este proceso, los desarrolladores utilizan herramientas que les ayudan a llegar a un proceso maduro de software y a medir la calidad del mismo. Medir el rendimiento de la entrega de un equipo de software resulta una tarea compleja. Tener un medio para medir y evaluar la efectividad de la estrategia de desarrollo de software es un factor clave para lograr los objetivos, por ello hoy queremos hablar de las Four Key Metrics.
En el libro “Accelerate” se describen cuatro métricas clave de entrega de software para medir la efectividad de las estrategias de software y progreso de los equipos. Este libro fue escrito como resultado de un proyecto de investigación de varios años que estudió la productividad de un amplio conjunto de organizaciones desarrolladoras de software.
Este proyecto de investigación estudia cómo las organizaciones más innovadoras están liderando el camino en el uso de principios y prácticas de DevOps. Los autores miden el rendimiento de la entrega de software, y lo que lo impulsa, utilizando diferentes métricas. Ofrece nuevos conocimientos sobre lo que permite tanto el rendimiento de la entrega de software como el rendimiento organizacional, representado por la rentabilidad, la productividad y la participación de mercado.
Lo que vas a ver en este post:
Métricas DevOps: Four Key Metrics
Estas métricas DevOps nos presentan datos claves que muestran el rendimiento de desarrollo de software DevOps y ayudan a identificar y eliminar rápidamente cualquier cuello de botella en el proceso. Estas métricas se pueden usar para rastrear tanto las capacidades técnicas como los procesos del equipo.
La clave de cada métrica es la mejora continua. Un mayor despliegue reduce las prácticas de pérdida de tiempo y consiguen una mayor eficiencia. Un tiempo medio de restauración más reducido nos ayuda a aumentar la satisfacción del cliente y la automatización y el monitoreo disminuyen la frecuencia de fallos que conducen al despliegue.
Hablemos de cada una de estas métricas:
- Deployment frequency
- Lead time for changes
- Time to restore service
- Change failure rate
Las cuatro medidas del rendimiento de la entrega de software:
Frecuencia de implementación (Deployment Frequency)
La métrica de frecuencia de implementación rastrea la frecuencia de las implementaciones. Para los sitios web con un alto tráfico y para los servicios basados en la nube se convierte en una necesidad. El objetivo de DevOps es desarrollar y realizar implementaciones pequeñas con una alta frecuencia, ya que reducir el tamaño de las implementaciones y la cantidad de cambios para cada ciclo hace más fácil la prueba y el lanzamiento de la implementación. Esta práctica es más favorable que menos versiones con cambios más grandes. La utilización de esta métrica implica realizar un seguimiento de la cantidad de implementaciones no solo en producción, sino también en los entornos de prueba y ensayo.
La medición puede hacerse de diferentes maneras, como a través de un pipeline de implementación automatizada, llamadas API o scripts manuales. La frecuencia de implementación puede ser una medida directa o indirecta del tiempo de respuesta, la cohesión del equipo, las capacidades del desarrollador, la efectividad de la herramienta de desarrollo y la eficiencia general del equipo DevOps.
Plazo de ejecución para cambios (Lead Time For Changes)
Es el tiempo entre la confirmación, y este código entra en producción. Las expectativas para un equipo de alto rendimiento es implementar cambios entre un día y una semana.
En este artículo te explicamos en profundidad qué es el Lead Time For Changes, cómo calcularlo y cómo reducirlo para mejorar los resultados comerciales.
Tiempo medio de restauración (o MTTR Mean Time To Restore)
Es el tiempo medio que se necesita para volver al servicio cuando ha habido un fallo en la producción. Por ejemplo, el tiempo que necesitamos para recuperarnos de una base de datos dañada o de una confirmación que rompe una característica. Se espera que los de alto rendimiento recuperen sus servicios en menos de un día.
El objetivo aquí es aumentar la velocidad de implementación a través de la automatización, y una optimización de la integración del proceso de prueba para acortar el tiempo total de implementación. Esto permite una métrica clara con la cual medir si las implementaciones del equipo están aumentando de una manera que pueda ser entendida por el equipo y cualquier cliente externo.
Se trata de medir el tiempo para restaurar un servicio, desde que se informa una incidencia hasta que se resuelve. MTTR no es el tiempo que lleva arreglar una compilación, si no que trata de medir la capacidad de respuesta de un equipo de DevOps a los problemas de soporte al cliente, así como su capacidad para resolver e implementar soluciones.
Tasa de fallo de cambio (Change Failure Rate)
Es la relación entre cambios que han fallado y los cambios exitosos en un servicio. Por ejemplo, si implementamos cuatro veces en una semana, y tres de nuestras implementaciones fallan por alguna razón, como por un error en el código o porque el pipeline es escaso, nuestro CFR será del 75%. Lo ideal es que en un servicio de alto rendimiento, la tasa de fallo sea inferior al 15%.
Una alta tasa de fallos puede indicar problemas en el proceso de DevOps y dar como resultado tiempos de inactividad que pueden causar pérdida de ingresos de una empresa. Los fallos, aunque es mejor evitarlos, a veces pueden conducir a situaciones que nos lleven a encontrar nuevas soluciones.
Te contamos más acerca del Change Failure Rate en este artículo.
Conclusión
En este artículo hemos revisado cuatro métricas clave (Four Key Metrics) para el éxito de DevOps. Hacer un buen seguimiento de estas métricas nos ayudará a encontrar soluciones para aumentar la velocidad y calidad en la entrega del software a producción
