Ha pasado una semana desde que Ivan pensó por primera vez en las métricas de DevOps y se dio cuenta de que necesitaban administrar el tiempo de entrega del producto (Time-To-Market)
con su ayuda .
Incluso durante el fin de semana, pensó en las métricas: “¿Y qué, qué mido el tiempo? ¿Qué me dará?
De hecho, ¿qué dará el conocimiento del tiempo? Supongamos que la entrega demora 5 días. Entonces, ¿qué sigue? ¿Es bueno o malo? Incluso si esto es malo, entonces necesita reducir de alguna manera este tiempo. Pero como?
Estos pensamientos no le dieron descanso, pero no llegó una solución.
Ivan entendió que se había acercado a la esencia misma. Las innumerables gráficas de métricas que había visto antes lo habían convencido hace mucho tiempo de que el enfoque estándar no funcionaría, y que si solo construyes una gráfica (
incluso una cohorte ), no tendría sentido.
¿Cómo ser? ...
La métrica es como una regla de madera ordinaria. Las mediciones realizadas con su ayuda no indicarán la razón
por la cual el objeto medido tiene exactamente la longitud que mostró. La línea simplemente mostrará su tamaño, y no más. No es una piedra filosofal, sino simplemente una tabla de madera que se mide.
La "rata de acero inoxidable" de su querido escritor Harry Harrison siempre decía: el pensamiento debería llegar al fondo del cerebro y permanecer allí, por lo que Ivan decidió hacer otra tarea durante varios días sin ningún resultado ...
Después de un par de días, leyendo un artículo sobre tiendas en línea, Ivan de repente se dio cuenta de que la cantidad de dinero que recibe una tienda en línea depende de cómo se comporta el visitante del sitio. Ellos, los visitantes / clientes, le dan a la tienda su dinero y son su fuente. La cantidad total de efectivo recibida por la tienda se ve afectada por los cambios en el comportamiento del cliente, y no por otra cosa.
Resultó que para cambiar el valor medido, era necesario influir en aquellos que forman este valor, es decir. Para cambiar la cantidad de dinero que una tienda en línea tenía que influir en el comportamiento de los clientes de esta tienda, y para cambiar el tiempo de entrega en DevOps era necesario influir en los equipos que "crean" ese tiempo, es decir. usar DevOps en su trabajo.
Ivan se dio cuenta de que las métricas de DevOps no deberían representar gráficos en absoluto. Deben ser una
herramienta para encontrar equipos "sobresalientes" que formen el tiempo de entrega final.
Ivan pensó que ninguna métrica mostrará la razón por la cual este o aquel equipo ha estado suministrando la distribución durante mucho tiempo, porque en realidad puede haber un millón y un carrito pequeño, y puede que no sean técnicos, sino organizativos. Es decir lo máximo que puede esperar obtener de las métricas es mostrar a los equipos y sus resultados, y luego aún tiene que ir a estos equipos con sus pies y averiguar qué les sucedió.
Por otro lado, había un estándar en la compañía de Ivan, que obligaba a todos los equipos a verificar las asambleas en varios puestos. El equipo no pudo pasar al siguiente puesto hasta que se completó el anterior. Resultó que si imagina el proceso DevOps como una secuencia de stands de pase, las métricas podrían mostrar el tiempo que los equipos pasaron en estos stands. Conociendo la posición y el tiempo del equipo, fue posible hablarle más específicamente sobre los motivos.
Sin dudarlo, Ivan cogió el teléfono y marcó el número de una persona bien informada en lo interno de DevOps:
- Denis, dime, por favor, ¿es posible de alguna manera entender que el equipo pasó esto o aquello?
- por supuesto. Nuestro Jenkins deja caer la bandera si la asamblea se ha desplegado con éxito (pasó la prueba) en el stand.
- Super ¿Qué es una bandera?
- Este es un archivo de texto normal del tipo "stand_OK" o "stand_FAIL", que dice que el conjunto pasó o no pasó el stand. Bueno, lo entiendes, ¿eh?
- En principio, si. ¿Está escrito en la misma carpeta en el repositorio, donde está el ensamblado?
- si
- ¿Y qué pasará si la asamblea no pasa el stand? ¿Necesitarás hacer un nuevo ensamblaje?
- si
- De acuerdo, gracias. Y otra pregunta: ¿entiendo correctamente que puedo usar la fecha de creación de la bandera como la fecha de aprobación del stand?
- ¡Absolutamente!
- Super!
Animado, Ivan colgó el teléfono y se dio cuenta de que todo estaba en su lugar. Al conocer la fecha de creación del archivo de ensamblaje y la fecha de creación de las banderas, fue posible calcular con precisión hasta un segundo cuánto tiempo pasan los equipos en cada puesto y comprender dónde pasan la mayor parte del tiempo.
"Entendiendo dónde lleva más tiempo, encontraremos los equipos punto por punto, iremos a ellos y buscaremos un problema". Ivan sonrió.
Para mañana, se propuso esbozar la arquitectura del sistema que se estaba dibujando.
Continuará ...