11 important things you need to know about DevOps - part one

From translator

In 2009, a movement appeared abroad that called itself DevOps. At first glance, they are developers with the skills of system administrators and system administrators with the skills of developers. But in fact this is not the case. This approach has clear objectives, philosophy, tools and methods that only some Russian-speaking companies are beginning to use. It seems to me that this approach is being undeservedly ignored and I would like to tell you about 11 things you need to know about DevOps, in particular:

• what is DevOps
• what are its values
• how is it implemented
• who does he benefit from

I hope you enjoy this text.

1. What is DevOps and where does it come from?

The term “DevOps” is commonly referred to as an emerging professional movement that advocates a joint working relationship between developers and the IT department, resulting in faster execution of planned work (for example, high deployment rates), while increasing reliability, stability, sustainability and safety of production- environment. Why developers and IT departments (hereinafter referred to as admins for short)? Because, as a rule, the value stream (value stream) is located between the business (where requirements are determined) and the customer (where the result is delivered).

The DevOps movement is believed to have emerged in 2009 as the union of numerous contiguous and complementary communities: the Velocity Conference, where John Allspaw and Paul Hammond’s “10 Deploys A Day” performance (Mark Burgess and Luke Kanies), "Agile infrastructure" (Andrew Shafer) and system administration in Agile (Patrick DeBois), Eric Rice's Lean Startup approach with its continuous integration, as well as the wide availability of cloud and PaaS technologies.

One of the co-authors of the DevOps Cookbook, John Willis, wrote a fantastic post about this event.
')

2. How are DevOps different from Agile?

One of Agile's principles is to provide working software with smaller and more frequent releases, in contrast to the big bang approach, which is inherent in the waterfall methodology. So Agile tends to have a potentially finished product at the end of each sprint (usually every two weeks).

High deployment rates result in a large mountain of tasks accumulating in front of admins. Clyde Logue, the founder of StreamStep, says it this way: “Agile played an important role in developing to restore business confidence, but he accidentally left IT Operations behind. DevOps is a way to restore trust in the entire IT organization. ”

DevOps complements Agile particularly well, as it expands and complements the processes of continuous integration and product release, making sure that the code is ready for release and carries value for the customer.

DevOps allows you to create a much more continuous work flow in the IT division. If the code is not supplied as an item, as it was developed (for example, developers deliver the code every two weeks, but it is deployed only once every two months), installation operations will accumulate before admins, customers will not receive important functionality for themselves and the installation process itself in this case leads to chaos and disorganization.

DevOps, among other things, changes the culture, as well as changes the processes and metrics of developers and admins. John Willis and Damon Edwards (co-authors of DevOps Cookbook) wrote in detail about this here .

3. How is DevOps different from ITIL and ITSM?

Although many people believe that DevOps is a reaction to ITIL (IT Infrastructure Library) and ITSM (IT Service Management), I have a different point of view. ITIL and ITSM are still the best codification of the business processes that underlie the IT department, since they actually describe many of the things needed for an IT team to work in DevOps format.

Continuous integration and releases are the result of the work of developers, which in turn is the material for the work of admins. In order to keep pace with the faster release rhythm that exists in DevOps, many ITIL processes require automation, in particular, related to configuration changes and releases in general.

The purpose of DevOps is not so much an increase in the speed of issuing a new functional, as the deployment of this functional in production, without chaos and disruption of an already running application, as well as the rapid detection and correction of problems if they still occur. This adds to ITIL such items as setting up services, managing incidents and problems.

4. How is DevOps similar to VisibleOps?

In collaboration with Kevin Behr and George Spafford, I wrote The Visible Ops Handbook in 2004. Visible Ops is a guide to achieving transformation to high-performance IT departments along the path “from good to great”, and one of the key concepts is the concept of limiting and reducing unplanned work.

DevOps, in turn, focuses primarily on how to create a fast and stable stream of planned work on development and administration. However, DevOps also has a more holistic approach to systematically eliminating unplanned work, addressing the principles of responsible management and reducing technical debt.

5. What are the principles of DevOps?

In DevOps Cookbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, we describe the underlying principles by which all DevOps patterns can be obtained using the Three Ways approach. They describe the values ​​and philosophy that are the basis of the processes, procedures, practices, as well as mandatory steps.

The First Path emphasizes the performance of the entire system as a whole, in contrast to the performance of an individual link or department — this can be either a large division (for example, a development or IT department) or individuals (for example, a developer, a system administrator).

The focus is on all value creation business flows that are included in IT. In other words, it begins when the basic requirements are determined (for example, for business or IT), they are finished in development, and then transferred to the IT department, in which the value of the service is then delivered to the customer as a service.

The results of following the First Path in practice consist in the fact that known bugs are never passed on to the next stage of work, local optimization never develops, leading to the creation of global degradation, there is a continuous improvement and a desire to achieve a deep understanding of the system (in accordance with Deming).

The second Way is to create a feedback loop going from right to left. The goal of almost any process improvement initiative is to reduce and enhance feedback so that the necessary amendments can be implemented continuously.

Results of the Second Way: understanding and reaction to all clients, both internal and external, reducing and strengthening all feedback loops, and deepening knowledge of the environment where it is needed.

The third way is to create a culture that affects two things: constant experimentation, which requires taking risks and learning from success and failure, and understanding that repetition and practice are a prerequisite for mastery.

We need both of these principles in equal measure. Experimenting and accepting risks is what ensures that we will continue to improve, even if it means that we can go too far into the wilds. And we need to learn skills that can help us get out of the danger zone when we have gone too far.

The results of the Third Way include the allocation of time to improve daily work, the creation of rituals that encourage the team to take risks and the possible creation of system faults in order to increase stability in the future.

6. DevOps implementation areas

In the book "DevOps Cookbook", we identified 4 models of the introduction of DevOps:

Model 1 : Deepening development processes in delivery: this includes expanding continuous integration and release to combat servers, integration of testing and information protection into workflows, which gives ready-for-delivery code, customized environments, and so on.

Model 2 : Creating feedback from sales to development: includes creating a complete chronology of events in development and administration, to help solve problems, as well as providing access to the development team to analyze problems on the market, simultaneously with the creation of self-service developers, wherever it is possible, and the creation of information radiators, showing a change in the behavior of the system when you make changes.

Model 3 : Integrating development and administration: consists of including the development team in the problem resolution chain, assigning developers to solve problems on the market, as well as mutual training between developers and administrators to reduce the number of escalations.

Model 4 : Involving the IT team in development: consists of including or closely linking IT and development, creating multi-stage user stories (including deployment, managing code in production, etc.), and defining non-functional requirements that can be used in all projects.

7. What is the value of DevOps?

I believe that there are three business benefits that organizations get from switching to DevOps: quicker entry to the market (for example, shorter cycle times and higher deployment rates), improved quality (for example, increased availability, fewer failures, etc.) , and an increase in organizational efficiency (for example, more time is spent on activities associated with an increase in the value of the product as compared to losses, an increase in the amount of functionality transferred to the customer).

Fast time to market

In 2007, at the IT Process Institute, we tested more than 1,500 IT organizations and concluded that high-performance IT organizations were, on average, 5-7x orders of magnitude more productive than their low-performing peers. They made 14 times more changes, getting problems only half of the cases, while having the speed of correcting problems from the first time is 4 times higher, and also had 10 times shorter periods of inactivity. They had 4 times fewer re-audit results, they were 5 times more likely to find violations at the expense of an automated internal control system, and 8 times better fit the project deadlines.

One of the characteristics of high-performing teams is that they go far ahead from the crowd. In other words, the best gets even better. This happens in the area of ​​application deployment rates. Accenture recently conducted a study on what Internet companies are doing, and Amazon went on record, stating that they are doing more than 1,000 deployments per day, maintaining a successful change rate of 99.999%!

The ability to maintain high deployment rates (for example, fast cycle time) is transformed into business value in two main ways: how quickly an organization can move from an idea to something that can be transferred to a customer and how many experiments an organization can conduct at the same time.

No doubt, if I work in an organization where I can only do one deployment every nine months, and my competitor can do 10 installations a day, I have significant, structural competitive disadvantages.

High rates of deployment allow you to experiment quickly and almost continuously. Scott Cook, the founder of Intuit, was one of the most ardent supporters of the "rampant innovation culture" at all levels of the organization. One of my favorite examples is given below :

"Every employee [should be able to] conduct fast, high-speed experiments ... Dan Maurer runs our customer department, including the launch of the TurboTax website. When he began work on this project, we did about seven experiments in a year. Due to the introduction of an innovative culture, they are now doing 165 experiments during the three months of the tax season. Business result? Website conversion rate is up to 50 percent. Result for employees? People just love it, because now their ideas can hit the market. "

For me, the most shocking part of Scott Cook’s story is that they did all these experiments during the peak tax filing season! Most organizations stop changing during peak season. But if you can increase your conversion rate, and therefore sales, during peak season, when your competitor cannot, then this is a genuine competitive advantage.

Prerequisites for this include the ability to be able to make many small changes quickly, without interruption in customer service.

Reducing the loss of IT-department

Mike Orzen and I once talked about the huge losses in the IT stream caused by long periods of inactivity, slow transfer of work, unplanned work and rework. For the article by Michael Krigsman, we estimated how much useful activity we could return by applying the principles of DevOps.

We calculated that if we could just halve the number of IT losses, and also redistribute these money in such a way that we could return five times more than was invested, we would produce $ 3 trillion worth of useful activity per year. This is a staggering amount of money and opportunity that we allow to slip out of our hands. This is 4.7 percent of annual global GDP, or more than all of Germany’s total output.

I think this is important, especially when I think of a world in which my three children will live. The potential economic impact on productivity, standard of living and prosperity puts it first.

However, there is another type of loss. People in most IT organizations often feel left out and frustrated. People feel as if they are trapped in an ever-recurring horror movie and are helpless to change the ending. Management renounces its responsibility for IT, which often leads to endless wars between development, IT and information security departments. And things only get worse when auditors reveal all this. The life of IT professionals is often demoralized and full of disappointments, which, as a rule, leads to a feeling of powerlessness and fills with stresses that permeate every aspect of life.

As humans, we strive to create and feel that we are part of something big. However, all too often, when IT professionals ask their organization for support, they hear “You don't understand,” or even worse, barely covered, “You are nobody.”