Let's compare the traditional software development waterfall model with the
DevOps model to understand the changes brought about by DevOps.
In the traditional division of labor mode, PD puts forward the requirements, the developer writes the code according to the requirements, and then tells SCM, SCM takes the code to package, tells QA after packaging, and informs the operation and maintenance OPS to go online after the QA test is completed, OPS goes online for deployment, and finally The entire demand is released.
Its advantages are: clear division of labor and responsibilities, quality is guaranteed, layers of restrictions, easy to control.
Its disadvantages are also obvious: communication costs and waiting costs are high, and every link has the risk of becoming a bottleneck. For example, DEV knows how to write code, but QA also needs to understand the requirements to know how to test, and OPS also needs to understand the demand maintenance line. On the stability, OPS is responsible for delivery, and it easily evolves into the role of buttocks, including daily bugs.
DevOps understood by
Alibaba Cloud experts
DevOps division of labor mode
In the DevOps division of labor model, everything has changed. It is no longer that everyone finishes their own things and hands it to the next person. In this mode of division of labor, development drives all processes through tools. For example, after writing code, tool-driven automated packaging, automated testing, automated deployment or upgrade, and monitoring are also provided; SCM, OPS, and QA are on the periphery of the tool. , To ensure that every link in the tool can work normally, the purpose of their support tool is to ensure that the DEV can use the tool to complete the human things, this is a change in decision-making, and also ensure that several modules in the tool can support the latest business Changes, when the business has updated changes, we must ensure that the tools can support development.
The benefits of the
DevOps division of labor model are obvious: it can reduce communication costs and waiting risks, reduce the time required for normal demand delivery, and DEV is responsible for delivery to avoid delivery rash.
The disadvantage of the DevOps division of labor model is also very prominent: each link has more participation roles and higher risks. It is more obvious for enterprises with more business forms. The cost of tools to support multiple business forms is very high. Human replacement is needed to ensure business release. If there are more replacements, DevOps division of labor will fail; professionalism will be reduced, and the tool can only support a fixed thing in a very precise way with precise input. If the input changes and the rules are exceeded, this link is more troublesome. The professional advancement of the tool is much slower than that of the person; the DEV has too much power and is easy to be warlordized.
Difficulties of DevOps and problems to be solved
Find a balance
DevOps exists in pursuit of maximizing engineering efficiency, but the goals of engineering efficiency and stability are contradictory in most scenarios. How can we ensure stability under the premise of improving engineering efficiency?
The traditional division of labor mode is the responsibility of the OPS team. In the DevOps division of labor mode, there is no OPS team, only the development team is responsible. When a team is responsible for two conflicting cases at the same time, what should I do? If divided into two parts, who are responsible for business KPI and stability KPI, they return to the traditional division of labor model.
Division of responsibilities
For developers, the main business is coding, and the other includes packaging, testing, and publishing are all auxiliary industries. It is a tool user, and it cannot completely do everything perfectly. In all links except coding, responsibility How to divide the division of labor, other than development, how much energy does the developer need to take up to ensure the smooth use of DEV and keep up with the company's business development?
Among them, the core is the tool. The tool bonds the two together. The tool plays the role of empowerment and bonding. The tool must also be intervenable and need human flesh. In addition, the evolution of the tool requires an operation and maintenance team and a test team. Responsible with the SCM team, the tool itself must be open enough to allow other teams to continuously optimize a link; the tool must also ensure sustainable growth and keep up with the development of the times.
Restrictions and assessment
After breaking the original balance, how to establish a new balance? It takes time to re-establish the balance. DEV’s right to speak in the project will increase, and the rights will be restricted, either internally or externally.
Every problem must find a balance point according to the actual situation of the company, find the division of responsibilities and powers, how to evaluate and restrict. Only after these three points are solved, can we survive to continue the division of labor model.
How to measure DevOps?
DevOps understood by
Alibaba Cloud experts
DevOps can be measured from four perspectives:
Engineering efficiency: How long does it take for a certain development team to receive a request, and when the requirement is delivered online. How much engineering efficiency can be improved represents the size of
DevOps to play a role;
Stability: When stability is not guaranteed, the higher the efficiency, the faster the death;
Proportion of non-R&D work: when the proportion is very large, it is not far from failure;
Business scale and operation and maintenance staff ratio: Each Google SRE also manages the business of 2000 machines.
to sum up
1. After the realization of automated operation and maintenance, many operation and maintenance personnel will face unemployment, but this is an inevitable result of the development of the times, we only need to accept it;
2. There is no best practice for DevOps. We should pay more attention to the environment and business background of some cases. DevOps itself is not a goal, but a method and a theory;
3. There is no good or bad difference between DevOps and the traditional model, only suitable or not.
