Escaping the sysadmin grind and becoming a DevOps Engineer

Making a start in your current role

First, be aware that anyone can start using DevOps tools and methodologies in their current role. Just because you don't have the word 'DevOps' anywhere in your job description doesn't mean you have to switch roles. Why? DevOps is a set of practices; it's not a job title. DevOps is about bridging the gap between developers and operations, and ensuring that the product you are responsible for smoothly transitions through the entire life cycle of development, build, test, deploy, and support.

'OK, fine, but I'm a Sysadmin. I'm responsible for managing core infrastructure. I'm not a developer and, besides, I'm not knowledgeable enough/I'm too busy/management would never agree to change all of our practices and procedures/[insert reason here],' you might say. And that's exactly what I thought??? ??that I would never get the chance to move into a DevOps-oriented career because I wasn't doing anything that could be considered as adhering to DevOps practices.

What I hope to show you in this article is a list of things you can start doing right now in your current role that will give you the skills and mindset needed to make real change in your career.

1. Find your sensei

Find someone who has some knowledge in any of the following:

• Linux (CentOS/RHEL, Ubuntu) and Bash
• Python
• Ruby
• Go
• or even PowerShell (more on that in a minute)

This can be a member of your team, a separate team in your organization, or even a friend or colleague outside of work. Make it your mission to sit down with them as much as you can and do paired programming together. It's all fine and well watching training videos online and reading all of the O'Reilly publications you can get your hands on; the real meat-and-potatoes of learning happens when two people sit down and work on something together.

Once you have this knowledge, you can

2. Automate, iterate, and build a portfolio

Find things you hate, and automate them into oblivion. This is where you start building your DevOps chops by seeing something through from the early stages of identifying a potential piece of work, breaking it into its component parts, developing a solution (automation!), deploying it, and finally supporting it.

Once you've automated the little (or hopefully very big) nuisance, sanitize your code and push it to GitHub. 'I don't know how to use Git yet,' you might say. Well, now is the perfect time for you to kill two birds with one stone. You'll learn Git by doing, starting with simply pushing and pulling code. Eventually you'll have a body of work that shows you know how to write code and can think creatively.

Here's an example of something I did a few years ago. I was sick of manually disabling users in AD and Exchange. This script??? ??along with a larger piece of work that slotted into our automation platform??? ??reduced a task that usually took several hours to one that was initiated by the press of a button, sent an email out to us when it was complete, and automatically notified the client that User X was kaput.

While you're at it, measure the impact your automation has had in terms of work hours reduced or support tickets prevented. This will bolster your CV or resume with evidence to show how the initiative you've taken and the code you wrote made a real impact in your organization.

And finally, don't just write a quick Python/PowerShell script to make something slightly less painful to work with. Absolutely drive your heart and soul into learning how to write things with proper logging, error handling, and reporting so you can measure how effective it is. It'll make you a better engineer and your future self will thank you for it.

3. Learn a Configuration Management Tool

If your organization is open to trialing something like Chef, Ansible or Puppet, be the one to champion that change. If your organization already uses something for managing the state of your servers/workstations (SolarWinds, Kaseya, or something else), then learn how to use Chef/Ansible/Puppet and make it configure your own workstation or a test machine. Push whatever you write up to Git, and keep refining it until you've automated every minute detail you want to configure. If you're using Chef, bonus points if you learn how to configure a Chef Server and push your cookbooks up to it!

If you want to play around with Ansible, here's something small, like configuring a Linux system:

- hosts: webServers
  remote_user: root
  tasks:
    - name: ensure packages are installed
      yum: name={{item}} state=latest
      with_items:
        - python-psycopg2
        - git
        - httpd
    - name: Add user 'jackmo' with uid 1040 and primary group 'admin'
      user:
        name: jackmo
        comment: Jack Morris
        uid: 1040
        group: admin

Since you've spent some time automating some tasks, you should be more comfortable with coding, Git, and thinking of how to solve problems via code instead of the GUI.

Once you've played around and learned how to use one of these config management tools, you can then try to bring this into your organization. At the very least, see if it's something worth considering for small, repetitive and specific tasks. If this is something your company is not up for, that's fine??? ??find small pieces of work that can be automated, write the Ansible playbooks/Chef cookbooks to automate it in your own time and push it up to your portfolio. Maybe one day they'll change their mind. If they do, all the code is already written. If they don't, you might find your code useful at another employer. Who knows!

4. Befriend the QA team

Working in the DevOps way means you will often be sat side-by-side with performance testers, security engineers, and QA analysts to resolve issues with deployments, security flaws, and run unit/soak/performance tests in an automated fashion. I would wholeheartedly recommend sitting down and learning what it is they do and what tools they use. You don't need to learn how JMeter works, for example, but it's helpful to know how your QA team uses it, and if they automate any of their testing. If they use automation, learn as much as you can about how they're doing it, what pitfalls they've encountered, and their thought process behind it all.

While this task is more of a fact-finding mission, it will expose you to (hopefully) new information and a field that's often integrated directly within a DevOps 'Team'. More importantly, this is where you practice the DevOps art of understanding how another team works. There will be many times where your work will intersect with this team, and for you to be able to effectively understand the ask is, you need to know how they operate.

5. Befriend the developers

OK, the reason this isn't #1 on the list is because you can't possibly conceptualize how an entire application is written, built, tested, packaged and deployed until you understand how to:

1. Read code
2. Write code
3. Store and version code
4. Deploy code

I could be wrong here, but I think it's best to have a good understanding of the basics before trying to understand a Jenkins pipeline that builds Maven project and deploys it to a spot EC2 instance for integration and performance testing.

Again, this is your chance to sit down and learn how another team works. This is critical: learning how another team functions??? ??and where those hand-off points are between that team and, say, QA or change management??? ??is par for the course in the DevOps world. Those hand-off points are likely where your automation tools, scripts, and pipelines play a key role. You will be expected to act as the 'glue' that holds all of it together. To do this effectively you have to understand how all of the components interact.

6. Apply for a junior role and take the plunge

OK, so I know I said DevOps isn't a role, but that doesn't stop people from posting positions on job boards with titles like 'Junior DevOps Engineer.' And that's fine??? ??so long as you know that DevOps, by definition, is not a role and that it's a set of practices, you're fine.

Apply for a Junior DevOps Engineer role that fits you. Even if the majority of your experience is in automating Windows tasks, this will serve as the bridge to your next job and shows you are willing to try new things. It will also give you exposure to more tech, grow your portfolio, and expand your professional network even further. So get out there and go for it!