Pain Point of Driven DevOps Practice: Challenge of Implementing (1)

I think we should first analyze what are the biggest problems encountered by our existing R&D operation and maintenance system, and gradually resolve DevOps by solving these problems or pain points.Such a path is a better landing path I think, the important thing is not for DevOps and DevOps.

Another fact is that O&M can actually appreciate the value brought by DevOps, so many times the original O&M is promoting DevOps. Today I also share it with you from an O&M perspective, combined with my own practice, How to build your own DevOps through problem solving.

Drive DevOps to the ground
About how to land, I have seen many successful cases and share, there are two ideas:
The first is driven by organization, I think top-down. This is very efficient, that is, from the top and the organization, to start all departments to act together, and then to promote the practice of DevOps throughout the company.

Another way of thinking is through tools. For example, I will build our automated tools, research and development collaboration tools, through this tool to improve the efficiency of our entire R & D and delivery system, and then promote the formation of DevOps culture.

No matter what kind of thinking, organizational culture and tools should be two indispensable factors for our DevOps implementation, and they are indispensable. Or in different organizational structures, there will be different methods and paths for DevOps implementation

DevOps organization
Take a look at the organization. A few years ago or in the ITIL era, when your business reached a certain scale, the DO was separated, each responsible for forming a professional team, based on ITIL to establish a service system, such as change management, service requests, etc., to a certain extent. Service and professional competence.

But recalling that the DO separation actually brought us some confusion, the R&D and operation and maintenance were inconsistent, various complaints and contradictions, and the inefficiency of the process were often criticized. For example, the operation and maintenance of the pot, this is the self-deprecating of the operation and maintenance people.

With the rise of DevOps, many people think that it is necessary to remove O&M, or let R&D do O&M. For example, the organization is flat, and all the roles are in the same team, which can maximize the consistency of everyone's goals.

But simply combining development, testing, and operation together can solve the problem. I think this may be a good way for a small team, but when the organization reaches a certain scale, there will be waste of resources. Repeated things, efficiency does not necessarily improve.

What kind of organization form we are pursuing? O&M and R&D should have their own core capabilities and teams. R&D focuses on product and demand realization, and O&M focuses on infrastructure, technical services, and efficiency tool development. There will be a trend that there will be more and more intersections between operations and R&D. The previous intersection relied more on the process and was delivered to the operation and maintenance through the process. The current intersection should be from the goal, responsibility to authority and skill.

For example, in terms of goals and responsibilities, some of the most basic indicators of the system, such as the availability of four 9s, were mostly KPIs or indicators of availability that were previously undertaken by the operation and maintenance.

We may not be the same. R&D undertakes this indicator, and operation and maintenance provide service guarantee and support.
In addition, it is in terms of skills and permissions. This skill does not represent technology. For example, release and deployment may have been done in operation and maintenance in the past. Operation and maintenance develops delivery standards, development delivers according to the standards, and operation and maintenance performs deployment and release.

In fact, is it possible for the R&D team to do deployment, release, or fully automated operation and maintenance is responsible for R&D and output tools and capabilities. Therefore, there will be a transformation in operation and maintenance, that is, operation and maintenance will increasingly change from the original deployment and execution of the implementation to the provision of tool capabilities and service delivery.

The challenge of landing DevOps
To do this is not so easy, it needs service and tool system support. So we have to solve some problems that need to be solved or called pain points in this form.

The first is the lack of automation and O&M service capabilities? The automation I have seen is not as mature as imagined or said by many teams. Maybe everyone is talking about AIOps and DevOps now, but these concepts are all based on the premise of sufficient automation and strong operation and maintenance services. Things to consider. Therefore, automation is always a point to be considered, and the most urgent need to solve is the degree of automation.

In the process of software delivery, in addition to operation and maintenance service capabilities, there are many links in front, CI, testing, etc. There is an automated operation and maintenance platform for operation and maintenance, an automated test platform for testing, and CI tools for research and development. If these tool capabilities in the software delivery process cannot be docked, they will not be able to maximize their effectiveness.
Finally, the quality of delivery. Driving high-quality delivery through efficient and rapid delivery is the ultimate ideal state of DevOps.

So our practice on the ground is actually the process of solving the current problems layer by layer.

Operation and maintenance service capabilities
Establish operation and maintenance service capabilities or operation and maintenance automation systems, and refer to the matrix model. Horizontal is a professional platform capability. There are too many roles in extensive operation and maintenance, such as system management, hardware engineer, network engineer, etc. These are professional fields. To build professional service capability output, for example, resource as a service, that is, IaaS .

Basic services such as DB, load balancing, and CDN, storage, etc. These service capabilities are considered as a whole, and a unified operation and maintenance support service system is established without the need to reinvent the wheel. The operation and maintenance capabilities of the application layer are relatively complicated, and the architectural differences between various application scenarios are relatively large. But like Docker doing operation and maintenance service application layer also provides some good solutions. Summary Provide professional O&M capability output for R&D and business O&M horizontally.

Longitudinal is the ability of the business, according to business characteristics and operation and maintenance scenarios to do integrated tools and automation. Vertical capacity building is more encapsulated by horizontal capacity. Such as automated resource acquisition, creation of basic services, application release deployment. The core is the business form and operation and maintenance scenarios, customized to make a specific tool you want.

Standardization to automation and then upgrade to the platform, this is the basic step to establish operation and maintenance service capabilities. The premise of operation and maintenance automation is based on standardization. This is easy to understand. Automation without standardization is actually a very painful thing. Like most teams, it is unlikely to consider standardization at the beginning. It is painful to consider standardization after the scale of business development, so standardization can be done as early as possible.

At the beginning, automation is all scripts. At most, the basic capabilities can be connected in series to make automation tools by calling each other through related APIs. In terms of O&M alone, most of these tools have already met our O&M needs and can free up a lot of time and energy in O&M.

But usually you can't give a bunch of automation scripts to R&D or other business operation and maintenance. Say you just use this script. So the next level is that we have to consider the ability to do service, that is, the operation and maintenance platform. For example, one-click release, one-click deployment, online expansion, etc., to achieve these capabilities, such service users regardless of R & D testing or business operation and maintenance, operation results are consistent, so your operation and maintenance capabilities will be upgraded to an open Level, you can safely hand over the operation and maintenance nodes to the delivery process to integrate, or save a lot of manual processes in the middle.

Application standardization
In-depth talk about application standardization. At the application level, because there are so many technology stacks, standardization needs to consider many issues, such as the operating system version, running dependencies, environment dependencies, middleware versions, and various environment configurations. These are all dependencies. There are also packages to formulate specifications for packaging code, configuration or startup scripts, log directories, and other variable things. The combination of environment dependency and package is a unit of our application.

Containers are a solution that simplifies standardization. The most important choice of Docker is the ability to solve standardization. It has many other advantages, such as resource isolation and low performance loss, which can save costs and distribute quickly. But every time a new technology is adopted, he must solve a very important pain point for you. For us to choose Docker, the most important thing is to have a great advantage in standardizing the pain points.

The infrastructure is irrelevant, and it can solve problems that depend on this level such as the operating system version. In addition, using the image as the delivery unit solves the delivery standards and interface problems of R&D and operation and maintenance. It has strong operability, good portability, and can quickly support hybrid cloud deployment. Many of our applications now require hybrid cloud deployment. If Docker solves the standardization problem, but the establishment of its service system based on Docker is the next problem we have to solve.

Please refer to Pain Point of Driven DevOps Practice: Container Delivery (2) to get the reat content.