Como fixo Ivan as métricas de DevOps. Obxecto de influencia

Pasou unha semana desde que Ivan pensou por primeira vez nas métricas de DevOps e se decatou de que coa súa axuda é necesario xestionar o tempo de entrega do produto (Time-To-Market).

Incluso os fins de semana, pensou nas métricas: "E se mido o tempo? Que me dará?

De feito, que dará o coñecemento do tempo? Digamos que a entrega tarda 5 días. Entón, que é o seguinte? É bo ou malo? Aínda que isto sexa malo, cómpre reducir dalgunha maneira este tempo. Pero como?
Estes pensamentos perseguíano, pero non chegou ningunha solución.

Iván entendeu que chegara á esencia mesma. As innumerables gráficas de métricas que vira antes habían convencido de que o enfoque estándar non funcionaría e que se simplemente trazase (aínda que sexa unha cohorte), non servirá de nada.

Como ser?…

Unha métrica é como unha regra de madeira común. As medicións feitas coa súa axuda non indicarán o motivo, por que o obxecto que se mide é exactamente a lonxitude que ela mostrou. A regra simplemente mostrará o seu tamaño e nada máis. Non é a pedra filosofal, senón simplemente unha táboa de madeira coa que medir.

A "rata de aceiro inoxidable" do seu escritor favorito Harry Harrison sempre dicía: un pensamento debe chegar ao fondo do cerebro e estar alí, así que despois de sufrir varios días en vano, Ivan decidiu emprender outra tarefa...

Un par de días despois, mentres lía un artigo sobre tendas en liña, Ivan deuse conta de súpeto de que a cantidade de diñeiro que recibe unha tenda en liña depende de como se comportan os visitantes do sitio. Son eles, visitantes/clientes, os que dan o seu diñeiro á tenda e son a súa fonte. O resultado final de efectivo que recibe unha tenda está influenciado polos cambios no comportamento dos clientes, non por outra cousa.

Resultou que para cambiar o valor medido era necesario influír nos que forman este valor, é dicir. para cambiar a cantidade de diñeiro dunha tenda en liña, foi necesario influír no comportamento dos clientes desta tenda, e para cambiar o tempo de entrega en DevOps, foi necesario influír nos equipos que "crean" nesta ocasión, é dicir. usar DevOps no seu traballo.

Ivan deuse conta de que as métricas de DevOps non deberían representarse en ningún caso mediante gráficos. Deben representarse a si mesmos ferramenta de busca equipos “sobresalientes” que configuran o prazo de entrega final.

Ningunha métrica mostrará nunca o motivo polo que tal ou cal equipo tardou moito en entregar unha distribución, pensou Iván, porque en realidade podería haber un millón e un carro pequeno, e ben poden non ser técnicos, senón organizativos. Eses. o máximo que podes esperar obter das métricas é mostrar os equipos e os seus resultados, e despois aínda tes que seguir estes equipos cos teus pés e descubrir o que lles pasa.

Por outra banda, a empresa de Iván tiña unha norma que obrigaba a todos os equipos a probar as montaxes en varios bancos. O equipo non puido pasar á seguinte grada ata completar a anterior. Resultou que se imaxinamos o proceso DevOps como unha secuencia de paso por gradas, entón as métricas poderían mostrar o tempo que pasan os equipos nestas bancadas. Coñecendo o posto e a hora do equipo, púidose falar con eles máis concretamente dos motivos.

Sen dubidalo, Ivan colleu o teléfono e marcou o número dunha persoa que coñece ben os pormenores de DevOps:

— Denis, por favor, dígame, é posible entender dalgún xeito que o equipo pasou por esta ou aquela grada?
- Certamente. O noso Jenkins descarta a bandeira se a construción se desenvolveu correctamente (pasou a proba) no banco.
- Súper. Que é unha bandeira?
- Este é un ficheiro de texto normal como "stand_OK" ou "stand_FAIL", que di que a montaxe pasou ou fallou no stand. Ben, entendes, non?
- Supoño que si. Está escrito no mesmo cartafol do repositorio onde se atopa a montaxe?
- Si
— Que pasa se a montaxe non supera o banco de probas? Terei que facer unha nova construción?
- Si
- Ben, ok, grazas. E outra pregunta: entendo ben que podo utilizar a data de creación da bandeira como data do stand?
- Absolutamente!
- Súper!

Inspirado, Iván colgou e deuse conta de que todo quedara no seu lugar. Coñecendo a data de creación do ficheiro de construción e a data de creación das bandeiras, foi posible calcular ata segundo o tempo que pasan os equipos en cada stand e comprender onde pasan máis tempo.

"Comprendendo onde se pasa máis tempo, identificaremos os equipos, iremos a eles e investigaremos o problema". Iván sorriu.

Para mañá, propúxose a tarefa de esbozar a arquitectura do sistema que se debuxa.

Continuar ...

Fonte: www.habr.com