Retraining in DevOps - what to prepare yourself for

    In this article, Alexandra Romanenko, who collaborates with EPAM as a Lead Software Engineer, shares her views on retraining and talks about what to look for if you want to become a DevOps specialist.

    image
    Photo Source: pexels.com

    My story


    I came across the DevOps specialty when I was still a developer while working on a project using serverless technologies. In classic Java projects, the roles of tester, developer, and DevOps are clearly delineated, and serverless systems are fundamentally different. This new, interesting topic “fueled” my professional curiosity, I began to delve into the project, study it, not limited only to my area of ​​work. Then I began to prepare reports on the topic of serverless Amazon services and speak with them on DevOps meetings. In my current position, I was ideally suited for skills, and there was a reorientation.

    Where do DevOps specialists come from?


    My experience shows that in DevOps, as a rule, they come from system administrators and, less often, developers. In order to be a reliable “bridge” between the development process and operational activities, you need to have knowledge in both areas. In practice, this is extremely rare, because in the process, colleagues have to share experiences. For example, I lacked knowledge in the field of system engineering. I did not study the necessary disciplines at the university and did not encounter them in practice. Filling in the gaps helped colleagues with experience in network administration, with whom I, in turn, shared my knowledge. In a good team, symbiosis and mutual assistance always reigns, otherwise - no way.

    In my opinion, it is easier for specialists with a developer background to get comfortable with DevOps for two reasons:

    1. They are more aware of requests from development and testing teams, they "speak the same language ."
    2. Programmers are used to structural complexity . They develop dexterity in working with large amounts of data, thousands of files and folders. Any project, in any programming language, is more complicated than the code that DevOps deals with, therefore, as they say, they are not used to it. But colleagues without development skills have a little more complicated.

    True, there is another side to the coin. If, for example, one of the tools that DevOps needs is not working properly, fellow sysadmins can only loudly express their displeasure. At the same time, as a developer, I am adding work to myself: I am looking for an error in the code and even trying to fix the bug. But this is only possible if the instrument is written in a language that I speak, if not, then there will be bitter disappointment. One of my reports is called “Why I Hate Terraform”: initially because it often breaks due to bugs. But the fact that it is written in GO, which I don’t own and therefore cannot fix bugs, does not help either

    Sources of knowledge


    I am in favor of not following others blindly, but of making my way. Therefore, I advise you to use the opportunities that are at hand and develop at a pace that is comfortable for you.

    1. Start with your project. Surely there is a DevOps specialist on your project. Analyze what he does, what skills he uses. If you have questions, ask directly. Your task is to become DevOps on your project. It is always easier to retrain in a familiar environment than to come to a new job in a different role. You know the tasks of your project, you know the team, comfortable conditions. It will be easier to adapt to the unfamiliarity of new skills.
    2. Face-to-face meetings, lectures, mitaps. If your project does not have a DevOps specialist, professional events are a great solution. At such conferences and meetings, you have access to practice. Developers can ask questions and seek advice. And the topics of reports will tell you what is now relevant in this profession.
    3. Work with official documentation. I am not a fan of online courses and video tutorials. All necessary information is contained in the official documentation. Often people encounter a problem, google the solution, copy and paste the code or script from the most “polused” answer on the forum. Globally, this does not solve the problem. A person still does not understand how what works or why it still does not work. Moreover, you can look for a solution, and create even more problems.

    My friend bought a macbook. Something went wrong with him, she decided to “ask” the Internet for a way out. On one of the forums I found the most “plausible” answer and decided to use it. As she later found out, lovers of sarcasm voted for this comment. In the response on the forum it was written: "Run" sudo rm -rf "on the command line." As a result, in one fell swoop, she took down everything on a new computer. If she checked what the task of this code was before using it, the problems could have been avoided.

    It is better to spend 3 hours to understand how a code or script works, than 5 minutes to copy someone else's answer on the Internet and 3 days to disassemble why something has broken.

    Key Features of DevOps


    • Perseverance. You need to be prepared for the fact that much will not work, not only the first time, but also the second, or even the third. But you cannot quit what you started halfway. Therefore, people who are painstaking, hard work is not suitable for the character, it will be very difficult.
    • Attention to detail. Inattentive DevOps is like an elephant in a china shop. One careless action will entail significant damage. You can inflict huge losses on companies by accidentally clicking on the wrong button.

    • Analytical Thinking: Some DevOps think they are on the path of least resistance, trying to find ready-made examples and apply them in their project instead of studying technical documentation. In fact, they develop a bad habit and drive themselves into a dead end. Well, if the found example works, but if not, then the person loses time on the next search. Remember the quote from the cartoon “Wings, legs and tails”: “It is better to spend a day, but then fly in 5 minutes”? I advise you to read the documentation, which clearly describes the principle of operation of a tool. It allows you to initially properly organize and start the process. Take an example from good developers: they study a question, analyze, think, and then write.
    • Multitasking . DevOps specialists have to combine support and development work. On the one hand, I constantly help the team in terms of support. Something breaks, does not work, something is missing, something needs to be changed, added, explained. At the same time, there is a constant background activity on programming. Of course, development is always easier when no one pulls at least a couple of hours. Being a DevOps, I had to come to terms with the fact that someone needs my help all the time. You need to get used to doing several tasks in parallel, quickly switching and adapting.

    You will automatically develop these skills. Engage them every day. The main thing is to be prepared and know what awaits you.

    My approach to retraining


    A precondition for a change in specialization is interest. It is he who encourages the study of related areas. For professional development, it is extremely important to study not only your profile topics in which you already have experience, but also get acquainted with completely new directions for you, if they inspire. Perhaps one of them will determine the vector of further career development.

    You have to try different things. "The craziness of doing the same thing, hoping to get different results" - I really like this expression.

    Professionals who want to be “on the crest of a wave”, work with advanced technologies, earn more money, cannot stop for a second. It is important for them to monitor trends daily, be interested in new company projects, and monitor current trends.
    But personally, I have a more romantic approach to professional implementation: I like to enjoy my favorite work calmly, to hone my skills, if you want to “go with the flow,” and to force myself to reorient myself to something new only because it is popular, not my style.

    Also popular now: