Uma semana se passou desde que Ivan pensou pela primeira vez nas métricas do DevOps e percebeu que elas precisavam gerenciar o tempo de entrega do produto (Time-To-Market)
com sua ajuda .
Mesmo no fim de semana, ele pensou em métricas: “E daí, o que eu mede o tempo? O que isso vai me dar? ”
De fato, o que o conhecimento do tempo dará? Suponha que a entrega demore 5 dias. Então, o que vem a seguir? Isso é bom ou ruim? Mesmo se isso for ruim, você precisará reduzir esse tempo de alguma forma. Mas como
Esses pensamentos não lhe deram descanso, mas nenhuma solução veio.
Ivan entendeu que havia abordado a própria essência. Os inúmeros gráficos de métricas que ele já havia visto o convenceram há muito tempo que a abordagem padrão não funcionaria e que, se você construísse um gráfico (
mesmo um de coorte ), não haveria sentido nele.
Como ser? ...
Metric é como uma régua de madeira comum. As medidas feitas com sua ajuda não informam o motivo pelo
qual o objeto medido tem exatamente o comprimento que ele mostrou. A linha simplesmente mostrará seu tamanho e não mais. Não é uma pedra filosofal, mas simplesmente uma tábua de madeira que é medida.
O "rato de aço inoxidável" de seu amado escritor Harry Harrison sempre dizia: o pensamento deveria chegar ao fundo do cérebro e permanecer ali, então Ivan decidiu fazer outra tarefa por vários dias sem resultados ...
Depois de alguns dias, lendo um artigo sobre lojas online, Ivan percebeu subitamente que a quantidade de dinheiro que uma loja online recebe depende de como o visitante do site se comporta. Eles, os visitantes / clientes, dão dinheiro à loja e são sua fonte. A quantidade total de dinheiro recebido pela loja é afetada por mudanças no comportamento do cliente, e não em outra coisa.
Verificou-se que, para alterar o valor medido, era necessário influenciar quem forma esse valor, ou seja, para alterar a quantidade de dinheiro que uma loja on-line teve que influenciar o comportamento dos clientes dessa loja, e para alterar o tempo de entrega no DevOps, foi necessário influenciar as equipes que "criam" esse tempo, ou seja, use DevOps em seu trabalho.
Ivan percebeu que as métricas do DevOps não deveriam representar gráficos. Eles devem ser uma
ferramenta para encontrar equipes "excelentes" que formam o tempo de entrega final.
Nenhuma métrica jamais mostrará o motivo pelo qual essa ou aquela equipe fornece a distribuição há muito tempo, pensou Ivan, porque, na realidade, pode haver um milhão e um carrinho pequeno, e eles podem não ser técnicos, mas organizacionais. I.e. o máximo que você pode esperar obter das métricas é mostrar as equipes e seus resultados, e você ainda precisará ir a essas equipes com os pés e descobrir o que aconteceu com elas.
Por outro lado, havia um padrão na empresa de Ivan, obrigando todas as equipes a verificar as montagens em vários estandes. A equipe não pôde passar para a próxima posição até que a anterior fosse concluída. Descobriu-se que, se você imaginar o processo do DevOps como uma sequência de postos de aprovação, as métricas poderão mostrar o tempo gasto pelas equipes nessas posições. Conhecendo a posição e o tempo da equipe, foi possível conversar mais especificamente com ela sobre os motivos.
Sem hesitar, Ivan pegou o telefone e discou o número de uma pessoa bem versada no interior do DevOps:
- Denis, diga-me, por favor, é possível entender de alguma forma que a equipe passou por essa ou aquela posição?
Claro. Nosso Jenkins descarta a bandeira se a montagem foi lançada com sucesso (passou no teste) no estande.
Super. O que é uma bandeira?
- Esse é um arquivo de texto comum do tipo “stand_OK” ou “stand_FAIL”, que indica que a montagem passou ou não no estande. Bem, você entendeu, hein?
- Em princípio sim. Está gravado na mesma pasta no repositório, onde está o assembly?
- sim
- E o que acontecerá se a assembléia não passar no estande? Você precisará fazer uma nova montagem?
- sim
Ok, obrigado. E outra pergunta: entendo corretamente que posso usar a data de criação da bandeira como a data da passagem do estande?
Absolutamente!
Super!
Incentivado, Ivan desligou o telefone e percebeu que tudo se encaixava. Sabendo a data de criação do arquivo de montagem e a data de criação dos sinalizadores, foi possível calcular com precisão até um segundo quanto tempo as equipes gastam em cada estande e entender onde gastam mais tempo.
"Entendendo onde leva mais tempo, encontraremos as equipes ponto a ponto, iremos até elas e descobriremos um problema." Ivan sorriu.
Para amanhã, ele se propôs a esboçar a arquitetura do sistema que está sendo desenhado.
Para continuar ...