DevOps metrics - where to get data for calculations

    Honestly, Ivan often laughed at the futile efforts of colleagues from the monitoring department. They made great efforts to implement the metrics that the company management ordered them. They were so busy that they didn’t want to do anything else.

    And the management was not enough - it constantly ordered more and more metrics, very quickly ceasing to use what was done earlier.

    Recently, everyone just talked about LeadTime - the delivery time of business features. The metric showed a crazy number - 200 days to deliver one task. How did everyone groan, groan and raise their hands to heaven!

    After some time, the noise gradually calmed down and an order came from the management to create another metric.

    Ivan was perfectly clear that the new metric would also quietly die in a dark corner.

    Indeed, Ivan mused, knowing the number tells absolutely nothing to anyone. 200 days or 2 days - there is no difference, because by the number it is impossible to determine the reason and understand whether it is good or bad.

    This is a typical metric trap: it seems that the new metric will tell the essence of being and explain some secret secret. Everyone hopes so, but for some reason nothing happens. Yes, because the secret must not be sought in metrics!

    For Ivan, this was a passed stage. He understood that metrics are just an ordinary wooden ruler for measurements, and all the secrets must be sought in the object of influence , i.e. in that this metric forms.

    For an online store, the object of influence will be its customers, who bring money, and for DevOps, the teams that create and roll out distributions using the pipeline.

    Once, having settled down in the lobby in a comfortable armchair, Ivan decided to think carefully about how he would like to see DevOps metrics, taking into account the fact that teams are the object of influence.

    Goal DevOps Metrics


    It is clear that everyone wants to reduce the delivery time. 200 days is, of course, good for nothing.

    But how, that’s the question?

    The company has hundreds of teams, and thousands of distributions go through the DevOps pipeline every day. Real delivery time will look like distribution. Each team will have its own time and its own characteristics. How can you find at least something among this mess?

    The answer arose naturally - you need to find problematic teams and figure out what is going on with them and why for so long, and learn how to do everything quickly with “good” teams. And for this you need to measure the time spent by the teams at each of the DevOps stands:



    “The purpose of the system will be the selection of teams according to the time of passing the stands, in the end, we should get a list of teams with the selected time, and not a number.

    If we find out how much time was spent on a stand in total and how much time was spent on downtime between the stands, we can find teams, call them and understand the reasons in more detail and eliminate them, ”thought Ivan.



    How to calculate delivery time for DevOps



    To count, it was necessary to delve into the DevOps process and its essence.

    The company uses a limited number of systems, and information can be obtained only from them and nowhere else.

    All tasks in the company were registered in Jira. When the task was taken to work, a brunch was created for it, and after implementation, a commit was made to BitBucket and Pull Request. When accepting PR (Pull Request), a distribution kit was automatically created and stored in the Nexus repository.



    Further, the distribution was rolled out on several stands using Jenkins to check the correctness of rolling, automatic and manual testing:



    Ivan wrote out which systems what information can be taken to calculate the time on the stands:

    • From Nexus - Distribution creation time and name of the folder in which the command code was contained
    • From Jenkins - Start time, duration and result of working out each job, the name of the stand (in the job parameters), stages (steps of the job), a link to the distribution in Nexus.
    • Ivan decided not to include Jira and BitBucket in the pipeline, because they were more related to the development phase, and not to rolling the finished distribution around the stands.



    Based on the information at its disposal, such a scheme was drawn:



    Knowing how much time the distributions are created and how much time is spent on each of them, you can easily calculate the total cost of going through the entire DevOps pipeline (full cycle).

    Here are the DevOps metrics from Ivan as a result:

    • Number of Distributions Created
    • The share of distributions “logged in” to the stand and “past” the stand
    • Time spent at the stand (stand cycle)
    • Full cycle (total time for all stands)
    • Job Duration
    • Simple between stands
    • Simple between job launches on one stand

    On the one hand, metrics very well characterized the DevOps pipeline in terms of time, on the other hand, they were considered very simple.

    Satisfied with the job well done, Ivan made a presentation and went to present it to the management.

    He returned frowning and with his hands down.

    “This is a fiasco, bro,” the ironic colleague smiled.

    Read on in the article “ How Fast Results Helped Ivan ”.

    Also popular now: