How Ivan metrics DevOps did. Object of influence
A week has passed since Ivan thought for the first time about the DevOps metrics and realized that with their help, it is necessary to manage the delivery time of the product (Time-To-Market).
Even at the weekend, he thought about the metrics: “So what if I measure time? What will it give me? "
Indeed, what will the knowledge of time give? Suppose the delivery takes 5 days. So, what is next? Is it good or bad? Even if it is bad, you need to somehow reduce this time. But how?
These thoughts did not give him peace, but the decision did not come.
Ivan understood that he came to the very essence. Countless graphs of metrics that he had seen before have long since convinced him that the standard approach would not work, and that if you simply build a graph ( even if a cohort one ), it would be zero from it.
How to be?...
A metric is like an ordinary wooden ruler. Measurements made with its help will not tell the reason why the measured object is exactly the length it showed. The ruler will simply show its size, and no more. It 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: the thought should reach the bottom of the brain and lie down there, so having been tormented unsuccessfully for several days, Ivan decided to take up another task ...
After a couple of days, reading an article about online shopping, Ivan suddenly realized that the amount of money that an online store receives depends on how the site visitors behave. They, the visitors / customers, give their money to the store and are their source. The total amount of money received by the store is influenced by changes in customer behavior, and nothing else.
It turned out that to change the measured value, it was necessary to influence those who form this value, i.e. to change the amount of money the online store had to influence the behavior of 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 graphics at all. They must be the search tool for "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 could be a million and a small trolley, and they may well be not technical, but organizational. Those. the maximum that you can expect to receive from the metrics is to show the teams and their results, and then you still have to go to these teams with their feet and find out what happened to them.
On the other hand, there was a standard in Ivan’s company that obliges all teams to check assemblies on several stands. The team could not go to the next stand until the previous one was passed. It turned out that if the DevOps process was presented as a sequence of passing the stands, then the metrics could show the time spent by the teams on these stands. Knowing the booth and the time of the team, one could more specifically talk about the reasons for it.
Without hesitation, Ivan picked up the phone and dialed the number of a person who is well versed in the internals of DevOps:
- Denis, tell me, please, is it possible to somehow understand that the team has passed this or that stand?
- Of course. Our Jenkins discards the flag if the assembly has successfully rolled (tested) on the stand.
- Great. What is a flag?
- This is a plain text file of the “stand_OK” or “stand_FAIL” type, which says that the build has passed or failed to pass the stand. Well, you understand, yes?
- I guess, yes. It is written in the same folder in the repository, where is the assembly?
- Yes
- And what will happen if the assembly did not pass the stand? Need to do a new build?
- yeah
- Well, ok, thanks. And another question: do I understand correctly that I can use the date of the creation of the flag as the date for passing the stand?
- Absolutely!
- Great!
Inspired, Ivan hung up and realized that everything fell into place. Knowing the date of creation of the assembly file and the date of creation of flags, it was possible to calculate, with an accuracy of a second, how much time the teams spend on each stand and understand where they spend the most time.
"Understanding where most time is spent, we will point out the teams, go to them and dig through the problem." Ivan smiled.
Tomorrow he set himself the task of sketching the architecture of the system being drawn.
To be continued…
Even at the weekend, he thought about the metrics: “So what if I measure time? What will it give me? "
Indeed, what will the knowledge of time give? Suppose the delivery takes 5 days. So, what is next? Is it good or bad? Even if it is bad, you need to somehow reduce this time. But how?
These thoughts did not give him peace, but the decision did not come.
Ivan understood that he came to the very essence. Countless graphs of metrics that he had seen before have long since convinced him that the standard approach would not work, and that if you simply build a graph ( even if a cohort one ), it would be zero from it.
How to be?...
A metric is like an ordinary wooden ruler. Measurements made with its help will not tell the reason why the measured object is exactly the length it showed. The ruler will simply show its size, and no more. It 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: the thought should reach the bottom of the brain and lie down there, so having been tormented unsuccessfully for several days, Ivan decided to take up another task ...
After a couple of days, reading an article about online shopping, Ivan suddenly realized that the amount of money that an online store receives depends on how the site visitors behave. They, the visitors / customers, give their money to the store and are their source. The total amount of money received by the store is influenced by changes in customer behavior, and nothing else.
It turned out that to change the measured value, it was necessary to influence those who form this value, i.e. to change the amount of money the online store had to influence the behavior of 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 graphics at all. They must be the search tool for "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 could be a million and a small trolley, and they may well be not technical, but organizational. Those. the maximum that you can expect to receive from the metrics is to show the teams and their results, and then you still have to go to these teams with their feet and find out what happened to them.
On the other hand, there was a standard in Ivan’s company that obliges all teams to check assemblies on several stands. The team could not go to the next stand until the previous one was passed. It turned out that if the DevOps process was presented as a sequence of passing the stands, then the metrics could show the time spent by the teams on these stands. Knowing the booth and the time of the team, one could more specifically talk about the reasons for it.
Without hesitation, Ivan picked up the phone and dialed the number of a person who is well versed in the internals of DevOps:
- Denis, tell me, please, is it possible to somehow understand that the team has passed this or that stand?
- Of course. Our Jenkins discards the flag if the assembly has successfully rolled (tested) on the stand.
- Great. What is a flag?
- This is a plain text file of the “stand_OK” or “stand_FAIL” type, which says that the build has passed or failed to pass the stand. Well, you understand, yes?
- I guess, yes. It is written in the same folder in the repository, where is the assembly?
- Yes
- And what will happen if the assembly did not pass the stand? Need to do a new build?
- yeah
- Well, ok, thanks. And another question: do I understand correctly that I can use the date of the creation of the flag as the date for passing the stand?
- Absolutely!
- Great!
Inspired, Ivan hung up and realized that everything fell into place. Knowing the date of creation of the assembly file and the date of creation of flags, it was possible to calculate, with an accuracy of a second, how much time the teams spend on each stand and understand where they spend the most time.
"Understanding where most time is spent, we will point out the teams, go to them and dig through the problem." Ivan smiled.
Tomorrow he set himself the task of sketching the architecture of the system being drawn.
To be continued…
Source: https://habr.com/ru/post/436310/