1, the process out of responsibility is meaningless
Software architecture and organizational structure to match, not only in the functional boundaries, but also in the division of responsibilities.
Clear boundaries of responsibility, in order to build a good team collaboration and development. Each team and each person should understand their own goals, what things should be undertaken and what things should be avoided, and devote their time and energy to things that are gainful to the main goal, not to get stuck in trivialities. In this way, the members in the team will not be so tired and have the possibility to sink some domain knowledge and think deeply.
Clear boundaries of responsibility are difficult. It is not a management problem, but an implementation problem. A process may involve a lot of people, but these people are not necessarily at the same level of business in their respective areas. Usually, we can see clear boundaries in large companies, and a very important point is that they recruit a group of bull people. In small and medium-sized companies, on the other hand, the percentage of bull people is very small, and once there is a shortage in a certain area, others are needed to supplement. This destroys the boundaries of responsibilities and leads to a state of no process.
The destruction of responsibility boundaries will make the team always in a state of fire-fighting. Every time something goes wrong, people on the team don’t focus on their own areas of responsibility and rely on a handful of firefighters to put out the fire. Because these firefighters are well versed in the entire process and handle problems quickly and well, the more they are used, the better they become. But this is not a sustainable approach. As the business grows, there will be more and more problems, but can the firefighters also grow in the same proportion? Whether we still need different proportions of firefighters at different business stages is a question that deserves continued thought.
The following discussion focuses on the two types of collaborative processes for DevOps and SRE.
2, DevOps to the right
In the figure below, DevOps is to the right in terms of workflow.
In the pipeline, developers complete requirements management, coding, compilation and deployment in sequence with the help of the platform. Here the whole process is simplified and no classic loop is formed.
DevOps emphasizes end-to-end value delivery, with one end referring to requirements and the other end referring to users. A complete DevOps iteration is considered from requirements to delivery to users.
DevOps does not emphasize metrics and management of delivered value, which is a significant difference from SRE.
While delivery is self-service by R&D, it is supported by operations and operations developers. Ops developers mainly provide automation capabilities to lower the threshold of delivery and improve the efficiency of delivery. And the O&M developers are mainly in the form of experts, providing guidance on the domain and designing the whole process.
3, SRE to the left
As shown in the figure below, the SRE is to the left from the workflow.
If DevOps works like KPI, then SRE works more like OKR. DevOps starts with requirements, makes a good plan, progresses steadily, and delivers to users one process at a time. But SRE is different. SRE starts with a goal and then considers what efforts should be made and where to start to reach the goal.
There is also an argument that SRE is a best practice for DevOps. I think this is just a conceptual generalization because there is so much overlap in who they are discussing. Rapidly evolving concepts are always subject to various interpretations and extensions. But here, we can clearly see one difference between DevOps and SRE in terms of workflows.
Let’s take a look at the SRE workflow. The first is the development of SLI core metrics by the Ops or domain personnel. The purpose of metrics is to be measurable. Only when business metrics can be measured can business metrics be managed. Next, the SLO targets are set based on the manager’s OKR and how many should be achieved. Then, the R&D staff works with the SLO targets to improve the business.
After the SRE workflow, the DevOps pipeline needs to be walked once more before the release can go live.
4, Summary
In this article, we have discussed the importance of segregation of duties to the process and the two workflows of DevOps and SRE. There is no confrontation between DevOps and SRE workflows. In fact, SRE workflows also need the support of DevOps workflows, and they do not exist in isolation.
On the other hand, the application scenario and business phase are also important. It is not appropriate to directly specify the SLO of a new business because the SLI is not easy to develop and measure, so you should use DevOps workflow and iterate on line steadily.