Various stages of DevOps

This article is based on my speech in the Swedish devopsdays, "DevOps is a stage, not a specific state". If you are interested, you can watch my speech online, but when you read this article, you don't need to watch it beforehand.

Over the past few years, we have been constantly learning about the word devops in articles, speeches, and conversations. DevOps claims to be able to build faster feedback loops while improving overall system stability and reduce product iteration costs. DevOps's goal is impressive, but as a new concept, it cannot prove to be able to achieve the desired goal, so the related activities can easily be overlooked or withdrawn. With the development of DevOps, many companies have benefited from DevOps, and there have been a large number of organizations using DevOps. Now it's a good time for you to research and practice devops.

For laymen, it's easy to assume that using DevOps is just a simple change, more like a switch that opens the bulb. From this perspective, the implementation of such a change would be a daunting and possibly impossible task. Like traditional engineering, when trying to build something complex without breaking it down, it usually turns out to be a failure. Fortunately, DevOps can be broken down into a series of stages. The content and time of change in each phase can be completely controlled by your organization.

For ease of understanding, this is illustrated by the timeline-style chart: The left side of the horizontal axis represents the traditional method of operation, and the rightmost means devops. In this way, no one will ask "has your company implemented DevOps?" "Question, but more precise, such as" Can you talk about the depth of DevOps in your company? ”

It should be explained that the views and cases in this article are based on specific organizational structure and are not universally applicable. These assumptions are based on my personal experience-I have worked with the transport and development teams in a number of companies (the operations team is responsible for the maintenance of the development environment), and several projects have been done. If these assumptions are different from what your organization is, then the idea may not apply. The benefit, of course, is that these ideas can actually be applied to similar teams, which combine our experience with actual implementation in multiple working environments.

The scope of the DevOps

In order to better understand the stages that we have spanned in the implementation of the DevOps process, it is necessary to have a detailed discussion of what is represented on the left and right side of the timeline.

The left-most represents the culture and practice of traditional operation and maintenance.

An extreme case of traditional operation can be described as "black box operation". In this culture, operation and development are separate, generally do not cooperate with each other, even if cooperation, is also extremely reluctant. Its characteristic is that development and operation Dimension have opposite goal. The task of the development team is to add new functionality to the product, to continuously upgrade the product, and to develop performance. The goal of the operation team is to stabilize the first. If there is not enough communication, two teams will have a conflict, when developers are excited to quickly develop new features, operators can not be in the mood to deploy new features. Any type of change to a stable system can cause a system to be hidden, so the operator will avoid changes as much as possible.

For example, an application developer submits a bug in the code that leads to an infinite loop under certain boundary conditions, which neither QA nor testers find. If the operator deploys this change, some server CPUs will soar to 100%, causing service instability. If the operator does not implement the change, then the problem will not occur, at least not a new problem. This is the concept of the most left-dimensional traditional operation.

The rightmost represents the full implementation of DevOps, where development and operation dimensions are a role. At this time, development is the operation of the dimension, operation is the development of the team in the common goal is to add new features, but also to ensure a certain degree of reliability.

When you know what's on both sides of the timeline--with special emphasis on both extremes--from one extreme to the other, it seems incredible. But this incredible situation is because you think the transition is coherent. If this timeline is divided into manageable phases, it will be easier to implement DevOps, the benefits will be clearer, and the results can be expected.