If we talk about where they get this engineering experience, then usually they come to devops either from development or from administration.
It happens that a programmer gets tired of writing code, and he decides to develop in a related direction. These people have a cool background in development, they tighten up the admin part and after that they help quite coolly with CI/CD processes, with the launch of applications, that is, with some processes around development, because they perfectly understand how it works.
The second option is devops who came from admins, they usually have experience in supporting services and infrastructure. They are just learning other tools and are great at maintaining services. Deploying some new service for them is usually not a problem.
Both in the first and in the second case, specialists receive the missing knowledge and develop further already in devops.
I myself was originally a Windows admin. I came to devops because, even as a Windows admin, I was ideologically engaged in just the processes. We helped developers with the delivery and stability of their software, albeit on a completely different stack. But the essence is about the same.
Experience and tools
If we talk about tools, today I can note the following:
any CI/CD tool, for example, GitLab;
basic knowledge of Linux administration;
Bash or Python, at least at the level of reading other people’s scripts.
This is the basic stack, everything else is nice additions, plus the tools vary greatly from company to company. It also happens that none of the above is used in the company, and it is also normal for them. Alternative tools are simply used.
It would be nice, of course, to know the specifics of programming languages. Conditionally — understand how to put Java in a container and how Python. As for writing code, the most popular languages for devops are Python and Go. Automation is now mostly written in Python and knowing it is a cool bonus. And the operators for k8s are written in Go, so knowledge of Go is also a priority. But in general, knowledge of any language is definitely a plus. On the other hand, if you can’t write, it’s not a blocker.
In addition to tools, devops’ work, of course, is related to communication. I would say that for a junior or middle specialist, about 70 percent of the time is occupied by handwork, and 30 percent is communication. The closest interaction is usually with the development and information security teams, these are direct working relationships.
And then it depends on imagination and enthusiasm. For example, I work closely with colleagues who are engaged in HR-brand, we hold internal meetings, participate in external events.
Accidents and monitoring
Communication is always very important, DevOps methodology is generally about negotiating. This is important both when everything works, and when everything went wrong and nothing works. I won’t tell you in detail here, but you can watch my report from HighLoad++ “Incidents and communication: what, how and why to say when everything is broken”. Initially, accidents are kind of about SRE, not about devops, but there are not many companies where there is a dedicated SRE team.
When an accident happens, the main thing is just to take it and fix it. Another question is that it is necessary to clearly understand who is responsible, in which place the accident occurred. The areas of responsibility, of course, should be separated before the incident. If the accident is in the area of responsibility of the devops engineer, he runs and repairs, if this development has rolled out something very, very bad, and it broke, then you can already agree.
What to do if you are June
There are a lot more junks on the market now than there are vacancies for them. I don’t believe that you can become a middleweight just by going to courses and not working a day for real. The courses provide theoretical knowledge, but do not provide real experience. But they are not useless. This is an easy and fast way to learn how to work with tools.
They help you stand out from other juniors and get an offer for your pet projects. It’s one thing — you come and say: “Here’s my resume, I don’t know how to do anything—take me.” There are thousands of them. Another thing is when you say: “Look, here is the repository, I have raised a cluster in the cloud. I have a demo application in this cluster, here is CI/CD, and I also added tests.”
And to switch to devops, you don’t always need to change your place of work. You can always try to switch horizontally within the company. If you are a developer, you can try to become a devops of your own development team. Add linters, code analyzers, automation of what is being done by hand to pipelines. This is often in demand.
You can also find people who are engaged in devops in your company and talk to them, ask: “Guys, tell me, what are they doing here? What should I learn and how to do it on our infrastructure?”. This will also give you practical experience working with tools.
Devops is no longer about a position, but about an approach, a set of practices that simplify interaction and improve processes. Devops appeared at the junction of operation and development, so knowledge from both areas is needed: if you come to devops from operation, you will need to learn more about the processes of developers and vice versa.
In addition to tools and technical skills, communication and the ability to negotiate are very important for a devops. Communication at work takes a significant amount of time, you need to be prepared for this. You can learn how to work with devops tools at the courses, developing your pet projects, you can learn from the experience of colleagues. All this will help you find your first job and develop further in the profession.