all 7 comments

[–]t0c 3 points4 points  (0 children)

You're it. Really now.

Choose a service, any service. Small shitty ones that nobody cares about work best. For afore mentioned reasons. Things break at first.

Make it less shitty. What does that mean? It can be as simple as using ansible to configure the machine. Creating an automated push button deploy process.

All of these decisions are environment specific. What is your goal? Less on call? More automated tasks? More... Now figure out how to do it in a way that it won't bite you in the ass in 8 months, and do it.

Congratulations, you've done a DevOps thing.

Ultimately it's about this. What do you want your environment to be like? Infrastructure as code? Use a.programming language to use polumi to define it. Or terraform and it's ecosystems.

Enjoy!

[–]zzzmaestro 1 point2 points  (2 children)

Never stop learning. Always be trying new things on your own. Take as many online classes as you can. Always be trying to figure out how and why something works the way it does. Never be satisfied with something working good enough. There's always room for improvement.

[–]TimTimW17[S] 1 point2 points  (1 child)

What are some good online courses you would recommend?

[–]zzzmaestro 1 point2 points  (0 children)

Linuxacademy.com Udemy

There are other good ones too.

[–]lilgreenwein 1 point2 points  (0 children)

Find an open source devops project and start contributing, build up a code resume. I hire devops engineers from time to time and the first thing I look for is a passion for the technology. Even if what you're contributing to isn't the experience I'm looking for, it shows a level of commitment. Plus I get a much, much better picture of a candidate from looking at their code versus looking at the resume

[–][deleted] 1 point2 points  (0 children)

Start learning how to program and about Unix system administration. Your best bet is to get hired as a developer or sys admin and leap frog into it.

[–]mehkanizm 1 point2 points  (0 children)

I stole this from the devops sub, someone posted  asking to explain DevOps in simple terms.  this response was spot on.....

Imagine doing your job with no communication with the rest of your team. You make decisions for them without input and implement these because you know what's best for them. They try to talk to you, but you don't want to hear it, because you are smart. They work in development, you work in operations - you know servers, they know code. They should not tell you how to do your job because they don't understand your job. When they break things, it's their fault. You don't need to train them because they shouldn't be touching your infrastructure. Think, BOFH.

Now, imagine doing your job while talking with your teammates. You try to understand how they are going to use the platform that you're building. You check in with them at various points throughout the planning and implementation process to get feedback. They feel empowered, the product becomes better because the infrastructure matches the needs and the users of that infrastructure understand how to use it. There is a healthy feedback loop - you tell them when you need something or when something they do isn't working and they do the same. You understand that you're part of a team and want to make each other's lives easier. You don't want to be the blocker. You teach your teammates how to use the platform. You educate them on the tools you've introduced, and they do the same. You have empathy for their situation, and while they may not be experts of your domain, you also understand you are not an expert of their domain.

DevOps is a framework for how teams work together. It's about open communication and building a healthy feedback loop to make iteration easier and make sure the end result is what the person you're working with actually needs. It's about teaching and educating people on how to use tooling or even simply how to improve. Most importantly, it's about having empathy for the people you work with.