Who am I?
Hello, I’m 37 years old and a junior DevOps. Yes, it sounds funny when you mention your age and realise that by this time, many people are already wrapping up their IT careers and becoming carpenters, plumbers, or farmers.
But I was driven by a natural curiosity that ultimately led me to the job of my dreams! In this article, I’ll try to break everything down and explain all the nuances of my journey.
Chapter 1: The Beginning
I was born and raised in a small town, and I didn’t get to see IT the way people with MacBooks and iPhones from the big tech companies do. I started as a typical Windows admin at companies where I had to change cartridges and crawl under tables in the accounting department.
But time passed, and I gained experience, sometimes relevant, sometimes not.
In 2018, I “leveled up” to head of department in a company named GazProm. The tasks were varied, but from that point, the story began to more closely represent what’s typically understood as OPS work.
My colleagues and I were replacing paid software with free alternatives: we switched from paid VMware to free Proxmox, set up stable communication between remote objects, and automated all routine tasks (although not yet in the way DevOps envisions). Time passed, salaries didn’t grow, motivation was lacking, and most of the department left for new opportunities.
Chapter 2: Prod Support
In 2021, I joined the production support team at the will of fate and the invitation of a former/current colleague.
EXANTE is a brokerage company with its own trading platform. Clients can trade globally across over 50 markets using a single multi-currency account. Our primary clients are professional traders and institutional clients.
So, in July 2021, I joined Prod Support and began struggling for several reasons: new and unfamiliar technologies, an overload of information, and an unknown financial industry. This was not only about the work itself but also a world I knew only from American movies, where the hero reaches the edge of a skyscraper and jumps. Well, whatever, I made my choice and carried on.
A few words about how the Prod Support team is organised
Essentially, this is Level 2-3 technical support. The team’s primary responsibility is to monitor the production environment and respond to abnormal situations in the systems, as well as local incidents: from issues faced by regular users (which weren’t solved by the first line) to incidents related to specific system components.
The team also handles release management, incident management, and overall management of the production environment.
A production support engineer is someone who:
Keeps the production system running smoothly,
Douses fires,
Manages releases,
Knows where to hit with the hammer of knowledge if something falls apart.
Almost 90% of my colleagues are former system administrators with knowledge in various areas, mostly Linux. The typical stack for a prod support engineer includes knowledge of Linux, understanding how networks work, monitoring (mostly Zabbix/Grafana), web technologies, and so on. In particular, skills related to stock trading were highly valued.
For a newcomer, onboarding is an adventure. It lasts six weeks, and you drown in an enormous amount of information during this time. As a result, a Production Support Engineer has the most comprehensive understanding of how the system works.
That’s precisely why this team is a talent factory for IT Operations and beyond. Four out of five colleagues who leave the team stay within the company, moving into development, testing, or DevOps.
When I started getting into the work, my mind screamed: “Linux? Logs? How am I supposed to do this? They’ll get rid of me in a week!” Despite a swarm of doubts, I needed to eat, the pay was good, and most importantly, I could work from home and truly feel like a remote worker. After COVID, that was a fantastic perk.
Chapter 3: Learning. Pet Project.
By November, I had settled in and decided I was ready for more. The vast amount of new information around me made me eager to start understanding what was happening, so I decided that taking some DevOps courses would be helpful.
A nice little perk was that the company paid half the course fee. Since November, I had become a student and a future DevOps specialist, part of the assembly line of IT professionals.
Here’s a brief look at the work of the DevOps & Infrastructure team. Imagine a mysterious “DevOps and Infrastructure” department in a company. They say their lights are always on, and the servers are flashing (like in sci-fi movies, though we can’t see the flashing lights – our infrastructure is in the clouds). You walk in, and it’s like a secret order: they sit in hoodies, surrounded by a pantheon of monitors, whispering commands like “kubectl apply,” “terraform plan,” and “docker-compose up.”
What do they do?
Magical rituals on servers: Essentially, DevOps engineers make sure everything developers create doesn’t just stay on their computers but works for all users. They’re like wizards with wands, only their wands are command lines. They also cast protective spells to keep unwanted intruders out.
Conquering the foggy clouds: They do “live in the clouds.” But not because they’re dreaming, but because they run servers and applications there.
Automation or “lazy but smart”: DevOps engineers love scripts and tools that save them from repetitive manual tasks.
Containers are the new nesting dolls: Colleagues can put servers in containers, containers in services, and services back in containers! Docker is like Russian nesting dolls in the IT world.
Monitoring and log cuddling: DevOps engineers love monitoring metrics (CPU, memory, disk usage, even the mood of office cats, i.e. anything measurable).
Heroes of the invisible front: If everything runs smoothly, no one remembers them (because there are no problems). But when a small service goes down, everyone starts yelling: "Help! Where are our DevOps?!"—and they’re already there, front and center, hugging the logs, wrench in one hand, Python script in the other.
DevOps and Infrastructure Engineers are the backstage masters, ensuring the stability and elegance of the IT ballet. They combine the skills of coder brotherhood, system administrators, and a touch of shamanism. If everything is working fine, their magic goes unnoticed. But when something breaks, only they can decipher the ancient scriptures of the logs, chant the proper incantations, and bring our technological world back to life.
My training took up a lot of time, covering many topics, but everything was crammed together, giving only a general idea of what I would have to deal with in the future. By the way, I studied in a netology course (not an advertisement, everyone can choose what they want). Overall, the course was clear, and the material was delivered well, but there were some bitter moments. For example, one such issue for me was the incompetence of certain instructors. But let’s leave that to them – luckily, there weren’t too many.
As I dove deeper into learning, I realised that without practice, I simply wouldn’t survive: all this knowledge would just turn into useless dust settling on the cortex of my brain.
A thoughtful reader might ask: "Why not learn on the job?" And they'd be right. But you can’t just show up and say, "Let me fix everything for you real quick." So, I figured it would be a good idea to develop a project where my raw, newly acquired knowledge could be used.
A quick side note: in production support, the job had shift-based scheduling, which meant I could allocate my time flexibly between work, study, family, and my project. Yes, it was tough, and honestly, such things should be done at 20, not at 35. At 20, your brain works faster, you can survive on three hours of sleep, and your back doesn’t ache (not to mention kids and their homework).
But the goal was set, and the next step was simple: Developing a project.
I decided not to overthink it and went straight to my colleagues. They were more than happy to help. Without much hesitation, they threw together a project covering everything a junior should know. The pilot task was to set up Ansible, configure it, write some playbooks, and test them. The project had everything I wanted: Kubernetes, Git, Docker, and more. It was a real-world project with clear objectives and clear deadlines.
The team assigned tasks and monitored their progress, occasionally inviting me to meetings where they held brainstorming sessions. (To be honest, I understood maybe 40% of what they were talking about at the time, but now I know where the dog is buried.) Besides that, I took on real tasks as they came in and documented their solutions.
Things kicked into high gear: my main job continued as usual, my studies progressed, and I applied my new knowledge to the pet project. It was a tough period because balancing everything was incredibly challenging. I lost count of how often I scolded myself for not discovering all this earlier, but history doesn’t work in the subjunctive mood.
Chapter 4: Junior DevOps. IT Operations
The project and my training were almost over. During this period, I became familiar with the key tools for a DevOps engineer: Docker, Kubernetes, cloud solutions, Git, Ansible, etc. I completed my training and received my “DevOps engineer” certification, though I feel I still have a long way to go to reach the true level of a DevOps engineer.
All that was left for me was to change teams and start proving myself in more complex projects alongside a team of professionals. That was the primary goal.
A quick note: Production Support is a team of people who know the entire internal kitchen. Their transition to other teams is prioritised—the company appreciates employees who grow, and the team benefits because the newcomer already understands the internal workings of services and overall operations.
The transition happened, and I became a Junior DevOps! Goal achieved!
A few words about onboarding: The team follows a buddy system, meaning you’re assigned to a more experienced colleague. That doesn’t mean the rest of the team just stands by and watches you drown. They use a carrot-and-stick approach, you know: do well, and you get praise; mess up, and they’ll knock your hat off so hard that your next career thought will be about becoming a mechanic, carpenter, or woodworker. But nobody is left behind. They’ll help until you fully understand where you went wrong and how to fix it.
Newcomers are also responsible for handling internal team chats, communicating with colleagues from other departments, solving their issues, and gaining deeper insights into the company’s specifics.
In short, the journey continues—working, learning, and growing.
To clarify things, here’s a brief diagram illustrating who is responsible for what and how the IT Operations hierarchy looks.
Production Support
A Production Support Engineer provides technical support at L2-L3 levels. Their most crucial responsibility is monitoring the production environment's state, responding to abnormal situations affecting the overall system operation, and handling localised incidents.
Monitoring
They are the eyes of our infrastructure. The team's main task is to monitor changes in infrastructure performance to prevent major incidents that could compromise the system. They use a standard set of tools, including Zabbix, ELK, Graylog, and more.
DevOPS & Infrastructure
Ops manage servers and networks and ensure the stability of the IT infrastructure. DevOps automates processes and bridges development and operations to speed up releases.
How We Interact with Each Other
Next, I’d describe how team interaction works in a simplified case. Here’s how it looks:
The monitoring team notices abnormal behavior in the system, collects preliminary information, and follows the flow to direct the incident to the production support or the infrastructure department (such incidents can be created by the monitoring operator or automatically).
Then, the Production support engineer handles the incident (SLA for processing is 5 minutes): the severity is determined (from minor to critical), followed by an analysis of the preliminary information provided by the monitoring team. If the data is insufficient, the engineer conducts additional research to understand what happened (checks logs, verifies if there’s any impact on clients or internal users, and assesses how the incident might affect the system as a whole).
Let’s assume the incident is somehow related to DevOps. All available information gets sent to the responsible person, who investigates the issue and resolves it either on their own or by involving colleagues from other departments who are directly related to it (for example, a problem with a crashed application).
This example is exaggerated and simply illustrates the point. In general, a large number of problems are solved similarly. The production support team gathers statistics on incidents that need attention and holds a meeting, which we internally refer to as the 'Incident Meeting.' This meeting is open to any employee and serves as a brainstorming session.
Chapter 5: Results and Thanks
In conclusion, here’s a short summary of what I’ve learned:
Communicate: The best information comes from the people who live it.
Don’t be afraid to ask questions.
It’s never too late to learn, even at 40 (but it’s better when you’re younger and unburdened by other responsibilities)
Every action will be rewarded, both positively and negatively.
Work hard, whether it’s DevOps, family, or relationships.
Special Thanks
I’d like to thank those who helped me with this journey: Zhenya, Ilya, Lida, Dima, Asylbek, Sasha, and of course, my family, who supported me. Thank you!