Honestamente, Iván a menudo se reía de los esfuerzos inútiles de sus colegas del departamento de monitoreo. Hacían un gran esfuerzo para implementar las métricas que la dirección de la empresa les encargaba. Estaban tan ocupados que no querían hacer nada más.
Y la dirección nunca estaba satisfecha: siempre pedía nuevas métricas, dejando rápidamente de utilizar las que ya se habían creado.
Últimamente, solo se hablaba del LeadTime: el tiempo de entrega de funcionalidades empresariales. La métrica mostró un número increíble: 200 días para entregar una tarea. ¡Qué asombro y qué desesperación se dio entre todos!
Después de un tiempo, el ruido se apagó gradualmente y desde la dirección llegó el encargo de crear otra métrica.
A Iván le quedó claro que la nueva métrica también moriría silenciosamente en un rincón oscuro.
En efecto, reflexionaba Iván, saber un número no significa nada para nadie. 200 días o 2 días: no hay ninguna diferencia, porque no se puede determinar la causa ni comprender si es bueno o malo solo a partir del número.
Esta es la trampa típica de las métricas: parece que la nueva métrica revelará la esencia de la existencia y explicará algún secreto oculto. Todos tienen grandes esperanzas, pero por alguna razón nada sucede. ¡Porque el secreto no hay que buscarlo en las métricas!
Para Iván, esto era algo que ya había pasado. Entendía que para medir, y todos los secretos deben buscarse en , es decir, en lo que forma esa métrica.
Para una tienda en línea, el objeto de influencia son sus clientes que generan ingresos, y para DevOps, son los equipos que crean y despliegan distribuciones utilizando la tubería.
Una vez, acomodándose en un sillón cómodo en el vestíbulo, Iván decidió pensar detenidamente cómo le gustaría ver las métricas de DevOps teniendo en cuenta que el objeto de influencia son los equipos.
El objetivo de las métricas DevOps
Está claro que todos quieren reducir el tiempo de entrega. 200 días, por supuesto, no es aceptable.
Pero ¿cómo, esa es la cuestión?
En la empresa trabajan cientos de equipos, y a través del canal DevOps pasan miles de distribuciones al día. El tiempo de entrega real se verá como una distribución. Cada uno de los equipos tendrá su propio tiempo y características específicas. ¿Cómo encontrar algo en medio de este lío?
La respuesta surgió por sí sola: es necesario identificar los equipos problemáticos y entender qué les sucede y por qué tardan tanto, mientras que de los equipos 'buenos' aprender a hacer todo rápidamente. Para ello, es necesario medir el tiempo que cada equipo pasa en cada uno de los stands de DevOps:
«El objetivo del sistema será seleccionar equipos según el tiempo de paso por los stands, es decir, al final debemos obtener una lista de equipos con el tiempo seleccionado, y no un número.
Si averiguamos cuánto tiempo se ha pasado en total en un stand y cuánto tiempo se ha perdido en inactividad entre stands, podremos encontrar a los equipos, contactarlos y profundizar en las razones para solucionarlas», pensó Iván.
Cómo calcular el tiempo de entrega para DevOps
Para poder calcularlo, era necesario profundizar en el proceso de DevOps y sus entidades.
La empresa utiliza un número limitado de sistemas, y la información solo se puede obtener de ellos y de ningún otro lugar.
Todas las tareas en la empresa se registraban en Jira. Cuando se comenzaba a trabajar en una tarea, se creaba una rama para ella, y después de implementarla, se hacía un commit en BitBucket y un Pull Request. Al aceptar el PR (Pull Request), se generaba automáticamente una distribución y se guardaba en el repositorio Nexus.
Luego, la distribución se desplegaba en varios stands con ayuda de Jenkins para verificar la correcta aplicación, pruebas automáticas y manuales:
Iván detalló de qué sistemas se podía obtener qué información para calcular el tiempo en los stands:
- De Nexus: el tiempo de creación de la distribución y el nombre de la carpeta en la que se encontraba el código del equipo.
- De Jenkins: la hora de inicio, duración y resultado de cada trabajo, el nombre del stand (en los parámetros del trabajo), las etapas (pasos del trabajo), enlace a la distribución en Nexus.
- Iván decidió no incluir Jira y BitBucket en el canal, ya que estaban más relacionados con la etapa de desarrollo y no con el despliegue de la distribución terminada en los stands.
Con la información disponible se esbozó el siguiente esquema:
Sabiendo cuánto tiempo se tarda en crear distribuciones y cuánto tiempo se dedica a cada una de ellas, se puede calcular fácilmente los costos totales del proceso completo de DevOps (ciclo completo).
Estas son las métricas de DevOps que obtuvo Iván al final:
- Número de distribuciones creadas
- Proporción de distribuciones que 'entraron' en el stand y 'pasaron' el stand
- Tiempo pasado en el stand (ciclo del stand)
- Ciclo completo (tiempo total en todos los stands)
- Duración de los trabajos
- Inactividad entre stands
- Inactividad entre ejecuciones de trabajos en un mismo stand
Por un lado, las métricas caracterizaban muy bien el proceso de DevOps en términos de tiempo, por otro lado, se calculaban muy fácilmente.
Satisfecho con el trabajo bien hecho, Iván preparó una presentación y se fue a presentársela a la dirección.
Regresó con el ceño fruncido y las manos caídas.
— Esto es un fracaso, amigo — sonrió un colega irónico...
Continúe leyendo en el artículo «».
Fuente: habr.com
