Honestamente, Ivan frequentemente ria dos esforços fúteis dos colegas do departamento de monitoramento. Eles fizeram grandes esforços para implementar as métricas que a gerência da empresa ordenou. Eles estavam tão ocupados que não queriam fazer mais nada.
E o gerenciamento não era suficiente - ele solicitava constantemente mais e mais métricas, deixando rapidamente de usar o que foi feito anteriormente.
Recentemente, todo mundo falou sobre o LeadTime - o tempo de entrega dos recursos da empresa. A métrica mostrou um número louco - 200 dias para entregar uma tarefa. Como todos gemeram, gemeram e levantaram as mãos para o céu!
Depois de algum tempo, o ruído gradualmente se acalmou e um pedido foi enviado pela gerência para criar outra métrica.
Ivan estava perfeitamente claro que a nova métrica também morreria silenciosamente em um canto escuro.
Na verdade, Ivan refletiu, sabendo que o número não diz absolutamente nada a ninguém. 200 dias ou 2 dias - não há diferença, porque pelo número é impossível determinar o motivo e entender se é bom ou ruim.
Essa é uma armadilha típica de métrica: parece que a nova métrica dirá a essência do ser e explicará algum segredo secreto. Todo mundo espera que sim, mas por alguma razão nada acontece. Sim, porque o segredo não deve ser procurado em métricas!
Para Ivan, este foi um estágio passado. Ele entendeu que as
métricas são apenas uma régua de madeira comum para medições, e todos os segredos devem ser buscados no
objeto de influência , ou seja, nessa forma de métrica.
Para uma loja on-line, o objeto de influência serão seus clientes, que trazem dinheiro, e para o DevOps, as equipes que criam e implementam distribuições usando o pipeline.
Uma vez, tendo se acomodado no saguão em uma poltrona confortável, Ivan decidiu pensar cuidadosamente sobre como gostaria de ver as métricas do DevOps, levando em consideração o fato de que as equipes são objeto de influência.
Métricas do DevOps da meta
É claro que todo mundo quer reduzir o tempo de entrega. É claro que 200 dias não servem para nada.
Mas como, eis a questão?
A empresa possui centenas de equipes e milhares de distribuições passam pelo pipeline do DevOps todos os dias. O tempo de entrega real será semelhante à distribuição. Cada equipe terá seu próprio tempo e suas próprias características. Como você pode encontrar pelo menos algo entre essa bagunça?
A resposta surgiu naturalmente - você precisa encontrar equipes problemáticas e descobrir o que está acontecendo com elas e por quê por tanto tempo e aprender a fazer tudo rapidamente com equipes "boas". E para isso, você precisa medir o tempo gasto pelas equipes em cada um dos estandes do DevOps:
“O objetivo do sistema será a seleção de equipes de acordo com o tempo de aprovação das arquibancadas, no final, devemos obter uma lista de equipes com o horário selecionado, e não um número.
Se descobrirmos quanto tempo foi gasto em um estande no total e quanto tempo foi gasto no tempo de inatividade entre os estandes, podemos encontrar equipes, ligar para eles e entender os motivos com mais detalhes e eliminá-los ”, pensou Ivan.
Como calcular o tempo de entrega do DevOps
Para contar, foi necessário aprofundar o processo do DevOps e sua essência.
A empresa utiliza um número limitado de sistemas, e as informações podem ser obtidas apenas com eles e em nenhum outro lugar.
Todas as tarefas da empresa foram registradas em Jira. Quando a tarefa foi levada para o trabalho, um brunch foi criado para ela e, após a implementação, uma confirmação foi feita no BitBucket e no Pull Request. Ao aceitar PR (solicitação de recebimento), um kit de distribuição foi criado e armazenado automaticamente no repositório do Nexus.
Além disso, a distribuição foi implementada em vários suportes usando Jenkins para verificar a exatidão dos testes de rolagem, automáticos e manuais:
Ivan pintou de quais sistemas quais informações podem ser obtidas para calcular o tempo nas bancas:
- Do Nexus - Horário de criação da distribuição e nome da pasta na qual o código de comando estava contido
- De Jenkins - Hora de início, duração e resultado do trabalho de cada trabalho, o nome do estande (nos parâmetros do trabalho), etapas (etapas do trabalho), um link para a distribuição no Nexus.
- Ivan decidiu não incluir Jira e BitBucket no pipeline, porque eles estavam mais relacionados à fase de desenvolvimento, e não a rolar a distribuição final pelos estandes.
Com base nas informações disponíveis, foi elaborado o seguinte esquema:
Sabendo quanto tempo as distribuições são criadas e quanto tempo é gasto em cada uma delas, você pode calcular facilmente o custo total de passar por todo o pipeline do DevOps (ciclo completo).
Aqui estão as métricas do DevOps de Ivan como resultado:
- Número de distribuições criadas
- A parcela de distribuições “efetuou login” no estande e “passou” o estande
- Tempo gasto no estande (ciclo do estande)
- Ciclo completo (tempo total para todos os estandes)
- Duração do trabalho
- Simples entre estandes
- Simples entre lançamentos de emprego em um único suporte
Por um lado, as métricas caracterizaram muito bem o pipeline do DevOps em termos de tempo; por outro, foram consideradas muito simples.
Satisfeito com o trabalho bem feito, Ivan fez uma apresentação e foi apresentá-la à gerência.
Ele voltou franzindo a testa e com as mãos para baixo.
"Isso é um fiasco, mano", o colega irônico sorriu.
Continue a ler o artigo "A rapidez com que os resultados ajudaram Ivan ".