Cómo Ivan hizo las métricas de DevOps. Objeto de influencia

Ha pasado una semana desde que Iván pensó por primera vez en las métricas de DevOps y se dio cuenta de que con su ayuda es necesario gestionar el tiempo de entrega del producto. (Hora de comprar).

Incluso los fines de semana pensaba en métricas: “¿Y qué pasa si mido el tiempo? ¿Qué me dará?

En efecto, ¿qué nos dará el conocimiento del tiempo? Digamos que la entrega demora 5 días. Entonces, ¿qué sigue? ¿Es bueno o malo? Incluso si esto es malo, entonces debes reducir de alguna manera este tiempo. ¿Pero cómo?
Estos pensamientos lo atormentaban, pero no llegó ninguna solución.

Iván comprendió que había llegado a la esencia misma. Los innumerables gráficos de métricas que había visto antes lo habían convencido hacía mucho tiempo de que el enfoque estándar no funcionaría y que si simplemente trazaba (incluso si es una cohorte), no servirá de nada.

¿Cómo ser?…

Una métrica es como una regla de madera común y corriente. Las mediciones realizadas con su ayuda no indicarán el motivo, por qué el objeto que se está midiendo tiene exactamente la longitud que ella mostró. La regla simplemente mostrará su tamaño y nada más. Ella no es la piedra filosofal, sino simplemente una tabla de madera con la que medir.

La “rata de acero inoxidable” de su escritor favorito Harry Harrison siempre decía: un pensamiento debe llegar al fondo del cerebro y quedarse ahí, así que después de sufrir durante varios días en vano, Iván decidió emprender otra tarea…

Un par de días después, mientras leía un artículo sobre tiendas en línea, Iván de repente se dio cuenta de que la cantidad de dinero que recibe una tienda en línea depende de cómo se comportan los visitantes del sitio. Son ellos, los visitantes/clientes, quienes dan su dinero a la tienda y son su fuente. El resultado final del efectivo que recibe una tienda está influenciado por los cambios en el comportamiento del cliente, y nada más.

Resultó que para cambiar el valor medido era necesario influir en quienes forman este valor, es decir para cambiar la cantidad de dinero de una tienda online, era necesario 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” este tiempo, es decir utilizan DevOps en su trabajo.

Ivan se dio cuenta de que las métricas de DevOps no deberían representarse mediante gráficos en absoluto. Deben representarse a sí mismos. herramienta de búsqueda Equipos “sobresalientes” que marcan el tiempo de entrega final.

Ninguna métrica mostrará jamás la razón por la que tal o cual equipo tardó tanto en entregar una distribución, pensó Iván, porque en realidad podría haber un millón y un carrito pequeño, y es posible que no sean técnicos, sino organizativos. Aquellos. Lo máximo que puedes esperar de las métricas es mostrar los equipos y sus resultados, y luego aún tienes que seguir a estos equipos con los pies y descubrir qué les pasa.

Por otro lado, la empresa de Iván tenía un estándar que exigía que todos los equipos probaran los ensamblajes en varios bancos. El equipo no pudo pasar a la siguiente grada hasta que se completara la anterior. Resultó que si imaginamos el proceso DevOps como una secuencia de paso por puestos, entonces las métricas podrían mostrar el tiempo que pasan los equipos en estos puestos. Conociendo la postura y el tiempo del equipo, fue posible hablar con ellos más concretamente sobre los motivos.

Sin dudarlo, Ivan cogió el teléfono y marcó el número de una persona que conoce bien los entresijos de DevOps:

— Denis, por favor dígame, ¿es posible entender de alguna manera que el equipo pasó tal o cual posición?
- Ciertamente. Nuestro Jenkins descarta la bandera si la compilación se implementó con éxito (pasó la prueba) en el banco.
- Súper. ¿Qué es una bandera?
- Este es un archivo de texto normal como “stand_OK” o “stand_FAIL”, que dice que el ensamblaje pasó o no el stand. Bueno, lo entiendes, ¿verdad?
- Supongo que si. ¿Está escrito en la misma carpeta del repositorio donde se encuentra el ensamblaje?
- Sí
— ¿Qué pasa si el montaje no pasa el banco de pruebas? ¿Tendré que hacer una nueva construcción?
- Sí
- Bueno, está bien, gracias. Y otra pregunta: ¿entiendo bien que puedo utilizar la fecha de creación de la bandera como fecha del stand?
- ¡Absolutamente!
- ¡Súper!

Inspirado, Iván colgó y se dio cuenta de que todo había encajado. Conociendo la fecha de creación del archivo de construcción y la fecha de creación de las banderas, fue posible calcular hasta el segundo cuánto tiempo pasan los equipos en cada stand y entender dónde pasan la mayor parte del tiempo.

"Al comprender dónde se gasta la mayor parte del tiempo, identificaremos los equipos, acudiremos a ellos y profundizaremos en el problema". Iván sonrió.

Para mañana se propuso la tarea de esbozar la arquitectura del sistema que se estaba dibujando.

To be continued ...

Fuente: habr.com

Añadir un comentario