11 things you need to know about DevOps

Transferred from: Http://www.infoq.com/cn/articles/11devops

About the author

Gene Kim is an award-winning player in multiple roles: CTO, researcher, and writer. He was the founder of Tripwire and was the CTO for 13 years. He has written two books, including "The Visible Ops Handbook", and is currently writing the Phoenix Project:a novel about IT, DevOps, and helping Your business Win "and" DevOps Cookbook ". Gene is a huge fan of IT operations and is obsessed with improving operations-without impacting the current IT production environment, allowing developers to deliver more operational functionality to production rather than just completing the code. He has worked with a number of top Internet companies to improve their publishing processes and improve the integrity of IT operations processes. In 2007, Computer World put gene on the list of "40 innovative IT professionals under the age of 40", and Purdue University awarded him the Outstanding Alumni Award to honor his accomplishments and leadership in the field of expertise.

Directory

1. What is DevOps
2. What is the difference between devops and agility?
3. What is the difference between DevOps and ITIL and ITSM
4. DevOps and visual operations
5. The basic principles of DevOps
6. Application areas of the DevOps model
7. The value of DevOps
8. How information security and QA fit into a devops workflow
9. One of my favorite devops patterns
10. My favorite DevOps Model II
11. My favorite DevOps model is three

1. What is DevOps

The term "DevOps" usually refers to the emerging specialization movement, which advocates a high degree of synergy between development and IT operations, thus improving the reliability, stability, resiliency, and security of the production environment while completing high-frequency deployments.

Related Vendor Content

AWS Business Value Microsoft SharePoint Server 2013 on AWS Cloud: QuickStart Reference deploying Docker on AWS: Running container scenarios in a cloud environment Amazon Web Services Overview MongoDB on the AWS Cloud: Quick Start Reference deployment

Why is development and IT operations? Because a typical value stream is between a business (defining a requirement) and a customer (delivering value).

The origins of the DevOps movement are usually placed around the 2009, accompanied by a number of movements that complement and promote each other-the efficiency seminar movement, especially the groundbreaking "10 deployments of the day" by John Allspaw and Paul Hammond, the "infrastructure as a Code" campaign (Mark Burgess and Luke Kanies), "Agile Infrastructure Movement" (Andrew Shafer), "Agile Systems Management" movement (Patrick Debois), "Lean Startup" campaign (Eric Ries), Jez Humble's continuous integration and release campaign, And the development of Amazon's "platform as a service movement" and other activities that complement and promote each other.

Co-author of DevOps John Willis wrote a very good post here

http://itrevolution.com/the-convergence-of-devops/

2. What is the difference between devops and agile?

As opposed to waterfall development, one of the fundamental principles of the agile development process is the delivery of minimal software available at a faster rate. In the agile goal, the most obvious is that at the end of each sprint iteration cycle, there is the ability to deliver.

The high frequency of deployment often leads to deployment piling up in front of IT operations. Clyde Logue, founder of Streamstep, summed up one sentence: "Agility is good for developing trust in business, but it is not intended to keep IT operations out of the way, and DevOps enables IT organizations to regain business trust as a whole."

DevOps and agile software development are mutually reinforcing, as it expands and complements the continuous integration and release process, thus ensuring that code is available on the production and that it does deliver value to the customer.

DevOps not only creates a workflow for IT operations, but when the code is already developed but cannot be deployed to production, these deployments accumulate in front of IT operations, customers will not be able to enjoy any value, and worse, deployments often lead to disruption of the IT environment and service unavailability.

DevOps has an innate genetic component of cultural change, as it revolutionized the workflow and traditional metrics of development and IT operations. John Willis and Damon Edwards (two co-authors of the DevOps Cookbook) wrote a number of articles on this topic:

http://itrevolution.com/devops-culture-part-1/

3. What is the difference between DevOps and ITIL and ITSM?

While many people view devops as a subversion of ITIL and ITSM, I have a different view, and the ITIL and ITSM processes are undoubtedly the best in supporting IT operations. In fact, they describe a collection of features that need to be supported by IT operations, which are sufficient to support a DevOps-style workflow.

Agile and continuous integration and continuous release are the outputs of the development, which serve as inputs to the IT operations, and in order to adapt to the pace of rapid deployment associated with DevOps, many aspects of the ITIL process, especially around the change, configuration, and release processes, need to be automated.

The goal of DevOps is not only to increase the frequency of changes, but also to ensure that functional deployment is successful without disrupting and destroying current services, and that defects can be detected and repaired quickly. This introduces the new ITIL guidelines for service design, accident and problem management.

4. How devops and visual operations match

In 2004, I co-authored with Kevin Behr and George Spafford, the Visible Ops Handbook, a descriptive guide that enables high-performance IT operations to achieve a transition from excellence to excellence. One of the key points is how to control and reduce unplanned work.

DevOps is not only focused on creating fast and stable planning workflows between development and IT operations, but DevOps also has a more holistic approach to systematically eliminate unplanned work, define development resilience guidelines, and be responsible for managing and reducing technical debt.

5. The basic principles of DevOps

In the book "The Phoenix project:a novel about IT, DevOps, and helping Your business Win" and "DevOps Cookbook", we describe the principles of devops support-"De Vops three basic points ", all DevOps models can derive from these 3 basic points.

The first basic point emphasizes the performance of the system as a whole, rather than limiting performance to a particular area of work, which can be as large as a department (for example, development and IT operations) or as small as a personal contributor (e.g. developers, system administrators, etc.).

The focus is on the business value stream driven by it, in other words, it starts with a requirement definition (such as defined by the business or it), builds it, and gives it operations, with the final value delivered to the customer in the form of a service.

Practice the result of the first basic point-never pass a known defect downstream, never pound foolish, always working to improve the process, clinging to a deep understanding of the system requirements (according to Deming's theory)

The second basic point is about creating a right-to-left feedback loop, and almost all of the process improvement plans aim to shorten and amplify the feedback loop so that the necessary corrections can be sustained.

Applying the results of the second basic point-including understanding and responding to all internal and external customers-shortens and amplifies all feedback loops, and, if necessary, easily embeds the knowledge required by the customer.

The third basic point is to create a culture that promotes two things-the spirit of continuous exploration, the courage to take risks and the ability to learn from success and failure, as well as remembering that repetition and practice are prerequisites for mastery.

These two things are equally important to us, and the spirit of exploration and risk-taking ensures that we continue to improve, and it even means that we may have reached dangerous areas that we have not been to before, so it forces us to learn, master and integrate those skills so that we can leave the danger zone smoothly.

The result of the third basic point-allocating time to improve daily routines, fostering a spirit of reward and risk-taking and proactively introducing failures into the system to improve resilience.

6. Application areas of the DevOps model

In "DevOps Cookbook", we divide the DevOps model into 4 areas,

Domain one, extending development to production-including extending continuous integration and release capabilities to production, integrating QA and information security to the entire workflow, ensuring that code and environment can be deployed directly in production.

Field two, adding production feedback to development-including a complete timetable for building development and IT operations events to help with incident resolution, allowing development to be integrated into the production rethink without blame, making development self-service as much as possible, and creating information indicators to show how local decisions affect global goals.

Field III, development embedded into IT operations dimension-including development into the entire production problem chain, allocating development resources for production problem management, and assisting in the return of technical debt, and developing the ability to provide cross-training for IT operations to increase IT operations, thereby reducing the number of escalation issues.

Field four, embedding IT operations into development-including embedding and contacting IT operations resources to development, helping to develop reusable user stories for IT operations (deployment, Production code management, etc.), and defining some non-functional requirements that can be shared across all projects.

7. The value of DevOps

I believe that enterprises can get 3 business advantages after applying DevOps: products are quickly brought to market (e.g., shorten development cycle time and higher deployment frequency), improve quality (for example, improve availability, improve the success rate of change, reduce failures, etc.) and improve the effectiveness of the Organization (for example, Spend time on value-added activities, reduce waste, and deliver more value to customers.

Products to market quickly:

In 2007, after reviewing more than 1500 IT organizations in the IT Process Association, we concluded that efficient IT organizations were 5 to 7 times times more effective than the average organization. Change to 14 times times more, change the rate of failure only the former 1/2, the first repair rate is 4 times times higher, and one-time accident is 10 times times shorter. Repeat audit found to be 4 times times less, through internal control to detect the vulnerability is about 5 times times higher, and 8 times times the former project due date performance!

In our study, the highest frequency observed was about 1000 production changes per week, with a success rate of 99.5%, which we thought was really fast ...

One of the high performance features is that it is better to continue to be better. This is definitely happening in the field of frequency of deployment. Organizations that have applied devops practices are showing faster rapid deployment and implementation, and are several orders of magnitude faster than a typical organization.

Accenture has recently done a study: What are internet companies doing? Amazon's records show that they are maintaining their current weekly deployment of 1000 times, while still guaranteeing a 99.999% success rate!

Http://www.youtube.com/watch?v=dxk8b9rSKOo

HTTP://WWW.SLIDESHARE.NET/SLIDESHOW/EMBED_CODE/9466635?STARTSLIDE=33)

The ability to maintain a high deployment rate (that is, a fast iteration count) translates into two main ways of business value:

How the organization can quickly turn an idea into value into the hands of the customer (for example, Damon Edwards and John Willis say "concept to landing"), the organization could do multiple attempts at the same time.

For me, if I were in an organization that could be deployed every 9 months, and my competitors could deploy 10 times a day, I would undoubtedly have a clear competitive disadvantage.

High-frequency deployments also enable rapid and ongoing deployment. Intuit's founder, Scott Cook, has been advocating a "sharp innovation culture" at all levels of the organization, and one of my favorite examples is the http://network.intuit.com/2011/04/20/ leadership-in-the-agile-age/.

"Every employee should be able to deliver quickly and at high speed ... Dan Maurer is responsible for our consumer sector, including the TurboTax website. When he takes over, we deploy only a few times a year, but by creating a sharp culture of innovation, they can now deploy 165 times in the 3 months of the tax season. Business value? Website conversion rate of up to 50%. Employee value? These guys really love it because they can quickly deliver their ideas to the market.

For me, the most shocking story of Scott Cook is that they do all these deployments during the busy tax season! In high season, most organizations freeze any changes (for example, from October to January, retailers may often have a change freeze). But if you can improve the conversion rate in the high season, and your competitors can't, then this is a real competitive advantage.

The premise of this effect is that many small changes can be quickly completed and deployed without impacting the customer base.

Reduce Total it waste:

Mike Orzen and I talked very early about the huge waste in the IT value stream, which was due to extended delivery deadlines, poor handover, unplanned work and rework. An article based on Michael Krigsman, after applying the principles of DevOps, can save a lot of value, not waste.

We have calculated that if we can reduce the amount of it waste by half and then reinvest those savings, we can generate a value of $30 trillion a year if we get 5 times times the return on investment.

This is a great value and opportunity to slip past our fingertips. accounts for 4.7% of global GDP, even surpassing the entire German economic output.

I think it's really important, especially when I think about the world my three children will inherit, and the potential impact of these wastes on productivity, living standards and economic prosperity is growing, and I feel compelled to change.

However, there is a greater cost, and in most IT organizations, work is thankless and frustrating, and people feel as if they are trapped in a recurring horror movie and cannot change the final outcome. Managers should have managed it well, but they have given up on the responsibility to directly lead to development, an endless division of conflict between IT operations and information security, and the presence of auditors only makes things worse.

In the long run, the inevitable result is slow progress. The life of IT professionals tends to be frustrating and frustrating, often leading to a sense of powerlessness and high-pressure conditions that permeate every aspect of life. IT professionals face stress-related health problems, social problems, and home problems that make them unhealthy, and life is likely to be unsustainable.

As human beings, we are destined to contribute, it feels as if we are playing an active role, different. But often when IT professionals ask their organizations for help, they get the answer: "You don't understand" and, worse, they even get the "You don't matter" treatment.

8. How information security and QA fit into a devops workflow

The high deployment frequency of devops often brings a lot of pressure to QA and information security, considering a scenario where development is deployed 10 times a day, and information security typically takes 4 months to assess the security of the application. Obviously, the rate of code development and code security auditing does not match at all.

The 2011 Dropbox failure is a well-known example of how much risk is associated with untested development code. Because of this accident, the authentication function was shut down for 4 hours, which led to unauthorized users accessing all stored data.

Of course, it's not all bad news for QA and information security, and development will maintain high-frequency deployments through continuous integration and good publishing practices (culture of continuous testing). In other words, once the code is committed, the automated test begins to run, and once the problem is found, it must be resolved immediately, just as the developer checks for code that has not yet been compiled.

By integrating functional testing, integration testing and information security testing into the daily routine of development, problems will be discovered faster and faster.

Similarly, there are more and more information security tools, such as Gauntlet and security Monkey, that can help us to test the security objects in the process of development and on-line, to achieve the information security objectives.

But there is also a very important question to consider, static code analysis tools usually take a long time to run out, in hours or days of memory. In this case, information security must indicate a specific security risk of the module, such as encryption, authentication module. As long as these modules change, a comprehensive round of information security testing runs, otherwise the deployment can continue without the need for full coverage of information security testing.

One particular point to note is that, compared to standard functional unit testing, DevOps workflows rely on detection and recovery for a bit more. In other words, it is difficult to deploy changes and patches when the development is delivered as a software suite, and QA relies heavily on code testing to verify the correctness of the functionality. On the other hand, when the software is delivered in the form of a service, defects can be repaired quickly. And QA can also reduce testing dependencies and replace them with more-dependent production monitoring, as long as defects can be quickly repaired.

Code failure recovery enables you to avoid a full-featured deployment by enabling or disabling certain code features in the form of a configuration, by means of a "functional label", instead of deploying only the functionality that is tested to production.

It is a better choice to rely on detection and recovery for QA when the functionality is not available or the performance is degraded, such as when worse occurs. But when it comes to loss of confidentiality or data and system consistency, we can not rely on detection and recovery of this method. Instead, adequate testing is required before deployment, which could lead to significant security incidents.

9. One of my favorite devops patterns

Typically, in a software development project, development runs out of all the planned time for development functionality. This leads to an inability to adequately address IT operations, and they save time by simply taking shortcuts in defining, creating and testing code dependencies such as databases, operating systems, networks, and virtualization.

So this is the main reason for the constant tension between development and IT operations and suboptimal results. The consequences are serious, such as inappropriate definitions and specified environments, inability to redeploy, incompatible code and environment, and so on.

In this mode, we will re-develop the process early to make environmental demands, and force the Code and environment to be tested together, once the agile development method is used, we can do it very concisely and elegantly.

As agile requires, at the end of each iteration, we publish code that can be run and can be deployed, typically two weeks. We will modify the agile iteration cycle strategy to not only deliver the code that can be run and be deployed, but also in the early stages of each iteration cycle and have to prepare the environment for deploying the code.

As a result, we no longer allow IT operations to create the specifications for the production environment, and instead, create an automated environment creation process that not only creates production environments, but also includes development and QA environments.

By making the environment available early, and perhaps even before a software project starts, development and QA can run and test their code in a unified and stable environment to control the differences between different environments.

In addition, by keeping the smallest possible differences between phases (for example, development, QA, integration testing, production), we can identify and fix interoperability issues between code and the environment before production deployment.

Ideally, the deployment mechanism we have built is fully automated. You can use many tools like shell scripting, Puppet, Chef, Soaris Jumpstart, Redhat Kickstart, Debian preseed, and much more.

10. My favorite DevOps Model II:

Browsermob former Ceo,patrick Lightbody once said, "When we woke up the development engineer at 2 o'clock in the morning to solve the problem, the bug was repaired faster than before, which is really an amazing feedback loop",

This is one of my favorite references.

It highlights the key points of the problem, where development typically submits code at 5 in Friday, and then happily goes home, while it ops spends an entire weekend cleaning up the mess. Worse, defects and known errors are constantly being handed down in production, forcing IT operations to keep fighting fires, and the root cause never gets repaired because development is always focused on developing new features.

An important element of the second model is to shorten and amplify the feedback loop, making development closer to the customer experience (including IT operations and end users)

Pay attention to the symmetry here, the pattern of a discussion as early as possible to make the environment uniform and available is to embed IT operations into the open, and the second model is to embed the development of the IT operations dimension.

We will develop an escalation chain embedded in the IT operations, which can be placed in level three support and even be responsible for the successful deployment of the entire code. Either roll back or fix the defect until the service is restored.

Our goal is not to allow development to replace IT operations, but rather to make sure that development sees downstream changes in their work and changes, motivating them to solve problems faster with IT operations, to achieve a global goal.

11. My favorite DevOps model is three:

Another frequently occurring problem in the DevOps value stream between development and IT operations is inadequate specification. An example of this is that each deployment has its own specificity, so it makes every deployment environment special, and once that happens, there is no control over the process configuration in the organization.

In this mode, we define a reusable deployment process that spans multiple projects, and there is a simple solution to the agile approach. is to turn the deployed activity into a user story. For example, we build a reusable user story for IT operations called "deploy to a highly available environment", a user story that defines the steps for a clear build environment, how long it takes, what resources are needed, and so on.

Then this information can be used by the project manager to integrate the deployment content into the project plan. For example, if we know that the "deploy to high-availability environment" User story has been deployed 15 times over the last 3 years, with an average deployment time of 3 days, plus or minus one day, we will be very confident in our own deployment plan.

In addition, we can gain confidence that deployment activities are properly integrated into software projects.

We also have to recognize that some specific software projects require a particular environment, and that they are not officially supported by IT operations, and that we can allow exceptions in those environments where production is allowed, but are supported by people outside the IT operations department.

In this way, we gain the benefits of environmental standardization (for example, reduced production variances, more consistent environments, increased support and maintenance of IT operations), and, in particular cases, the flexibility to provide business needs.

11 things you need to know about DevOps