What does a typical day look like for a DevOps engineer?

Quick answer: a typical day mixes monitoring dashboards and alerts, reviewing and approving pipeline/infrastructure changes, pairing with developers on deployment or automation problems, and a smaller share of hands-on scripting or infrastructure-as-code work — less "firefighting all day" than people expect once monitoring, automation, and CI/CD are properly in place.

Hi, I'm Neil, a DevOps engineer, an SRE, a platform engineer — but what the heck do I do all day? In this video you'll find out.

Morning checks

How do I start the day? Coffee, obviously. I then walk into my office — a lot of my colleagues work from home, and some walk into an office if they're close enough, maybe one or two days a week. I'm not obligated to either, but it gives me a chance to stretch my legs, otherwise I'd sit down all day and just drink coffee.

I get in, and the first thing I need to do is look at the dashboards — check to see if all the infrastructure is ticking along nicely. Is Jenkins running, has it rebooted over the weekend, do I need to do anything to it, are the agents running, are they registered correctly, are they processing jobs, is anything running particularly hot? I jump into a dashboard that shows me CPU usage, and check if anything's bouncing off the ceiling. Some things I've got alerts set up for already, like how much database space we've got, whether we're running low. Those kinds of things all get checked in the morning, and take me about an hour or so. Once everything's tickety-boo, I either raise a ticket for something that's gone wrong, if it's not urgent, or fix it there and then, in which case we have runbooks already written so we know exactly what to do.

Standup and pairing

Next comes standup — this is where I confer with the team about what I intend to do today and what I did yesterday, and hear from them about the same, so we all know what each other's doing and don't have any conflicts during the day. If we do have conflicts, maybe it's an opportunity to work together. On larger teams I've been on, I often pair — this means I work alongside somebody else, either with the same skill set as me, or a different one — maybe they're a tester if we're writing tests, a programmer if we're creating programming guidelines, or from the logging team if I'm setting up alerts.

The work itself

Once standup's done, we move on to actual work. We look at the kanban board and what we just discussed about what we're going to do — this might be a range of things. We might have to upgrade some stuff — that happens quite often, say Artifactory drops a new version, so we have to upgrade it, come up with a plan, and write a runbook if we don't have one already, then do it in test, ready to go live the following day.

Or maybe we're adding new functionality — I've been part of a team putting together an API for build and deploy that takes inputs and events from all sorts of things, the simplest being a GitHub webhook: something changes on GitHub, it sends a request through to the API, the API analyzes it and does something with it — it might build and test because it's a PR check, or build and publish an artifact because somebody merged a PR. Then we might need a new feature in that API — for instance, checking that other dependencies need updating. We've added a new tool into the pipeline that now does an additional check: are you running up-to-date software, are your dependencies up to date. There are always little improvements that make everyone's life easier.

Afternoon and evening

Moving on to the afternoon, there's probably some more programming — I love programming, I love automating things, and automation to me is the heart of DevOps, SRE, and platform engineering. I'm providing tools and functionality so the developers and other people on my team have an easier life — what's the one thing I can do today to make tomorrow easier and better for everybody else, including myself?

Then in the evening it's time to catch up — research new tools that are available, read the newsletters, maybe learn something, or on some occasions present at a meetup, virtually like this or in person (those are starting to come back now — I had an in-person meetup last week, very exciting). I also run a Q&A session every Wednesday.

In summary

So there you have it, what a day looks like for me — I start the morning with checks to make sure everything's running fine, then attend standup to catch up on what everyone achieved yesterday and what we hope to achieve today. Then I get on with work, usually scripting — could be Terraform, could be APIs, could be Python, could be Go — expanding features or fixing bugs in the tools we run. In the evening, connecting with the community, answering your questions, asking questions of my mentors and peers, gathering knowledge, and generally making myself more useful to everybody else. That's why I'm here — I want to be more useful to you.

Got any questions about SRE, DevOps, or platform engineering? Come along every Wednesday — I run a free Q&A, link at tech-answers.club — and I'll do my utmost to serve you and answer your questions.

I'd like to finish with a joke: a developer and a system administrator walk into a bar. The barman says, "what is this, some kind of DevOps joke?" and they reply in unison, "it's not a joke, it's a collaborative deployment" — then proceed to spend the next hour arguing about who's going to write the infrastructure code. Okay, maybe not that funny, but jokes and humour are what get me through the day. Until next time, I'll see you on the next Q&A session, every Wednesday over at tech-answers.club.