12 DevOps Anti Patterns that need urgent destruction

So if you find yourself on this blog post, you probably want to enhance the workflow operations and services. Perhaps, you want to speed up the delivery process or achieve the maximum stability and zero-downtime deployments. In any case, you want to follow DevOps principles. Here is a list of common traps on your way. Forewarned, forearmed.

This problem seems to be familiar for almost all companies of any size, though for the IT segment it is a crucial blunder. It's commonplace when team members don't fully understand what part of the system unit they are responsible for.

For example, some team members may interfere with the work of others or make decisions not compatible with the general workflow or technologies. Simplest example сan be a platform with microservices architecture.

The mistake almost everyone is doing when going into microservices is that several teams responsible for several microservices, but they don't interact with each other a lot.

Yes, I understand your concern, that parts of the microservice architecture shouldn't be dependent on each other, but this independency comes from active internal communication between teams and understanding levels of responsibility and ways to ensure that independency.

In this case, a goodDevOps team patternwould be like:

• team members work according to the plan and overall strategy;
• the communication chain is properly set up and each team member knows to whom he or she can refer with the questions.
• only a CTO or other Lead-level person can make the final decisions; Why is this needed - if you are not a giant with perfect IT infrastructure like Netflix or Amazon you most likely don't have that robust processes that allow developers to publish changes into the production several times per day. So you must have someone who will be responsible for overall architecture.

Constant manual undocumented changes in the infrastructure configurations wouldn't bring any fruits. It's a typical case when the team members may be replaced (swapped or new hires), so a new-comer wouldn't bring the things together.

The documentation must be in a good state with detailed descriptions of what was configured/deployed, when it was done, why this or that decisions were made. Having good documentation overall - allows teams to reduce amount of technical debt.

For sure DevOps and automation come together and they complement each other. But don't dive deep into the automation unless you understand manual processes your team is doing day by day. If you don't understand how to do manual steps properly, it is very bad idea to start using Ansibe, Terraform or any other Infrastructure as Code tool. Definitely - when IaC is implemented you will benefit a lot from it, but the problem that you need to step back at first, and make sure you understand all the processes inside the team/company, so you are sure on what you will be automating and what challenges you will be dealing with.

What is most important to keep in mind is 3 key principles of DevOps: Flow, Feedback and Continuous experimentation and learning.

• By flow we mean optimization of business and dev processes in general and understanding the overall flow of how work is being done.
• Feedback principle means that we understand and respond to needs of our customers and understand how we can shorten/speed up so called `feedback loops` to make sure we can quickly change whatever we need in the very early stage. This is the main principle where most companies stop implementing DevOps.
• 3rd principle and the hardest one is Continuous experimentation, because you need to dedicate time for new experiments, you need to try reward teams for taking risks, and so on.

Learn more about these principles in Gene Kim's book "The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win".

"I talked with my friend and he told me to use Kubernetes, it will boost our productivity!" or "oh! everybody is talking about this X tool and I want to implement it on Friday" - seems familiar, yeah?

Rational decision making is a key concept in the DevOps deployment patterns. In this case, rationalism should always take place for solving the problems of all levels. Surely, you have to take into consideration modern practices and tools and implement them whenever the need arises. But think first of all - "do I really need this?". This will save time and money on refactoring and eliminates the need for inventing the "bicycle"?

• Blaming culture 

Blaming or punishing when mistakes are made is apriori a disastrous approach. This culture of pointing out a guilty person produces hostility among the coworkers and they will be focused more on shifting the blame away from themselves rather than on doing their jobs well. Another problem in this approach is the opinion that human beings can't make a mistake, especially if it is a senior specialist.

Moreover, search for "black sheep in the family" will lead to Anti-pattern #4: the individuals will be concentrated only on their piece of job, without dipping into the business. What, in its turn, will consequently lead to building silos between teams.

• Walls between teams 

Same old silos, meaning the acquired mentality when team members don't want or can't share information, their knowledge. Role segregation and blameful culture are a consequence of the silos, which, in its turn, lead to decrease in efficiency.
For instance, an average siloed climate within the teams: they use absolutely incompatible tools to complete similar tasks, the team members don't have a straight access to the decision makers or those possessing the needed information. Thus, the lack of information leads to endless downtimes and technical debt.

To avoid this, each DevOps adoption pattern begins with breaking the silos and establishment of the normal communication between ALL teams, not only between Devs and Ops. That's why, when hiring the companies providing DevOps as a Service, it's worthwhile to begin with business processes analysis and estimation of how teams communicate between each other.

In this article we uncovered the question "what are the anti patterns of DevOps culture?" and provided the most common examples of these anti patterns and how to avoid them.
Indeed, effective DevOps as a cultural process within the organization stands on 4 core pillars:

• Proper collaboration between ALL teams. 
• Building interteam relationships and defining overall goals. 
• Successful tools choices. 
• Gradual scaling and changeability.

Taken all these 4 main pillars together, you will be able to solve difficult cultural, operational, and technical problems that may explicitly influence application development process.