(Tiempo de Mercado).
Incluso durante el fin de semana, pensaba en las métricas: «¿Y qué si mido el tiempo? ¿Qué me va a aportar?»
De hecho, ¿qué aporta conocer el tiempo? Supongamos que la entrega tarda 5 días. ¿Y qué? ¿Es bueno o malo? Incluso si es malo, hay que reducir ese tiempo. Pero, ¿cómo?
Estos pensamientos no le dejaban en paz, pero no llegaba a una solución.
Iván entendía que se había acercado a la esencia del asunto. Los innumerables gráficos de métricas que había visto antes lo habían convencido de que el enfoque estándar no funcionaría y que simplemente hacer un gráfico () no serviría de nada.
¿Qué hacer?…
Una métrica es como una regla de madera común. Las mediciones hechas con ella no explican la razón por la cual el objeto medido tiene precisamente la longitud que muestra. La regla solo mostrará su tamaño y nada más. No es una piedra filosofal, sino simplemente una tabla de madera para medir.
La «Rata de acero inoxidable» de su autor favorito, Harry Harrison, siempre decía: el pensamiento debe llegar al fondo del cerebro y reposar allí, así que tras varios días de lucha infructuosa, Iván decidió abordar otra tarea…
Un par de días después, al leer un artículo sobre tiendas en línea, Iván de repente comprendió que la cantidad de dinero que recibe una tienda online depende del comportamiento de los visitantes del sitio. Ellos, los visitantes/clientes, son quienes entregan su dinero a la tienda y son su fuente. La cantidad total de dinero que recibe la tienda se ve afectada por los cambios en el comportamiento de los clientes, y no por otra cosa.
Resulta que, para cambiar la cantidad medida, había que influir en aquellos que forman ese valor, es decir, para cambiar la cantidad de dinero de la tienda online, era necesario influir en el comportamiento de los clientes de esa tienda, y para cambiar el tiempo de entrega en DevOps, había que influir en los equipos que "crean" ese tiempo, es decir, que utilizan DevOps en su trabajo.
Iván comprendió que las métricas de DevOps no deberían ser simplemente gráficos. Deberían ser una herramienta de búsqueda de equipos "excepcionales" que definen el tiempo total de entrega.
Ninguna métrica nunca mostrará la razón por la que un equipo tardó en entregar un distribuidor, pensaba Iván, ya que en realidad puede haber un millón de razones, y es posible que no sean solo técnicas, sino organizativas. Es decir, lo máximo que se puede esperar obtener de las métricas es el rendimiento de los equipos y sus resultados, y luego, de todos modos, tendrás que ir personalmente a esos equipos y averiguar qué sucedió.
Por otro lado, en la empresa de Iván existía un estándar que obligaba a todos los equipos a verificar las compilaciones en varias estaciones. Un equipo no podía pasar a la siguiente estación hasta que no habían superado la anterior. Esto significaba que, si se imaginaba el proceso de DevOps como una secuencia de estaciones, las métricas podrían mostrar el tiempo que los equipos dedicaban en estas estaciones. Conociendo la estación y el tiempo del equipo, se podría hablar con más precisión sobre las razones.
Sin pensarlo mucho, Iván levantó el teléfono y marcó el número de una persona que entendía bien de los entresijos de DevOps:
— Denis, ¿podrías decirme si hay alguna forma de saber si un equipo ha pasado por alguna estación?
— Claro. Nuestro Jenkins marca un indicador si la compilación se despliiega correctamente (pasa las pruebas) en la estación.
— Genial. ¿Y qué es un indicador?
— Es un archivo de texto común, tipo «estación_OK» o «estación_FAIL», que indica si la compilación pasó o no. ¿Entendiste?
— En principio sí. ¿Se guarda en la misma carpeta del almacenamiento donde está la compilación?
— Sí.
— ¿Y qué pasa si la compilación no pasa la estación? ¿Tendría que hacer una nueva compilación?
— Ajá.
— Bueno, gracias. Y otra pregunta: ¿entendí correctamente que puedo usar la fecha de creación del indicador como fecha de paso por la estación?
— Absolutamente.
— ¡Genial!
Animado, Iván colgó y se dio cuenta de que todo encajaba. Sabiendo la fecha de creación del archivo de compilación y las fechas de creación de los indicadores, se podría calcular con precisión hasta el segundo cuánto tiempo dedican los equipos a cada estación y entender dónde están gastando más tiempo.
«Al entender dónde se va más tiempo, identificaremos a los equipos específicos, iremos a ellos y profundizaremos en el problema». Iván sonrió.
Para mañana, se propuso realizar un esbozo de la arquitectura del sistema en desarrollo.
Continuará...
Fuente: habr.com
