How fast results helped Ivan
Ivan worked in a large organization in the department associated with DevOps. Every day, thousands of employees used DevOps tools to create, test and implement their software.
Thousands of distros per day passed through the pipeline was a normal situation.
However, where there is great strength, there is great responsibility. The inevitable difficulties of the teams resulted in hundreds of calls to technical support per day.
Naturally, many people didn’t like DevOps tools. Someone said that they are too buggy, while others thought that you can do without them, and it will be much faster.
')
The company's management understood that all 100% of the teams could not be satisfied with DevOps, but there was no exact data. It would be nice to see if there are problems on the pipeline, however, even the usual number of distributions passing through it per day was not known. What can we say about serious metrics.
The question of DevOps metrics was constantly being raised - they were all very necessary.
Ivan, as an employee who knows the metrics and knows DevOps technology well, was closely involved in the preparation of the project.
Together with DevOps admins, he worked through a possible solution architecture, and also studied a huge amount of literature on DevOps metrics. There is not a single article on the Internet and not a single book on this topic that he would not have read.
As a result, a full-fledged technical solution was born, which Ivan presented to the management.
The management response was unexpected - no decision was taken on implementation.
“This is a fiasco, bro,” said a kind colleague with a grin, leaving with the meeting with Ivan.
Despite the irony, he was right. If the decision is not made, then there was some deterrent factor 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.
And it was caused by a very simple reason: the technical solution showed that implementation, although possible, would require a large amount 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.
All decided case. Once a letter arrived at the post office stating that two students took an internship at the department. One of the students was ready to take on some small work.
Ivan thought that it might be possible to do it by metrics at least - and sent the student a technical task for a piece of the project that was cut down to impossibility.
All that was there was pulling data from Jenkins and Nexus in the simplest way possible.
What was Ivan's surprise when, after just a couple of days, the student invited him to look at the working system. The question “Why did I deserve such a high priority?” Was answered: “You only had normal TK.”
Be that as it may, the system has earned. She pulled data from Jenkins and Nexus and put it into her own database.
Ivan realized that you need to finish the rest as quickly as possible. He used the free version of QlikView to generate raw data reports and by the evening the first version of the DevOps metrics was ready.
The following Monday was a breakthrough. Seeing working metrics, Ivan’s manager exclaimed: “This is the most useful data I've seen lately!”
The issue of resources 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 reduced functionality that gives real benefits.
“Quick results” work, because when it comes to a big expensive system, inevitably a lot of ambiguities arise. If the price is significant, the result is not always obvious.
Therefore, the start of work is constantly postponed 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.
Several insights, received by Ivan from the project:
Ivan knew exactly which metrics he needed, right up to the screen layouts. This allowed him to quickly discard the extra functionality and leave only that, without which the metrics completely lost their meaning.
Of the ten alleged DevOps metrics to be implemented, Ivan left only one, and having limited it to one stand and one team. In fact, it was the most concentrated squeeze on the one hand, and practical real data on the other.
Such a reduced version allowed us to solve one perfectly practical task - to analyze the real team and see if it would give the metrics the result that was expected of them.
The simplest Deployment scheme with information flows and data helped Ivan very well to understand where everything lies and how easy it is to get it.
Jenkins: Joby. What do jobs need for metrics? How to pull it out? What protocols, from what addresses?
Nexus: distros. What of Nexus is required for metrics? How to get it?
Help systems: discard, because for metrics they are not needed.
How to combine data? Where to do this is the easiest to implement as quickly as possible?
If you can get by with the finished unloading in XLS or CSV, it is better to do this and not encode it at all.
Sometimes you can’t do without coding, but you still need to choose the easiest option.
For example, Jenkins provides data in RSS and JSON. Choose the option that is easier to implement.
Nexus only returns XML? Well, there's nothing you can do, you have to encode.
Super-automation for fast results is not needed. You can do with command codes instead of their names. Do not connect additional systems just to enrich the data. These are just flowers and beauty guidance - it’s better to do without them and save time.
Instead of writing to the database, you can write to a plain text file or csv, if this is faster.
Where you can start manually - run, do not waste time on the sheduler.
If it's easier to write in an easy scripting language like Python or PHP - write. All the same, you do at a minimum, so you will not have to rewrite a lot.
Use tools that allow you to get results quickly, for example, free QlikView or Tablue for metrics - they allow you to easily load and merge data, as well as build all the necessary graphs.
Ivan took the “quick results” into service and in the following projects he always tried first to make a minimally working system giving utility, 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.
Write, please, in the comments your case, when quick results gave effect.
Thousands of distros per day passed through the pipeline was a normal situation.
However, where there is great strength, there is great responsibility. The inevitable difficulties of the teams resulted in hundreds of calls to technical support per day.
Naturally, many people didn’t like DevOps tools. Someone said that they are too buggy, while others thought that you can do without them, and it will be much faster.
')
The company's management understood that all 100% of the teams could not be satisfied with DevOps, but there was no exact data. It would be nice to see if there are problems on the pipeline, however, even the usual number of distributions passing through it per day was not known. What can we say about serious metrics.
The question of DevOps metrics was constantly being raised - they were all very necessary.
Ivan, as an employee who knows the metrics and knows DevOps technology well, was closely involved in the preparation of the project.
Together with DevOps admins, he worked through a possible solution architecture, and also studied a huge amount of literature on DevOps metrics. There is not a single article on the Internet and not a single book on this topic that he would not have read.
As a result, a full-fledged technical solution was born, which Ivan presented to the management.
Everything is lost
The management response was unexpected - no decision was taken on implementation.
“This is a fiasco, bro,” said a kind colleague with a grin, leaving with the meeting with Ivan.
Despite the irony, he was right. If the decision is not made, then there was some deterrent factor 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.
And it was caused by a very simple reason: the technical solution showed that implementation, although possible, would require a large amount 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 do not impress,
- Screen layouts do not impress,
- Examples do not impress.
In general, the start of the project was postponed indefinitely. The task seemed to Ivan completely unsolvable.
Fateful occasion
All decided case. Once a letter arrived at the post office stating that two students took an internship at the department. One of the students was ready to take on some small work.
Ivan thought that it might be possible to do it by metrics at least - and sent the student a technical task for a piece of the project that was cut down to impossibility.
All that was there was pulling data from Jenkins and Nexus in the simplest way possible.
What was Ivan's surprise when, after just a couple of days, the student invited him to look at the working system. The question “Why did I deserve such a high priority?” Was answered: “You only had normal TK.”
Be that as it may, the system has earned. She pulled data from Jenkins and Nexus and put it into her own database.
Ivan realized that you need to finish the rest as quickly as possible. He used the free version of QlikView to generate raw data reports and by the evening the first version of the DevOps metrics was ready.
The following Monday was a breakthrough. Seeing working metrics, Ivan’s manager exclaimed: “This is the most useful data I've seen lately!”
The issue of resources 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 reduced functionality that gives real benefits.
“Quick results” work, because when it comes to a big expensive system, inevitably a lot of ambiguities arise. If the price is significant, the result is not always obvious.
Therefore, the start of work is constantly postponed 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.
Several insights, received by Ivan from the project:
First, imagine what kind of end result you need.
Ivan knew exactly which metrics he needed, right up to the screen layouts. This allowed him to quickly discard the extra functionality and leave only that, without which the metrics completely lost their meaning.
Of the ten alleged DevOps metrics to be implemented, Ivan left only one, and having limited it to one stand and one team. In fact, it was the most concentrated squeeze on the one hand, and practical real data on the other.
Such a reduced version allowed us to solve one perfectly practical task - to analyze the real team and see if it would give the metrics the result that was expected of them.
A simple architecture diagram simplifies things a lot.
The simplest Deployment scheme with information flows and data helped Ivan very well to understand where everything lies and how easy it is to get it.
Jenkins: Joby. What do jobs need for metrics? How to pull it out? What protocols, from what addresses?
Nexus: distros. What of Nexus is required for metrics? How to get it?
Help systems: discard, because for metrics they are not needed.
How to combine data? Where to do this is the easiest to implement as quickly as possible?
If possible, do without coding. Quite
If you can get by with the finished unloading in XLS or CSV, it is better to do this and not encode it at all.
Sometimes you can’t do without coding, but you still need to choose the easiest option.
For example, Jenkins provides data in RSS and JSON. Choose the option that is easier to implement.
Nexus only returns XML? Well, there's nothing you can do, you have to encode.
Do not hang too much. Remove all
Super-automation for fast results is not needed. You can do with command codes instead of their names. Do not connect additional systems just to enrich the data. These are just flowers and beauty guidance - it’s better to do without them and save time.
Instead of writing to the database, you can write to a plain text file or csv, if this is faster.
Where you can start manually - run, do not waste time on the sheduler.
If it's easier to write in an easy scripting language like Python or PHP - write. All the same, you do at a minimum, so you will not have to rewrite a lot.
Use tools that allow you to get results quickly, for example, free QlikView or Tablue for metrics - they allow you to easily load and merge data, as well as build all the necessary graphs.
Ivan took the “quick results” into service and in the following projects he always tried first to make a minimally working system giving utility, 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.
Write, please, in the comments your case, when quick results gave effect.
Source: https://habr.com/ru/post/458370/
All Articles