Métricas del modelo DevOps

Lo que no se mide no se puede mejorar. Esta máxima nos invita a disponer de una serie de métricas que nos ayuden a evaluar la calidad de nuestro proceso DevOps.

El objetivo principal de la práctica DevOps es agilizar el ciclo de vida del software, asegurando la calidad en cada uno de los pasos y partiendo de la automatización y la monitorización como herramientas fundamentales para conseguirlo. Por ello, las métricas que proponemos desde MTP y que mostramos a continuación se centran en ese objetivo, manteniendo también el foco en la calidad, ya que tampoco hay que olvidar que lo que se desea no es producir mal software a gran velocidad:

Número de commits asociados correctamente a un ticket.

Por medio de esta métrica podremos conocer en todo momento si los equipos de desarrollo están contribuyendo a la trazabilidad del código, un aspecto fundamental.

Porcentaje de código cubierto por test unitario.

Aunque no hay que llevar al extremo la cobertura de código por test unitario, contar con un nivel adecuado ayuda a prevenir problemas en etapas posteriores.

Ratio de construcciones fallidas.

Si una build, con independencia del motivo, no se completa correctamente, se pierde un tiempo valioso que repercutirá en el resto del proceso de construcción del software.

Ratio de despliegues fallidos.

Ya sea por indisponibilidad de entornos, por fallos en la configuración o por defectos en los tests postdespliegue, conviene llevar traza de la cantidad de despliegues que no se han completado con éxito.

Tiempo medio de despliegue.

Esta métrica nos ayudará a identificar procedimientos que no estén del todo maduros, por ejemplo, pasos que aún no estén automatizados o que requieran de revisión manual.

Frecuencia de despliegue.

Uno de los objetivos debe ser hacer despliegues pequeños y frecuentes. Esta métrica nos ayudará a saber si estamos acercándonos o alejándonos de este objetivo.

Porcentaje de éxito en tests automáticos.

Los tests automáticos son fundamentales en un entorno DevOps. Un despliegue puede interrumpirse por errores en los tests automáticos. Relacionar esta métrica con otras, como el número de defectos encontrados por entorno, puede ayudar a saber si los tests automáticos construidos son o no suficientes.

Defectos encontrados en entornos de integración y UAT.

Ya sea por fallos detectados gracias a tests automáticos o a tests de usuario, es una métrica que debería tender a cero con el tiempo. Es un indicador de la madurez de todo el proceso.

Ratio de indisponibilidad.

Tanto en entornos intermedios como en entornos productivos, una indisponibilidad es un problema grave. Evidentemente, el problema es mayor si un entorno de producción deja de estar disponible. Por ello, podría tener sentido dividir esta métrica por tipo de entorno.

Tiempo medio para salir de indisponibilidad.

La rapidez con la que se reaccione para volver a dar servicio es clave para no interrumpir el ciclo de vida y para no dañar la imagen de cara al cliente, además de limitar una potencial pérdida de ingresos.

Defectos encontrados en entorno productivo.

Un defecto será más costoso de corregir cuanto más tarde se detecte en el ciclo de vida. El objetivo es que esta métrica tienda a cero. Como mencionábamos anteriormente, si no vemos disminuido este valor con el tiempo, convendría ajustar las baterías de test de todo tipo aplicadas al software.

Tiempo medio de resolución de defectos en entorno productivo.

Cada defecto que se da en un entorno productivo supone un coste en términos de deterioro de imagen, potencial pérdida de ingresos o corrupción de datos, por poner sólo algunos ejemplos. El tiempo de resolución debe ser mínimo para mantener estas consecuencias dentro de lo admisible.

“Lead time” de un cambio.

Tiempo medio transcurrido entre el registro de un ticket y la puesta en producción de la funcionalidad asociada. Nos ayuda a medir el tiempo de respuesta de todo el engranaje DevOps.

Todas estas métricas son una ayuda a la hora de tomar decisiones, pero también para conocer si los cambios aplicados van o no en el buen camino.

Por Francisco M. Lozano Sanjuán

Consultor Senior Calidad de Código

Ver más historias