Critical Thinking As A Way To Success In Your DevOps Journey
In my opinion, one of the crucial skills for a DevOps engineer is critical thinking. In this article, I will explain what that means and why you need to develop it.
In order to succeed as a DevOps engineer, you must have an impressive amount of skills, both on the technical and personal sides.
You must have a solid amount of technical knowledge, be familiar with a wide range of products, and be able to learn any of them quickly.
You must be a high-level thinker and a solution-oriented person, attentive to details, and focused.
You need to be a team player with excellent communication skills.
This list can go on, and it’s never-ending. Each skill makes you better, and there are no limits.
In my opinion, one of the crucial skills for a DevOps engineer is critical thinking.
Here is the Critical Thinking definition from Wikipedia:
“Critical thinking is the analysis of available facts, evidence, observations, and arguments in order to form a judgement by the application of rational, skeptical, and unbiased analysis and evaluation”.
In other words,
- Question everything.
- Understand why before you do.
- Make judgements based on reliable information.
- Be an active listener.
Let’s look closer at these points.
- Question everything.
Let’s analyze the following real-life example:
James, the DevOps engineer on duty, gets a call from Mike, the developer who is responsible for the API application.
Mike says he released a new version to the dev environment, and now the client side cannot reach the backend service.
Mike is sure that the cause of the issue is a new version, as nothing else was changed, and he is asking James to rollback the API to the previous version.
James does what Mike is asking for. Mike checks and confirms the client side can now access the backend.
“Probably something in the code of the new version,” Mike says. “I will fix it.”
What really happened?
The operation team uses Docker Compose in a dev environment without any container orchestrator software.
There is a cronjob on the server that checks for a new version in a registry, and if it’s found, the server pulls a Docker image and restarts the container to apply it.
For some reason, an API container crashed during the version update process and did not restart because there is no restart:always definition in docker-compose.yml.
So the real situation is that nobody knows if there is an issue with the new version of API because the API container does not run at all.
Mike was sure it’s a version-related issue, as “nothing changed” from his point of view. James, as a DevOps engineer, did not ask questions and took Mike’s position as logical because “nothing changed” except the new version.
In the eyes of James, rolling back to the previous version was the easiest and fastest “solution” to bring the app to a working state instead of basic troubleshooting.
As a result, Mike will spend some time solving the issue that might not exist at all.
James, as a DevOps engineer, had to ask himself, “Is the cause of the issue really a new version?”.
“I need to verify all containers are running. If they are, I will check the logs. If nothing is in the logs, I will try to reach the API from the client, then the backend from the API, etc.”
It would take a little longer than a rollback, but in the end, it would save Mike’s time.
2. Understand why before you do.
Another real-life example:
Linda, a DevOps team leader, assigned James a task: “Please change all ubi8-micro images to Alpine in the chatbot project.”
James can spend some time to update the image in Dockerfile, build the images, test them locally, release them to dev, ask QA for integration testing, and close the task.
However, the first thing he should do is to ask questions and understand why.
Why are we using the ubi8-micro image currently?
Why do we need to replace ubi8-micro with alpine images, and what are the possible issues it can cause?
What are the pros and cons of each image in our current environment?
Maybe in the past your team had DNS issues within Kubernetes while using images based on musl, so they decided to switch to ubi8-micro?
Maybe there is another reason, and who knows how this change will impact the whole environment?
James should not be the person who blindly follows orders, he has to think critically.
Ask questions, decide, implement, and document what has been done and why it’s done.
3. Make judgements based on reliable information.
There is a lot of information on the internet. Google anything, and you will see thousands of articles.
You can ask ChatGPT anything and get the answer.
But how do you know the data you read, see, or hear is correct?
How do you know it’s up-to-date data?
How do you know the person who wrote the manual knows what he is talking about and has not just copied and pasted it from somewhere?
How do you know the answer from ChatGPT is correct?
What are reliable information sources in the DevOps world?
- Official websites. For example, https://kubernetes.io/ for Kubernetes or https://helm.sh/docs/ for Helm.
- Blogs are written by companies with a reputation, for example, https://blogs.nvidia.com/ or https://blogs.cisco.com/.
- Blogs are written by people with a reputation in the industry.
Bear in mind that even if you read an article on a reliable information source, it can have been written months or years ago and be irrelevant at the current time, so don’t forget to check if it’s up-to-date.
Always remember to question everything.
It doesn’t matter what information you consume.
Question everything until you do it yourself and verify.
4. Be an active listener.
Ask questions when you listen to someone. Your goal is to understand their message and avoid making assumptions.
Real-life example:
Imagine a website that contains a client side, an API, and a backend. Each service runs on a separate Docker container.
Product managers report to the DevOps team that the production team decided to combine client and API applications into one application, and they opened a request for the DevOps team to create a new Dockerfile and CI/CD process for that new application.
Your goal is to understand the real needs of those who are talking to you and sharing their requests.
Ask why. What are the reasons behind that need?
Maybe they want to do it because it will simplify the deployment process, but they don’t think about the security consequences, scalability challenges, or resource allocation. Explain to them the limitations and downsides.
Every technical talk should be a negotiation.
I hope that I covered my idea well enough, and I hope that you, as a DevOps engineer, will question everything.
No one is born with critical thinking.
It’s something that you develop with time.
Critical thinking, like almost everything in life, is gained and improved by doing and practicing it.
If you liked my articles, you can join my newsletter, and you will receive weekly DevOps tutorials, articles, and tips every Saturday.
As a bonus, you will receive a free step-by-step DevOps CI/CD project, which you can use in your portfolio.
Subscribe here: https://junior-devops-hub.ck.page
