Shulou(Shulou.com)06/01 Report--

Today, I would like to talk to you about what DevOps is, many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something from this article.

Speaking of how popular DevOps is, I believe you can feel it in your moments every day. At the same time, another evidence is that in the newly released Gartner 2015 iTuno Automation report, DevOps is at the * point of its technological development curve (see figure below).

Of course, the above diagram also shows that there is still a long way to go for the implementation of DevOps within the enterprise, which needs to be implemented in the development, testing, operation and maintenance of the daily IT system of the enterprise, so as to effectively improve the IT service capability of the enterprise. Because of this, many people may still be skeptical about the idea of DevOps. However, the continuous emergence of successful cases still makes people look forward to it. To this end, the annual DevOps Development report led by Puppet Labs also hopes to conduct a more comprehensive analysis and research, and its 2014 DevOps Development report once again uses specific survey data to reveal the relationship between organizational performance, IT service performance and DevOps practice. The core ideas include the following:

Companies with strong IT service performance in ◆ usually double their market and profit targets.

There is a very obvious positive correlation between the IT service performance of ◆ enterprises and the common practices (such as continuous delivery, etc.) advocated by DevOps. For example, the survey found that teams with strong IT service performance deployed 30 times faster and had a 50% lower change failure rate than poor IT service performance teams.

From the above, it can be seen that DevOps practice plays an obvious positive role in improving the ability of enterprise IT services, and it has been widely verified in practice, which is worthy of attention and learning.

Where does DevOps come from?

If you want to understand DevOps, you will inevitably need to expand the two roles in the word: Dev and Ops. (note: Dev here includes what we often call developers and testers, and Ops refers to service operators, and more often refers to service operators in production environments.) Looking back at history, the two roles Dev and Ops have existed since the birth of the computer, and they were one at the beginning of their birth. In the earliest days, the scope of use of computers was very limited. Its hardware production, software development and daily operation and maintenance often come from the same person or team. Therefore, the two roles Dev and Ops naturally merge together.

With the expansion of the use of computers, more and more industries begin to use computers to improve efficiency. In particular, the emergence of personal computer (PC) has greatly expanded the computer from the traditional computing field. As a result, in the era of PC, many independent computer software and hardware suppliers appeared. After entering this stage, the research and development of computer software and hardware will be naturally separated from the end user. When enterprises generally begin to use computers and related software to improve their daily operational efficiency, they will need full-time IT system operation and maintenance personnel to ensure their normal operation, so the earliest full-time operation and maintenance personnel (also known as system administrators) also emerge as the times require.

At this stage, the system development personnel (Dev) and operation and maintenance personnel (Ops) are actually in different organizations. The communication and interaction between them is mainly done by product manuals, operating documents and paid Support. In order to ensure the stable operation of the IT system in the enterprise, the operation and maintenance management system with Ops as the center (such as ITIL) has been gradually formed. During this period, the enterprise operation and maintenance management system mainly serves the internal operation of the enterprise, and does not directly face the end users of the enterprise. The core goal of the actual operation and maintenance process is to ensure the stability of the system, and the iterative speed of the system itself is not high. One of the most obvious examples is that the delivery cycle of software and systems during this period is usually in years (even Windows updates in three years). At the same time, because the Dev and Ops at this stage are completely separated in different organizations, it is basically impossible to form sustained and effective communication and interaction, that is, they are unable to understand each other. Generally speaking, the Ops team lacks the most basic understanding of the design and implementation of the software, while the Dev team knows little about the challenges and problems of Ops in the actual operation and maintenance process.

With the emergence of the Internet and mobile Internet, people have found a better way to deliver software and services, that is, online services. In this mode, users no longer have to undertake the operation and maintenance of software and services, but directly "out of the box". The development and operation and maintenance of the system once again return to an organization, that is, online service providers. However, due to the influence of legacy systems (many online service providers do not have self-research capabilities in the early days, but purchase external technologies to build their own service systems) and traditional operation and maintenance ideas, many online service providers still set up their own operation and maintenance teams according to the traditional mode. Therefore, although the operation and maintenance team and R & D team within many organizations are in the same company, they also serve the same product. But they still report independently in terms of organizational structure. Even, this kind of organizational structure is also used as a magic weapon to balance the power of all sides within many companies. For these reasons, all the problems caused by the separation of Dev and Ops have not been fundamentally changed by their return to the same organization. There are also many old problems, such as Dev and Ops do not know each other, do not trust each other, and the launch process is extremely slow. As a result, people will think about the question: since they are all in the same organization and serve the same product, why not merge the two into a team with the goal of delivering * value to end users? As a result, the ideological trend of DevOps began to emerge, and from theoretical research has gradually become a very mainstream mode of software production. Many excellent DevOps practitioners have been born among them, such as Facebook, Netflix and so on.

Reviewing the development history, we can see that with the continuous evolution of the delivery and use of the system, Dev and Ops have also experienced a process from integration to division, and then to integration. It can be seen that the mode of production of the system is closely related to the delivery and use of the system. What kind of delivery and use mode, there will be a matching system mode of production. Now, the delivery and use mode represented by the Internet and SaaS has become the mainstream trend, and the corresponding software production mode is bound to develop to a brand-new DevOps direction.

What does DevOps include?

Although DevOps is back to integration at this stage, it is fundamentally different from the earliest Dev and Ops teams. No matter from the complexity of the system, the scale of users, or the use of software engineering ideas are very different. Specifically, I think the current DevOps should include the following three levels of content:

1. From the perspective of organizational culture, DevOps should become an inherent requirement of organizational culture. First of all, the output that enterprises focus on should turn to the final delivery value (that is, the product functionality, user experience delivered to the end user) and the ability to respond to changes in the user and the market. Secondly, enterprises need to solve the isolated state of Dev and Ops left over from the organizational structure, so as to provide organizational system guarantee for their integration. * DevOps culture emphasizes cross-departmental collaboration and direct proactive communication rather than a process-oriented pipeline model. To sum up, there is a need to establish a "you build it you run it" code of conduct within the organization.

two。 From a methodological point of view, DevOps includes a series of practices that transform the delivery of value. For example, continuous delivery to increase the frequency of delivery, to ensure that every improvement in Dev can be delivered to the end user as soon as possible, and to quickly get feedback from real users in order to reorient the product in a timely manner. Continuous build and automated testing ensures that Dev can get feedback as soon as possible, identify potential problems in the code and fix them in a timely manner. The principle of automating everything is to avoid human error as much as possible and to ensure that the whole process is efficient and repeatable.

3. From a tool perspective, DevOps refers to a set of tools that adapt to the needs of DevOps organizational architecture and help teams implement DevOps*** practices. These include code management tools, continuous build tools, code deployment tools, system monitoring and operation and maintenance tools and so on. In tool selection, users can not only build their own based on open source software, but also consider purchasing commercial software (such as FIT2CLOUD) to quickly land.

In summary, the DevOps team needs to be guaranteed and supported at the organizational culture level, and team members can accept and implement various DevOps practices, and provide appropriate tools to help implement them. Only in this way can we fully implement the DevOps practice and ultimately benefit both the team and the business, and realize the value delivered to the end user. Instead of becoming a mere formality and hype, it will not be able to achieve results in practice.

3. Where is the grip of DevOps?

If an organization wants to promote the landing of DevOps practice, where to start may be the most confused place for front-line managers in many organizations. There is a lot of content about DevOps sharing on the Internet. So where is DevOps's grip? The conclusions from the Puppet Labs 2015 DevOps Development report provide a good answer to this question. The conclusions of the report include the following points:

If you need to know the DevOps status of a team, you only need to ask a simple question, that is, "how painful it is for a team to deploy a service at once." The answer to this question will tell you a lot of details.

Similarly, the grip of DevOps*** also lies here. Improving the team's ability to deliver and deploy continuously is a breakthrough in implementing DevOps practices in most cases. In implementing this breakthrough, the team needs to pay attention to the following points:

1. It is critical to sort out and figure out the entire channel from code to service for the team. For example, the following figure is a typical channel from code to service. The need to improve the team's ability to deliver and deploy continuously lies in whether this channel can be opened and run as efficiently as possible.

In the process of getting through this channel, the team encountered the following common problems:

The ◆ team lacks basic implementable deployment specifications (including Artifact packaging specifications and deployment process specifications). Standardization is an important part of improving the efficiency of team cooperation. At the same time, the specification here must be able to implement the deployment process and be able to implement it automatically. If the team does not have a history of success here, it is recommended to adopt existing specifications that are already widely used (such as AWS's CodeDeploy specification) to speed up implementation.

The ◆ team lacks a unified product library management. In the real environment, the artifacts built by the team is often directly stored on the FTP and shared directory, the organization is not standardized and is not centrally managed. Therefore, there are often a series of problems, such as the wrong version, there is no old version when you need to roll back, and the wrong version is selected in different environments. It is recommended that the team establish a unified product library (such as open source Nexsus, commercial software Artifactory, etc.) and directly interface with the construction environment and deployment system. The build result is automatically packaged and uploaded to the repository during construction, and the deployment package is taken from the unified repository for deployment.

The ◆ team lacks the ability to ensure consistency between different environments. As shown in the figure above, the system delivery process needs to involve development, testing, acceptance and production environment (DTAP). How to ensure the consistency of different environments and avoid accidents caused by environmental inconsistencies is an important challenge. In general, the use of a unified underlying environment (such as mirroring) plus a unified deployment process and tools is the key to ensuring environmental consistency.

two。 Focusing on team deployment efficiency and continuous improvement is a magic weapon to further improve team delivery and deployment capabilities. After opening the channel from code to service, there will be a qualitative improvement in the overall delivery capability of the team. However, if you need to improve the team delivery capability deeply and continuously, you also need to pay continuous attention to the team deployment efficiency, identify potential obstacles that affect the team's further progress, and make targeted improvements. In this regard, the Puppet Labs 2015 DevOps report proposes a quantitative analytical model that is very helpful. Specifically, the quantitative analysis model consists of the following key indicators:

◆ output indicators:

○ deployment frequency (Deployment frequency): the frequency of team code deployment (including the number of deployments for all environments), generally calculated in terms of the number of deployments per day.

Online delay of ○ code (Deployment lead time): the interval between the time the code is submitted to the code base and the time it runs online.

◆ stability index:

Average ○ service recovery time (Mean time to recover): average service recovery time.

○ change failure rate (Change fail rate): change failure rate.

By following the trends in the above metrics, the team can quantitatively measure the efficiency and quality of the entire application delivery, and can always ensure a focus on application delivery. Of course, in order to make it easier to count the above indicators, you need to record all the deployment operations and results of the team, but this should be one of the basic functions that a good deployment system needs to support.

After reading the above, do you have any further understanding of what DevOps is? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.