Have you ever wondered how it would feel to be a software engineer, detective, personal coach and janitor all at the same time? Dennis Szczepanski kind of knows. Dennis is working as a DevOps Engineer for the Toll Product Team of DKV Mobility since February 2020. For him, in a way the DevOps-role has similarities to many aspects of the above-mentioned roles. But let’s start at the beginning. What exactly is a DevOps Engineer?

The word ‘DevOps’ (Development Operations) relates more to a general mindset than to a specific role. It was meant to describe software developers which not only consider writing code but also think about how to operate their software. How can we avoid downtimes for customers? What should happen if an error occurs? How can development processes be improved? Those are key questions in the working day of a DevOps Engineer.

As both development and operations are colossal fields with countless specializations, the definition of ‘working as a DevOps Engineer’ becomes blurry very fast. If development and operations would be two points on a line, a DevOps-Engineer might be anywhere between the two. For Newsroom, Dennis Szczepanski takes a look at the middle of this spectrum and shares with us what a day in the life of a DevOps Engineer actually looks like.

Dennis Szczepanski, DevOps Engineer for the Toll Product Team at DKV Mobility

“Hey! I’m Dennis, I’m 27, have a small daughter which is the love of my life, and generally I am a typical nerd. From books to games to technology I dig it all. But let’s talk about work.

Usually, I try to start work quite early at around 7am. I’m barely alive before I’ve had a bit of coffee,. The early start helps me to work on topics I deem important. Improving the overall state of our applications for the future, creating alerts for scenarios which were not covered previously, or optimizing the allocation of resources. Those are things I prefer to do before the rest of my team starts their work and other, more urgent topics might pop up. I’m part of the Toll Product Team in our department, which is something I really like about DKV Mobility. In many companies you still have ‘pure’ development teams. Here, we’re all responsible for our applications which makes things much easier. The developers think about the effects their software might have on the overall system, create useful metrics for business processes and proactively react to alerts. I love that!

At around 9am our team starts its daily meeting. Here we briefly talk about the achievements of the last- and the plans for the current day. Mostly, my day-to-day work either involves tasks which the team needs to reach with their current objectives or tasks which will benefit the team (or even multiple teams) in the long term.

After our meeting, most days vary immensely depending on external factors. In the simplest case, I can drive forward the needs of my team. This might range from changes on how our applications interact with our infrastructure, which consists of multiple Kubernetes-Clusters (1), up to changes which aim to improve the experience of the developers while creating their applications. For example, I’m currently working on a way to improve the creation of new applications for our team. We have several standards in our applications. So having one ‘master’ project to showcase these standards would make sense. The challenge, however, is the fact that these standards are updated regularly, so ideally it should be possible to automatically provide updates on the master project to all other projects. I already have an idea how to solve that issue.

On other days the operation of our services is in focus. When big features are released, I’m closely monitoring our environments for anomalies to see whether adjustments to our infrastructure or configurations are necessary to fulfill the demands of the customers. Often developers contact me to assist them on finding the cause of unusual behavior in their pipelines (2) or their code. This might range from small problems which are solved in a few minutes to multiple hours of detective work, digging deep into the logs and metrics of the application, data collected from tracing or even profiling, up into the running application itself. Some time ago, we had an issue which seemingly happened at random. One business process was not working in around 1% of the cases it was executed. While looking through monitoring and tracing data we were quickly able to find out that this only occurred if one specific process took around 25 seconds. Any time shorter or longer and it would work fine. The issue was a simple misconfiguration and was mitigated very quickly. Although such tasks are mostly unplanned, they are often crucial in keeping our systems running and even improving them.

Usually, I end my working day at around 4pm. I spend the afternoon with my daughter and wife. In the evening, I like to read, play games, or work on personal programming projects. As you might have noticed, each day is potentially different from any previous day, and I might be wearing different hats on the same day. From a janitor keeping everything running from the shadows to a developer hacking at stuff and then back again. In my opinion, this makes every day quite interesting and varied. I hope this little summary helps people understand my role a bit more despite its non-descriptive name.”

(1) Kubernetes - describing this correctly would go way beyond the scope of this article. Think of this as underlying application which helps us to run our applications.

(2) Pipeline - automated process to build, test and ship developed code.