Get best of the week

Profession DevOps-engineer: a view of the system administrator



I work as a DevOps engineer at Parallels. I support the development of various services, I write scripts for their automatic deployment, I communicate closely with the development team. I’ll tell you how the work is arranged, how much they pay and what the DevOps approach for software development is good for.

It all started with the fact that I became bored with working as a system administrator, I wanted something new. I tried to develop 1C, but pretty quickly realized that this was not mine. He learned Python, improved his skills on Unix systems and went for an interview at Parallels. Then I knew almost nothing about DevOps, I just came and said: I want to work for you. Two months later they took me.

What is DevOps?


If you ask 5 people what DevOps is, you get 5 different answers. For evangelists, this is a culture, or even rather a transformation of thinking. For engineers, a set of solutions and tools. For managers, a methodology. For recruiters - a profession. And for everyone else, it's probably just a buzzword.

The truth, as usual, is somewhere in between. DevOps is all of the above, taken together. Its main task is to accelerate the delivery of the product from business to the consumer. The term itself was coined by independent IT consultant Patrick Debois about twelve years ago. He wanted to break down the metaphorical wall between developers (dev) and sysadmins (ops), combine them into one effective unit, which can create software faster, roll out releases more often and with fewer errors.

Therefore, at the heart of DevOps is the idea of ​​shared responsibility, there is no division of powers. The programmer can participate in the configuration if he knows better how to write the configuration of his service, and the system administrator in development. When a problem arises, it is not transferred from one employee to another, like a ball in a ping-pong, but becomes common. Everyone is involved in its elimination.



A minute of boring statistics. According to the DORA research (DevOps Research and Assessment), cross-functional teams using the DevOps approach:

  • 208 times more often deploy code;
  • 106 times reduce the time from commit to deployment;
  • 2.604 times faster restore systems after failures;
  • 7 times lower the chance of failure itself as a result of changes.

Of course, combining dev and ops alone does not lead to such efficiency. The DevOps approach includes the use of many new development, testing and deployment tools for organizing CI \ CD (the concept of continuous integration and delivery). Among the most famous:

  • Git and GitHub - source code management systems;
  • Jenkins - an automation server for creating CI / CD pipelines;
  • Docker - software for automating deployment and application management in environments with support for containerization;
  • Kubernetes - an open container orchestration system;
  • Chef, Puppet and Ansible - tools for automatic configuration and deployment;
  • Selenium - test automation solution;
  • Prometheus and Nagios - server monitoring software;
  • Grafana is a solution for collecting and analyzing metrics.

At the same time, a universal set of tools suitable for every business does not exist, nor is there a single path to DevOps. There is only what works or, conversely, does not work in your infrastructure. I regularly attend conferences and various events, communicate with colleagues from other companies and I can say that 80% of the things they use in Parallels are not particularly applicable.

Each organization has its own product, its own technology stack and its bottlenecks. Therefore, the approach to optimization is very different. Sometimes you have to change the architecture of the services themselves, some are so complex or inflexible that it’s difficult to transfer the DevOps approach to them.

The essence of the DevOps engineer


At a basic level, a DevOps engineer is a technical specialist who understands all the main stages of the software development life cycle, corrects bottlenecks in processes, and adjusts the environment:

  • Writes code for automated application deployment
  • partially responsible for their availability, not personally as a system administrator, but with his team;
  • carries a duty on its infrastructure (understands errors, sometimes together with a programmer).

Automation is what falls on the shoulders of a DevOps engineer in the first place. The creation of an IT product with the traditional approach is as follows: the programmer writes his code, compiles it in some format, and gives it to the sysadmin. He goes to the server, installs and configures everything with his hands. At the same time, they are fighting for different things: the system administrator - for stability, the programmer - for their changes, which, of course, complicates the work of each of them.

In DevOps, this works a little differently. The application is deployed using scripts. The DevOps engineer sets a certain sequence of actions that brings the code written by the programmer, first to the test server, and then to the battle server (if it is decided that the changes can be released). Thus, the developer has the opportunity to check his code at least every 15 minutes and do it even at three in the morning with a simple click of a button.

Specific responsibilities, as well as necessary skills, are highly dependent on the place of work. We, in Parallels, have a lot of our infrastructure, the most critical parts are not in the public clouds, but on our own physical servers in several data centers. And sometimes there are major updates regarding hardware and software on these servers, and migration is required periodically.

This is also my job.


I try to automate everything to the maximum so that the process is less painful. The last time, in the framework of testing cross-backups and infrastructure fault tolerance, it was possible to transfer services from the USA to Switzerland in 10 minutes and update everything that was required along the way. For modern technology, this, of course, is not a huge achievement. But for us - a big step forward.

Legacy is also a definite challenge for DevOps engineers. Even in companies with well-built workflows, there are services that have been written for a very long time, and no one fully remembers how they were configured, because it was often done manually, and the people who worked on them no longer work in the organization. If this is an important service, a lot of research is undertaken - you have to figure it out to the slightest nuance how it works, write code for deployment, cover it with monitoring and metrics.

This is worth doing, even if the application code does not change very actively. Why, if everything works like that? In order to be able to reproduce it in the event of a failure, install security updates, find and fix problems that, perhaps, no one even knows about. Recently, I just wrote scripts for such a service with a long history. Changes in its code were required, work is not finished yet, but progress is big. It is very interesting to collect a complete picture of the application from disparate pieces, it is nice to look at the result later.

And, of course, the implementation of the DevOps approach is closely related to measurement. How much has the response time changed? How often do the intended errors occur? Before, a system administrator often had no idea how to measure these things. Applications were black boxes, only the most basic characteristics remained: processor load, memory consumption, traffic. And when the new version was deployed, neither the system administrator nor the programmer could quickly determine that everything did not go exactly as planned. It remained to wait for angry calls to tech support.

With the DevOps approach, this is a thing of the past. You can configure the collection of real application metrics, compare them with resource consumption, and due to this, it is better and faster to find problems, optimize, improve the quality of products, and not just server uptime.

How much do DevOps engineers earn?


The salary of a DevOps engineer depends on skills, place of work and region of residence. The salary of a specialist working in Moscow is the highest in Russia, 130-350 thousand rubles a month. St. Petersburg companies offer 100–300 thousand rubles in this position. In other regions of our country, they are ready to pay 70–120 thousand rubles.

The average annual income in the States, as some HRs say, ranges from 100 to 125 thousand US dollars, according to data released by Puppet. In Australia and New Zealand - 75-100 thousand US dollars. In Europe - 50-75 thousand US dollars. In Asia, DevOps engineers receive no more than 25 thousand US dollars per year.

More articles:


All Articles