About admins, devops, endless confusion and DevOps transformation within the company

What is needed for the success of an IT company in 2019? Lecturers at konfs and mitaps speak a lot of loud and not always clear words to normal people. The struggle for the deployment, microservices, the rejection of the monolith, DevOps transformation and much, much more. If you discard verbal beauty and speak directly and in Russian, it all comes down to a simple thesis: make a quality product, and do it with comfort for the team.



The latter has become critically important. Business finally came to the conclusion that a comfortable development process improves 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, some smart person invented backups, but the industry is developing, and we came to DevOps engineers - people who turn the process of interaction between development and external infrastructure into something adequate and not related to shamanism.



The whole story from “modulo” is beautiful, but ... It so happened that part of the admins were abruptly dubbed DevOps, and the DevOps engineers themselves began to require at least telepathy and clairvoyance skills.



Before talking about the modern problems of providing infrastructure, let's decide what we mean by this term. To date, the situation has developed in such a way that we have reached the duality of this concept: infrastructure can be conditionally external and conditionally internal.



An external infrastructure should mean everything that ensures the serviceability of a 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 whom there are usually a lot. These are internal servers of code storage systems, a locally deployed task manager and everything-everything-everything that exists within the corporate intranet.



What does the system administrator do in the company? In addition to administering this corporate intranet itself, it often lays the burden of economic worries to ensure the availability of office equipment. The admin is the same guy who quickly drags a new system unit out of the back room or a spare laptop ready for work, gives out a fresh keyboard and crawls on all fours around the offices, stretching out the Ethernet cable. Admin is a local master and master of not only internal and external servers, but also a business executive. Yes, some administrators can work only in the system plane, without hardware. They should be distinguished 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 one nor the other devops are not.



And who are DevOps? Devops are guys who are talking about the interaction of software development with external infrastructure. More precisely, modern devs are involved in the development and deployment processes much deeper than the administrators who simply flooded updates on ftp were ever involved. One of the key tasks of the 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 part of the load off developers and concentrate as much as possible on their extremely important task. In this case, the devopus will never stretch a new cable or give out a new laptop from the back room (s)

What's the catch?

To the question “Who is DevOps?” Half of the sphere’s employees begin to answer something like “Well, this is, in short, such an admin who ...” and hereinafter. Yes, once upon a time, when the profession of DevOps-engineer was only just making out of the most talented administrators in terms of servicing, the differences between them were not obvious to everyone. But now, when the functions of the devops and admin in the team began to radically differ, confusing them among themselves, or even putting an equal sign between them, is unacceptable.



But what does it translate into business?



Hiring, it's all about him.



You open the vacancy “System Administrator”, and there are listed the requirements “interaction with development and customers”, “CI / CD delivery system”, “servicing the company's servers and equipment”, “administering internal systems” and so on; you understand that the employer is carrying some nonsense. The catch is that instead of "System Administrator" in the title of the vacancy 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-tool operator, which will deploy both a version control and monitoring system and shake its teeth with its teeth ...



But in order not to increase the degree of drug addiction in the labor market, it is enough to call the vacancies by their proper names and clearly understand that the DevOps engineer and system administrator are two different entities. The only irrepressible desire of some employers to present to the candidate the widest possible list of requirements leads to the fact that the "classical" system administrators cease to understand what is happening around them. What, the profession mutates and they lag behind life?



No no and one more time no. Infrastructure administrators who will steer the company's internal servers, or occupy the positions of L2 / L3 support and help other employees, have not gone anywhere and are not going to disappear.



Can these specialists become DevOps engineers? Of course they can. In fact, this is akin to their environment, which requires system administration skills, but in addition, work with monitoring, delivery systems and, in general, tight interaction with the development and testing team is added.

Another DevOps Problem

In fact, everything is not limited to hiring and constant confusion between administrators and devops. At some point, the business was faced with the problem of delivering updates and the interaction of the development team with the final infrastructure.



Perhaps this was when an uncle with burning eyes came to the scene of a conference and said, “And we are doing this and call it DevOps. These guys will solve all your problems ”- and began to tell how well he lives in the company after the implementation of DevOps practices.



However, it’s not enough to hire a DevOps engineer to make things work as they should. The company must completely go through the DevOps transformation, that is, the role and capabilities of our devs should be clearly understood also on the side of the product development and testing team. We have a “beautiful” story on this subject, which fully illustrates all the tin in places.



Situation. Devops are required to deploy a version rollback system, without particularly delving into how it will work. Suppose, inside the Users system, these are separate fields under the first name, last name and password. A new version of the product is released, 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 in the next patch combined the first and last name fields, rolled it out into the prod, and the version slows down for some reason. What's happening? The manual comes to the devoop and says “Pull the knife 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 understand how this rollback is done, no one told the devo that it was also necessary to roll back the base. As a result, everything falls down for us, and instead of a slowing down site, users see the error "500", because the old version does not work with the fields of the new database. Devops is not aware of this. Developed 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 for some period of time.



The nuts go, of course, to the devopus, who “did not 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 much of it.

The main thing to remember: DevOps engineer is not a magician, and without high-quality communications and two-way interaction with development, he will not be able to cope with his tasks. Devops cannot be left alone with their “problems” or given the command “do not go to developers, code their business”, and then hope that at a critical moment everything will work as it should. So it does not work.



Essentially, DevOps are competencies on the edge between management and technology. Moreover, it is far from obvious that in this cocktail of technologies there should be more than management. If you really want to build faster and more efficient development processes, you must trust your devs. He knows the right tools, he has implemented similar projects, he knows how to do it. Help him, listen to his advice, do not try to isolate in some 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.



Well, the last thing: stop offending infrastructure administrators. They have their own, extremely important field of work. Yes, the admin can become a DevOps engineer, but this should happen at the request of the person himself, and not from under the stick. And there is nothing wrong with the fact that a 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 we must in no case forget that it will be necessary to build up not only technological skills, but also managerial ones. It’s most likely that you as a leader will have to bring all these people together and learn to communicate in one language.