What does it take for an IT company to succeed in 2019? Lecturers at conferences and meetups say a lot of loud words that are not always clear to normal people. The struggle for deployment time, microservices, the rejection of the monolith, DevOps transformation and much, much more. If we discard verbal beauty and speak directly and in Russian, then everything comes down to a simple thesis: make a quality product, and make it comfortable for the team.
The latter has become critical. Business has finally come to the conclusion that a comfortable development process increases productivity, and if everything is debugged and works like clockwork, it also gives some room for maneuver in critical situations. Once, for the sake of this maneuver, a certain smart person came up with backups, but the industry is developing, and we have come to DevOps engineers - people who turn the process of interaction between development and external infrastructure into something adequate and not related to shamanism.
This whole story from “modulo” is wonderful, but ... It so happened that some of the admins were sharply dubbed DevOps, and they began to require at least the skills of telepathy and clairvoyance from the DevOps engineers themselves.
Before talking about modern problems of providing infrastructure, let's define what we mean by this term. By the current moment, the situation has developed in such a way that we have reached the duality of this concept: the infrastructure can be conditionally external and conditionally internal.
External infrastructure should be understood as everything that ensures the operability of the service or product that the team is developing. These are application or site servers, hosting and other services that ensure the product's performance.
The internal infrastructure includes services and equipment used by the development team itself and other employees, of which there are usually also a lot. These are internal servers of code storage systems, a locally deployed task manager, and everything that exists within the corporate intranet.
What does a system administrator do in a company? In addition to the work of administering this very corporate intranet, it often bears the burden of economic concerns to ensure the operability of office equipment. The admin is the same guy who will quickly bring a new system unit or a spare laptop ready for work from the back room, give out a fresh keyboard and crawl on all fours through the offices, stretching out the Ethernet cable. The admin is a local owner and master of not only internal and external servers, but also a business executive. Yes, some administrators can only work in the system plane, without hardware. They should be singled out in a separate subclass of "infrastructure system administrators". And someone specializes in servicing exclusively office equipment, fortunately, if the company has more than a hundred people, the work never ends. But neither of them are devops.
Who are DevOps? Devops are the guys who are about the interaction of software development with external infrastructure. More precisely, modern devops are involved in development and deployment processes much deeper than admins who simply uploaded updates to ftp were ever involved. One of the key tasks of a DevOps engineer now is to ensure a comfortable and efficiently built process of interaction between development teams and the product infrastructure. It is these people who are responsible for deploying rollback and deployment systems, it is these people who take some of the burden off developers and concentrate as much as possible on their extremely important task. At the same time, devops will never pull a new cable or issue a new laptop from the back room (c) KO
What's the catch?
To the question “Who is DevOps?” half of the workers in the sphere begin to answer something like “Well, in short, this is such an admin who ...” and further in the text. Yes, once upon a time, when the DevOps engineer profession was just emerging from the most talented admins in terms of service maintenance, the differences between them were not obvious to everyone. But now, when the functions of the devops and the admin in the team have become radically different, it is unacceptable to confuse them with each other, or even put an equal sign between them.
But what does it mean for business?
Naim, it's all about him.
You open a vacancy for a “System Administrator”, and the requirements are “interaction with development and customers”, “CI / CD delivery system”, “maintenance of company servers and equipment”, “administration of internal systems”, and so on; you understand that the employer is talking nonsense. The catch is that instead of "System Administrator" in the job title should be "DevOps Engineer", and if this title is changed, then everything falls into place.
However, what impression is created when reading such a vacancy? That the company is looking for a multi-machine operator who will deploy a version control and monitoring system, and will squeeze the vituka with his teeth ...
But in order not to increase the degree of drug addiction in the labor market, it is enough to call vacancies by their proper names and clearly understand that a DevOps engineer and a system administrator are two different entities. But the indefatigable desire of some employers to present to the candidate as wide a list of requirements as possible leads to the fact that "classic" system administrators no longer understand what is happening around them. What, the profession is mutating and they are behind the times?
No no and one more time no. Infrastructure admins who will manage the company's internal servers, or take the position of L2 / L3 support and help other employees, have not gone anywhere and are not going to go away.
Can these specialists become DevOps engineers? Of course they can. In fact, this is a kindred environment that requires system administration skills, but in addition, work with monitoring, delivery systems and, in general, close interaction with the development and testing team is added.
Another DevOps problem
In fact, everything is not limited to hiring and constant confusion between admins and devops. At some point, the business faced the problem of delivering updates and the interaction of the development team with the final infrastructure.
Perhaps it was when an uncle with burning eyes rose to the stage of some conference and said, “And we do this and call it DevOps. These guys will solve all your problems, ”and began to talk about how good life is in the company after the introduction of DevOps practices.
However, it is not enough to hire a DevOps engineer to make everything work “as it should”. The company must go through a complete DevOps transformation, that is, the role and capabilities of our devops must also be clearly understood on the side of the product development and testing team. On this topic, we have a "beautiful" story that fully illustrates all the tin that is happening in places.
Situation. Devops are required to deploy a version rollback system, without really understanding how it will work. Suppose, inside the Users system, these are separate fields for the first name, last name and password. A new version of the product comes out, but for developers, “rollback” is just a magic wand that will fix everything, and they don’t even know how it works. So, for example, the developers combined the first and last name fields in the next patch, rolled it out to the prod, and the version slows down for some reason. What's happening? The management comes to the devops and says “Pull the switch!”, That is, asks him to roll back to the previous version. What does devops do? It rolls back to the previous version, but since the developers did not want to figure out how this rollback is done, no one told the devops that the base also needs to be rolled back. As a result, everything crashes, and instead of a slow site, users see a “500” error, because the old version does not work with the fields of the new database. Devops is not aware of this. The developers are silent. The management begins to lose nerves and money and recalls backups, offering to roll back from them so that “at least something works”. As a result, users lose all their data over a period of time.
The nuts go, of course, to the devops, who “didn’t make the right rollback system,” and the fact that the moose in this story are developers does not bother anyone.
The conclusion is simple: without a normal approach to DevOps as such, there is not very much sense from it.
The main thing to remember is that a DevOps engineer is not a magician, and without good communication and two-way interaction with development, he will not cope with his tasks. Devops cannot be left alone with their “problems” or give the command “don’t mess with the developers, it’s their job to code”, and then hope that at a critical moment everything will work as it should. So it doesn't work.
In essence, DevOps is a competency on the verge between management and technology. Moreover, it is far from obvious that there should be more technology in this cocktail than management. If you really want to build faster and more efficient development processes, you have to trust your devops. He knows the right tools, he has implemented similar projects, he knows how to do it. Help him, heed his advice, don't try to isolate him into some kind of autonomous unit. If admins can work on their own, then devops are useless in this case, they will not be able to help you become better if you yourself do not want to accept this help.
And last but not least: stop offending infrastructure administrators. They have their own, extremely important front of work. Yes, an admin can become a DevOps engineer, but this should happen at the request of the person himself, and not under duress. And there is nothing wrong with the fact that the system administrator wants to remain a system administrator - this is his separate profession and his right. If there is a desire to undergo a professional transformation, then in no case should one forget that it will be necessary to build up not only technological skills, but also managerial ones. Most likely, you as a leader will have to bring all these people together and learn to communicate in the same language.
Source: habr.com