Ask HN: DevOps Engineers, What Do You Do at Work? | Hacker News Reader

Ask HN: DevOps Engineers, What Do You Do at Work?

15 pointsSmaointe6 comments

Inspired by:

https://news.ycombinator.com/item?id=40610794

There are two main things I do. The first is to make sure everything runs as expected, with no faults, no security risks, deployments are successful, etc.

The second (and personally more important) thing I do is try to remove as much friction from the dev's experience as possible. I go and chat with the devs, find out what parts annoy them, where they get stuck, and what level of control they want to have. Then I go away and try and resolve those issues.

For me, DevOps is more about Dev than Ops. I started as a dev, and nothing kills productivity for me more than waiting for the pipeline, not being able to find where logs are being sent, not being able to get access to the Kube cluster and so on. So I do what I can to make the devs happy, happy devs generally equals better outcomes.

I wear the DevOps hat a bit with SRE. Typically I look for things that take a lot of time and refine/automate. Rinse and repeat.

I specifically go for things that seem guarded. Stuff people do that seems to be job security. Exists 'only' to keep them employed.

Not with any animosity, mind you. There are usually tendrils to that kind of stuff. It's usually important work but perhaps the specifics need updating.

For instance: while "Bob" does the same he always does, there may be a group of new people wondering why it existed this way. He may just need help getting out from under it.

Perhaps the work can be saved instead of repeated, the new folks can take it on, or they obsolete it entirely. Processes are funny like that.

This spills into meetings a lot. Convincing people to do the obviously good thing, defending reason, etc. It's not just writing Ansible/Python (our tools of choice) as much as I'd prefer that.

Overall the goal is to be a force multiplier without rustling too many feathers

One thing though is that some people might want to do some shadow DevOps for fun. I'd definitely be angry if someone takes away a chance to write some automation code from me because they want to centralize everything. Part of the reason I left one of my previous companies.

My recommendation, if that happens, is to give best practices to that person and make sure he rewrites the code properly.

Good point! I try to avoid making anyone feel like I'm stealing the show, or even criticizing. Given the position of the thing, I can usually make a case for how improving it would be good for everyone.

I don't start actual work until everyone involved is aware/agrees - lest my actions be for naught. Maybe I'm missing important context. Checking in, amicably, is important.

We can do this stuff in the shadows, that's fine. I just want the day to be better for everyone.

I'm technically DevSecOps. It honestly feels like any other software dev role in the cloud. Our org is big enough that there are enterprise templates for the various AWS services. So we end up doing very little Ops work, just some tweaking and troubleshooting. I manage the paperwork for security vulnerabilities that get discovered on our team. Really nothing fancy.

Most of them just are constantly updating jira tickets and making pipelines slower.

Reply on news.ycombinator.com