What is DevOps? Complete Guide

When the application doesn’t work, nobody wants to hear the phrase “the problem is on your side” from colleagues. As a result, users suffer and the client is unsatisfied – and they don’t care which part of the team is responsible for the breakdown. In the past, there was a barrier between developers and IT operators(admins). It sounds paradoxical, but they had different goals, although they work on the same product. The development goal is to implement business requirements as quickly as possible and add them to a working product. Admin is responsible for so that the product works stably – and all the changes put stability at risk. So, there is a conflict between them – DevOps has appeared to solve it. DevOps culture came just to bring development and IT operations together and unite them in common responsibility for the final product.

The term “DevOps” appears to be an offshoot of Data center Operations. I’ve worked on and around operations teams for much of my career. Some teams focus on automation to manage much of the operations and deployment process, others do not. Relying instead on manual and semi-automated processes to manage the data center. How a team evolves relies on the skills of its members. Some teams will automate as much as possible, refactoring automation to catch issues when they arise. Other teams will develop minimal automation, making ongoing manual changes instead of fixing automation when it breaks. Personally, prefer to automate everything. Automation itself cab be straight forward. The hard part is the testing and validation modules to ensure that the automation works correctly. My estimate is testing and process validation can be 3/4 of the project.

First step is to automate manual processes, this improves reliability and decreases the chance of an error. However, in a large organization the automation jobs can become unwieldily. leading to mistakes where operations staff can accidentally run an incorrect process, causing unintended results. At this point, an automated process must be designed and build to manage the underling automated processes.

Then of course, Team A doesn’t realize Team B is making a change that affects Team A. This can lead to outages with Team A on-call attempting to determine why their automation, which has run flawless for months or years is now crashing in the middle of the night. Team B may be in the next room but could also be an outside source on the other side of the country. Sometimes can take days to track down the root issue.

Currently on a development team that supports Operations teams. This is great because many teammates have lived on the edge and know the challenges. I find this preferable to some DevOps teams where developers are the minority. Expected to not just write code but participate in operations as well. This can be challenging at times, if operations are seen as a priority. Know how to fix what is breaking but firefighting leaves no time to automate your way out of the unreliability.

When the finger pointing begins, let others know you are there to find a solution, not cast blame.