Honestamente, Ivan a menudo se reía de los inútiles esfuerzos de colegas del departamento de monitoreo. Hicieron grandes esfuerzos para implementar las métricas que la gerencia de la compañía les ordenó. Estaban tan ocupados que no querían hacer nada más.
Y la administración no fue suficiente: constantemente ordenó más y más métricas, dejando de usar muy rápidamente lo que se hizo antes.
Recientemente, todo el mundo acaba de hablar sobre LeadTime: el tiempo de entrega de las funciones comerciales. La métrica mostró un número loco: 200 días para entregar una tarea. ¡Cómo todos gimieron, gimieron y levantaron sus manos al cielo!
Después de un tiempo, el ruido se calmó gradualmente y llegó una orden de la gerencia para crear otra métrica.
Ivan tenía perfectamente claro que la nueva métrica también moriría silenciosamente en un rincón oscuro.
De hecho, reflexionó Ivan, sabiendo que el número no le dice absolutamente nada a nadie. 200 días o 2 días: no hay diferencia, porque por el número es imposible determinar el motivo y comprender si es bueno o malo.
Esta es una trampa métrica típica: parece que la nueva métrica contará la esencia del ser y explicará algún secreto secreto. Todos lo esperan, pero por alguna razón no pasa nada. Sí, porque el secreto no debe buscarse en las métricas.
Para Ivan, esta fue una etapa pasada. Entendió que las
métricas son solo una regla de madera ordinaria para las mediciones, y todos los secretos deben buscarse en el
objeto de influencia , es decir. en que esta métrica se forma.
Para una tienda en línea, el objeto de influencia serán sus clientes, quienes aportan dinero, y para DevOps, los equipos que crean y distribuyen distribuciones utilizando la tubería.
Una vez, después de instalarse en el vestíbulo en un cómodo sillón, Ivan decidió pensar detenidamente en cómo le gustaría ver las métricas de DevOps, teniendo en cuenta el hecho de que los equipos son objeto de influencia.
Métricas de DevOps de objetivos
Está claro que todos quieren reducir el tiempo de entrega. 200 días es, por supuesto, bueno para nada.
¿Pero cómo, esa es la pregunta?
La compañía tiene cientos de equipos y miles de distribuciones pasan por la tubería de DevOps todos los días. El tiempo real de entrega se verá como distribución. Cada equipo tendrá su propio tiempo y sus propias características. ¿Cómo puedes encontrar al menos algo entre este desastre?
La respuesta surgió de forma natural: necesita encontrar equipos problemáticos y descubrir qué sucede con ellos y por qué durante tanto tiempo, y aprender a hacer todo rápidamente con equipos "buenos". Y para esto, debe medir el tiempo que pasan los equipos en cada uno de los puestos de DevOps:
"El propósito del sistema será la selección de equipos de acuerdo con el tiempo de paso de las gradas, es decir, al final, deberíamos obtener una lista de equipos con el tiempo seleccionado, y no un número.
Si descubrimos cuánto tiempo se pasó en total en un stand y cuánto tiempo se dedicó al tiempo de inactividad entre los stands, podemos encontrar equipos, llamarlos y comprender las razones con más detalle y eliminarlos ”, pensó Ivan.
Cómo calcular el tiempo de entrega de DevOps
Para contar, era necesario profundizar en el proceso DevOps y su esencia.
La compañía utiliza un número limitado de sistemas, y la información solo se puede obtener de ellos y de ningún otro lado.
Todas las tareas en la empresa se registraron en Jira. Cuando la tarea se puso a trabajar, se creó un brunch para ella y, después de la implementación, se realizó una confirmación en BitBucket y Pull Request. Al aceptar PR (solicitud de extracción), se creó y almacenó automáticamente un kit de distribución en el repositorio de Nexus.
Además, la distribución se implementó en varios puestos utilizando Jenkins para verificar la exactitud de las pruebas de rodadura, automáticas y manuales:
Ivan pintó de qué sistemas qué información se puede tomar para calcular el tiempo en los stands:
- From Nexus: tiempo de creación de distribución y nombre de la carpeta en la que estaba contenido el código de comando
- Desde Jenkins: hora de inicio, duración y resultado del trabajo de cada trabajo, el nombre del stand (en los parámetros del trabajo), etapas (pasos del trabajo), un enlace a la distribución en Nexus.
- Ivan decidió no incluir a Jira y BitBucket en la tubería, porque estaban más relacionados con la fase de desarrollo y no con la distribución final de los stands.
Con base en la información disponible, se dibujó el siguiente esquema:
Sabiendo cuánto tiempo se crean las distribuciones y cuánto tiempo se dedica a cada una de ellas, puede calcular fácilmente el costo total de pasar por toda la tubería de DevOps (ciclo completo).
Estas son las métricas de DevOps de Ivan como resultado:
- Número de distribuciones creadas
- El porcentaje de distribuciones "iniciadas" en el stand y "pasado" el stand
- Tiempo pasado en el stand (ciclo de stand)
- Ciclo completo (tiempo total para todos los stands)
- Duración del trabajo
- Simple entre stands
- Sencillo entre lanzamientos de trabajo en un soporte
Por un lado, las métricas caracterizaron muy bien la canalización de DevOps en términos de tiempo, por otro lado, se consideraron muy simples.
Satisfecho con el trabajo bien hecho, Ivan hizo una presentación y fue a presentarla a la gerencia.
Volvió frunciendo el ceño y con las manos hacia abajo.
"Este es un fiasco, hermano", sonrió el colega irónico.
Continúe leyendo el artículo " Cómo los resultados rápidos ayudaron a Ivan ".