Recently, such advertisements have flooded the Internet. Despite the pleasant salary, one cannot help but be embarrassed that wild heresy is written inside. At first it is assumed that “DevOps” and “engineer” can somehow be glued together into one word, and then there is a random list of requirements, some of which are clearly copied from the sysadmin vacancy.
In this post I would like to talk a little about how we got to this point of life, what DevOps really is and what to do with it now.
Such vacancies can be condemned in every possible way, but the fact remains: there are many of them, and this is how the market works at the moment. We held a devops conference and openly declare: “ - not for DevOps engineers." This will seem strange and wild to many: why people who are doing a completely commercial event go against the market. Now we'll explain everything.
About culture and processes
Let's start with the fact that DevOps is not an engineering discipline. It all started with the fact that the historically established division of roles does not work for the quality of products. When programmers only program, but don’t want to hear anything about testing, the software is littered with bugs. When admins don't care how or why the software is written, support turns into hell.
For example, describing the difference between a system administrator and an SRE approach to service management . Interesting studies have been carried out within — it’s clear that the best developers somehow manage to deploy new changes to production faster than once an hour. They test with their hands no more than 10% (this can be seen from ). How do they do this? “Excel or die” says one of the report headings. For a detailed discussion of these statistics in the context of testing, you can refer to the keynote of Baruch Sadogursky at our other conference, Heisenbug.
“When there is no consensus in comrades,
In the mood their business will not go,
And it will not work out of him, only flour.
Once upon a time a Swan, a Crayfish and a Pike..."
What part of web programmers do you think really understands the conditions under which their applications are used in production? How many of them will go to the admins and try to figure out what will happen if the database crashes? And which of them will go to the testers and ask them to teach them how to write tests correctly? And there are also security guards, product managers, and a bunch of other people.
The overall idea of DevOps is to create collaboration between roles and departments. First of all, this is achieved not by some cleverly configured software, but by the practice of communication. DevOps is about culture, practices, methodology and processes. There is no engineering specialty that can answer these questions.
Vicious circle
Where did the discipline of “devops engineering” come from then? We have a version! DevOps ideas were good—so good that they became victims of their own success. Some shady recruiters and human traffickers, who have their own atmosphere, began to swirl around this whole topic.
Imagine: yesterday you were making shawarma in Khimki, and today you are already a big man, a senior recruiter. There is a whole process of searching and selecting candidates, everything is not easy, you need to understand. Let’s say the head of a department says: find a specialist in X. We assign the word “engineer” to X, and we’re done. Need Linux? Well, this is definitely a Linux engineer, if you want DevOps, then a DevOps engineer. The vacancy consists not only of a title, but also some text must be entered inside. The easiest way is to enter a set of keywords from Google, depending on your imagination. DevOps consists of two words - “Dev” and “Ops”, which means that we need to glue together keywords related to developers and administrators, all into one pile. This is how vacancies appear about proficiency in 42 programming languages and 20 years of using Kubernetes and Swarm simultaneously. Working diagram.
This is how the meaningless and merciless image of a certain “devops” superhero has taken root in people’s minds, who will configure everyone to deploy to Jenkins, and happiness will come. Oh, if only everything were so simple. “And this is also how you can hunt down system administrators,” thinks HR, “it’s a fashionable word, the keywords are the same, they should take the bait.”
Demand creates supply, and all these trash vacancies have been filled with an insane number of system administrators who realized: you can do everything the same as before, but get several times more by calling yourself “devops.” Just as you configured servers via SSH manually one at a time, you will continue to configure them, but now this is supposedly a devops practice. This is some kind of complex phenomenon, partly related to the underestimation of classic admins and the hype around DevOps, but in general, what happened, happened.
So we have supply and demand. A vicious circle that feeds itself. This is what we are fighting against (including by creating the DevOops conference).
Of course, besides the system administrators who have renamed themselves “devops,” there are other participants - for example, professional SREs or Infrastructure-as-Code developers.
What people do in DevOps (really)
So you want to get ahead in learning and applying DevOps practices. But how to do this, in which direction to look? Obviously, you shouldn’t blindly rely on popular keywords.
If there is a job, someone should do it. We have already found out that these are not “devops engineers”, then who are? It seems more correct to formulate this not in terms of positions, but in terms of specific areas of work.
First, you can address the heart of DevOps—processes and culture. Culture is a slow and difficult business, and although it is traditionally the responsibility of managers, everyone is involved in one way or another, from programmers to administrators. A couple of months ago Tim Lister :
“Culture is determined by the core values of the organization. Usually people don't notice this, but having worked in consulting for many years, we are used to noticing it. You enter a company and literally within a few minutes you begin to feel what is happening. We call this "flavor". Sometimes this scent is really good. Sometimes it causes nausea. (...) You cannot change a culture until the values and beliefs behind specific actions are understood. Behavior is easy to observe, but searching for beliefs is difficult. DevOps is just a great example of how things are becoming more and more complex.”
There is also a technical part of the issue, of course. If your new code gets tested in a month, but is released only a year later, and it’s physically impossible to speed it all up, you may not live up to good practices. Good practices are supported by good tools. For example, with the idea of Infrastructure-as-Code in mind, you can use anything from AWS CloudFormation and Terraform to Chef-Ansible-Puppet. You need to know and be able to do all this, and this is already quite an engineering discipline. It is important not to confuse cause with effect: first you work according to the principles of SRE and only then implement these principles in the form of some specific technical solutions. At the same time, SRE is a very comprehensive methodology that does not tell you how to set up Jenkins, but about five basic principles:
- Improved communication between roles and departments
- Accepting mistakes as an integral part of the job
- Making changes gradually
- Using tooling and other automation
- Measuring everything that can be measured
This is not just some set of statements, but a specific . For example, on the path to accepting errors, you will need to understand the risks, measure the availability and unavailability of services using something like SLI () and SLO (), learn to write postmortems and make writing them not scary.
In the SRE discipline, the use of tools is only one part of success, although an important one. We need to constantly develop technically, look at what is happening in the world and how it can be applied in our work.
In turn, Cloud Native solutions have now become very popular. As defined by the Cloud Native Computing Foundation today, Cloud Native technologies enable organizations to develop and run scalable applications in today's dynamic environments, such as public, private, and hybrid clouds. Examples include containers, service meshes, microservices, immutable infrastructure, and declarative APIs. All of these techniques allow loosely coupled systems to remain elastic, manageable, and highly observable. Good automation allows engineers to make big changes frequently and with predictable results without making it a chore. All this is supported by a stack of well-known tools such as Docker and Kubernetes.
This rather complicated and broad definition is due to the fact that the area is also quite complex. On the one hand, it is argued that new changes to this system should be added quite simply. On the other hand, to figure out how to create a kind of containerized environment in which loosely coupled services live on a software-defined infrastructure and are delivered there using continuous CI/CD, and build DevOps practices around all this - all this requires more than one eat the dog.
What to do with all this
Everyone solves these problems in their own way: for example, you can publish normal vacancies to break the vicious circle. You can figure out what words like DevOps and Cloud Native mean and use them correctly and to the point. You can develop in DevOps and demonstrate the right approaches by your example.
We're doing a conference , which provides an opportunity to delve deeper into the things we just talked about. There are several groups of reports for this:
- Processes and culture;
- Site Reliability Engineering;
- Cloud Native;
How to choose where to go? There is a subtle point here. On the one hand, DevOps is about interaction, and we really want you to attend presentations from different blocks. On the other hand, if you are a development manager who came to the conference to concentrate on one specific task, then no one limits you - obviously, this will be a block about processes and culture. Don't forget that you will have recordings after the conference (after filling out the feedback form), so you can always watch less important presentations later.
Obviously, at the conference itself you cannot go on three tracks at once, so we organize the program in such a way that each time slot has topics for every taste.
All that remains is to understand what to do if you are a DevOps engineer! First, try to determine what you actually do. Usually they like to call this word:
- Developers who work on infrastructure. The groups of reports about SRE and Cloud Native are most suitable for you.
- System administrators. It's more complicated here. DevOops is not about system administration. Fortunately, there are a lot of excellent conferences, books, articles, videos on the Internet, etc. on the topic of system administration. On the other hand, if you are interested in developing yourself in terms of understanding culture and processes, learning about cloud technologies and the details of life with Cloud Native, then we would love to see you! Think about this: you are doing administration, and then what will you do? To avoid suddenly finding yourself in an unpleasant situation, you should learn now.
There is another option: you persist and continue to claim that you are specifically a DevOps engineer and nothing else, whatever that means. Then we have to disappoint you, DevOops is not a conference for DevOps engineers!
slide from in Munich
DevOops 2020 Moscow will be held on April 29-30 in Moscow, tickets are already available .
In addition, you can until February 8. Please note that when filling out the form, you must select the target audience that will benefit most from your report (there's a surprise buried inside the list).
Source: habr.com