12 KPI de DevOps que debe seguir para medir las mejoras

No es tarea fácil transformar una organización de TI para integrar equipos de desarrollo, operaciones y control de calidad. Una metodología DevOps requiere cambios de equipo y procesos y luego, una vez que todo está en su lugar, la responsabilidad de TI es crear KPI de DevOps y medir los resultados.

La clave para un programa DevOps productivo es la medición y el monitoreo efectivos y completos. Cree un plan de juego detallado para comprender cómo funcionan los procesos y proyectos, y cómo mejorarlos con el tiempo.

Los indicadores clave de rendimiento (KPI) de DevOps son complicados por el hecho de que esta metodología no tiene un marco formal, por lo que la definición de progreso puede variar entre las organizaciones. Sin embargo, hay métricas e indicadores clave de rendimiento comunes que deberían mantener un proyecto DevOps en marcha.

Frecuencia de implementación

La innovación genera rápidos cambios tecnológicos. Siga la frecuencia de implementación del código para obtener una imagen clara de la rapidez con la que se implementan las nuevas características y capacidades. Esta métrica debe mantenerse constante o tener una tendencia ascendente con el tiempo. Una disminución o tartamudeo sugiere un cuello de botella en algún lugar dentro del flujo de trabajo del equipo DevOps.

Cambiar el tiempo de entrega

Determine cuánto tiempo lleva un cambio, como una corrección de errores o una nueva característica, desde el inicio, el desarrollo y las pruebas hasta la producción. Los largos plazos de entrega podrían sugerir procesos ineficientes que inhiben las implementaciones de cambios; los tiempos de entrega cortos pueden indicar un proceso DevOps sin problemas en general.

Este KPI de DevOps debería ser un punto de partida para descubrir patrones respecto a que la complejidad de la señal haya causado un cuello de botella en un área determinada.

Cambiar el volumen

Esta métrica va de la mano con la frecuencia de implementación y cuantifica la cantidad de nuevas historias de usuarios o cambios de código que el equipo de DevOps ofrece con cada lanzamiento, o en un período de tiempo determinado. Este KPI ayuda a medir el valor de una implementación para los usuarios finales y si el equipo está pensando atómicamente sobre el cambio, o si todavía está en la mentalidad de implementaciones grandes y complejas que se ven a menudo en el desarrollo en cascada.

Si bien un volumen de cambio alto puede ser un signo de un enfoque iterativo efectivo para el producto, también puede ser un indicador de un corte demasiado estrecho del proyecto, y de que los cambios ocurren solo por el cambio. Los equipos deben tener cuidado de no dedicar demasiado tiempo a los cambios frecuentes de código que son insignificantes para su organización o usuarios finales.

Despliegues fallidos

Los cambios deben implementarse sin problemas, no solo con frecuencia. Mantenga la tasa de falla para los cambios y lanzamientos de aplicaciones implementados en producción lo más bajo posible. Las posibles fallas incluyen un cambio que conduce a problemas de tiempo de espera para los usuarios, o que requiere una reversión para más trabajo. Desarrolle un sistema para rastrear el éxito y el fracaso de los cambios. Una alta tasa de falla de cambio afecta a los usuarios finales de la aplicación y requiere que los administradores inviertan tiempo adicional para solucionar problemas y corregir errores en lugar de llevar a cabo iniciativas de alto valor.

Volumen del defecto y tasa de escape

Un cambio puede implementarse con éxito, pero genera muchos errores. Si bien estos errores no son necesariamente lo suficientemente significativos como para causar una interrupción, afectan negativamente la experiencia del usuario final. Idealmente, el KPI de DevOps para el volumen del defecto debe permanecer lo más bajo posible. Sin embargo, algunas organizaciones adoptan el concepto de un presupuesto de error, postulando que el 100% de tiempo de actividad y confiabilidad afectan negativamente las capacidades de la aplicación y los presupuestos de los proyectos. En su forma más básica, un presupuesto de error fomenta la innovación y las iteraciones rápidas, con un nivel y frecuencia esperados y tolerables de errores y tiempo de inactividad.

También controle la tasa de escape de defectos, también conocida como relación de escape de defectos. Esta métrica representa la cantidad de errores o defectos que los usuarios finales identifican en la producción, en comparación con la cantidad de defectos que las preguntas y respuestas o los equipos de desarrollo presentaron antes de la implementación. Una alta tasa de escape de defectos indica un problema con las pruebas de control de calidad y revisión del código.

Tiempo medio de detección

No mida los KPI de DevOps de forma aislada. Una tasa de falla de cambio baja no es lo suficientemente buena si lleva demasiado tiempo detectar un problema. Por ejemplo, si el MTTD es de 30 días, eso significa que podría tomar un mes completo diagnosticar un problema que hace que aumenten las tasas de falla. El MTTD debería disminuir con el tiempo a medida que los procesos DevOps maduren. Si el MTTD es alto o tiende hacia arriba, espere que los cuellos de botella que causan estos retrasos existentes introduzcan congestión adicional en el flujo de trabajo de DevOps más adelante. La detección rápida también es una bendición para la seguridad, ya que debería minimizar el alcance de un ataque.

Tiempo medio de recuperación

MTTR es otra métrica clave que los administradores deben mantener lo más baja posible. Elimine los problemas una vez que se dé cuenta de ellos. Las organizaciones DevOps siguen el principio de que los cambios frecuentes e incrementales son más fáciles de implementar y más fáciles de solucionar cuando algo sale mal. Si una versión incluye un alto grado de cambio y complejidad, se hace más difícil identificar y resolver problemas dentro de ella.

Priorización de funciones

¿Con qué frecuencia los usuarios finales aprovechan las características del producto o servicio? Si su equipo de DevOps dedica el tiempo y el esfuerzo para crear e implementar un nuevo código en la producción, asegúrese de que esas características sean valiosas para la población objetivo. BizDevOps refuerza el valor de la iteración para satisfacer la demanda del usuario lo más rápido posible. Si el uso de las funciones es bajo o está disminuyendo, reevalúe los factores de priorización con la administración para determinar un mejor ciclo de retroalimentación de los usuarios.

Trabajo no planificado

Esta métrica ayuda a rastrear tanto la calidad de las versiones de software como la productividad general y la felicidad de un equipo de DevOps. Cuantifique la cantidad de trabajo para una versión al comienzo del ciclo DevOps y compárelo con el trabajo real requerido para finalizar la versión. Tenga en cuenta el trabajo no planificado que se completa, así como el trabajo que comienza y luego se abandona, y en progreso continuo más allá del lanzamiento.

Cuanto más tiempo dediquen los desarrolladores y los administradores de operaciones a trabajos no planificados, como resolver errores en la producción, es más probable que haya un problema inherente al enfoque de DevOps. Quizás no haya suficientes prácticas de prueba o discontinuidad entre los entornos de desarrollo, prueba y producción.

Cuando los equipos pasan mucho tiempo luchando contra incendios imprevistos, la productividad general disminuye y aumenta el riesgo de agotamiento de TI.

Tasa de pases de prueba de seguridad

El escaneo de vulnerabilidades no es un caso de prueba común dentro de una secuencia de entrega de software. Determine la viabilidad de la prueba e impleméntela siempre que sea posible. Una prueba de seguridad fallida durante la fase de compilación podría evitar que algunas versiones entren en producción. Si los lanzamientos de código fallan constantemente en las pruebas de vulnerabilidad, este KPI de DevOps sugiere que los equipos ignoran las prácticas seguras en sentido ascendente y, en última instancia, deben corregir esos problemas.

Cumplimiento de SLA

El tiempo de actividad de la aplicación es una métrica importante para toda organización de TI. Los acuerdos de nivel de servicio requieren que la infraestructura, los servicios y las aplicaciones de soporte cumplan con un alto objetivo de disponibilidad. Los servicios deben estar en línea tanto como sea posible, lo que crea objetivos de tiempo de actividad de hasta el 99.999%.

Rendimiento de la aplicación

Una afluencia inesperada de usuarios finales puede crear problemas de rendimiento en la capa de infraestructura; resulta que puede obtener demasiado de algo bueno. Los cuellos de botella de almacenamiento, los picos de CPU, el alto consumo de memoria y la latencia de la red son todos los efectos secundarios comunes de un aumento en el uso de aplicaciones. Supervise de cerca estos aspectos de rendimiento estándar de los servidores que soportan una aplicación. El aumento de los volúmenes de usuarios finales puede requerir la creación de una infraestructura adicional. Sin embargo, las disminuciones de rendimiento sin solicitudes adicionales del usuario final podría indicar que los errores o los cambios ineficientes desde el desarrollo y el lanzamiento están bloqueando la aplicación. Verifique y corrija esto a medida que ocurra para permitir una alta disponibilidad y una buena experiencia del usuario final.