July 1, 2019 at 15:13How quick results helped Ivan
Ivan worked in a large organization in a department related to DevOps. Every day, thousands of employees used DevOps tools to create, test, and implement their software.
Thousands of distributions per day that went through the assembly line was a normal situation.
However, where there is great power, there is also great responsibility. The inevitable difficulties of the teams resulted in hundreds of technical support calls per day.
Naturally, many did not like DevOps tools. Someone said that they are too buggy, while others believed that you can do without them at all, and it will be much faster.
The company management understood that all 100% of the teams could not be satisfied with DevOps, however, there was no exact data. It would be nice to see the problems on the assembly line, but not even the usual number of distributions going through it per day was known. What can we say about serious metrics.
The question about DevOps metrics was constantly raised - everyone needed them very much.
Ivan, as an employee who knows metrics and knows the DevOps technology well, took a close part in preparing the project.
Together with DevOps admins, he worked out a possible solution architecture, and also studied a huge amount of literature on DevOps metrics. There was not a single article on the Internet and not a single book on this topic that he would not read.
As a result, a complete technical solution was born, which Ivan presented to the management.
The management reaction was unexpected - no decision on implementation was made.
“This is a fiasco, bro,” the good colleague said with a grin, leaving Ivan from the meeting.
Despite the irony, he was right. If the decision is not made, then there was some kind of deterrent that Ivan did not see and did not take into account.
The management was convinced of the technical feasibility of implementing DevOps metrics, but still doubted it.
And this was caused by a very simple reason: the technical solution showed that the implementation, although possible, would require a large number of human and technical resources, i.e. will be dear. But whether there will be any real useful result from this is a big question.
When it comes to an expensive project, then:
In general, the start of the project was postponed indefinitely. The task seemed to Ivan completely unsolvable.
Everything was decided by chance. Once, a letter arrived at the post office stating that two students were taken to the department for an internship. One of the students was ready to do some small work.
Ivan thought that it might be possible to do at least something by metrics - and sent the student a technical assignment for a piece of the project that was reduced to impossibility.
All that was there was pulling data from Jenkins and Nexus in the easiest of all possible ways.
Imagine Ivan’s surprise when only a couple of days later a student invited him to look at the working system. To the question “How did I earn such a high priority?” The answer was: “You only had normal TK”.
Be that as it may, the system worked. She pulled data from Jenkins and Nexus and put it into her own database.
Ivan realized that he needed to finish the rest as quickly as possible. He used the free version of QlikView to generate reports from raw data and by the evening the first version of DevOps metrics was ready.
The following Monday was a breakthrough. Seeing the working metrics, the head of Ivan exclaimed: “This is the most useful data I have seen lately!” The
resource issue was resolved instantly, and in the next few days the project with metrics started to its fullest.
Ivan acted correctly and without realizing it gave out “quick results” - a working system with the most truncated functionality, which gives real benefits.
“Quick Results” work, because when it comes to a large expensive system, inevitably a lot of ambiguities arise. With significant high cost, the result is not always obvious.
Therefore, the start of work is constantly delayed or the system is completely abandoned.
Quick results help test the hypothesis with minimal means. The main thing is to try to make a prototype without attracting additional resources and so that it at the same time carries value and benefits.
A few insights received by Ivan from the project:
Ivan knew exactly which metrics he would need, right up to the screen layouts. This allowed him to quickly discard unnecessary functionality and leave only that without which the metrics completely lost their meaning.
Of the ten DevOps metrics proposed for implementation, Ivan left only one, and limiting it to one stand and one team. In fact, this was the most concentrated squeeze on the one hand, and practical real data on the other.
Such a truncated version made it possible to solve one completely practical problem - to analyze the real team and to understand whether the metrics on it would give the result that was expected of them.
The simplest Deployment scheme with information flows and data very well helped Ivan understand where what lies and how easier it is to get it.
Jenkins: Jobs. What is required for metrics in jobs? How to pull it out? What protocols, from which addresses?
Nexus: distributions. What Nexus requires for metrics? How to get it?
Help systems: discard, because they are not needed for metrics.
How to combine data? Where is it easiest to do so as quickly as possible?
If you can do it with ready-made uploading to XLS or CSV - it is better to do this and not to encode at all.
Sometimes you can’t do without coding, but you still need to choose the easiest option.
For example, Jenkins feeds data in RSS and JSON. Choose the option that is easier to implement.
Nexus returns only XML? Well, there's nothing to be done, you have to code.
Super automation is not needed for fast results. You can do with command codes instead of their names. You should not connect additional systems only for the enrichment of data. These are just flowers and beauty guidance - it is better to do without them and save time.
Instead of writing to the database, you can write to a regular text file or csv, if it is faster.
Where you can start manually - start, do not waste time on the sheduler.
If it is easier to write in a light scripting language such as Python or PHP - write. Anyway, you do the minimum, so you won’t have to rewrite a lot.
Use tools that allow you to get results quickly, for example, free QlikView or Tablue for metrics - they make it easy to load and combine data, as well as build all the necessary graphs.
Ivan took the “quick results” into service and in the following projects he always tried to first make a minimally working system that provides usefulness, and only then take up the rest. And it always worked.
If the story of Ivan seemed useful to you, I will be extremely happy about it.
Please write in the comments your case when quick results have had an effect.
Thousands of distributions per day that went through the assembly line was a normal situation.
However, where there is great power, there is also great responsibility. The inevitable difficulties of the teams resulted in hundreds of technical support calls per day.
Naturally, many did not like DevOps tools. Someone said that they are too buggy, while others believed that you can do without them at all, and it will be much faster.
The company management understood that all 100% of the teams could not be satisfied with DevOps, however, there was no exact data. It would be nice to see the problems on the assembly line, but not even the usual number of distributions going through it per day was known. What can we say about serious metrics.
The question about DevOps metrics was constantly raised - everyone needed them very much.
Ivan, as an employee who knows metrics and knows the DevOps technology well, took a close part in preparing the project.
Together with DevOps admins, he worked out a possible solution architecture, and also studied a huge amount of literature on DevOps metrics. There was not a single article on the Internet and not a single book on this topic that he would not read.
As a result, a complete technical solution was born, which Ivan presented to the management.
Everything is lost
The management reaction was unexpected - no decision on implementation was made.
“This is a fiasco, bro,” the good colleague said with a grin, leaving Ivan from the meeting.
Despite the irony, he was right. If the decision is not made, then there was some kind of deterrent that Ivan did not see and did not take into account.
The management was convinced of the technical feasibility of implementing DevOps metrics, but still doubted it.
And this was caused by a very simple reason: the technical solution showed that the implementation, although possible, would require a large number of human and technical resources, i.e. will be dear. But whether there will be any real useful result from this is a big question.
When it comes to an expensive project, then:
- Presentations are not impressive
- Screen layouts are not impressive
- The examples are not impressive.
In general, the start of the project was postponed indefinitely. The task seemed to Ivan completely unsolvable.
Fatal case
Everything was decided by chance. Once, a letter arrived at the post office stating that two students were taken to the department for an internship. One of the students was ready to do some small work.
Ivan thought that it might be possible to do at least something by metrics - and sent the student a technical assignment for a piece of the project that was reduced to impossibility.
All that was there was pulling data from Jenkins and Nexus in the easiest of all possible ways.
Imagine Ivan’s surprise when only a couple of days later a student invited him to look at the working system. To the question “How did I earn such a high priority?” The answer was: “You only had normal TK”.
Be that as it may, the system worked. She pulled data from Jenkins and Nexus and put it into her own database.
Ivan realized that he needed to finish the rest as quickly as possible. He used the free version of QlikView to generate reports from raw data and by the evening the first version of DevOps metrics was ready.
The following Monday was a breakthrough. Seeing the working metrics, the head of Ivan exclaimed: “This is the most useful data I have seen lately!” The
resource issue was resolved instantly, and in the next few days the project with metrics started to its fullest.
Ivan acted correctly and without realizing it gave out “quick results” - a working system with the most truncated functionality, which gives real benefits.
“Quick Results” work, because when it comes to a large expensive system, inevitably a lot of ambiguities arise. With significant high cost, the result is not always obvious.
Therefore, the start of work is constantly delayed or the system is completely abandoned.
Quick results help test the hypothesis with minimal means. The main thing is to try to make a prototype without attracting additional resources and so that it at the same time carries value and benefits.
A few insights received by Ivan from the project:
First imagine what end result you need
Ivan knew exactly which metrics he would need, right up to the screen layouts. This allowed him to quickly discard unnecessary functionality and leave only that without which the metrics completely lost their meaning.
Of the ten DevOps metrics proposed for implementation, Ivan left only one, and limiting it to one stand and one team. In fact, this was the most concentrated squeeze on the one hand, and practical real data on the other.
Such a truncated version made it possible to solve one completely practical problem - to analyze the real team and to understand whether the metrics on it would give the result that was expected of them.
A simple architecture diagram makes things much easier
The simplest Deployment scheme with information flows and data very well helped Ivan understand where what lies and how easier it is to get it.
Jenkins: Jobs. What is required for metrics in jobs? How to pull it out? What protocols, from which addresses?
Nexus: distributions. What Nexus requires for metrics? How to get it?
Help systems: discard, because they are not needed for metrics.
How to combine data? Where is it easiest to do so as quickly as possible?
If possible, do without coding. Quite
If you can do it with ready-made uploading to XLS or CSV - it is better to do this and not to encode at all.
Sometimes you can’t do without coding, but you still need to choose the easiest option.
For example, Jenkins feeds data in RSS and JSON. Choose the option that is easier to implement.
Nexus returns only XML? Well, there's nothing to be done, you have to code.
Do not hang too much. Clean everything
Super automation is not needed for fast results. You can do with command codes instead of their names. You should not connect additional systems only for the enrichment of data. These are just flowers and beauty guidance - it is better to do without them and save time.
Instead of writing to the database, you can write to a regular text file or csv, if it is faster.
Where you can start manually - start, do not waste time on the sheduler.
If it is easier to write in a light scripting language such as Python or PHP - write. Anyway, you do the minimum, so you won’t have to rewrite a lot.
Use tools that allow you to get results quickly, for example, free QlikView or Tablue for metrics - they make it easy to load and combine data, as well as build all the necessary graphs.
Ivan took the “quick results” into service and in the following projects he always tried to first make a minimally working system that provides usefulness, and only then take up the rest. And it always worked.
If the story of Ivan seemed useful to you, I will be extremely happy about it.
Please write in the comments your case when quick results have had an effect.