Five myths about DevOps transformation
Jez Humble brings up five myths about DevOps transformation:
Let's analyze it in detail:
Myth #1: Abandoning existing sysadmins, testers, and hiring new DevOps experts Have to say, this is definitely a bad idea and not recommended. From experience, recruiting new DevOps experts is a difficult thing. Some of my friends are looking for such talent, but it is actually difficult to find the perfect person. Because DevOps engineers or experts are not directly trained, and there is no university that teaches DevOps courses, these experienced people are gradually growing up in the process of encountering and solving problems at work.
So the crux of the matter is how to create an organizational environment where employees can learn on the job, they are not deliberately restricted to their roles, but encouraged to continuously learn new skills in the process of problem solving, and for the The entire organization serves.
Misunderstanding 2: Carry out large-scale organizational restructuring (Re-Org) Some organizational transformations are very straightforward, and large-scale organizational restructuring is carried out as soon as they come up. But experience tells us that organizational restructuring is a very chaotic activity. Organizations usually consume several months of time and enormous energy. Employees need to be re-familiar with the new organizational structure and working methods, which has a great impact on organizational productivity. .
It is worth noting that we are not saying that improvements to the organization are not required. We all know that cross-functional teams (such as service or feature-oriented) are more productive than functionally segmented teams, so building cross-functional teams can be very effective by itself. But the point here is that Re-Org is not the only option. We can also achieve this goal in other ways, such as bringing these different roles together physically; or downstream functional teams can give their capabilities to upstream teams through automated self-service platforms (see figure below). Many admirable DevOps organizations are also not fully cross-functional teams (such as Etsy, Google, and GitHub), but they are also very productive.
Myth #3: Rewrite your application and migrate to the cloud The State of DevOps survey report also shows that DevOps is applicable to a variety of scenarios, including Mainframe host systems and commercial packaged software (COTS).
In my last article DevOps sounds good, but is it right for your business, I covered the case for continuous delivery on large embedded software, mainframe systems in insurance companies. In addition, the "DevOps Handbook" also mentions an example of fast and low-risk release using blue-green deployment on traditional POS machines.
So, instead of waiting for a long application rebuilding and migrating to the cloud, you can use DevOps ideas in existing systems and organizational environments to make incremental improvements. The best time to start the transformation is now!
Misunderstanding 4: Buying a package of DevOps tools DevOps has developed to this day, and there have been many supporting tools. We recognize that good tools can provide very strong support for DevOps implementation, but our point is: if you just buy tools, you can't really help you solve problems.
When Jez Humble and Dave Farley worked on continuous delivery from 2005 to 2006, they did not have so many tools as shown in the figure above. Many automated tasks were done by Bash scripts, but they also achieved very significant results. . The question is how you solve the problem, not which tool to use. If an organization just buys tools and doesn't change workflows, that doesn't change anything.
I have seen people use Jira as a traditional project management tool for management and control, and use Jenkins as a manual trigger for batch tasks. Only tools but no changes in methods and practices can not embark on the road to success in DevOps of.
Misunderstanding 5: Give full access to the development and production environment Some people say that DevOps is to let the development release itself, so it needs to give the development permission to all production environments. We think this is a terrible idea. Ideally, no one should have access to the production environment, and all deployments to the production environment should be triggered manually and only by automated means.
Only in special scenarios, such as when you need to diagnose in the production environment, can someone be allowed to log in to the production environment. However, special care is still required in this case, such as using a one-time login password, and logging any operations and sending them to the system administrator.
To sum up , today we start with the analogy between the bird flying school and the aerodynamic school. The transformation of DevOps cannot copy the implementation process of other organizations, but should have a deep understanding of the principles, principles and practices behind it.
Due to the limited space, this article focuses on five misunderstandings of DevOps transformation, namely: abandoning existing personnel and recruiting new DevOps experts, conducting large-scale organizational restructuring, rewriting applications and moving to the cloud, purchasing a package of DevOps tools, giving Full access to development and production environments.
So what should be the correct posture for DevOps transformation? In the next article, I will elaborate on the five key practices and specific transformation paths of DevOps transformation, so stay tuned!
DevOpsDays conference Beijing station registration channel : http://event.31huiyi.com/1281765435/index?c=osc
On May 5, 2018, have a face-to-face chat with the great god Jez Humble about DevOps!