{"id":36025,"date":"2019-10-31T22:09:12","date_gmt":"2019-10-31T19:09:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/metriki-devops-otkuda-brat-dannye-dlya-raschetov\/"},"modified":"2019-10-31T22:09:12","modified_gmt":"2019-10-31T19:09:12","slug":"metriki-devops-otkuda-brat-dannye-dlya-raschetov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/metriki-devops-otkuda-brat-dannye-dlya-raschetov","title":{"rendered":"M\u00e9tricas DevOps \u2013 de onde pegar dados para c\u00e1lculos","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Para ser sincero, Ivan frequentemente ria dos esfor\u00e7os f\u00fateis dos colegas do departamento de monitoramento. Eles se esfor\u00e7avam imensamente para implementar as m\u00e9tricas que a alta administra\u00e7\u00e3o solicitava. Estavam t\u00e3o ocupados que mais ningu\u00e9m queria fazer nada. <\/p>\n

E a administra\u00e7\u00e3o nunca estava satisfeita - estava constantemente pedindo novas e novas m\u00e9tricas, rapidamente deixando de usar as que j\u00e1 haviam sido feitas.<\/p>\n

Ultimamente, todos s\u00f3 falavam sobre Lead Time - o tempo de entrega das funcionalidades de neg\u00f3cios. A m\u00e9trica mostrou um n\u00famero insano - 200 dias para entregar uma tarefa. Como todos se impressionaram, exclamando e levantando as m\u00e3os ao c\u00e9u!<\/p>\n

Depois de um tempo, o barulho gradualmente diminuiu e a administra\u00e7\u00e3o pediu a cria\u00e7\u00e3o de mais uma m\u00e9trica.<\/p>\n

Ivan tinha plena certeza de que a nova m\u00e9trica tamb\u00e9m morreria silenciosamente em um canto escuro.<\/p>\n

De fato, pensou Ivan, saber o n\u00famero n\u00e3o diz nada a ningu\u00e9m. 200 dias ou 2 dias - n\u00e3o h\u00e1 diferen\u00e7a, porque com o n\u00famero n\u00e3o \u00e9 poss\u00edvel determinar a causa e entender se isso \u00e9 bom ou ruim.<\/p>\n

Esta \u00e9 a armadilha t\u00edpica das m\u00e9tricas: parece que a nova m\u00e9trica revelar\u00e1 a ess\u00eancia da exist\u00eancia e explicar\u00e1 algum segredo oculto. Todos esperam por isso, mas nada acontece. Justamente porque o segredo n\u00e3o deve ser procurado nas m\u00e9tricas!<\/p>\n

Para Ivan, isso era um est\u00e1gio j\u00e1 superado. Ele entendia que m\u00e9tricas s\u00e3o apenas uma r\u00e9gua de madeira comum<\/a><\/noindex> para medi\u00e7\u00f5es, e todos os segredos devem ser buscados em objeto de influ\u00eancia<\/a><\/noindex>, ou seja, no que forma essa m\u00e9trica.<\/p>\n

Para uma loja online, o objeto de influ\u00eancia ser\u00e3o seus clientes, que trazem dinheiro, enquanto para o DevOps \u2013 as equipes que criam e implantam distribui\u00e7\u00f5es usando o pipeline.<\/p>\n

Certa vez, acomodando-se no sagu\u00e3o em uma poltrona confort\u00e1vel, Ivan decidiu pensar cuidadosamente sobre como gostaria de ver as m\u00e9tricas do DevOps, considerando que o objeto de influ\u00eancia s\u00e3o as equipes.<\/p>\n

Objetivo das m\u00e9tricas do DevOps<\/h2>\n

\n\u00c9 claro que todos desejam reduzir o tempo de entrega. 200 dias - isso simplesmente n\u00e3o \u00e9 aceit\u00e1vel. <\/p>\n

Mas como, essa \u00e9 a quest\u00e3o?<\/a><\/noindex><\/p>\n

Na empresa, centenas de equipes trabalham, e milhares de distribui\u00e7\u00f5es passam diariamente pelo pipeline do DevOps. O tempo real de entrega se apresentar\u00e1 como uma distribui\u00e7\u00e3o. Cada equipe ter\u00e1 seu pr\u00f3prio tempo e caracter\u00edsticas pr\u00f3prias. Como encontrar algo entre essa bagun\u00e7a?<\/p>\n

A resposta surgiu por si s\u00f3 \u2013 \u00e9 necess\u00e1rio identificar as equipes problem\u00e1ticas e entender o que est\u00e1 acontecendo com elas e por que demoram tanto, enquanto se aprende com as equipes \"boas\" como fazer tudo rapidamente. Para isso, \u00e9 preciso medir o tempo que as equipes passaram em cada um dos ambientes DevOps:<\/p>\n

\"M\u00e9tricas
\n
\nO objetivo do sistema ser\u00e1 a sele\u00e7\u00e3o de equipes com base no tempo de passagem pelos ambientes, ou seja, no final devemos obter uma lista de equipes com tempos selecionados, e n\u00e3o apenas n\u00fameros.<\/p>\n

Se soubermos quanto tempo foi gasto no total em cada ambiente e quanto tempo foi gasto em paralisa\u00e7\u00f5es entre os ambientes, poderemos contatar as equipes, investigar mais detalhadamente as causas e resolv\u00ea-las\", pensou Ivan.<\/p>\n

\"M\u00e9tricas
\n <\/p>\n

Como calcular o tempo de entrega para DevOps<\/h2>\n

Para fazer a contagem, era necess\u00e1rio se aprofundar no processo DevOps e suas entidades.<\/p>\n

Na empresa, \u00e9 utilizado um n\u00famero limitado de sistemas, e as informa\u00e7\u00f5es podem ser obtidas apenas a partir deles, e de mais nenhum outro lugar.<\/p>\n

Todas as tarefas na empresa eram registradas no Jira. Quando uma tarefa era iniciada, um branch era criado, e ap\u00f3s a implementa\u00e7\u00e3o, era feito um commit no BitBucket e um Pull Request. Ao aceitar o PR (Pull Request), um pacote era automaticamente criado e salvo no reposit\u00f3rio Nexus. <\/p>\n

\"M\u00e9tricas
\n
\nEm seguida, o pacote era implantado em v\u00e1rios ambientes com o uso do Jenkins para verificar a corre\u00e7\u00e3o do deploy, testes autom\u00e1ticos e manuais:<\/p>\n

\"M\u00e9tricas
\n
\nIvan detalhou quais informa\u00e7\u00f5es poderiam ser extra\u00eddas de quais sistemas para calcular o tempo nos ambientes:<\/p>\n