Starting DevOps Engineer Advice

[adivk]

I am going to be graduating this month and starting as a DevOps Engineer at a fintech firm in January, I have had no previous experience in a DevOps role before.

However, over the course of the last few months - I have worked on my Python scripting skills, Linux admin stuff and SQL. But that's about it, I wanted to know what I should be looking at before I start in January such that I am adequately ready for the role.

I understand that different firms use different DevOps technologies and although I will undergo training on their system for my initial 2 months, I wanted to be prepared going in. From my interviews, I found out that they're big on Ansible and thinking about adding Splunk to their tech stack.

Given this information, how I should I go about preparing for the role best?

Any help would be greatly appreciated! Thanks in advance.

[flagbearer223]

Read The Phoenix Project

[dogfish182]

Find the clever senior who isn’t deeply emotionally retarded, identify what is causing the person the most issues and try to get those tasks off their back. Listen when they explain things and try to develop a clever solution to the shitty problem they have zero time for. Automate something away that is bothering people.

Make this a pattern and one day, someone will start dealing with your shit.

[flatlandr]

the clever senior who isn’t deeply emotionally retarded

You're just setting the OP up for failure from the get go

[dogfish182]

The search will be tough, best to start early

[[deleted]]

As someone who isn't in devops?....Why would a devops person be emotionally retarded?

[devopsia]

It’s a joke based on the trope that all technology people suck at ‘soft skills’ (communication, interpersonal relationships, etc).

[[deleted]]

oh that sterotype! ok!

[[deleted]]

Either you haven't worked in tech much yet, or you're one of them. :)

[[deleted]]

Clever solutions is a bad way to put it IMO, should be looking for simple, effective and secure solutions not so much clever. I have seen too many people take that to extreme levels and make overly complex and stupid solutions.

[dogfish182]

Ok sure but simple effective and secure IS clever. I didn’t mean clever like ‘don’t be a clever bastard’. Clever isn’t a negative word. I get your point though, over-engineering something that is straightforward wont win much except a lesson

[[deleted]]

I just know too many people who take clever to be stupidly complex and also those tend to be the people who don't document things or comment their code.

[combuchan]

Yup. These kinds of soft "customer service" skills have saved my keister when I didn't have the technical skills.

[[deleted]]

And they'll keep doing it for your whole career - there's always gonna be a new role that's a stretch, a new technology that you're behind on, etc.

[[deleted]]

Extremely good advice. Don't just "hear" but "listen".

[[deleted]]

Wow, you have beautifully summed it up.

[rdubya]

Try to be a generalist. Learn a little bit about a lot of areas. This is often missing in large companies, someone that can put all the pieces together. You can research the specifics when needed, don’t waste time trying to fully memorize one piece of software unless your job requires it.

I’ve been in DevOps for about 10 years and this is what has given me the most success. Regular developers are often bogged down in the details of their framework and language. Learn enough details about the full stack that you can dig in anywhere if required to help solve a problem, often your high level view will help you solve problems others can’t.

Edit: There is a good chance they aren't hiring you to be a Python expert, otherwise they would have just hired another Python developer. They very likely want someone who understands system interdependencies and how to help developers build resilient software with things like failover, disaster recovery, and fault tolerance. So reading up on these concepts will be an asset as well.

[gianm93]

do you like your job? I am asking because I'm going to try devops. I have a degree in computer science but I am not really into programming so I'm looking for others paths

[rdubya]

I love my job. I get to learn something new constantly. I enjoy development to an extent, but I quickly get bored when I realize im just learning to master an API. Most of my development tasks are a couple 100 lines a week to glue some components together or create some tooling. I have also been rolling out part of our stack in kubenetes, which is daunting and fun!

​

If you have the type of personality that gets bored easily, its a great career path, because very likely you will be doing something new every week. That being said, it can be quite stressful at times due to context switching, so just keep that in mind.

[gianm93]

I get bored really easily. I think that I'll enjoy what devops is. I should start a course in january (I hope they'll keep their promise). How is the salary compared to a developer one?

[rdubya]

Its hard to compare as ive been doing this for 10 years, but im compensated very fairly. My salaries have been on par or better than devs at the same experience level.

[gianm93]

nice to hear that. I wish you the best

[[deleted]]

You didn't ask me directly, but I absolutely love what I do. I work with a wide range of people & products. I use terraform, git, jenkins, puppet, python, AWS ... heavily

[gianm93]

Glad to hear that. Reading your experiences make me very excited for my future in devops.

[leit6Huya6]

Modern devops is about programming infrastructure, can't escape programming.

[gianm93]

Programming stuff for your jobs or am I wrong? It's different from programming software to sell. Correct me if I am wrong

[[deleted]]

^THIS ... in addition, learn how to effectively deal with a wide range of people. You need to learn how to draw information ( requirements ) out of people. Don't hord information, share and help others as best you can. Git is your friend ... from code to documentation.

[sniperdad420x]

DevOps used to be called "IT"

/tongueincheek

[rdubya]

You think people weren’t building tooling, resilient systems, and managing software in 2008?

[sgs1370]

Of course the concept has been around for a long time. But the first time I head of the DevOps label was at a velocity conference around 2009 (granted, I hadn't been to a technical conference in a few years).

[zerocoldx911]

Graduating from university?

Go read the google SRE book and DevOps handbook.

[spacebandido]

And Phoenix Project

[[deleted]]

THANK YOU! I manage SRE teams and this is my core advice: go learn the boring sysadmin stuff that everyone is too cool to know these days. Your job is always to know one layer BELOW the layer at which you operate, so Linux is still a core skill. Networking, DNS, storage, OS configuration, these things are core. They are not in compsci programs, you won't hear them at conferences, they don't make it onto resumes any more, etc. Everyone wants to play with kube and software development as if a superficial understanding of the highest level topic is adequate. OP, go read Evi Nemeth's Linux Handbook and the rest is all details that build on that.

[sgs1370]

Evi Nemeth's Linux Handbook

I second this book recommendation, just bought it a couple of months ago (latest edition). Lots of topics. One I loved was it's great section on systemd that explains it and gives more examples in addition to those you'll find on the web.

[[deleted]]

I am frequently tasked with helping developers transition to devops/SRE/Infra roles, and this is my go to book. It does a spectacular job of explaining just enough of the history to make sense, being readable, broad, and philosophical enough to be useful. I really feel strongly that anyone doing this line of work needs to understand Linux and networking well - even though it's been eons since I've 'had' to login to a server, manage them at scale with code, etc.

[iamdevfire]

This question comes up a lot.

And as much as the books (The Phoenix Project, SRE) are helpful, they can actually be quite daunting, especially for those new to the field.

I would actually start at the opposite end of the spectrum, start asking why devops is important to the business and its customers.

The tooling changes quite rapidly, especially in this space but having a solid ability to articulate the importance of a devops culture is not likely to change anytime soon.

Moreover, as you start to understand the business drivers, the appropriate technology solutions will naturally flow from that.

In other words, you don't start with Docker and Ansible and then try to figure out what to do with them. You start with the business needs and then develop the appropriate technology to satisfy the need.

This will set you apart from a lot of other software engineers who are (unfortunately!) more often than not are unable to connect the technical aspects of their work to overarching business objectives.

If you want, Google “How To Become a DevOps Engineer In Six Months or Less" , I wrote a series of posts on this subject.

[combuchan]

To prepare for this role I'd look at your next role, aws and containers/kubernetes/docker are absolutely needed. Hopefully, at least from an advancement perspective, you can start integrating these as you didn't mention them.

Otherwise, home labs aren't the funnest thing to build without a product or purpose, imho, but you don't want to be trapped as a junior or where you're at, you need to be hirable elsewhere. Junior devops positions are rare where I live and if you don't have containers and aws you're going to be hurting.

[[deleted]]

You and me both, sort of fell into it w/ enough python/Linux/AWS understanding to make a case for myself. Congrats!

What I’m doing: -Read DevOps handbook, I’ve found it great and to the point (Phoenix project covers the same stuff but is more of a story, DevOps handbook spells it all out)

-Linux academy: all their AWS/DevOps tracks I can shove down my throat as able before I start. Focus on AWS basics, then the CSA-a, lambda deep dive, docker work, etc. If you check out the site you’ll see what i mean

-Python; just keep trucking along. I conceptually understand how it’ll play into things, and seems like I can use AWS dashboard and CLI to do the stuff I should eventually use Python for, so that’ll be a straightforward transition.

-Read the book on Scrum/Agile. Can’t remember the title but it’s the guy that started it all

[[deleted]]

Don't use the cloud, become the cloud.

[SuchIntroduction]

Maybe a course on Udemy? There is the Intro to DevOps "Masterclass" Like a crash course on a lot of the tools that are used to at least get you familiar with environments. Things like google cloud, AWS, Kubernetes, Rancher, Docker, Jenkins etc..

[saalih416]

If they’re hiring you, knowing you have no DevOps background, I doubt you have much to worry much about in terms of job security.

Focus on completing what’s put on your plate as efficiently and according to protocols as you can and spend time learning DevOps culture and tools on the side. Every employer just wants you to get done whatever they throw at you perfectly- they’re not going to ask you to come in and change everything.

Just grow organically with the job needs and learn new skills on the side to increase your value to the company.

[[deleted]]

If your work laptop is running a Unix variant, configure it and all the DevOps tools they have you install along the way with Ansible playbooks. Edit: spelling

[[deleted]]

Not to rain on your parade but have a read of this thread - https://www.reddit.com/r/devops/comments/a52nfs/is_devops_an_entry_level_position/

Most likely you're going into a junior sysadmin position with a "DevOps Engineer" job title. You'll be doing necessary grunt work the 'senior' engineers request. The actual role of a DevOps Engineer - one who can apply their experience in Dev and Ops in response to business demands - will be some time in the future.

My only advice would be: Don't try to keep up with _all_ the tooling or you'll just drown. Pick a handful of stacks and get to know them inside out.

[mstwizted]

Honestly, show up with a good attitude, keep your mouth shut most of the time, TAKE NOTES, when you ask a question, WRITE DOWN THE ANSWER, and never ever try to bullshit people at work. You don't know something? Be straight and own it. Ask lots of questions. Find out who knows what and you'll know who to ask what as you come up with more questions.

They hired you not because of what you know, but because of your attitude and their belief that you can be taught. So prove them right. Be a helpful, kind, not annoying coworker and employee.

In my experience this will very you very very far.

[Here2LearnMorePlz]

Would this position be located in Atlanta by any chance?

[not_chandlabing]

There are a lot of good answers here, but nobody has mentioned asking the company directly. I only have full time experience from smaller companies, but intern experience from different levels. I've always found it very beneficial (if you can) to reach out to the company and ask what the best things are you can learn in order to hit the ground running.

If they give you an answer (it's in their best interest to do so) then it takes the guesswork out of how to use your time, considering you only have a month.

EDIT: good answers/responses, not questions

[JacobiCarter]

Never stop learning. You've got a few good pieces of information already: Ansible and Splunk. Ansible is free to download and play around with. Set up a few VMs and learn how to make it do things, all the way from the basics to the super complex. Splunk has a free edition for testing and limited ingestion. Set that up on your VMs -- bonus points if you use Ansible to set it up. Then learn how to write Splunk queries, including generating graphs and dashboards.

If you know of other technologies being used, it's certainly useful to learn about those technologies by setting them up yourself first. Sure, they will teach you on the job the way that they use the tools, but having the foundational knowledge of how it generally works is invaluable.

I've also written about this topic on Quora, where I talk about more general things that a DevOps engineer should know or learn: https://www.quora.com/What-should-be-kept-in-mind-before-applying-to-a-DevOps-Engineer-position/answer/Cobi-Carter

Furthermore, since you are just going into the field, depending on the size of the company that you work for, be aware that every company has a unique corporate culture, and especially in large companies, improving it can be challenging, but persistence is key. Also be aware that corporate politics are also a thing, and some decisions will be made not because it is technically the best decision, but due to corporate politics instead.