What do you need to know to become a beginner systems engineer (devops)?

Question

Devops

Please tell me what skills you need to have in order to be able to get a job as a junior in the above specialty. What literature should be read? What kind of things should you try to write yourself so that you have something to show at the interview. The opinion of people working in this specialty is especially important.
I found a job description, but it’s far from being a junior and, frankly, it’s difficult to choose a list of references on my own: rabota.ngs.ru/vacancy/Sistemniy_inzhener_DevOps?id...
Thank you in advance for the detailed answers.

Answer 1

An article that everyone should read.
DevOps is not a profession. This is the name of the culture of delivering code from the developer (dev) through testers to the system administrator (ops) and feedback along this chain.
The person who implements DevOps is usually called ... whatever they want. Most often, this is done by some non-conformist in the team.
The professions that will be drawn in the process of building this methodology are as follows:
The list did not include the most important specialty - "psychology". A person who has to follow people and figure out the psychologically important aspects of the team that hit performance bottlenecks.
Almost always, all these roles are combined by one or two people. Well it depends on the quality of the code.
Let's call this company BRAE/CM for short.
The task of BRAE / CM is to ensure that the program code that comes out of the pen of programmers remains under the control of programmers and system administrators at the same time. Developers, as well as system administrators, thanks to the DevOps approach, have the opportunity and even the obligation to maintain the code throughout the entire life cycle from architecture planning to trash.
That is, sysadmins start to steer even before the code gets to them - in the early stages, and programmers continue to steer their tasks after the code has gone from them to sysadmins - in the later stages. And all this is transparent to each other, and all problems and solutions go back and forth and do not stumble over the bureaucracy in the style of "I don't know anything, we've already committed the code, I have my own problems here, they broke - let them fix it themselves."
So this work is the final stage of the system administrator and the beginning stage of the developer. Therefore, there is no Junior BRAE / CM.
BRAE/CM is always only Senior in system administration and always Junior in programming.
One more moment. At home, you can learn the instruments at a basic level. But without cooking in the same pot with real developers, the meaning of this whole kitchen cannot be understood. So hit it right away. But if you want, I can describe a step-by-step long way how to become RE/CM:
I will make a reservation about languages ​​right away.
Each language has its own purpose. Java is more commonly used in the corporate sector. There are many servers and complex business applications. Therefore, the Java world is very sensitive to concepts such as "technical debt" and "management of the development process." And that is why it is there that all the main DevOps vacancies and it is there that the most interesting experience will be.
Besides Java, Ruby has a traditionally strong DevOps culture. Almost all other languages ​​do not have such a developed and popular infrastructure in this context and therefore you are likely to be uninterested.
In other words, if in the developer environment the choice of language is a topic for holivar and emotions with millions of comparative analyzes with opposite results, then for DevOps specialists the choice is obvious and transparent. Java is at the same time the most interesting tasks, the richest toolset, the largest selection of vacancies and the highest salaries.
Each subsequent paragraph, except for a particularly long first one, will result in a week or two of fairly dense work. If you do not procrastinate and give it a few hours in the evening.
So what to do:
1) Read Head First Java books. Take Java courses on EDX.
2) Master SVN. There are excellent tutorials. (We'll learn GIT later)
3) Install VirtualBox (not VMWare!!!)
4) Write a simple application. Commit the code to SVN. Build it with maven.
5) Raise on a separate Jenkins virtual machine. He must take the application code on SVN and run his local maven to build.
6) Write unit tests for your code. Let maven drive them away as well.
7) Pick up a Nexus somewhere. Make it more difficult for maven so that it now puts everything in Nexus. If maven needs external libraries, it also does not have to go to the Internet itself, but through Nexus (Central repo).
8) Set up vagrant on your desktop so that it creates VirtualBox virtual machines from scratch.
9) Create a DEV virtual machine using vagrant. At the same time, ansible must configure something on it (for example, install the JDK)
10) Learn how to deploy jar / war from Nexus to the DEV virtual machine with something. What I won’t advise, since I myself work with a very complex IBM uDeploy, and this is definitely not for a beginner. Look towards Rundeck or something like that. Maybe deploy it yourself with Jenkins.
11) Write integration AUTOtests. On whatever you want (as an option: Selenium).
We complicate the system.
12) Customizing Jenkins: builds a maven project; uploads to Nexus; pulls vagrant / ansible to create a virtual SIT (system integration test); deploy the application to SIT; runs autotests on SIT; removes the virtual machine after successful completion of autotests.
13) We fasten SonarQube in Jenkins for static code analysis. We fix the jambs of our code, according to the recommendations received from SQ.
14) Fasten the Sensu monitoring.
15) We write load tests on something. Ideally, touch two tools: jMeter and Gatling.
16) As in the 12th step, we fasten in Jenkins the automation of creating an SLT (Stress / Load test) virtual machine and running tests on it. Only load tests (mandatory) and stress tests (optional) respectively.
17) We add some functionality to our application so that the base is used.
18) You will have to get acquainted with LiquiBase. Deploying SQL by hand is prohibited.
19) Switch to Docker (that is, now the application is not laid out directly in the OS, but inside the docker)
20) A day to read about Agile, Scrum, Waterfall and other organizational arrangements.
And now we go a little into project management:
21) Install Atlassian Jira. Understand the difference between Epic, Story, Task, Sub-Task. Create a front of work similar to this structure (you don’t have to do it, just fantasize).
22) Install Atlassian Stash and link it to Jira.
23) Move from your SVN to GIT provided by Stash.
24) Go through some Git tutorial. The tool is very non-trivial.
25) Take any task to work. At the same time, at the beginning of the work, make a new Git branch from the Jira ticket.
26) Upon completion of work, launch the entire chain built earlier, but for your branch.
Let me guess: did you have to copy all the jobs and rewrite the branches in them?
27) Do jobs normally. So that the same ones can be used for any branches - by analogy with the programming principle "reuse code". You will have a reuse job :)
28) Make a pull request, do a code review yourself and self-approve. After that, merge your branch into master.
29) Make branch build automatic by git-hook (or SCM pool)
30) And now aerobatics: to hell with Docker, Copistrano and other buzz-word-hipsters-nonsense. Now you are familiar with this and can apply it, but it's time to gnaw out this kindergarten with a red-hot iron. Now you only deliver code as .deb packages. This means that you:
a) split the control file into several packages, possibly with lib*,
b) override all ~20 dh_ in the rules file so that it all matches your work in the previous paragraphs.
c) scatter files over .install
d) the heaviest: prepare .preinst, .postinst, .prerm, .postrm files ACCORDING TO THEIR EXAMPLES .ex generated by dh_make - i.e. split into update/configure/broken-install and what else is there. This means that when reinstalling, when upgrading, when downgrading, when uninstalling, and when purging, you will have different scenarios, each of which must be worked out thoroughly. At this stage, you will also become familiar with the concept of "regression tests".
Well, here's the basic version. But this is not the whole toolkit and the way. That's right, for starters.
In addition, it would be nice to get acquainted with Puppet (this is not very suitable for DevOps, rather for ordinary admins with a bunch of servers, but this is a very popular tool because no one understands what DevOps is and you will most likely be forced to manage hundreds of servers, instead of releasing engineering). And you also need to get acquainted with the operating systems NixOS (required) and CentOS / Debian (optional, but I would beat those who do not know these OS with a stick). In addition, you need to have a basic understanding of PostgreSQL.
Attention, an important point that should be sewn into the subconscious level of a DevOps-oriented engineer: you are trying new tools all the time. You will always find something very different. Know Nexus like the back of your hand and it solves almost every problem? Fine! Now throw out Nexus and install Artifactory. Do you know CentOS well? Cool! Now try to do all this on Windows or Debian. Because only when you can compare tools, your work will be jewelry. And DevOps is either jewelry, or it is not DevOps. You must be language-independent, platform-independent, and tool-independent.
What will happen next? Next, you will start working with microservices (hundreds of identical containers in the cloud that must somehow work with each other without manual configuration). Then get acquainted with all sorts of Consul, ZooKepper and a bunch of AWS / OpenStack tools.