Um dia, Ivan foi convocado para uma reunião para discutir as métricas do DevOps.
Cada participante preparou para a reunião uma lista de determinadas métricas que, na sua opinião, valeriam a pena implementar.
Ouvindo os relatórios, Ivan tentou calcular quantas métricas foram sugeridas: 5,10, novamente 10 e cerca de uma dúzia mais. Acabou 30 com alguma coisa.
Por alguma razão, de repente surgiu a ideia de que as pessoas que se reuniram pesquisaram e escreveram os nomes que pareciam interessantes para eles. Aparentemente, ninguém pensou na essência das métricas.
Observando de lado, Ivan se perguntou: por quê? Por que exatamente essas métricas? O que eles vão te dar? De repente, ficou evidente que a reunião reuniu pessoas que estavam longe de compreender realmente a natureza das métricas e que tudo terminaria como de costume, perdendo uma quantidade enorme de tempo e jogando o trabalho no lixo.
Tornou-se triste e ofensivo. É uma pena que o tempo e o dinheiro da empresa não cheguem a lugar algum, e é triste que um negócio útil não seja feito.
Ivan estuda métricas há muito tempo e entende há muito tempo que o tópico é muito sério e complexo, e é impossível abordá-lo a partir da baía de bote em qualquer caso.
Nesse dia, a reunião terminou com tudo e nada - decidimos implementar tudo de uma vez (ninguém queria assumir a responsabilidade pela recusa, porque eu não entendia por que outra pessoa precisava dessas métricas).
Ivan decidiu preparar sua visão das métricas do DevOps e garantir que cada métrica fosse justificada, tivesse um objetivo específico, fosse útil e compreensível.
Foi o que ele fez ...
O que você deseja gerenciar?
Antes de tudo, Ivan decidiu pensar no objetivo principal, para o qual as métricas são feitas.
Os livros bem lidos Lean Analytics e The Practice of Tao Toyota sugeriram: escolha o número que deseja controlar como a principal métrica. Em seguida, selecione os componentes desse número que você pode influenciar como métricas.
O objetivo do DevOps na última reunião declarou "qualidade de software", mas o conceito de qualidade era muito vago. O que é qualidade? Como expressá-lo em um número? Quais componentes o afetam?
Infelizmente, a qualidade do software não pode ser expressa em um único número.
Enfim, o objetivo de usar o DevOps é realmente de qualidade?
Há alguns anos, Ivan trabalhou como diretor de TI de uma pequena empresa que produzia seu próprio software e, lá, ele lançou e usou o DevOps. E o objetivo deste DevOps não era realmente de qualidade. Pelo contrário, qualidade também. O principal e único objetivo era eliminar o trabalho manual durante as implantações no baile.
Ao remover o trabalho manual, ele alcançou tal aceleração e redução no número de erros que tornou possível liberar melhorias pelo menos uma vez por minuto.
Assim, descobriu-se que, como um
TARGET METRIC DevOps por si só se sugere
Tempo de entrega
É precisamente a sua diminuição ou aumento que mostraria o efeito das decisões gerenciais tomadas.
O tempo de entrega (Time To Market, TTM) aumentou - pouco. Diminuiu - excelente.
Mas o tempo de entrega depende do volume da tarefa e da duração dos testes e de muitos outros fatores! Sim está certo.
E foi por isso que Ivan decidiu deliberadamente iniciar a contagem regressiva não a partir do momento da codificação e análise, mas a partir do momento em que a montagem (distribuição) já foi criada e está armazenada e tudo o que resta é realizar uma série de verificações e implantá-la em um ambiente industrial (o chamado Entrega Contínua, CDL).
É importante aqui desenvolver primeiro um princípio, um conceito, pensou Ivan, e estendê-lo a outras áreas não alcançadas, porque a codificação, a montagem e todas as outras etapas de desenvolvimento também afetam o tempo de entrega, assim como o estágio CDL. Vamos fazer em um - faremos no outro.
Na grande empresa em que Ivan trabalhava, as métricas eram vitais. Milhares de desenvolvedores viram o código e centenas de montagens foram feitas diariamente, mas ninguém, ninguém na empresa sabia quanto tempo as equipes realmente gastam no DevOps.
Reclamações de todos os lados: besteira do DevOps, não funciona, desacelerou terrivelmente, não adianta. Mas ninguém tinha números reais em mãos, e era simplesmente impossível provar ou refutar as declarações das equipes.
Ivan estabeleceu esse objetivo - calcular o tempo que as equipes gastam no DevOps e, em particular, no estágio de entrega da montagem.
Isso não pode ser, pensou Ivan, se uma vez eu iniciei o DevOps e ele produziu um efeito instantâneo, por que não está aqui?
A criação de um sistema de métricas se tornou uma questão de honra para Ivan.
Controle o que você pode controlar
Como gerenciar o tempo de entrega? Isso é possível? - perguntou Ivan.
Se considerarmos o tempo de entrega como um número, fica claro que há locais no processo do DevOps que afetam significativamente esse número.
A empresa de Ivan tinha um padrão: cada montagem antes de ir ao baile passava por três bancos de teste, nos quais vários aspectos do software eram testados.
Naturalmente, as assembléias nelas “caíram” devido a erros, e novas foram criadas.
Os estandes são os elementos-chave do tempo total de entrega e são eles que afetam o tempo total, aumentando-o.
Tempo de entrega = Tempo no estande 1 + Tempo no estande 2 + Tempo no estande 3Influenciando o tempo gasto pelas equipes em cada um dos estandes, será possível influenciar o tempo final de entrega.
Duas perguntas simples permaneceram:
- como calcular fisicamente os custos das equipes nos estandes e
- o que fazer com os períodos de inatividade entre estandes (os períodos de inatividade também são componentes do tempo de entrega)?
Ivan não teve escolha a não ser mergulhar na selva de Jenkins e Nexus (software usado na CDL).
Jenkins e Nexus ajudam
A montagem "roll" no estande foi realizada usando Jenkins. De fato, Jenkins é um sheduler regular, como o crontab, mas com recursos avançados.
Jenkins sabe como exibir os logs de todos os trabalhos em execução (tarefas para rolar a montagem no estande) na forma de RSS, e há um horário de início, fim e um link para uma montagem específica.
Descobriu-se que, à disposição de Ivan, obtivemos dados sobre a hora exata do início e do fim dos trabalhos de montagem, ou seja, foi possível calcular com facilidade e precisão o tempo líquido gasto pelas equipes em estandes.
E se os dados de todos os estandes foram despejados em um banco de dados, foi possível calcular o tempo de inatividade entre os estandes. Isso foi ótimo!
No Nexus (armazenamento de arquivos de rede), Ivan obteria a data de criação do próprio assembly e assim por diante. determine o momento de sua aparência e o ponto de referência.
Tudo se encaixou. Quase.
- E como lidar com isso, pensou Ivan?
Para ser continuado. Objeto de influência