Fotolia
Nueve métricas DevOps que debería usar para estimar las mejoras
¿Qué le falta a su piloto de DevOps y sus planes de ampliación? Números fríos, duros e imparciales. Haga un seguimiento de estas métricas clave para garantizar que los procesos de DevOps logren los objetivos establecidos.
No es tarea fácil transformar una organización de TI para integrar equipos de desarrollo, operaciones y garantía de calidad. Una metodología DevOps requiere cambios de equipo y proceso y, una vez que todo está en su lugar, la responsabilidad recae en TI para crear métricas 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 los proyectos, y cómo mejorarlos a lo largo del tiempo.
Las métricas de DevOps se complican 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 comunes e indicadores de rendimiento clave que deben mantener una implementación de DevOps en buen camino.
Frecuencia de despliegue
La innovación engendra rápidos cambios tecnológicos. Haga un seguimiento de la frecuencia de implementación del código para tener una idea clara de la rapidez con que se implementan las nuevas características y capacidades. Esta métrica debe permanecer estable o mantener una tendencia ascendente con el tiempo. Una disminución o tartamudeo podría indicar un cuello de botella en algún lugar dentro de la estructura 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 hasta la producción. Los plazos de entrega largos podrían sugerir procesos ineficientes que inhiben las implementaciones de cambios. Esta métrica de DevOps debe ser un punto de partida para descubrir patrones que indiquen la complejidad que está causando un cuello de botella en un área determinada.
Cambiar la tasa de éxito o falla
Los cambios deben desarrollarse sin problemas, no solo con frecuencia. Mantenga la tasa de fallas de los cambios implementados en las aplicaciones de producción lo más baja posible. Desarrolle un sistema para rastrear el éxito y el fracaso de los cambios. Una tasa alta de fallas 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.
Tiempo medio de detección
No mida las métricas de DevOps de forma aislada. Una tasa baja de fallas de cambio no es lo suficientemente buena si lleva mucho tiempo detectar un problema. Por ejemplo, si el MTTD es de treinta días, eso significa que podría llevar un mes completo diagnosticar un problema que hace que aumenten las tasas de falla. MTTD debería disminuir con el tiempo, a medida que los procesos de DevOps maduran. Si el MTTD es alto o tiende hacia arriba, se espera que los cuellos de botella que causan estos retrasos existentes introduzcan una congestión adicional en el flujo de trabajo de DevOps más adelante. La detección rápida también es una gran ayuda para la seguridad, ya que debe minimizar el alcance de un ataque.
Tiempo medio de recuperación
MTTR es otra métrica de DevOps 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 incrementales frecuentes son más fáciles de implementar y más fáciles de corregir cuando algo sale mal. Si un lanzamiento incluye un alto grado de cambio y complejidad, se hace más difícil identificar y resolver problemas dentro de él.
Priorización de funciones
¿Con qué frecuencia los usuarios finales aprovechan las características del producto o del servicio? Si su equipo de DevOps dedica el tiempo y el esfuerzo necesarios para crear e implementar 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 de los usuarios lo más rápido posible. Si el uso de 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.
Tasa de aprobaciones de pruebas de seguridad
El examen de vulnerabilidades no es un caso de prueba común dentro de una secuencia de lanzamiento. Determine la viabilidad de la prueba e impleméntela siempre que sea posible. Una prueba de seguridad fallida durante la fase de construcción podría evitar que algunas versiones entren en producción. Si los lanzamientos de código fallan consistentemente en las pruebas de vulnerabilidad, esta métrica de DevOps sugiere que los equipos ignoran las prácticas seguras en sentido ascendente y, en última instancia, deben corregir esos problemas.
Disponibilidad del servicio
El tiempo de actividad de la aplicación es una medida importante para cada 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 tan altos como 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, picos de CPU, el alto consumo de memoria y la latencia de la red son todos efectos secundarios comunes de un aumento en el uso de la aplicación. Supervise de cerca estos aspectos de rendimiento estándar de los servidores que soportan una aplicación. Aumentar los volúmenes de usuarios finales puede requerir la construcción de infraestructura adicional. Sin embargo, el rendimiento disminuye sin las solicitudes adicionales de los usuarios finales, lo que podría indicar que los errores o los cambios ineficaces de desarrollo y lanzamiento están empantanando la aplicación. Verifique y corrija estos a medida que ocurren para permitir una alta disponibilidad y una buena experiencia para el usuario final.
