How can I help?

“How can I help?” is a common phrase often said by Dr. Max Goodwin, who was the medical director of the New Amsterdam hospital in the movie called “New Amsterdam”.

After seeing this TV series and several others like “The Good Doctor” and “Chicago Med,” I started to learn a lot about the cultural philosophies of a DevOps Engineer’s job description.

What is DevOps?

There are many definitions of DevOps, but I particularly like the definition from AWS, which is:

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.

DevOps is less about the tools and technologies used and more about the cultural philosophies revolving around how and why these are adopted by the development team and used within the company.

In this article, I would like to focus on the “cultural philosophies” component of DevOps by loosely comparing it with the Medical Field in the following section.

Patients

Patients are to Doctors as development teams (or sometimes Infrastructure) are to DevOps engineers. They can be challenging to work with. However, It’s one’s job as a DevOps engineer to keep them “alive” regardless.

Consent

Just like a Doctor needs some form of consent from the Patient before performing an invasive surgery, DevOps engineers should also seek consent from the engineering team responsible for applications using an infrastructure before making “invasive” changes to those infrastructures.

Emergency

When there is an emergency in a hospital, the goal of the Doctor in charge is to keep the Patient alive, regardless of other factors surrounding the Patient’s situation. This also applies to a DevOps engineer; when faced with an emergency — in this case, think “Critical Production application downtime” — the goal at that point is to try to restore the affected application(s); investigating the root cause should come after.

History

The Doctor learns a Patients’ medical history before new prescriptions. As a DevOps engineer, when you join a company, before tearing down all the current infrastructure in place because it doesn’t fit into the perfect architecture you have in mind, learn where they are coming from, why they made the decision that led them to where they are from a technical perspective, look into how you can start making little suggestions/changes and building on from there.

Communication

Just like a Doctor would do to a Patient, As a DevOps engineer, you have to communicate with other engineers in simple and clear terms, help them understand the situation of things, present them with all possible options, and help them choose the best option with your expertise.

You might be in a position where an engineer thinks they need to have two different Kubernetes clusters for their different environments just because they read about it in the SRE book by Google only for you to check, and they probably don’t even need a Kubernetes cluster at all, or one is just enough with the current state of things in the startup, this has to be communicated in the best possible way.

Emotions

Control your emotions as much as you can. You are dealing with both humans and machines :)

When there is an emergency (worse if you cause it), the best thing you can do to yourself while trying to put out the fire is to remain calm as you do it. This would help you think straight and prevent you from making more mistakes.

Sometimes, it helps to be vocal about what you are doing especially if you are on a call with other engineers trying to resolve the issue which could help others learn how the issue is being resolved.

Keep calm, think fast, and execute quickly. The clock is ticking.

Documentation

Hospital records are vital in treating a Patient. As a DevOps engineer, try to document everything as much as possible. Among other things, this helps you to see how things have progressed over time.

• Document incidents and how to resolve them.
• Create “How to” documents that help other engineers to use the infrastructure you manage (for example, How to connect to the VPN, How to connect to the Kubernetes cluster, How to set up… etc.).
• Provide high-level diagrams of the whole infrastructure you manage; this helps others understand what technologies are in use and how they connect to each other.
• Document new findings that can help the DevOps and other teams.
• Keep these documents as up-to-date as possible. Please put them in versions; don’t override outdated documents.

It is terrible to have no documentation; it is risky to have outdated documentation.

Conclusion

In conclusion, This does not, in a way, cover everything about the cultural philosophies of DevOps. However, DevOps engineering can get a little easier on everyone once cultural philosophies are considered as important as the tools being used to solve problems.