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

The five major practices of DevOps and the specific implementation process of the transformation, I believe that many inexperienced people do not know what to do about this. Therefore, this paper summarizes the causes and solutions of the problems. Through this article, I hope you can solve this problem.

So what should be the correct posture for the transformation of DevOps?

Five practices of DevOps transformation: get used to working in small batches (development, architecture, evolution of organizational culture)

Lasting change needs to be carried out in a small batch and continuous way, through repeated experiments and rapid learning according to the feedback loop to find the most correct implementation path. This requires breaking down the big problems into a series of small problems one by one, gradually solving them one by one. It may not be exciting without Big Bang-style change, but this is the right posture for us to succeed.

1. Find the most important job.

The most classic example is project management, which traditionally plans and applies for budgets half a year or one year, which drives us to work on large and complex projects, spending a lot of time on transactional tasks such as features in to-do lists (Backlog) waiting to be analyzed, estimated, approved, and prioritized. According to a white paper called Black Swan Farm, they analyzed the different requirements waiting to be developed on 3000 to-do lists, using the priority of deferred costs (the weekly lost costs if not made).

They found that there were three features on the to-do list, each of which would cost the organization $2 million a week if they were not delivered. These features are hidden in a huge to-do list, but they are crucial. They realized that they should stop all the work at hand and deliver these three features as quickly as possible. From a statistical point of view, this situation is consistent with the power law distribution, as shown in the following figure.

So our job is to find what is really important among multiple projects, which requires more transparency, clearer priorities, and the collaboration of everyone in the organization.

two。 Continuous evolution of architecture

It is common that many organizations have a large number of legacy systems, some software or hardware is so old that vendors may no longer support it, and some organizations' individual systems do not even have source code (which may be in the hands of Party B or have been lost). Such organizations usually choose to solve their problems through architectural reengineering for a year or two, and when they go on for a year, they may say that the system complexity is so high that we need another two years! I have personally experienced such a super-large project, and in the end, the CTO in charge has been replaced, and the project is not finished yet.

The key problem with the scenario described above is that the focus is often on the technical level of the architecture rather than on the results that need to be achieved. Survey data show that if the answers to the following questions are Yes, then you are more likely to do a good job of continuous delivery and DevOps to become a high-performance IT organization:

Is it possible to make extensive design changes to your own system without the authorization of someone outside the team or other teams?

Can you do your job without fine-grained communication with others outside the team?

Can you deploy and publish your own products or services on demand independent of other dependent services or products?

Can you test most of your own systems on demand without relying on a complex integrated test environment?

Is it possible to perform a non-downtime deployment during daily business hours?

You can achieve all of these effects on an old legacy system, but you may not be able to achieve any of the above effects when it is full of high-tech and new technologies. So we need to focus on the results of architectural evolution, not just the use of cool technologies.

I have also introduced more about the evolutionary architecture and the idea of the hanger model in my previous article, and its main principles are as follows:

Starting with delivering the new features required by the business (at least initially), the new features use service-oriented design

Do not rewrite existing functionality unless it can be continuously simplified

Faster delivery through continuous split

Design for testability and deployment

The new architecture runs on the PaaS platform

Practice 2: create a feedback loop

On the basis of small batch work, we should establish a feedback loop. The feedback loop enables us to learn continuously and make continuous improvement based on learning, which is also a key principle of agile and learning organizations.

Continuous delivery pipeline is the concrete implementation of feedback loop, which can provide feedback information of multiple levels and links, and can strike a balance between feedback efficiency and feedback integrity.

The following is the design and effect of the all-open source continuous delivery pipeline that I worked with my friends last year, which fully reflects the principle of successive promotion and feedback loop of the pipeline.

Full open source pipeline can only meet the needs of small and medium-sized enterprises, and the design and implementation of assembly line in large enterprises is more complex. I will introduce it to you later.

Practice 3: cross-functional collaboration through value streams

The roles of requirements, development, testing, information security and operation and maintenance need to work together in the software delivery value stream. The value stream map is a key tool for promoting cross-functional collaboration. Through the Workshop of value stream combing, we can identify the various roles that support the value stream and the collaborative relationship between the roles. Instead of documenting the details of every step of the value stream, we need to understand how value is delivered and how the roles work together.

The above models not only stay at the theoretical level, but also can be applied in the field of practice.

Case one. Disaster recovery testing of Google

Google did a study a few years ago on how to build a good team. They surveyed 200 respondents from 180 Google teams and looked at more than 250 different factors, such as someone in the team who received a doctorate, extroverts, someone who was obsessed with AngularJS, and so on. But they eventually found that to build a high-performance IT organization, the first factor is the psychological sense of security, that is, you can take risks in the team without feeling insecure or hurt.

We need to build a secure environment in which failure is acceptable and serves as the basis for organizational learning. Both Google and Amazon conduct disaster recovery tests online to ensure that the recovery strategy is really effective and the system can still function properly in the event of a serious failure.

Google has an entire team focused on planning and implementing disaster recovery tests, and even simulated an alien invasion of Silicon Valley for one year, disconnecting Mountain View from the outside world, shutting down data centers and having a real impact on infrastructure, but requiring the team to maintain service-level goals. The disaster recovery tests they designed need to be collaborated by engineers from many different groups who don't normally work together, so they have established a strong working relationship when a large-scale disaster really comes.

Case two. Etsy's "three-sleeve sweater" reward

Etsy holds an annual developer conference and gives a "three-sleeved sweater" to the maker of the biggest disruption in the production environment in the past year. So why is the reward a three-sleeved sweater? Because there is a picture of a three-sleeved sweater on Etsy's 404 page.

Practice 5: continuously eliminate waste and optimize value stream

DevOps needs continuous improvement to remove waste and make the flow of value smoother. I recently coached some teams to sort out processes and problems using value stream diagrams, and found that this is really helpful for organizations to recognize and optimize existing software delivery processes.

The transformation of DevOps is not easy, and here are a few Tips to be successful:

Agree on measurable business goals. Set "hop-achievable" goals, such as reducing the number of serious defects by 10%, increasing service availability by 20%, releasing twice as often, or other mixed outcome indicators.

Give team resources to experiment and motivate learning. The team is unable to "work overtime" to explore improvement under the premise of daily work as usual. Improvements require real effort, which should be prioritized in the same way as developing new features and fixing defects. Specifically, you can use Kanban to manage WIP, assign a full-time team to do improvement work, or give the team a specific time each week to do improvement work.

Communicate with other teams and encourage collaboration. Many people often refer to compliance, security, governance and other teams as obstacles to improvement. But in fact, if you communicate amicably with these teams, you may find that they are very eager to discuss specific measures for a win-win situation.

Get a quick win. You need to make improvements in a month or two. Specifically, there are three key points: first, through the value stream graph or constraint theory, find a problem that has the greatest impact and can be solved quickly and can be measured; second, limit the scope of improvement for the first time and minimize the improvement work; then, work with teams that are interested in improvement and have sufficient capacity and ability to win quickly.

Share successful experiences. In order to get the support of others, you need to do a good job in publicizing successful experiences and attracting more people to join in the improvement work. For example, some enterprise organizations within the DevOpsDays conference, cross-departmental promotion of experience, which is very effective. In addition, lunch sessions, internal blogs, mailing lists, Slack or HipChat channels are all the best ways to get participants. Also provide help to other people who try, just as DevOps coaches are supposed to do.

Continuous improvement. Efficient organizations always pursue opportunities for improvement. As Niichi Ono, the founder of Toyota's management system, said: "Kaizen [improvement] opportunities are infinite", the opportunities for improvement are endless. Lu Qi, president and COO of Baidu Group, also said in a speech last year: "Engineering Excellence is a never-ending, individual, team, ability pursuit and tool platform innovation, which together can bring us long-term, core competitiveness." Relentless pursuit of excellence, this is the attitude we should stick to.

Five practices of DevOps transformation. Accustomed to working in small batches (development, architecture, evolution of organizational culture), creating feedback loops (pipeline construction), cross-functional collaboration through value streams, establishing experimental organizational culture, continuously eliminating waste and optimizing value streams

Suggestions for the implementation of DevOps transformation. Focus on key competency elements of DevOps transformation, agree on measurable business goals, give team resources to experiment and motivate learning, communicate with other teams and encourage collaboration, achieve quick wins, share successful experiences, and continue to improve.

After reading the above, have you mastered the five major practices of DevOps and the specific implementation process of the transformation? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.