{"id":458083,"date":"2025-04-29T15:00:43","date_gmt":"2025-04-29T15:00:43","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=458083"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=458083","title":{"rendered":"<span>It\u2019s Never Too Late: My Start into DevOps<\/span>"},"content":{"rendered":"<div><!--[--><!--]--><\/div>\n<div id=\"post-content-body\">\n<div>\n<div class=\"article-formatted-body article-formatted-body article-formatted-body_version-2\">\n<div xmlns=\"http:\/\/www.w3.org\/1999\/xhtml\">\n<h3>Who am I?\u00a0<\/h3>\n<p>Hello,  I\u2019m 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.\u00a0<\/p>\n<p>But I was driven by a natural curiosity that ultimately led me to the job of my dreams! In this article, I\u2019ll try to break everything down and explain all the nuances of my journey.<\/p>\n<h3>Chapter 1: The Beginning\u00a0<\/h3>\n<p>I was born and raised in a small town, and I didn\u2019t 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.\u00a0<\/p>\n<p>But time passed, and I gained experience, sometimes relevant, sometimes not.\u00a0<\/p>\n<p>In 2018, I \u201cleveled up\u201d 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\u2019s typically understood as OPS work.\u00a0<\/p>\n<p>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\u2019t grow, motivation was lacking, and most of the department left for new opportunities.<\/p>\n<h3>Chapter 2: Prod Support\u00a0<\/h3>\n<p>In 2021, I joined the production support team at the will of fate and the invitation of a former\/current colleague.\u00a0<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p><strong>A few words about how the Prod Support team is organised<\/strong><\/p>\n<p>Essentially, this is Level 2-3 technical support. The team\u2019s 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\u2019t solved by the first line) to incidents related to specific system components.<\/p>\n<p>The team also handles release management, incident management, and overall management of the production environment.<\/p>\n<p>A production support engineer is someone who:<\/p>\n<ul>\n<li>\n<p>Keeps the production system running smoothly,<\/p>\n<\/li>\n<li>\n<p>Douses fires,<\/p>\n<\/li>\n<li>\n<p>Manages releases,<\/p>\n<\/li>\n<li>\n<p>Knows where to hit with the hammer of knowledge if something falls apart.<\/p>\n<\/li>\n<\/ul>\n<p>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.\u00a0<\/p>\n<p>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.<\/p>\n<p>That\u2019s 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.<\/p>\n<p>When I started getting into the work, my mind screamed: \u201cLinux? Logs? How am I supposed to do this? They\u2019ll get rid of me in a week!\u201d 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.<\/p>\n<h3>Chapter 3: Learning. Pet Project.<\/h3>\n<p>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.<\/p>\n<p>A nice little perk was that the company paid half the course fee. Since November, I had become a student and a future\u00a0 DevOps specialist, part of the assembly line of IT professionals.<\/p>\n<p>Here\u2019s a brief look at the work of the DevOps &amp; Infrastructure team. Imagine a mysterious \u201cDevOps and Infrastructure\u201d department in a company. They say their lights are always on, and the servers are flashing (like in sci-fi movies, though we can\u2019t see the flashing lights \u2013 our infrastructure is in the clouds). You walk in, and it\u2019s like a secret order: they sit in hoodies, surrounded by a pantheon of monitors, whispering commands like \u201ckubectl apply,\u201d \u201cterraform plan,\u201d and \u201cdocker-compose up.\u201d<\/p>\n<p><strong>What do they do?<\/strong><\/p>\n<ul>\n<li>\n<p><strong>Magical rituals on servers:<\/strong> Essentially, DevOps engineers make sure everything developers create doesn\u2019t just stay on their computers but works for all users. They\u2019re like wizards with wands, only their wands are command lines. They also cast protective spells to keep unwanted intruders out.<\/p>\n<\/li>\n<li>\n<p><strong>Conquering the foggy clouds:<\/strong> They do \u201clive in the clouds.\u201d But not because they\u2019re dreaming, but because they run servers and applications there.<\/p>\n<\/li>\n<li>\n<p><strong>Automation or \u201clazy but smart\u201d:<\/strong> DevOps engineers love scripts and tools that save them from repetitive manual tasks.<\/p>\n<\/li>\n<li>\n<p><strong>Containers are the new nesting dolls: <\/strong>Colleagues can put servers in containers, containers in services, and services back in containers! Docker is like Russian nesting dolls in the IT world.<\/p>\n<\/li>\n<li>\n<p><strong>Monitoring and log cuddling: <\/strong>DevOps engineers love monitoring metrics (CPU, memory, disk usage, even the mood of office cats, i.e. anything measurable).<\/p>\n<\/li>\n<li>\n<p><strong>Heroes of the invisible front:<\/strong> If everything runs smoothly, no one remembers them (because there are no problems). But when a small service goes down, everyone starts yelling: <em>&#171;Help! Where are our DevOps?!&#187;<\/em>\u2014and they\u2019re already there, front and center, hugging the logs, wrench in one hand, Python script in the other.<\/p>\n<\/li>\n<\/ul>\n<p>DevOps and Infrastructure Engineers are the backstage masters, ensuring the stability and elegance of the IT ballet. They combine the skills of <em>coder brotherhood<\/em>, 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.<\/p>\n<p>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 <em>bitter moments<\/em>. For example, one such issue for me was the incompetence of certain instructors. But let\u2019s leave that to them \u2013 luckily, there weren\u2019t too many.<\/p>\n<p>As I dove deeper into learning, I realised that without practice, I simply wouldn\u2019t survive: all this knowledge would just turn into useless dust settling on the cortex of my brain.<\/p>\n<p>A thoughtful reader might ask: <em>&#171;Why not learn on the job?&#187;<\/em> And they&#8217;d be right. But you can\u2019t just show up and say, <em>&#171;Let me fix everything for you real quick.&#187;<\/em> So, I figured it would be a good idea to develop a project where my raw, newly acquired knowledge could be used.<\/p>\n<p>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\u2019t ache (not to mention kids and their homework).<\/p>\n<p>But the goal was set, and the next step was simple: Developing a project.<\/p>\n<p>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.<\/p>\n<p>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 <em>know where the dog is buried<\/em>.) Besides that, I took on real tasks as they came in and documented their solutions.<\/p>\n<p>Things kicked into high gear: my main job continued as usual, my studies progressed, and I applied my new knowledge to the <em>pet project<\/em>. 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\u2019t work in the subjunctive mood.<\/p>\n<h3>Chapter 4: Junior DevOps. IT Operations\u00a0<\/h3>\n<p>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 \u201cDevOps engineer\u201d certification, though I feel I still have a long way to go to reach the true level of a DevOps engineer.<\/p>\n<p>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.<\/p>\n<p>A quick note: Production Support is a team of people who know the entire internal <em>kitchen<\/em>. Their transition to other teams is prioritised\u2014the company appreciates employees who grow, and the team benefits because the newcomer already understands the internal workings of services and overall operations.<\/p>\n<p>The transition happened, and I became a Junior DevOps! Goal achieved!<\/p>\n<p>A few words about onboarding: The team follows a <em>buddy system<\/em>, meaning you\u2019re assigned to a more experienced colleague. That doesn\u2019t mean the rest of the team just stands by and watches you drown. They use a <em>carrot-and-stick<\/em> approach, you know: do well, and you get praise; mess up, and they\u2019ll <em>knock your hat off<\/em> so hard that your next career thought will be about becoming a mechanic, carpenter, or woodworker. But nobody is left behind. They\u2019ll help until you fully understand where you went wrong and how to fix it.<\/p>\n<p>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\u2019s specifics.<\/p>\n<p><strong>In short, the journey continues\u2014working, learning, and growing.<\/strong><\/p>\n<p>To clarify things, here\u2019s a brief diagram illustrating who is responsible for what and how the IT Operations hierarchy looks.<\/p>\n<figure class=\"full-width\"><img decoding=\"async\" src=\"https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/02c\/c6b\/0c7\/02cc6b0c782a13068726e8f8a52072e6.png\" width=\"750\" height=\"307\" sizes=\"auto, (max-width: 780px) 100vw, 50vw\" srcset=\"https:\/\/habrastorage.org\/r\/w780\/getpro\/habr\/upload_files\/02c\/c6b\/0c7\/02cc6b0c782a13068726e8f8a52072e6.png 780w,&#10;       https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/02c\/c6b\/0c7\/02cc6b0c782a13068726e8f8a52072e6.png 781w\" loading=\"lazy\" decode=\"async\"\/><\/figure>\n<p><u>Production Support<\/u><\/p>\n<p>A Production Support Engineer provides technical support at L2-L3 levels. Their most crucial responsibility is monitoring the production environment&#8217;s state, responding to abnormal situations affecting the overall system operation, and handling localised incidents.<\/p>\n<p><u>Monitoring<\/u><\/p>\n<p>They are the eyes of our infrastructure. The team&#8217;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.<\/p>\n<p><u>DevOPS &amp; Infrastructure<\/u><\/p>\n<p>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.<\/p>\n<p><strong>How We Interact with Each Other<\/strong><\/p>\n<p>Next, I\u2019d describe how team interaction works in a simplified case. Here\u2019s how it looks:<\/p>\n<ol>\n<li>\n<p>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).<\/p>\n<\/li>\n<li>\n<p>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\u2019s any impact on clients or internal users, and assesses how the incident might affect the system as a whole).<\/p>\n<\/li>\n<li>\n<p>Let\u2019s 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).<\/p>\n<\/li>\n<\/ol>\n<figure class=\"full-width\"><img decoding=\"async\" src=\"https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/994\/202\/9d8\/9942029d881606b4e4350adcc5077df8.png\" width=\"942\" height=\"944\" sizes=\"auto, (max-width: 780px) 100vw, 50vw\" srcset=\"https:\/\/habrastorage.org\/r\/w780\/getpro\/habr\/upload_files\/994\/202\/9d8\/9942029d881606b4e4350adcc5077df8.png 780w,&#10;       https:\/\/habrastorage.org\/r\/w1560\/getpro\/habr\/upload_files\/994\/202\/9d8\/9942029d881606b4e4350adcc5077df8.png 781w\" loading=\"lazy\" decode=\"async\"\/><\/figure>\n<p>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 &#8216;Incident Meeting.&#8217; This meeting is open to any employee and serves as a brainstorming session.<\/p>\n<h3>Chapter 5: Results and Thanks\u00a0<\/h3>\n<p>In conclusion, here\u2019s a short summary of what I\u2019ve learned:<\/p>\n<ul>\n<li>\n<p><strong>Communicate:<\/strong> The best information comes from the people who live it.<\/p>\n<\/li>\n<li>\n<p><strong>Don\u2019t be afraid to ask questions.<\/strong><\/p>\n<\/li>\n<li>\n<p><strong>It\u2019s never too late to learn<\/strong>, even at 40 (but it\u2019s better when you\u2019re younger and unburdened by other responsibilities)<\/p>\n<\/li>\n<li>\n<p><strong>Every action will be rewarded<\/strong>, both positively and negatively.<\/p>\n<\/li>\n<li>\n<p><strong>Work hard<\/strong>, whether it\u2019s DevOps, family, or relationships.<\/p>\n<\/li>\n<\/ul>\n<h4>Special Thanks<\/h4>\n<p>I\u2019d 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!<\/p>\n<\/div>\n<\/div>\n<\/div>\n<p><!----><!----><\/div>\n<p><!----><!----><br \/> \u0441\u0441\u044b\u043b\u043a\u0430 \u043d\u0430 \u043e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 <a href=\"https:\/\/habr.com\/ru\/articles\/905392\/\"> https:\/\/habr.com\/ru\/articles\/905392\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<div><!--[--><!--]--><\/div>\n<div id=\"post-content-body\">\n<div>\n<div class=\"article-formatted-body article-formatted-body article-formatted-body_version-2\">\n<div xmlns=\"http:\/\/www.w3.org\/1999\/xhtml\">\n<h3>Who am I?\u00a0<\/h3>\n<p>Hello,  I\u2019m 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.\u00a0<\/p>\n<p>But I was driven by a natural curiosity that ultimately led me to the job of my dreams! In this article, I\u2019ll try to break everything down and explain all the nuances of my journey.<\/p>\n<h3>Chapter 1: The Beginning\u00a0<\/h3>\n<p>I was born and raised in a small town, and I didn\u2019t 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.\u00a0<\/p>\n<p>But time passed, and I gained experience, sometimes relevant, sometimes not.\u00a0<\/p>\n<p>In 2018, I \u201cleveled up\u201d 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\u2019s typically understood as OPS work.\u00a0<\/p>\n<p>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\u2019t grow, motivation was lacking, and most of the department left for new opportunities.<\/p>\n<h3>Chapter 2: Prod Support\u00a0<\/h3>\n<p>In 2021, I joined the production support team at the will of fate and the invitation of a former\/current colleague.\u00a0<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p><strong>A few words about how the Prod Support team is organised<\/strong><\/p>\n<p>Essentially, this is Level 2-3 technical support. The team\u2019s 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\u2019t solved by the first line) to incidents related to specific system components.<\/p>\n<p>The team also handles release management, incident management, and overall management of the production environment.<\/p>\n<p>A production support engineer is someone who:<\/p>\n<ul>\n<li>\n<p>Keeps the production system running smoothly,<\/p>\n<\/li>\n<li>\n<p>Douses fires,<\/p>\n<\/li>\n<li>\n<p>Manages releases,<\/p>\n<\/li>\n<li>\n<p>Knows where to hit with the hammer of knowledge if something falls apart.<\/p>\n<\/li>\n<\/ul>\n<p>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.\u00a0<\/p>\n<p>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.<\/p>\n<p>That\u2019s 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.<\/p>\n<p>When I started getting into the work, my mind screamed: \u201cLinux? Logs? How am I supposed to do this? They\u2019ll get rid of me in a week!\u201d 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.<\/p>\n<h3>Chapter 3: Learning. Pet Project.<\/h3>\n<p>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.<\/p>\n<p>A nice little perk was that the company paid half the course fee. Since November, I had become a student and a future\u00a0 DevOps specialist, part of the assembly line of IT professionals.<\/p>\n<p>Here\u2019s a brief look at the work of the DevOps &amp; Infrastructure team. Imagine a mysterious \u201cDevOps and Infrastructure\u201d department in a company. They say their lights are always on, and the servers are flashing (like in sci-fi movies, though we can\u2019t see the flashing lights \u2013 our infrastructure is in the clouds). You walk in, and it\u2019s like a secret order: they sit in hoodies, surrounded by a pantheon of monitors, whispering commands like \u201ckubectl apply,\u201d \u201cterraform plan,\u201d and \u201cdocker-compose up.\u201d<\/p>\n<p><strong>What do they do?<\/strong><\/p>\n<ul>\n<li>\n<p><strong>Magical rituals on servers:<\/strong> Essentially, DevOps engineers make sure everything developers create doesn\u2019t just stay on their computers but works for all users. They\u2019re like wizards with wands, only their wands are command lines. They also cast protective spells to keep unwanted intruders out.<\/p>\n<\/li>\n<li>\n<p><strong>Conquering the foggy clouds:<\/strong> They do \u201clive in the clouds.\u201d But not because they\u2019re dreaming, but because they run servers and applications there.<\/p>\n<\/li>\n<li>\n<p><strong>Automation or \u201clazy but smart\u201d:<\/strong> DevOps engineers love scripts and tools that save them from repetitive manual tasks.<\/p>\n<\/li>\n<li>\n<p><strong>Containers are the new nesting dolls: <\/strong>Colleagues can put servers in containers, containers in services, and services back in containers! Docker is like Russian nesting dolls in the IT world.<\/p>\n<\/li>\n<li>\n<p><strong>Monitoring and log cuddling: <\/strong>DevOps engineers love monitoring metrics (CPU, memory, disk usage, even the mood of office cats, i.e. anything measurable).<\/p>\n<\/li>\n<li>\n<p><strong>Heroes of the invisible front:<\/strong> If everything runs smoothly, no one remembers them (because there are no problems). But when a small service goes down, everyone starts yelling: <em>&#171;Help! Where are our DevOps?!&#187;<\/em>\u2014and they\u2019re already there, front and center, hugging the logs, wrench in one hand, Python script in the other.<\/p>\n<\/li>\n<\/ul>\n<p>DevOps and Infrastructure Engineers are the backstage masters, ensuring the stability and elegance of the IT ballet. They combine the skills of <em>coder brotherhood<\/em>, 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.<\/p>\n<p>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 <em>bitter moments<\/em>. For example, one such issue for me was the incompetence of certain instructors. But let\u2019s leave that to them \u2013 luckily, there weren\u2019t too many.<\/p>\n<p>As I dove deeper into learning, I realised that without practice, I simply wouldn\u2019t survive: all this knowledge would just turn into useless dust settling on the cortex of my brain.<\/p>\n<p>A thoughtful reader might ask: <em>&#171;Why not learn on the job?&#187;<\/em> And they&#8217;d be right. But you can\u2019t just show up and say, <em>&#171;Let me fix everything for you real quick.&#187;<\/em> So, I figured it would be a good idea to develop a project where my raw, newly acquired knowledge could be used.<\/p>\n<p>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\u2019t ache (not to mention kids and their homework).<\/p>\n<p>But the goal was set, and the next step was simple: Developing a project.<\/p>\n<p>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.<\/p>\n<p>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 <em>know where the dog is buried<\/em>.) Besides that, I took on real tasks as they came in and documented their solutions.<\/p>\n<p>Things kicked into high gear: my main job continued as usual, my studies progressed, and I applied my new knowledge to the <em>pet project<\/em>. 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\u2019t work in the subjunctive mood.<\/p>\n<h3>Chapter 4: Junior DevOps. IT Operations\u00a0<\/h3>\n<p>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 \u201cDevOps engineer\u201d certification, though I feel I still have a long way to go to reach the true level of a DevOps engineer.<\/p>\n<p>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.<\/p>\n<p>A quick note: Production Support is a team of people who know the entire internal <em>kitchen<\/em>. Their transition to other teams is prioritised\u2014the company appreciates employees who grow, and the team benefits because the newcomer already understands the internal workings of services and overall operations.<\/p>\n<p>The transition happened, and I became a Junior DevOps! Goal achieved!<\/p>\n<p>A few words about<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-458083","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/458083","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=458083"}],"version-history":[{"count":0,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=\/wp\/v2\/posts\/458083\/revisions"}],"wp:attachment":[{"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=458083"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=458083"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/savepearlharbor.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=458083"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}