From zero to one, aliyun’s senior experts call it DevOps

DevOps is an engineering model, essentially a division of labor. Through the division of responsibilities of development, operation and maintenance, testing, and management, maximize engineering efficiency and meet business requirements.

The core of DevOps is the division of roles, not organizational change. Vertical organizational structure does not represent the division of labor required by DevOps, nor does horizontal organizational structure represent the traditional division of labor.

Advantages: clear division of labor and responsibility, quality assurance. Layer upon layer, easy to control.

Disadvantages: Communication costs and waiting costs are too high, and each link has the risk of becoming a bottleneck. OPS is responsible for delivery, and it’s easy to evolve into a “wipe the ass” role.

Advantages: reduced communication cost and waiting risk, reduced time required for normal requirements delivery, DEV is responsible for delivery, avoiding delivery wraparound.

Disadvantages: There are many roles involved in each link, which leads to higher risks and lower professionalism. DEV has too much power and is easily warlordised.

The goals of engineering efficiency and stability are contrary to each other in most scenarios. How to ensure stability without problems on the premise of improving engineering efficiency?

In all links except Coding, how should responsibilities and division of labor be divided so as to ensure smooth use of DEV and keep up with the business development of the company?

After breaking the old balance, how can a new balance be established? DEV has a bigger say in the project, and his power is bound to be restricted, either internally or externally.

Engineering efficiency is the biggest goal of DevOps, and it exists for that purpose. I write this code from the beginning of development until the requirement is delivered to the market and users, which is the goal of DevOps.

Stability is Paramount. If the stability is not up to par, nothing else matters.

The percentage of non-R&D effort is the amount of non-coding effort that a DEV team spends on things. The less non-R&D the better.

The higher the proportion of business scale and operation personnel, the better. Take Google for example, we believe that the degree of DevOps in Google is already very high. As far as I know, the number of Devices in Google is about 1 ~2 million, and the number of operation and maintenance personnel is about 1000, that is to say, each SRE can manage about 2000 units of business.

I think DevOps is, until now, just a methodology that suggests a division of labor that, in theory, could make r&d more efficient.

Also, don’t trust best practices, because every environment is different. DevOps is a management decision, and once the decision is made, we need to think about how the theory fits into the business. Learn from the best practice methodology and how it handles conflicts, but never copy them.

That’s all for today’s sharing, thank you!