{"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\/en\/blog\/administrirovanie\/metriki-devops-otkuda-brat-dannye-dlya-raschetov","title":{"rendered":"DevOps Metrics \u2013 Where to Get Data for Calculations","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

To be honest, Ivan often laughed at the futile efforts of his colleagues in the monitoring department. They put enormous effort into implementing the metrics that the company management ordered. They were so busy that they didn't want to do anything else. <\/p>\n

But the management was never satisfied \u2013 they constantly ordered new metrics, quickly forgetting about the ones that had already been created.<\/p>\n

Recently, everyone was talking about Lead Time \u2013 the time it takes to deliver business features. The metric showed a staggering number \u2013 200 days to deliver a single task. Everyone gasped, sighed, and raised their hands to the sky!<\/p>\n

After a while, the noise gradually subsided, and management came up with a request for yet another metric.<\/p>\n

Ivan understood that this new metric would quietly fade away in a dark corner just like the previous ones.<\/p>\n

Indeed, Ivan thought, knowing the number doesn't tell anyone anything. Whether it's 200 days or 2 days makes no difference because the number doesn't help to identify the cause or to understand whether it's good or bad.<\/p>\n

This is the typical trap of metrics: it seems that the new metric will reveal the essence of existence and explain some secret. Everyone hopes for it, but somehow nothing happens. It's because the secret should not be sought in the metrics at all!<\/p>\n

For Ivan, this was a phase he had already gone through. He understood that metrics are just a regular wooden ruler<\/a><\/noindex> for measurements, but all secrets should be sought in the object of influence<\/a><\/noindex>, i.e., in what shapes this metric.<\/p>\n

For an online store, the object of influence would be its customers bringing in money, and for DevOps \u2013 the teams that create and deploy distributions using a pipeline.<\/p>\n

One day, settling into a comfortable chair in the lobby, Ivan decided to carefully think about how he would like to see DevOps metrics, considering that the object of influence is the teams.<\/p>\n

The goal of DevOps metrics<\/h2>\n

\nIt's clear that everyone wants to reduce delivery time. 200 days is, of course, unacceptable. <\/p>\n

But how, that's the question?<\/a><\/noindex><\/p>\n

The company has hundreds of teams, and thousands of distributions pass through the DevOps pipeline each day. The actual delivery time will look like a distribution. Each team will have its own time and its own peculiarities. How can anything be found amidst this mess?<\/p>\n

The answer came to itself \u2013 we need to identify the problematic teams and figure out what is happening with them and why it takes so long, while learning from the 'good' teams how to do everything quickly. For this, it is necessary to measure the time spent by teams on each DevOps stand:<\/p>\n

\"DevOps
\n
\nThe goal of the system will be to select teams based on stand passage time, meaning we should end up with a list of teams along with their selected times, rather than just numbers.<\/p>\n

If we find out how much total time was spent on the stand and how much time was spent on downtime between stands, we can contact the teams, investigate the reasons in more detail, and address them,\" Ivan thought.<\/p>\n

\"DevOps
\n <\/p>\n

How to calculate delivery time for DevOps<\/h2>\n

To perform this calculation, it was necessary to delve into the DevOps process and its entities.<\/p>\n

The company uses a limited number of systems, and information can only be obtained from them and nowhere else.<\/p>\n

All tasks in the company were logged in Jira. When a task was taken up, a branch was created for it, and after implementation, a commit was made in BitBucket and a Pull Request was created. Upon PR acceptance, a distribution was automatically created and stored in Nexus. <\/p>\n

\"DevOps
\n
\nThe distribution was then deployed on several stands using Jenkins for verifying the correctness of the deployment, automatic and manual testing:<\/p>\n

\"DevOps
\n
\nIvan outlined what information can be extracted from which systems to calculate the time on the stands:<\/p>\n