Evolving as a DevOps Engineer
DevOps is a relatively new aspect of IT that changes the paradigm of how we deliver technology to customers. A major part of being a DevOps engineer is problem solving — this could be in the platform, in a CICD pipeline or in the dreaded network. In order to solve these issues quickly, it needs a skilled engineer who has experience in these problems, otherwise a junior engineer will face the depths of the internet.
This blog post is part of a series that will give some advise on how to develop and refine these problem solving skills. My hope is that it will help junior engineers to level up their skill on the path to becoming a technical DevOps engineer.
The 5 Steps to Problem Solving
When you’re facing a problem, there are a few steps that we can use as a standard approach to tackle a problem. Especially as engineers, we face these problems on a daily basis. Whether it be in Kubernetes clusters or whether it be in the cloud, when provisioning infrastructure with Terraform. The approach that I take is detailed in the following steps.
1. Read the error message: I get too many people who send me error messages, where the solution is in the error message itself. Sometimes you can get a lot of good clues from the error message about. Then we can go and investigate more. For some reason engineers just don’t read the error message. Sometimes they see red text and they immediately send it off to a senior engineer to see if they can get a solution. First step, please, please read the error message.
2. Your best friend: if the solution is not in the error message then the next step is Google it. Most errors that we will come across will be something that another person has experienced already. Sometimes when we are carrying out innovative or exploratory work with a new tool it can be difficult to find a solution available on stackoverflow.com or other forums. However, in 90% cases, if you Google your error message, someone has faced that problem before and by doing so you can use the code or the solution that they have written and then tweak it a little bit so that you can actually make it work for your specific kind of circumstance.
3. Keep in mind the goal: In each of the problems that we face, we are trying to achieve something and what that means is that sometimes we get these error messages, which are so obscure, and we just have no idea where to start our investigation and Google is not telling us anything. At these times, we have to remember what we are trying to achieve. Then we might be able to Google something around that particular topic and we might be able to actually find a different way of approaching it. Sometimes we need to go back to the drawing board to understand whether our solution is the best approach to reach the goal.
4. Team assist: Internet has let us down. I can’t find anything. I know what my goal is, but I’m not sure what I can do to approach it. Let me go and seek help from my team. Now, the team understands the context of our particular project, the specific tech stack. It could be because of this, or maybe some of the team members have come across that area before as well. So it’s like, you know, we can actually solve this by doing this particular thing. Seeking team help.
5. The depth of the Internet: Get on a forum like stack overflow and ask your question. Without getting into specific details of the setup and revealing too much potentially sensitive data, ask the question, give some details. How can we make some progress with our problem? Sometimes with newer tools, it actually helps to develop a community based around that tool. It helps them because their engineers can’t tackle every problem that comes up. The engineering community can come together to help each other.
