Improve DevOps engineer soft skills, you can look at an article before "DevOps engineers required soft skills"
"Phoenix Project" is the DevOps community God book, although the content is a form of fiction, but still agile development and DevOps in the field of reading books. Many well-known consultants are opened up by this book DevOps and agile journey story in the book are derived from the operation and maintenance of the daily work, is a manifestation of art from life, than the essence of life. The author interval of two years, read the book twice, I hope you can speak some experience in the book learned to others.
Bill protagonist, temporarily took over the position of IT operations managers, however this time, the company has gone through several rounds of layoffs, production line fault constantly. The Board expect Phoenix to restart the project to save the company, but the layers of the difficulties faced, Bill began to stop to cope with sudden fault line, physically and mentally fatigued. In order to survive and the normal operation of the company, try a set for the company's IT transformation program, the whole process is like DevOps transformation of development mode as we transition from traditional development mode, stepped on a lot of pits, summed up a lot of sense, the content of the novel I was only narrative and more, to understand the wonderful stories can go directly to the purchase of books, the following will give you summarize some of the important lessons of the book.
1. form of four working
In the story, the hero succeed Bill in the IT manager, through a series of troubleshooting and interpersonal communication process, we came to this conclusion. IT's job is nothing more than the following four types:
- IT projects within the department
- Business group project
- Change work
- Fire fighting efforts
In fact, the above four types of work is consistent with the current state of our operation and maintenance departments, we need to develop their own operation and maintenance and monitoring platform, to participate in the development and testing business, we should be all the infrastructure and application version changes and upgrades . And these are part of the normal work, we are often the most reluctant to deal with is the fire fighting operations, all user functions such as line leading to sudden failure can not be used, often in technical operation and maintenance personnel will be vp, cto, ceo of even watching the next line knocked command line, fix the problem. A large number of operation and maintenance personnel should have had a similar experience, in retrospect must have been terrible, so we have to work to reduce this fire, and the first three rational allocation of work.
2. Strengthen change management, reduce fire behavior
From four working form of IT, we come out of a problem, how to reduce fire behavior, let's look at the operation and maintenance of two laws circles
The famous eight law: 80% of the line fault from the 20% of the change.
GoogleSRE theory: about 70% of the accidents by the deployment of some kind of change is triggered
We do not tangle 80% and 70% of the difference is how to produce, but the conclusion is unity, a large number of fault lines are due to changes result of changes including applications, databases, operating systems, network or hardware physical, logical or virtual operating. We can see, the content covers a lot of operation and maintenance work, why operation and maintenance easy scapegoat, that is because usually these changes to deal with high-risk operations, it may cause a failure of the line. The outsiders, operation and maintenance is in trouble, after the start of fire fighting operations, troubleshooting. In order to avoid the kind of situation, how to handle it? The article gives us a very important method is to use the Kanban method, standardized management of all changes, planned changes once every, every change brings risk assessment point, even if a failure occurs, it can be quickly repaired.
3. Strengthening technical reserves, avoid personal heroism
When solve all the changes caused by the failure of the novel, there was an important person, Du Lunte, this is a heroic role in the operation and maintenance team, he does not solve the problem. But is such a powerful person, like all developers are looking for him to make changes, all system failures need to deal with him, so much so that people who are engaged in the fire fighting work every day. This role becomes a bottleneck point we shipped dimensional standardization process. As long as his work can not be replaced by other people, we can not let him do the operation and maintenance team more important things, such as building automation, such as monitoring vital construction. The novel To solve this problem, Bill set up a troubleshooting classification mechanism, the Du Lunte protected, does not allow developers to communicate directly with Du Lunte, and arrange contact with other engineers Du Lunte original work, let's Du Lunte focus on building automation and monitoring construction. Such an increase in the key position on the technical reserves, but also the core technical staff used in the most important position.
4. limited number of products, do from 0 to 1, reducing the number of (kanban) 0.5
The name of the novel called "Phoenix Project", the story revolves around the core to the Phoenix project, the Phoenix project is a program for three years, after three years of barely hold back the big move a project on line, of course, prepared for so long Finally, the project ended in failure, the question of what it tells us. Hero factory floor to realize that if the factory labor is fixed, if semi-finished products accumulated too much, it will lead to the final product delivered to the customer will slow down, which is what we used to say in the field of software development affects the WIP the speed of delivery, if the iterative development team at the same time too much demand, then there must needs be delivered into the hands of the user to extend the time. So limit the number of products is a core element of DevOps construction, we should do the 0-1 thing, and reduce the number of 0.5. The book summarizes very well, once locked in the form of semi-finished products R & D capital of more than one year without the return of cash to the company, he is almost impossible to pay off for the company.
The three-step method of work
Finally, the author sums up the novel three-step working method, comprising:
1) flow principle
Flow principle is DevOps infrastructure and shorten the time to meet potential customer needs, build automation tool chain, reducing manual intervention process, reduce the number of products, rapid iteration, can effectively improve the quality of work and productivity.
2) feedback principle
Found the problem at the source, find problems early, testing and safety left, at the source of production is necessary to ensure quality.
3) continuous learning and experimental principles
The productivity, workflow rise to leadership, to promote the landing DevOps culture.
Summary: What are you waiting for, buy books to see it, "Phoenix Project."
More exciting content to focus our online classroom
Search micro-channel public number: jfrogchina get course notifications