Jeff Keyes, vicepresidente de producto de Plutora, presenta 10 mediciones como base para medir DevOps que ayudarán al negocio a prosperar y permitirán operar con una arquitectura DevOps optimizada.
Dado que se espera que el tamaño del mercado de DevOps alcance los 12.900 millones de dólares estadounidenses para 2025, vale la pena comprender cómo aprovechar al máximo este enfoque en evolución. DevOps esencialmente vincula los aspectos operativos y de desarrollo de la entrega de software, sin embargo, a menudo se considera complicado comparar su éxito. Pero no se preocupe, hay algunos indicadores de rendimiento, conocidos como métricas, que todo equipo de DevOps puede usar para medir la efectividad de su enfoque.
Estos son los que se pueden considerar los 10 principales, y cada una de estas métricas es lo suficientemente importante como para afectar el éxito de la relación entre el desarrollador y las operaciones, implícita en el concepto mismo de DevOps.
1. Disponibilidad de la aplicación
Los usuarios deben tener acceso ininterrumpido a su aplicación las 24 horas del día, los 7 días de la semana, a menos que se les haya advertido con anticipación que se debe realizar un mantenimiento programado. Medir la disponibilidad es una métrica simple para impulsar los recursos hacia el mantenimiento de una aplicación. Una vez que se lleva a cabo la implementación, la disponibilidad de una aplicación puede disminuir. El equipo de DevOps debe ser capaz de seguir los registros y revertir los cambios a su última versión disponible; sin embargo, las empresas que implementan sus aplicaciones miles de veces, de forma rutinaria, argumentarán que esto es más difícil de lo que parece.
Para medir la disponibilidad, una herramienta de orquestación, como Kubernetes o Jenkins, puede ser útil. También puede buscar administradores de rendimiento de aplicaciones (APM) para manejar sin problemas los registros y los puntos de reversión.
2. Tráfico y uso de aplicaciones
El siguiente enfoque debe ser monitorear el tráfico y el uso de la aplicación. Si su aplicación experiencia alta demanda, se puede enfrentar problemas cuando esté bajo presión. Un analizador de registros intuitivo puede notificar a los desarrolladores en el momento que se acerque a un punto crítico.
Usar estadísticas también es apropiado mientras se liberan nuevas actualizaciones periódicamente. Un bajón en el uso sugeriría que se implementó un cambio que no es tan atractivo para el usuario final. Un equipo competente de DevOps tomará las medidas y los controles que corrijan con prontitud estos bajonazos causados por nuevas características. Por ejemplo, se pueden agregar nuevos cambios usando marcas de funciones, estas permiten liberar de forma gradual estas funciones a grupos de usuarios. Y esto permite que la función se implemente de forma tan acompasada que logre la aceptación entre los usuarios sin que se disminuya su uso.
3. El número de entradas
Los usuarios proveen comentarios al enviar las entradas a su equipo de soporte y los cambios se pueden implementar entre la codificación y las pruebas en el flujo de las DevOps. La logística en torno a estas mediciones de DevOps se debería simplificar: No se busca que los usuarios emitan tiquetes de entrada en un sistema de tiquetes deficiente. Herramientas de terceros usadas tradicionalmente para rastrear las entradas y su ciclo de vida son la opción más inteligente. Puede que cuesten más, pero se deben sopesar frente a un menor tiempo y esfuerzo.
Su equipo de DevOps puede concentrarse en mantener actualizado el sistema enviando tiquetes de entrada internos. Sin embargo, por naturaleza estos son de menor prioridad frente a los generados externamente. Una forma de superar esto es con un gráfico de entradas a lo largo del tiempo, ya que ayuda a enfocarse en la tendencia y no solo en los boletos.
4. Conteo de asignaciones
Las asignaciones son los cambios enviados a la fuente de código principal, usando generalmente un sistema de control de versiones (VCS, por sus siglas en inglés) com GitHub. 4. Recuento de compromisos Cuantos más compromisos registre el equipo, más productivos será en términos generales. Sin embargo, un compromiso solo es realmente útil cuando los desarrolladores senior lo han aprobado y, por lo tanto, los compromisos aprobados son mucho más importantes.
Cualquier VCS permite contar el total de confirmaciones completadas en un período determinado. Esto puede ser una fuente de inspiración, ya que normalmente los desarrolladores con más compromisos inspiran al resto de su equipo a acelerar. Las confirmaciones bajas también pueden revelar por qué el control de versiones de su aplicación es lento, lo que permite a los administradores identificar y apoyar a los desarrolladores con las confirmaciones más bajas.
5. Número de pruebas realizadas
Al profundizar sobre el conteo general de confirmaciones, la cantidad de pruebas en una única asignación también es vital. Si tiene que hacer más de una prueba en un solo cambio posible, podría haber un problema con el proceso. La realización de pruebas manualmente es una causa común. Si bien es exhaustivo, confiar en un evaluador humano crea oportunidades para cometer errores al ejecutar experimentos manuales en sus asignaciones y compilaciones antes de las implementaciones.
Por otro lado, el uso de pruebas automatizadas distribuidas en tantos contenedores como sea posible, en entornos de producción, reduce la cantidad de tiempo que tendrá que esperar por una sesión. También aumenta el número de pruebas simultáneas realizadas (que cuentan como una en vez de contar como varias).
6. Tasa de despliegue
Una implementación es cuando se crea una nueva versión de su aplicación, y la velocidad a la que se producen es una indicación general de la productividad de su equipo. Sin embargo, aumentar las implementaciones exitosas depende de un buen sistema que gestione los pasos previos. Podría tener miles de confirmaciones en espera de pruebas, pero si no está utilizando los mejores métodos de prueba, aún con los mejores desarrolladores, pero implementar muy poco.
Si bien una empresa del tamaño de Amazon tendrá equipos de DevOps trabajando para realizar mejoras las 24 horas del día, la mayoría de las empresas más pequeñas no implementan con tanta frecuencia. Pero los despliegues que hacen, cuando se hacen a diario, reflejan el trabajo que se lleva a cabo a puerta cerrada. Para la administración, las caídas en esta métrica son pistas para que desde el lado de operaciones de DevOps se mejoren los procesos que conducen a las implementaciones.
7. velocidad de las implementaciones
La velocidad de la implementación mide el tiempo necesario para completar una sola implementación. El tiempo de implementación de cada aplicación variará dependiendo del tamaño final del archivo. Cuantas más líneas de código, activos y dependencias, más tardará una aplicación en implementarse.
Un asunto a considerar es si resulta mejor asingar tareas una vez al día y construir lo que más se pueda, o si tiene más sentido aplicar múltiples y pequeños cambios en el transcurso del día. La última opción permite implementaciones más rápidas, ahorra los recursos informáticos necesarios en un momento dado (es decir, los costos) y lo hace con la suficiente seguridad como para que, si es necesario, pueda volver al último estado en el que se realizaron los cambios correctamente.
8. Retrocesos en la implementación y frecuencia de las fallas
Las implementaciones a veces se deshacen mediante reversiones y por razones que incluyen la falta del alcance de los requisitos de una aplicación, por orden administrativa y por los errores que podrían haber escapado a las pruebas. Todas las herramientas de integración e implementación continuas (CI / CD) registran las implementaciones completadas con éxito, así como las que tienen un problema y se detienen antes de su finalización. Usted querrá la menor cantidad posible de reversiones, por lo que, si ocurren muchos retrocesos, haga uso de de más verificaciones manuales antes de las compilaciones.
La frecuencia de las fallas en su ciclo también es importante. No solo analiza la implementación final, sino cada paso para llegar allí. Un proceso de retroalimentación bien definido conduce a mejores codificaciones y asignaciones, lo que luego conduce a menos reversiones después de la implementación.
9. Plazo de ejecución de la versión
El tiempo de entrega de la versión mide el tiempo que transcurre desde que se recibe hasta que se resuelve un ticket. Quizás esta es una de las descripciones más precisas de la productividad de sus procesos DevOps; El tiempo de entrega de la versión da un paso atrás para ver todo en acción. Los gerentes de proyectos suelen utilizar esta métrica para estimar los plazos de las tareas al distribuir recursos a los proyectos.
Aquí es importante considerar cómo las tareas varían en dificultad. Ayuda incluir el peso relativo de un cambio en los informes recopilados para presentar los plazos de entrega, así como cuántos desarrolladores participaron en el cambio. Lógicamente, cuantas más manos pongas a trabajar en un cambio, menos tiempo debería llevar.
10. Tasa de respuesta a los tickets
Al optimizar la velocidad, se obtiene una gran cantidad de información al monitorear la tasa de respuesta a los tickets. Las nueve métricas anteriores reciben impulso a partir de los resultados que obtiene de este paso. Independientemente de lo difícil que parezca un cambio sugerido por un ticket, el proceso de emisión de tickets asegura que se le asignen suficientes trabajadores. Esto recorta inmediatamente el tiempo de espera previsto y aumenta el número de asignaciones posibles.
Una forma de generar una buena tasa de respuesta a los tickets radica en tener una herramienta de administración de flujo de valor (VSM). Esta conecta información en todas sus aplicaciones en los departamentos a lo largo de su flujo, aumentando la visibilidad. La información de antecedentes que tienen sus desarrolladores al crear y reparar funciones aumenta, y los problemas de tickets llegan a la etapa de implementación más rápido y con menos posibilidades de ser revertidos.
Esta lista de métricas no es exhaustiva; sin embargo, estas 10 le brindan una base para medir DevOps que ayudarán a que su negocio crezca. Una vez que estas métricas están implementadas y se revelan los datos, el objetivo clave es realizar pequeños cambios en diferentes áreas para mejorar la canalización, de modo que cada métrica también mejore lentamente. En última instancia, tener un objetivo claro conocido por todos los miembros del equipo para cada una de las métricas de DevOps lo coloca en la dirección correcta hacia una arquitectura de DevOps optimizada.
Haga clic a continuación para compartir este artículo
