Para ser honesto, Ivan muitas vezes ria dos esforços inúteis de seus colegas do departamento de monitoramento. Eles fizeram grandes esforços para implementar as métricas que a administração da empresa lhes ordenou que atingissem. Eles estavam tão ocupados que não queriam que mais ninguém fizesse nada.
Mas isso não foi suficiente para a gestão - eles encomendaram constantemente mais e mais novas métricas, deixando rapidamente de usar o que havia sido feito anteriormente.
Ultimamente, todo mundo tem falado sobre LeadTime – o tempo para entrega de recursos de negócios. A métrica mostrou um número absurdo: 200 dias para entregar uma tarefa. Como todos fizeram ooh e aah e levantaram as mãos para o céu!
Depois de algum tempo, o ruído diminuiu gradualmente e a administração recebeu uma ordem para criar outra métrica.
Estava completamente claro para Ivan que a nova métrica morreria silenciosamente em um canto escuro.
Na verdade, pensou Ivan, saber o número não diz nada a ninguém. 200 dias ou 2 dias - não há diferença, pois é impossível determinar o motivo pelo número e entender se é bom ou ruim.
Esta é uma armadilha típica das métricas: parece que uma nova métrica contará a essência da existência e explicará algum segredo secreto. Todo mundo espera muito por isso, mas por algum motivo nada acontece. Sim, porque o segredo não deve estar nas métricas!
Para Ivan, esta foi uma etapa ultrapassada. Ele entendeu que para medições, e todos os segredos devem ser procurados em , ou seja é que essa métrica é formada.
Para uma loja online, o objeto de influência serão os clientes que arrecadam dinheiro, e para DevOps, serão as equipes que criarão e implementarão distribuições usando um pipeline.
Um dia, sentado em uma cadeira confortável no corredor, Ivan decidiu pensar cuidadosamente em como queria ver as métricas de DevOps, levando em consideração o fato de que o objeto de influência são as equipes.
Objetivo das métricas DevOps
É claro que todos querem reduzir o tempo de entrega. 200 dias, claro, não são bons.
Mas como, essa é a questão?
A empresa emprega centenas de equipes e milhares de distribuições passam pelo pipeline de DevOps todos os dias. O prazo de entrega real aparecerá como uma distribuição. Cada equipe terá seu tempo e características próprias. Como você pode encontrar alguma coisa nesta bagunça?
A resposta surgiu naturalmente - precisamos encontrar as equipes problemáticas e descobrir o que está acontecendo com elas e por que está demorando tanto, e aprender com as “boas” equipes como fazer tudo rapidamente. E para isso, é preciso mensurar o tempo gasto pelas equipes em cada um dos estandes de DevOps:
“O objetivo do sistema será selecionar as equipes com base no tempo de passagem pelas arquibancadas, ou seja. Como resultado, devemos obter uma lista de comandos com o horário selecionado, e não um número.
Se descobrirmos quanto tempo foi gasto no total no estande e quanto tempo foi gasto em paradas entre estandes, podemos encontrar as equipes, chamá-las e entender mais detalhadamente os motivos e eliminá-los”, pensou Ivan.
Como calcular o tempo de entrega para DevOps
Para calculá-lo foi necessário aprofundar-se no processo DevOps e em sua essência.
A empresa utiliza um número limitado de sistemas e as informações só podem ser obtidas neles e em nenhum outro lugar.
Todas as tarefas da empresa foram registradas no Jira. Quando uma tarefa era executada, um branch era criado para ela e, após a implementação, era feito um commit no BitBucket e no Pull Request. Quando um PR (Pull Request) era aceito, uma distribuição era automaticamente criada e armazenada no repositório Nexus.
Em seguida, a distribuição foi lançada em diversos estandes utilizando Jenkins para verificar a exatidão do lançamento, testes automáticos e manuais:
Ivan descreveu de quais sistemas quais informações podem ser obtidas para calcular o tempo nos estandes:
- Do Nexus – Hora de criação da distribuição e nome da pasta que continha o código de comando
- Do Jenkins – Horário de início, duração e resultado de cada trabalho, nome do stand (nos parâmetros do trabalho), etapas (etapas do trabalho), link para distribuição no Nexus.
- Ivan decidiu não incluir Jira e BitBucket no pipeline, porque... estavam mais relacionados à fase de desenvolvimento e não à implantação da distribuição finalizada nos estandes.
Com base nas informações disponíveis, foi desenhado o seguinte diagrama:
Sabendo quanto tempo leva para criar distribuições e quanto tempo é gasto em cada uma delas, você pode calcular facilmente os custos totais de percorrer todo o pipeline de DevOps (ciclo completo).
Aqui estão as métricas de DevOps que Ivan obteve:
- Número de distribuições criadas
- Parcela de distribuições que “vieram” ao estande e “passaram” pelo estande
- Tempo gasto no estande (ciclo de estande)
- Ciclo completo (tempo total para todos os estandes)
- Duração do trabalho
- Tempo de inatividade entre estandes
- Tempo de inatividade entre lançamentos de trabalhos no mesmo estande
Por um lado, as métricas caracterizaram muito bem o pipeline DevOps em termos de tempo, por outro lado, foram consideradas muito simples.
Satisfeito com o trabalho bem executado, Ivan fez uma apresentação e foi apresentá-lo à administração.
Ele voltou sombrio e com as mãos abaixadas.
“Isso é um fiasco, mano”, sorriu o irônico colega...
Leia mais no artigo “".
Fonte: habr.com