DevOps scope, vision and goals
The
DevOps standard mainly includes five major areas: R&D and operation integration, application design, security and active risk management, organizational structure, and system tools. The core module is in the first part of the "R&D and Operation Integration Process", and the standard clearly states what best practices are and what specific details are corresponding to different levels of practices.
Based on the above framework, we can actually see that DevOps has many goals, involving three modules: development, testing, and operation and maintenance.
Because there are so many goals, how does DevOps go? Can DevOps be implemented well by following the blueprint? Because there are blueprints, best practices, and standards, it stands to reason that the implementation of DevOps should be very easy. Our answer is also very clear: it is not the case. Here I will give two examples, let’s take a look at some detours in DevOps practice.
If we follow the blueprint, will
DevOps be easily implemented?
The first is a large-scale central enterprise DevOps promotion case: the internal cloud team wants to plan and build PaaS platforms, including DevOps platforms. Because PaaS includes DevOps, the cloud team wants to push the DevOps capabilities in the PaaS platform to the R&D department.
The overall scope of construction is agile development management, continuous delivery management, and integration of operations. A lot of energy was spent on this matter, and a lot of internal team communication was also done. Overall, the promotion effect in the business team was not particularly good, and it was gradually shelved. This is not to say that it failed, at least the effect did not show up. To sum up: Who should use the DevOps platform and build it may be easier in the initial stage.
The second is the case of one of our medium-sized financial institutions. The construction goal of this case was relatively high, and a consulting company was consulted. The things done by consulting companies are indeed better, more complete and more detailed. The entire construction goal includes development management, continuous integration, test deployment, continuous monitoring, and the plan is very complete.
When it comes to the landing stage, the project will have a total landing cycle of 10 months and 7 systems will be launched. The entire landing module includes project collaboration, assembly line product library, etc., which includes project collaboration, CICD assembly line, measurement dashboard, and management cockpit. Objectively speaking, the actual promotion effect is still OK, especially the development team feels OK. However, the operation and maintenance team put forward a lot of opinions when the whole project was summarized later, saying that the early operation and maintenance team also participated, and the leader also put forward goals and requirements, but in the last 10 months, the operation and maintenance team did not feel the value of this platform.
This should be considered a relatively successful DevOps project, but the operation and maintenance team put forward clear negative opinions during the evaluation, which affected the project evaluation. To sum up: the project has been adjusted too high and the scope is too large. The expectations of each team are relatively high, but in fact, some teams may not get the desired effect when it is implemented, and the effect evaluation is affected. The initial target design for DevOps landing should be more reasonable.
The above two small cases illustrate the typical problems in the implementation of DevOps.
Based on the previous case, I want to answer why the DevOps blueprint is difficult to achieve in one step. The first is because of the organizational structure. It is difficult for DevOps projects to achieve good results in the development department, test department, and operation and maintenance department at the same time. It is best to do it step by step. It is more reasonable to solve the single department problem first.
The second DevOps automatic deployment tool is only part of it. In fact, it also involves the establishment of DevOps culture and common understanding, which requires a longer process. The problems to be solved by the overall DevOps blueprint involve a lot of underlying tools, and it is difficult to quickly implement it in a short time without a good foundation. A good DevOps implementation requires the promotion and implementation of a series of standards and specifications. But generally speaking, because of historical burdens, the promotion of standards and norms requires a gradual process of getting rid of the burden. These specifications are very needed, but because of the historical burden of promotion is very troublesome, and the business needs of business departments are very large, so it is more difficult to promote standard specifications, but it must be done, but promotion requires a process. On the whole, these reasons are that DevOps has blueprints and best practices, and it is still difficult to get it in one step.
Try to summarize the principles of DevOps implementation path selection.
The first is to set reasonable goals. The core reason is that the most important goals of each team are not the same. As we just mentioned, as a software company, we are more inclined to quickly iteratively release and measure these two content, but as an online system may be more important It is some other indicators, so it is more important to start from the core pain points based on your current situation, and it is more important to formulate reasonable project goals. At the same time, there are requirements in the operation and maintenance release and CICD pipeline.
The second is to manage internal and external expectations. In fact, we have to put forward our goals at the beginning. One aspect must be of great value. In addition, we must not be too high and do not set high expectations. Promotion is not that easy. We must have reasonable expectations, including the leadership. If expectations are too high, it is easy to be disappointed. After being disappointed, the promotion failed.
The third is that the system design depends on the organizational structure. It is best not to do the organizational structure first, this can certainly be done, but it is more troublesome. In DevOps practice, there are many things done inside the organization. You can start from your own organization and then gradually realize the integration of cross-departmental. This is very reasonable. In addition to the platform, there are people’s cultural cognitions, so step-by-step implementation and gradual evolution do not need to be planned in one step. DevOps can be achieved in one month. This is actually not realistic. It is very difficult to do it in one step, and the effect is not good. Then the pilot team is to pilot first, cooperate better, and have a stronger willingness to promote it. This is the engineering practice of almost all DevOps successful companies.
In the other cycle, there must be a continuous promotion mechanism. It may be very good at the beginning. Then after half a year of promotion, have you forgotten? There must be a continuous promotion mechanism, and there must be preparations for a protracted battle, and gradually develop DevOps. The landing is optimized to the best.
The last one is: specification. The more standardized the more useful, the value of the norm is very large. When possible, you can implement the norms first. With norms, many things will become very easy, and for users, the experience will be good after landing. So the sooner the specification is pushed, the better.
On the whole, this is the planning principle for the implementation path of DevOps. You can use it as a reference.
