(Tempo de lançamento no mercado).
Mesmo nos finais de semana, ele pensava em métricas: “E daí se eu medir o tempo? O que isso vai me dar?
Na verdade, o que o conhecimento do tempo proporcionará? Digamos que a entrega demore 5 dias. Então, o que vem a seguir? Isso é bom ou ruim? Mesmo que isso seja ruim, você precisa reduzir de alguma forma esse tempo. Mas como?
Esses pensamentos o assombravam, mas nenhuma solução veio.
Ivan entendeu que havia chegado à essência. Os incontáveis gráficos de métricas que ele tinha visto antes o convenceram há muito tempo de que a abordagem padrão não funcionaria e que se ele simplesmente traçasse (), não terá utilidade.
Como ser?…
Uma métrica é como uma régua de madeira comum. As medições feitas com sua ajuda não dirão o motivo, por que o objeto que está sendo medido tem exatamente o comprimento que ela mostrou. A régua simplesmente mostrará seu tamanho e nada mais. Ela não é a pedra filosofal, mas simplesmente uma tábua de madeira para medir.
O “rato de aço inoxidável” de seu escritor favorito, Harry Harrison, sempre dizia: um pensamento deve chegar ao fundo do cérebro e ficar ali, então, depois de sofrer por vários dias sem sucesso, Ivan decidiu assumir outra tarefa...
Alguns dias depois, ao ler um artigo sobre lojas online, Ivan de repente percebeu que a quantidade de dinheiro que uma loja online recebe depende de como os visitantes do site se comportam. São eles, visitantes/clientes, que dão o dinheiro à loja e são a sua fonte. O resultado final do dinheiro que uma loja recebe é influenciado pelas mudanças no comportamento do cliente, e não por qualquer outra coisa.
Descobriu-se que para alterar o valor medido era necessário influenciar quem forma esse valor, ou seja, para alterar a quantidade de dinheiro de uma loja online foi necessário influenciar o comportamento dos clientes desta loja, e para alterar o prazo de entrega em DevOps foi necessário influenciar as equipas que “criam” esse tempo, ou seja, usam DevOps em seu trabalho.
Ivan percebeu que as métricas de DevOps não deveriam ser representadas por gráficos. Eles devem se representar ferramenta de busca Equipes “destacadas” que moldam o prazo final de entrega.
Nenhuma métrica jamais mostrará o motivo pelo qual esta ou aquela equipe demorou tanto para entregar uma distribuição, pensou Ivan, porque na realidade poderia haver um milhão e um carrinho pequeno, e eles podem muito bem não ser técnicos, mas organizacionais. Aqueles. o máximo que você pode esperar obter das métricas é mostrar as equipes e seus resultados, e então você ainda terá que acompanhar essas equipes com os pés e descobrir o que há de errado com elas.
Por outro lado, a empresa de Ivan tinha uma norma que exigia que todas as equipes testassem as montagens em diversas bancadas. A equipe não poderia passar para a próxima arquibancada até que a anterior fosse concluída. Descobriu-se que se imaginarmos o processo DevOps como uma sequência de passagem pelos estandes, as métricas poderiam mostrar o tempo gasto pelas equipes nesses estandes. Conhecendo a posição e o horário da equipe, foi possível conversar com eles mais especificamente sobre os motivos.
Sem hesitar, Ivan pegou o telefone e discou o número de uma pessoa que conhece bem os meandros do DevOps:
— Denis, por favor me diga, é possível entender de alguma forma que a equipe passou por esta ou aquela posição?
- Certamente. Nosso Jenkins descarta o sinalizador se a compilação foi implementada com sucesso (passou no teste) no banco.
- Ótimo. O que é uma bandeira?
- Este é um arquivo de texto normal como “stand_OK” ou “stand_FAIL”, que indica que a montagem foi aprovada ou reprovada no estande. Bem, você entende, certo?
- Eu acho que sim. Ele está gravado na mesma pasta do repositório onde o assembly está localizado?
- Sim
— O que acontece se a montagem não passar na bancada de testes? Vou precisar fazer uma nova construção?
- Sim
- Bem, ok, obrigado. E outra pergunta: entendi bem que posso usar a data de criação da bandeira como data do estande?
- Absolutamente!
- Super!
Inspirado, Ivan desligou e percebeu que tudo havia se encaixado. Sabendo a data de criação do arquivo build e a data de criação das bandeiras, foi possível calcular ao segundo quanto tempo as equipes passam em cada estande e entender onde elas passam mais tempo.
“Compreendendo onde é gasto mais tempo, identificaremos as equipes, iremos até elas e investigaremos o problema.” Ivan sorriu.
Para amanhã, ele se propôs a esboçar a arquitetura do sistema que estava sendo desenhado.
Para ser continuado ...
Fonte: habr.com