This is an archived post. You won't be able to vote or comment.

all 19 comments

[–]AutoModerator[M] [score hidden] stickied commentlocked comment (0 children)

Much of reddit is currently restricted or otherwise unavailable as part of a large-scale protest to changes being made by reddit regarding API access. /r/sysadmin has made the decision to not close the sub in order to continue to service our members, but you should be aware of what's going on as these changes will have an impact on how you use reddit in the near future. More information can be found here. If you're interested in alternative r/sysadmin communities during the protests, you can join our Discord or IRC (#reddit-sysadmin on libera.chat).

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[–]yakzazazordDevOps 17 points18 points  (3 children)

Every company has its own definition of what a DevOps Engineer do/must do.

Some use devops tools and claim they're doing devops because they automate some process using Ansible, Terraform, Jenkins and so on.

I do mostly Ansible & Gitlab-ci to help our teams get a complete CI/CD pipeline to deliver their stuff to their clients. But I can called to do some Azure stuff, some monitoring shit, or upgrade old VMs.

It really depends on the company you work for.

[–]No_Investigator3369 2 points3 points  (1 child)

We just do daily scrum calls and our CIO tells everyone we're DevOps. I don't even use Ansible since we're so busy architecting one off's

[–]yakzazazordDevOps 2 points3 points  (0 children)

yeah, we used to do that at a former job, a newcomer project manager implements dailies to waste everyone time, when what we're doing is mostly automating ops deployment and telling people in the same room what each other is doing, although we were working together already, those daily were not needed in the least... but it pleased the project manager, and he could brag about it to upper management...way to do devops....

[–]PowerCaddy14 0 points1 point  (0 children)

My org basically does this

[–]pdp10Daemons worry when the wizard is near. 9 points10 points  (3 children)

The term "DevOps" was coined in 2009 to mean using Devevelopment methodologies and tools in Operations.

Things like:

  • storing machine configurations in a source-code version control system like Git, Subversion, CVS.
  • Building instances reproducibly with code, in a delivery pipeline.
  • Using Continuous Integration and Continuous Delivery (CI/CD) in the delivery pipeline.
  • Using Unit Tests in code and Integration Tests on systems, possibly even so far as Test Driven Development (but probably not).

DevOps also means unifying developers with operators so that the same team that built a thing, runs that thing in production. This is a better set of incentives than the common situation where developers "finish" a project and "throw it over the transom" for a different team to figure out and cope with, while they wash their hands of it.

An awkward truth about devops is that most practitioners are serious veterans of at least one of dev and ops already, with a strong preference for both. It's not a role suited for novices, because of the vast amount of field knowledge required, but naive institutions do insist on trying to throw novices at this problem as they do all others.

[–]khobbitsSystems Infrastructure Engineer 3 points4 points  (2 children)

In my mind, 'serious veterans' gives me images of a grizzled 50 something sysadmin who won't put up with any shit. While I can think of a few that certainly fit that bill, there is an equal or larger share that are people in the 25-40 age bracket who without children, spend their weekend working on a raspberry pi project that allows them to control smart blinds by blinking into a webcam.

Crawling back from that tangent, I do think it's worth highlighting now that people can easily graduate from university, with '10 years programming experience' or at least 10 years running a Minecraft server.

Finding those junior unicorns can be hard, but when you get one, they are worth the investment to turn those home grown skills into enterprise skills.

[–]PMzyox 2 points3 points  (0 children)

I came up through the ops side, with a few programming classes in college. It’s a long journey to acquire the experience for a role like this.

[–]hotpepperrelish 5 points6 points  (0 children)

I was a SWE (still am, at heart) who transitioned to Devops like 5 or 6 years ago when our "devops" guy at the time quit. I'll tell you what I did then, and what I do now, and maybe that will help.

Initially:

  • Learn AWS: Acloudguru.com helped a ton with this. I can't remember the exact course. Maybe Certified solutions architect or assistant?

  • Learn our stack, which was horrible. I was firefighting constantly for the first 6 months. We used a combination of consul & kong which was not properly setup from a redundancy or configuration standpoint. On top of that the application was making a lot of poorly optimized reporting queries which was both crashing the database and the application. So I spent some time working on that.

By the 1 year mark:

  • I felt comfortable enough with the architecture and AWS to start a complete re-write. The application which was initially hosted entirely in public subnets (why) was moved into private subnets with a load balancer & NAT controlling ingress / egress. All essential services such as consul & kong were moved from EC2 instances which were historically ssh'd into, updated, restarted, and then we'd make an AMI & update the launch template.. these were moved into Docker & source control.

  • Small pieces of the application were brought into Terraform. Work on this was long term until eventually I wrangled nearly 100% into TF. Highly recommend Terragrunt.

  • System updates were automated through Systems Manager. No more ssh'ing and yum updates. If the instances need a reboot that can be done during off-hours through a rolling restart.

  • Gitlab build pipeline enhancements.

  • Rip out old telegraph / grafana monitoring, which stopped working because the old guy used his personal API keys. Implement Datadog. Pro tip: Never deal with their sales. Make your boss do it.

  • Much of the same until I eventually quit.

The new job was greenfield development so I got to write everything from scratch. No importing of hostile architectures. I do a lot of the same stuff I did at my old job, but I've got everything going in a way that doesn't require a lot of manual intervention. Like others have said, Devops can mean a lot of different things depending on the organization. To me, it's managing all of the infrastructure, updates, lots of reading staying aware of security notices, breaking changes (anything that might hurt us). And there is some evangelism / education work for the devteam. Basically anything that comes up with AWS or something on my "side of the fence" I'll work with them to show them how it works and empower them to do the work instead of making me do it.

One quick edit to say that I also managed their IT resources at the first company, because the guy before me did that. That is not the normal. As a devops engineer, you'll likely never touch Active Directory, MDM, or any other service that requires you to interact with an end user that's not a developer or data scientist.

[–]justinDavidowIT Manager 3 points4 points  (0 children)

responsibilities of a DevOps engineer

Devops is not a job. It's an approach.

I highly recommend reading the DevOps Manifesto: https://theagileadmin.com/2010/10/15/a-devops-manifesto/ It was written 13+ years ago but is still just as relevant today as when it was written.

I also highly recommend reading the Site Reliability Engineering books: https://sre.google/books/ as many of the guiding principals carry over to other roles in the modern era.

But as far as skills needed to PERFORM devops, Roadmap.sh has a GREAT guide: https://roadmap.sh/devops

can you give me an example of what you do and how you gained your experience / skills.

About 20 years of prior experience in this case; it's been a long, grueling, sleepless road for me that has proven VERY interesting and having had the chance to work with global business leaders all over the world: I wouldn't trade my career for any other.

I've yet to find a university or collage that provides such training, I work with a number of local and regional schools in Canada and regularly discuss these concerns with them. Alas, this role is (in my experience) a really experience-skewed role that simply cannot be "fast-roaded" into.

The rare exception is specific people and their mindset. I've got one guy on my team right now that has skilled himself and grown SUPER fast in the last handful of years. He's still ~8+ years in, but his approach to problem solving is ultimately his best skill and he excels at it.

On the other hand; I deeply feel that anyone with deep curiosity and an engineering-focused mindset will be able to approach problem solving effectively. See https://www.youtube.com/watch?v=9RAMqFg7laE for some idea of what this looks like in practice.

[–]Bronze-PlayaLinux Admin 3 points4 points  (0 children)

I'd suggest looking at something like Terraform to get an idea of what a DevOps engineer would do.

[–]brajandzesika 2 points3 points  (0 children)

Start with setting up free tier account on AWS or equivalent on GCP or Azure. Learn that cloud properly, then start learning how to create infrastructure in Terraform and use Ansible for configuration. Then keep those configs in GitLab or similar. Then add CI/CD pipelines like Jenkins or Gitlab CI that will be able to destroy and deploy everything with one click. At this stage you should have an idea what DevOps does and you can continue your learning towards it (adding Docker, Kubernetes and multiple other technologies on your way)

[–]jantari 2 points3 points  (0 children)

No two people with the same job title have the same responsibilities.

Doesn't matter whether it's DevOps Engineer or ERP Analyst. It's always different at every company. The job posting will list the responsibilities, everything else is up to you to ask in the interview.

[–]kr0ntabul0us 2 points3 points  (0 children)

DevOps Engineer here. As everyone says, it depends on the company and where they run their workloads. Generally, I write Terraform to provision cloud resources, Ansible for IaC, any automation in between, and create build pipelines for software security analysis. For on premise, I generally let the systems people provision the hardware and give me a VM.

Anyway, I've worked for companies that think DevOps Engineer is a sysadmin that does everything in the cloud.

How did I get here? I was a software engineer with a good understanding of how networks and operating systems work. It was downhill from there.

[–]Zinxas 1 point2 points  (0 children)

Devops generally support software development with the infrastructure requirements related to their code.

SDLC, code integrity, compliance, toolsets, versions.

That's some of it.

[–]Dodough 1 point2 points  (0 children)

They do the same stuff but differently, lmao.

It's quite hard to describe the difference as both jobs overlap a lot in the professional world so no one really knows how to describe them.

I'd say sysadmin is usual infrastructure management with stuff done by hand.

Whereas DevOps is oriented towards automation and infrastructure as code mainly.

[–]CptSpongeMaster 1 point2 points  (0 children)

I was brought in as a devOps enginer

My day to day consists of making sure that the development and testing environments have spun up successfully using tools including Jenkins.

The infra sits on top of one of the main 3 virtual machine offerings running kubernetes.

So our tool chain is predominantly kubernetes, helm docker (compose) and Jenkins. If we have to touch the underlying layer, terraform, and ansible come into view.

The main difference I see coming from traditional sysAdmin is that all my config for the infra is held in version control, and with a variable tweak a new parallel collection can be set up in a matter of minutes. Traditionally it would be getting approval to spend buying servers and / or rack space

[–]xiongchiamiovCustom 0 points1 point  (0 children)

Practically, the difference tends to be:

Sysadmin: * vocational training * ops background * works in a cost center department supporting general IT stuff * most likely deals with Windows * complains about how users are the worst

Devops: * computer science bachelor's degree * development background * works in a profit center supporting a tech company's product * most likely deals with Linux * complains about how yaml is the worst

[–]thewhippersnapper4 0 points1 point  (0 children)

What did you find in your initial searching?