Para ser honesto, Ivan ría moitas veces dos esforzos inútiles dos seus colegas do departamento de seguimento. Fixeron grandes esforzos para implantar as métricas que a dirección da empresa lles ordenou acadar. Estaban tan ocupados que non querían que ninguén fixese nada.
Pero non foi suficiente para a xestión: encargaban constantemente máis e máis métricas novas, deixando moi rapidamente de usar o que se fixera anteriormente.
Últimamente, todo o mundo está a falar de LeadTime: o momento da entrega de funcións empresariais. A métrica mostrou un número tolo: 200 días para entregar unha tarefa. Como todo o mundo oh e aah e levantou as mans ao ceo!
Despois dun tempo, o ruído diminuíu gradualmente e a dirección recibiu unha orde para crear outra métrica.
Iván tiña completamente claro que a nova métrica morrería igual de silenciosa nun recuncho escuro.
De feito, pensou Iván, saber que o número non lle di nada a ninguén. 200 días ou 2 días: non hai diferenza, porque é imposible determinar o motivo polo número e comprender se é bo ou malo.
Esta é unha trampa típica das métricas: parece que unha nova métrica contará a esencia da existencia e explicará algún segredo secreto. Todo o mundo espera moito para iso, pero por algún motivo non pasa nada. Si, porque o segredo non debe atoparse nas métricas!
Para Iván, esta foi unha etapa superada. El entendeu iso para medicións, e hai que buscar todos os segredos , é dicir. é que esta métrica está formada.
Para unha tenda en liña, o obxecto de influencia serán os seus clientes que aporten diñeiro, e para DevOps, serán os equipos os que creen e desenvolvan distribucións mediante un pipeline.
Un día, sentado nunha cómoda cadeira no salón, Ivan decidiu pensar detidamente como quería ver as métricas de DevOps, tendo en conta que o obxecto de influencia son os equipos.
Propósito das métricas de DevOps
Está claro que todos queren reducir o tempo de entrega. 200 días, por suposto, non son bos.
Pero como, esa é a pregunta?
A empresa emprega a centos de equipos e miles de distribucións pasan pola canalización de DevOps todos os días. O prazo de entrega real aparecerá como distribución. Cada equipo terá o seu tempo e as súas propias características. Como podes atopar algo entre esta desorde?
A resposta xurdiu de xeito natural: necesitamos atopar os equipos problemáticos e descubrir o que está a suceder con eles e por que leva tanto tempo, e aprender dos equipos "bos" a facer todo rapidamente. E para iso, cómpre medir o tempo que pasan os equipos en cada un dos postos de DevOps:
“A finalidade do sistema será seleccionar equipos en función do tempo que pasen polas bancadas, é dicir. Como resultado, deberíamos obter unha lista de comandos coa hora seleccionada, e non un número.
Se descubrimos canto tempo se pasou na bancada en total e canto tempo se pasou en paradas entre bancadas, poderemos atopar os equipos, chamalos e entender máis polo miúdo os motivos e eliminalos”, pensou Iván.
Como calcular o tempo de entrega para DevOps
Para calculalo, foi necesario afondar no proceso DevOps e na súa esencia.
A empresa utiliza un número limitado de sistemas, e só se pode obter información deles e en ningún outro lugar.
Todas as tarefas da empresa foron rexistradas en Jira. Cando se asumiu unha tarefa, creouse unha rama para ela e, tras a súa implementación, realizouse un compromiso con BitBucket e Pull Request. Cando se aceptaba un PR (Pull Request), creábase automaticamente unha distribución e almacenábase no repositorio de Nexus.
A continuación, a distribución realizouse en varios stands usando Jenkins para comprobar a corrección do lanzamento, as probas automáticas e manuais:
Ivan describiu de que sistemas se pode tomar a información para calcular o tempo nas bancadas:
- Desde Nexus: hora de creación da distribución e nome do cartafol que contiña o código de comando
- De Jenkins: hora de inicio, duración e resultado de cada traballo, nome do posto (nos parámetros do traballo), etapas (pasos do traballo), ligazón á distribución en Nexus.
- Ivan decidiu non incluír a Jira e BitBucket no proceso, porque... estaban máis relacionados coa fase de desenvolvemento, e non con estender a distribución acabada en stands.
A partir da información dispoñible, debuxouse o seguinte esquema:
Sabendo canto tempo leva crear distribucións e canto tempo se dedica a cada unha delas, podes calcular facilmente os custos totais de pasar por toda a canalización de DevOps (ciclo completo).
Estas son as métricas de DevOps coas que acabou Ivan:
- Número de distribucións creadas
- Porcentaxe de distribucións que "viñeron" á bancada e "pasaron" a bancada
- Tempo de permanencia no stand (ciclo de stand)
- Ciclo completo (tempo total para todos os stands)
- Duración do traballo
- Tempo de inactividade entre stands
- Tempo de inactividade entre os lanzamentos de traballo no mesmo posto
Por unha banda, as métricas caracterizaron moi ben a canalización de DevOps en termos de tempo, por outra banda, consideráronse moi sinxelas.
Satisfeito co traballo ben feito, Iván fixo unha presentación e foi presentala á dirección.
Volveu sombrío e coas mans baixas.
"Este é un fiasco, irmán", sorriu o irónico compañeiro...
Ler máis no artigo "».
Fonte: www.habr.com