In recent years, the frequency of
DevOps around us has increased. DevOps special sessions often appear at various conferences. Companies in the industry are hiring DevOps engineers. The enterprise's DevOps transformation looks imminent. The company must also design and develop a DevOps platform...In this way, DevOps seems to be everywhere.
But come back and think about it, do we really think a lot about DevOps? Is the so-called DevOps platform equivalent to an automated operation and maintenance platform or a continuous delivery platform? What skill requirements should be written in the job description of DevOps engineer? In addition, how to prove that the enterprise has achieved DevOps transformation? These problems really stumped the heroes. So after all, after listening to
DevOps for so long, what is its "definition"? It seems that no one can ever make it clear.
Now, let’s take a look at Wikipedia’s definition of DevOps. However, it is estimated that no one can understand what this is talking about.
DevOps (combination of development and operations) is a culture, a movement, or practice that emphasizes the interaction between software developers and other information technology (IT) professionals in automating software delivery processes and infrastructure changes Collaboration and communication. It aims to establish a culture and environment that enables construction, testing, and software release to proceed quickly, frequently, and more stably.
Therefore, whenever it is mentioned what
DevOps is, the most common metaphor is "blind people touch the elephant". Interestingly, Patrick, the father of DevOps, also used this metaphor when he first participated in the DevOpsDays China event. It seems that at this point, Chinese and Western cultures are common. After all, everyone's perspective is different, and the DevOps they see are naturally very different.
The tide of DevOps is surging, and many people are wrapped up to explore and practice DevOps. There is even an extreme view that all good practices belong to DevOps, and all bad practices are anti-patterns of DevOps.
When agile started to be popular, it seemed to be the same argument, but this general definition did not help us to sort out our ideas, and even brought a lot of negative voices. For example,
DevOps is to develop and eliminate operations, or, DevOps is to Let O&M abandon the old bank and start a comprehensive transformation for development. This made many IT practitioners very anxious.
Objectively speaking, since the birth of the DevOps movement, those pioneers have never tried to give DevOps an official definition. Of course, the benefits of doing so are obvious. Since there is no restriction on the crowd and scope, everyone can contribute to DevOps from their own standpoint, thus making the scope of DevOps wider and wider. However, the disadvantages are also obvious. With the continuous development of DevOps, people who are just getting started with DevOps are often out of the question. Seeing the trees but not the forest, the deviation of cognition makes
DevOps more mysterious.
My geek time column "DevOps combat notes" has just been updated, limited time offer ¥68, save ¥31, poke here to try
Rather than struggling with the definition of DevOps, let us try to return to the original together to see what problem DevOps is trying to solve.
In fact, the secret of DevOps comes from the two roles represented by its name-development and operation and maintenance. So what's the problem between these two roles? We start with three important stages of development since the birth of software engineering.
Waterfall development model
The waterfall development model divides the software delivery process into several stages, from requirements to development, testing, and operation and maintenance. Its philosophy is that the scale of software development is getting larger and larger, and each stage must be defined in a project management manner. , As well as the corresponding delivery products and delivery standards, with a view to passing a heavy process, re-control, and step by step to advance the entire project delivery process according to the plan.
However, as the market environment and user needs continue to accelerate, this step-by-step approach has a serious potential problem.
Software development activities need to determine the project objectives, scope, and implementation methods at the beginning of the project, and this time point is often when we have the least knowledge about users and market environment information. The decisions made in this way often carry great uncertainty. , It is easy to cause the scope of the project to change continuously, the plan is continuously delayed, and the delivery time is continuously pushed back. The final result is that even if we invest a lot of resources, it is difficult to achieve the expected results.
According to the statistics of industry giant IBM, 34% of new IT projects have been delayed, and nearly half of the application systems have been rolled back online due to defects. This is a very frustrating thing.
Agile development model
Based on this problem, agile thoughts began to prevail. Its core idea is that since we can’t fully understand what the user’s real needs are, then it’s better to dismantle a big goal and turn it into small deliverable goals, and then iterate through small steps The fast-running method continues to develop.
At the same time, the testing work is injected into the entire development activity from an independent link at the end of the R&D, and the content of the development delivery is continuously verified to ensure that each deliverable is a usable set of functions, and is built into the R&D due to the quality In the link, the quality of the delivery function is also guaranteed.
Obviously, agile is a more flexible R&D model. People often ask, will Agile directly improve the development speed of the team? the answer is negative. Imagine if the agile method is used, will the speed of R&D coding increase by two or even three times? Recalling the "man-month myth" that was widely circulated in the IT industry many years ago, we can find out how important correct perception is.
The fundamental reason why agile is faster is that
continuous iteration and verification save a lot of unnecessary waste and rework. On this point, I will do a more detailed introduction in the content of agile and lean.
In the final analysis, agile stems from development practices, and the application of agile keeps the development and testing teams warm. But the problem came again, the development and testing team found that no matter how fast the research and development speed became, at the other end of the software delivery, there was always a group of people watching them coldly, and the sentence "now not coming to the release window" made new The developed functions fell on the threshold of going online.
After all, no matter how many genius functions are developed, if they are not deployed online after the operation and maintenance link, and finally released to real users, then these functions are actually useless.
DevOps mode
As a result, the operation and maintenance team living at the other end of the wall became the object of being drawn together. These teams at the very end of software delivery are always in a state of "backfire", and they also have the willingness to change, so DevOps came into being. That is to say, the first thing DevOps wants to break is between development and operation and maintenance. Opposition and estrangement.
In the traditional model, the way to measure the efficiency of the development team is to see how many requirements the development has completed. Therefore, in order to achieve performance goals, of course, to meet business needs, new functions are constantly being piled up, but there is little time to seriously think about the operability and testability of these functions. As long as the status of the requirements flows to the completion of the development, everything will be fine. .
For the operation and maintenance team, their assessment indicators are the stability, availability, and security of the system. However, the modern IT system is so complicated that every launch is a battle, and the entire team is like an enemy. The anxiety of failing to launch is always there.
In many cases, we don’t know what will happen after going online, we can only follow the deployment manual step by step, and after completion, we take orders. Therefore, every time the big promotion event, there will be a variety of "worship server" photos widely circulated.
On the other hand, after being devastated by unreliable functional defects countless times, the operation and maintenance team realized that change is the biggest enemy affecting their performance goals. As a result, the pre-established online window has become the reserved place for the operation and maintenance team. The constantly rising online threshold has also made the delivery of the development team an impossible task. In the end, "harming each other" has become the destiny of this story. ending.
Even today, it is still a sacred thing for most companies to deploy online. I tell you something interesting.
When I visited Patrick, the father of
DevOps, in Europe last year, I visited his company. Gent, Belgium, was very deserted that day. After we parked the car, we just had to push the door to enter their company and happened to meet Patrick and one of his colleagues to go downstairs and smoke.
After a brief greeting, we learned that a system that Patrick was responsible for came online after 15 minutes. They took advantage of this interval to change their minds, and then went back to do a big job. So you see, even the father of DevOps is so formal when it comes online, it can be seen that the development road of DevOps is still a long way to go.
From the beginning, if the team wanted to promote collaboration between development and operation and maintenance, the team slowly discovered that in the entire software delivery process, not only development and operation and maintenance, but also business is an important part.
For example, if the business sets an unreliable requirement, no matter how the development and operation and maintenance work together, the result is an unreliable result and waste of manpower. However, the business does not know the real situation of the user, so the operation and maintenance team slowly turns to the operation team. They need to continuously feedback the real online data and user behavior to the demand team in time to help the demand team objectively evaluate the value of the demand. , And make timely adjustments that are conducive to product development. In this way, the business is also introduced into DevOps, and even a specialized vocabulary such as BizDevOps is born.
Well, since communication and coordination are universal, security has also begun to actively participate. Security is no longer a "time bomb" after the system is launched, but is involved in the entire software development process, injecting a security feedback mechanism in each process to help the team respond to security risks in the first place, then, for the security team In general, DevSecOps has become DevOps in their eyes.
Such examples abound, including functional departments, strategic departments, etc., have joined them one after another, making DevOps expand from the beginning to the line, and then to the face, and continue to develop and grow. Everyone is involved, which makes DevOps a knowledge and skill system that every IT practitioner needs to learn and understand.
In the end, I still hope to give my own "definition" based on my understanding of DevOps:
DevOps is an organic integration of platform (Process) and process (People), guided by C (collaboration) A (automation) L (lean) M (measurement) S (shared) culture, and aims to establish a A modern IT organization that can deliver value quickly and has continuous improvement capabilities.
