Un día, Ivan fue convocado a una reunión para discutir las métricas de DevOps.
Cada participante preparó para la reunión una lista de ciertas métricas que, en su opinión, valdría la pena implementar.
Al escuchar los informes, Ivan trató de calcular cuántas métricas se sugirieron: 5.10, nuevamente 10 y aproximadamente una docena más. Resultó 30 con algo.
Por alguna razón, surgió la idea de que la gente reunida simplemente buscó en Google y escribió los nombres que les parecieron interesantes. Aparentemente, nadie pensó en la esencia de las métricas.
Mirando desde un lado, Ivan se hizo preguntas: ¿por qué? ¿Por qué exactamente estas métricas? ¿Qué te darán? De repente, se hizo evidente que la reunión reunió a personas que estaban lejos de comprender realmente la naturaleza de las métricas, y que todo terminaría como de costumbre, al perder una gran cantidad de tiempo y tirar el trabajo a la basura.
Se volvió triste e insultante. Es una pena que el tiempo y el dinero de la empresa no lleguen a ningún lado, y es triste que no se haga un negocio útil.
Ivan ha estado estudiando métricas durante mucho tiempo y ha entendido durante mucho tiempo que el tema es muy serio y complejo, y en cualquier caso es imposible abordarlo desde la bahía.
Ese día, la reunión terminó con todo y nada: decidimos implementar todo de una vez (nadie quería asumir la responsabilidad del rechazo, porque no entendía por qué otra persona necesitaba estas métricas).
Ivan decidió preparar su visión de las métricas de DevOps y asegurarse de que cada métrica estuviera justificada, tuviera un propósito específico, fuera útil y comprensible.
Eso fue lo que hizo ...
¿Qué quieres gestionar?
En primer lugar, Ivan decidió pensar en el OBJETIVO PRINCIPAL, para el cual se realizan las métricas.
Los libros bien leídos Lean Analytics y The Practice of Tao Toyota sugirieron: elija el número que desea controlar como la métrica principal. A continuación, seleccione los componentes de este número en los que puede influir como métrica.
El objetivo de DevOps en la última reunión declaró "calidad de software", pero el concepto de calidad era muy vago. ¿Qué es la calidad? ¿Cómo expresarlo en un número? ¿Qué componentes lo afectan?
Desafortunadamente, la calidad del software no se puede expresar en un solo número.
De todos modos, ¿el propósito de usar DevOps es realmente de calidad?
Hace un par de años, Ivan trabajó como director de TI para una pequeña empresa que producía su propio software, y allí lanzó y utilizó con éxito DevOps. Y el propósito de este DevOps no era realmente de calidad en absoluto. Más bien, calidad también. El principal y único objetivo era eliminar el trabajo manual durante los despliegues en el baile de graduación.
Al eliminar el trabajo manual, logró tal aceleración y reducción en el número de errores que fue posible lanzar mejoras al menos una vez por minuto.
Por lo tanto, resultó que, como una
META OBJETIVO, DevOps por sí mismo se sugiere
Tiempo de entrega
Es precisamente su disminución o aumento lo que mostraría el efecto de las decisiones gerenciales tomadas.
El tiempo de entrega (Time To Market, TTM) ha aumentado de manera deficiente. Disminuido - excelente.
¡Pero el tiempo de entrega depende del volumen de la tarea y de la duración de las pruebas y de muchos otros factores! Si, eso es correcto.
Y es por eso que Ivan decidió deliberadamente comenzar la cuenta regresiva no desde el momento de la codificación y el análisis, sino desde el momento en que el ensamblaje (distribución) ya se ha creado y está almacenado y todo lo que queda es realizar una serie de comprobaciones y desplegarlo en un entorno industrial (el llamado Entrega continua, CDL).
Aquí es importante desarrollar primero un principio, un concepto, pensó Ivan, y extenderlo a otras áreas no alcanzadas, porque la codificación, el ensamblaje y todos los demás pasos de desarrollo también afectan el tiempo de entrega al igual que la etapa CDL. Hagámoslo en uno, lo haremos en el otro.
En la gran empresa donde trabajaba Ivan, las métricas eran vitales. Miles de desarrolladores vieron el código y cientos de ensamblajes se hicieron a diario, pero nadie, nadie en la compañía sabía cuánto tiempo los equipos dedican realmente a DevOps.
Las quejas llegaron desde todos los lados: mierda de DevOps, no funciona, se desaceleró terriblemente, no tiene sentido. Pero nadie tenía números reales a mano, y era simplemente imposible probar o refutar las declaraciones de los equipos.
Ivan se propuso este objetivo: calcular el tiempo que los equipos pasan en DevOps, y en particular en la etapa de entrega de la asamblea.
Esto no puede ser, pensó Ivan, si una vez lancé DevOps y dio un efecto instantáneo, ¿por qué no está aquí?
La creación de un sistema de métricas se convirtió en una cuestión de honor para Ivan.
Controla lo que puedes controlar
¿Cómo gestionar el tiempo de entrega? ¿Es esto posible? - preguntó Ivan
Si consideramos el tiempo de entrega como un número, queda claro que hay lugares en el proceso DevOps que afectan significativamente este número.
La compañía de Ivan tenía un estándar: se suponía que cada asamblea antes de ir al baile de graduación debía pasar tres bancos de prueba, en los que se probaron varios aspectos del software.
Naturalmente, los ensamblajes en ellos "se cayeron" debido a errores, y en su lugar se crearon nuevos.
Resultó que los stands son los elementos clave del tiempo total de entrega, y son ellos los que afectan el tiempo total, incrementándolo.
Tiempo de entrega = Tiempo en el stand 1 + Tiempo en el stand 2 + Tiempo en el stand 3Al influir en el tiempo que pasan los equipos en cada una de las gradas, será posible influir en el tiempo de entrega final.
Quedaban dos preguntas simples:
- Cómo calcular físicamente los costos de los equipos en las gradas y
- ¿Qué hacer con los tiempos de inactividad entre stands (los tiempos de inactividad también son componentes del tiempo de entrega)?
Ivan no tuvo más remedio que sumergirse en la jungla de Jenkins y Nexus (software utilizado en la CDL).
Jenkins y Nexus ayudan
El montaje del "rollo" en el stand se realizó con Jenkins. De hecho, Jenkins es un programador regular, como crontab, pero con funciones avanzadas.
Jenkins sabe cómo mostrar los registros de todos los trabajos en ejecución (tareas para rodar el ensamblaje en el soporte) en forma de RSS, y hay un inicio, una hora de finalización y un enlace a un ensamblaje específico.
Resultó que a disposición de Ivan se obtuvieron datos sobre la hora exacta del comienzo y el final del trabajo de montaje, es decir fue posible calcular de manera fácil y precisa el tiempo neto que los equipos pasaron en las gradas.
Y si los datos de todos los stands se volcaron en una base de datos, entonces era posible calcular el tiempo de inactividad entre los stands. Eso estuvo genial!
Desde el Nexus (almacenamiento de archivos de red), Ivan iba a obtener la fecha de creación del ensamblaje, y así sucesivamente. Determinar el momento de su aparición y el punto de referencia.
Todo cayó en su lugar. Casi.
- ¿Y cómo manejar esto, pensó Ivan? ..
Continuará Objeto de influencia