Hire people in DevOps and other bad ideas
Once I witnessed a conversation between two friends and heard:
“Do you already implement DevOps?” We just have everything in full swing at MegaTele! We recently recruited a team of 35 people from DevOps! ”
At that moment I kept myself from the Captain Picard facepalm. Unfortunately, hiring employees for a position that contains the word DevOps and the joy of the participant in this conversation about this is not an accidental mistake. A quick review of sources on the Internet shows that many companies are looking for DevOps engineers who, among others, will be involved in:
The list is made up of pieces of real vacancies, slightly modified, so as not to hint at someone specific.
In general, I have a positive attitude to the fact that the concept of DevOps is becoming popular. However, as was already the case with Agile, DevOps is in danger of getting the status of another fashionable term, and subsequently losing all meaning. It seems to me that most of the companies looking for DevOps want to hire just a sysadmin, but at the same time look modern. The lion's share of requirements in a standard DevOps job is fully covered by the competencies of a support engineer or system administrator. At the same time, it is especially funny that these requirements often lack the clause “the ability to create simple and working solutions”. It seems that instead of working in the direction of the interaction of development and support for quality improvement, the IT industry is trying to "cut off", simply by giving the admin a new title - DevOps.
')
Instead of creating a new DevOps team, try removing the wall between the development and support departments. Developers and sysadmins should meet on a regular basis in order to pronounce all the working moments, including installation, setting up software and its problems. Feedback and discussion of ideas should work in both directions. Project managers should consider system administrators the same software users, and therefore, consider their work scenarios and take into account wishes, as they do for external users. Developers, on the other hand, should understand the requirements of support and approach their implementation responsibly. Of course, the two teams must remain independent, because each has its own specifics, strengths and competencies, but working together in the framework of a “super team” with a common goal is to create and accompany an elegant and high-quality product to solve difficult business problems.
Instead of the ubiquitous scripting of the infrastructure, you should make the software complete and logical. It is believed that the term DevOps is not in Windows due to the lack of effective automation tools in this ecosystem, like in the Linux world (here I hint at chef and puppet). It's hard not to agree, such tools are extremely useful, but I do not support the view that automation is the cornerstone of DevOps. In fact, your software should not rely on non-trivial scripts for installation and configuration (no matter perl, puppet). The implementation should be simple, ideally, like a regular xcopy on the target machine (it would be nice if the software installs itself when you first start it). Settings should be received from the configuration service, rather than arranging carnivals for XML files. Instead of constructing the next Goldberg machine , in order to script all the features and difficulties of customizing your software, interact, finally, with the development (and management) to get rid of such problems and unnecessary complexity.
Do not think of DevOps as another buzzword, better accept this philosophy and spread it. In reality, DevOps cannot be set up by simply hiring specialists with this word in a resume or by implementing monstrous automation software. To comprehend Zen DevOps, you need a cultural leap. Developers who focus on end users should look to support and its needs. Admins, instead of quiet grunts, should report product inconveniences and contribute to improving the work process. Thus, building relationships within the company is the first and important step. Next, you will have to devote time and resources to improve the product to a “simple and convenient” state. Configuration through the central service, implementation by simple copying, the absence of external dependencies, deliberate metrics instead of garbage in the logs are important tasks along the way.
DevOps should not be taken for show. This philosophy involves communication and interaction, and most importantly, the desire to create high-quality software that is developed, maintained and used with pleasure.
“Do you already implement DevOps?” We just have everything in full swing at MegaTele! We recently recruited a team of 35 people from DevOps! ”
So why hiring a DevOps team is a bad idea?
At that moment I kept myself from the Captain Picard facepalm. Unfortunately, hiring employees for a position that contains the word DevOps and the joy of the participant in this conversation about this is not an accidental mistake. A quick review of sources on the Internet shows that many companies are looking for DevOps engineers who, among others, will be involved in:
- automating infrastructure changes
- JIRA configuration
- MySQL administration
- support for large-scale Linux projects
- doing everything related to puppet
- writing scripts in ruby, python or bash
- operative backing up "crutches" here and there
The list is made up of pieces of real vacancies, slightly modified, so as not to hint at someone specific.
In general, I have a positive attitude to the fact that the concept of DevOps is becoming popular. However, as was already the case with Agile, DevOps is in danger of getting the status of another fashionable term, and subsequently losing all meaning. It seems to me that most of the companies looking for DevOps want to hire just a sysadmin, but at the same time look modern. The lion's share of requirements in a standard DevOps job is fully covered by the competencies of a support engineer or system administrator. At the same time, it is especially funny that these requirements often lack the clause “the ability to create simple and working solutions”. It seems that instead of working in the direction of the interaction of development and support for quality improvement, the IT industry is trying to "cut off", simply by giving the admin a new title - DevOps.
')
So what is really needed for the development of DevOps?
Instead of creating a new DevOps team, try removing the wall between the development and support departments. Developers and sysadmins should meet on a regular basis in order to pronounce all the working moments, including installation, setting up software and its problems. Feedback and discussion of ideas should work in both directions. Project managers should consider system administrators the same software users, and therefore, consider their work scenarios and take into account wishes, as they do for external users. Developers, on the other hand, should understand the requirements of support and approach their implementation responsibly. Of course, the two teams must remain independent, because each has its own specifics, strengths and competencies, but working together in the framework of a “super team” with a common goal is to create and accompany an elegant and high-quality product to solve difficult business problems.
Instead of the ubiquitous scripting of the infrastructure, you should make the software complete and logical. It is believed that the term DevOps is not in Windows due to the lack of effective automation tools in this ecosystem, like in the Linux world (here I hint at chef and puppet). It's hard not to agree, such tools are extremely useful, but I do not support the view that automation is the cornerstone of DevOps. In fact, your software should not rely on non-trivial scripts for installation and configuration (no matter perl, puppet). The implementation should be simple, ideally, like a regular xcopy on the target machine (it would be nice if the software installs itself when you first start it). Settings should be received from the configuration service, rather than arranging carnivals for XML files. Instead of constructing the next Goldberg machine , in order to script all the features and difficulties of customizing your software, interact, finally, with the development (and management) to get rid of such problems and unnecessary complexity.
Do not think of DevOps as another buzzword, better accept this philosophy and spread it. In reality, DevOps cannot be set up by simply hiring specialists with this word in a resume or by implementing monstrous automation software. To comprehend Zen DevOps, you need a cultural leap. Developers who focus on end users should look to support and its needs. Admins, instead of quiet grunts, should report product inconveniences and contribute to improving the work process. Thus, building relationships within the company is the first and important step. Next, you will have to devote time and resources to improve the product to a “simple and convenient” state. Configuration through the central service, implementation by simple copying, the absence of external dependencies, deliberate metrics instead of garbage in the logs are important tasks along the way.
DevOps should not be taken for show. This philosophy involves communication and interaction, and most importantly, the desire to create high-quality software that is developed, maintained and used with pleasure.
Source: https://habr.com/ru/post/208196/
All Articles