How Ivan did DevOps metrics. Object of influence

A week has passed since Ivan first thought about DevOps metrics and realized that they should be used to manage product delivery time (Time-To-Market).

Even on weekends, he thought about metrics: “So what if I measure time? What will it give me?

Indeed, what will the knowledge of time give? Let's say delivery takes 5 days. So, what is next? Is it good or bad? Even if this is bad, then you need to somehow reduce this time. But how?
These thoughts haunted him, but the decision did not come.

Ivan understood that he had come to the very essence. The countless graphs of metrics he had seen before convinced him long ago that the standard approach would not work, and that if he simply plotted (even cohort), there will be zero sense from it.

How to be?…

The metric is like a regular wooden ruler. Measurements made with it won't tell the reason why the measured object is exactly the length that it showed. The ruler will simply show its size, and no more. She is not a philosopher's stone, but simply a wooden board, which is measured.

The “stainless steel rat” of his favorite writer Harry Harrison always said: a thought must reach the bottom of the brain and lie down there, so after suffering for several days to no avail, Ivan decided to take on another task ...

A couple of days later, while reading an article about online stores, Ivan suddenly realized that the amount of money that an online store receives depends on how the site visitor behaves. It is they, the visitors/customers, who give the store their money and are the source of it. The final amount of money received by the store is affected by changes in customer behavior, and nothing else.

It turned out that in order to change the measured value, it was necessary to influence those who form this value, i.e. to change the amount of money of an online store, it was necessary to influence the behavior of the customers of this store, and to change the delivery time in DevOps, it was necessary to influence the teams that “create” this time, i.e. use DevOps in their work.

Ivan realized that DevOps metrics should not represent graphs at all. They must represent search tool "outstanding" teams that form the final delivery time.

No metric will ever show the reason why this or that team delivered the distribution kit for a long time, Ivan thought, because in reality there can be a million and a small cart, and they may well be not technical, but organizational. Those. the most you can expect to get from metrics is to show teams and their results, and then you still have to go to these teams and find out what happened to them.

On the other hand, Ivan's company had a standard obliging all teams to check the builds on several stands. The team could not advance to the next booth until the previous one had been completed. It turned out that if we imagine the DevOps process as a sequence of passing stands, then the metrics could show the time spent by teams on these stands. Knowing the stand and the time of the team, it was possible to talk more specifically with her about the reasons.

Without hesitation, Ivan picked up the phone and dialed the number of a person who is well versed in the innards of DevOps:

- Denis, tell me, please, is it possible to somehow understand that the team has passed this or that stand?
- Certainly. Our Jenkins drops the flag if the build has successfully rolled out (passed validation) on the bench.
- Super. What is a flag?
- This is a regular text file like "stand_OK" or "stand_FAIL", which says that the assembly passed or failed the stand. Well, you understand, right?
- I guess, yes. Is it written to the same folder in the repository where the assembly is located?
- Yes
— And what happens if the assembly does not pass the stand? Will I need to do a new build?
— yeah
- Well, ok, thanks. And another question: do I understand correctly that I can use the flag creation date as the date of the stand passage?
- Absolutely!
- Super!

Encouraged, Ivan hung up and realized that everything fell into place. Knowing the date of creation of the build file and the date of creation of the flags, it was possible to calculate, to the nearest second, how much time the teams spend on each stand and understand where they spend the most time.

“Understanding where it takes the most time, we will pinpoint the teams, go to them and dig the problem.” Ivan smiled.

For tomorrow, he set himself the task of sketching the architecture of the emerging system.

To be continued ...

Source: habr.com