Book Club: The DevOps Handbook (Chapter 20. Convert Local Discoveries into Global Improvements)

The following is a chapter summary for “The DevOps Handbook” by Gene Kim, Jez Humble, John Willis, and Patrick DeBois for an online book club.

The book club is a weekly lunchtime meeting of technology professionals. As a group, the book club selects, reads, and discuss books related to our profession. Participants are uplifted via group discussion of foundational principles & novel innovations. Attendees do not need to read the book to participate.

Background on The DevOps Handbook

More than ever, the effective management of technology is critical for business competitiveness. For decades, technology leaders have struggled to balance agility, reliability, and security. The consequences of failure have never been greater―whether it’s the healthcare.gov debacle, cardholder data breaches, or missing the boat with Big Data in the cloud.

And yet, high performers using DevOps principles, such as Google, Amazon, Facebook, Etsy, and Netflix, are routinely and reliably deploying code into production hundreds, or even thousands, of times per day.

Following in the footsteps of The Phoenix Project, The DevOps Handbook shows leaders how to replicate these incredible outcomes, by showing how to integrate Product Management, Development, QA, IT Operations, and Information Security to elevate your company and win in the marketplace.

The DevOps Handbook

Chapter 20

Use Chat Rooms and Chat Bots to Automate and Capture Organizational Knowledge

Having work performed by automation in a chat room has numerous benefits, including:

• Everyone sees everything that is happening
• Engineers on their first day of work can see what daily work looks like and how it’s performed
• People are more apt to ask for help when they see others helping each other
• Rapid organizational learning is enabled and accumulated

Automate Standardized Processes in Software Re-use

Instead of putting our expertise into Word documents, teams need to transform these documented standards and processes, which encompass the sum of our organizational learnings and knowledge, into an executable form that makes them easier to reuse.

One of the best ways to make this knowledge re-usable is by putting it into a centralized source code repository, making the tool available for everyone to search and use.

ArchOps: “enables our engineers to be builders, not bricklayers. By putting our design standards into automated blueprints that were able to be used easily by anyone, we achieved consistency as a byproduct.”

Justin Arbuckle

Create a Single, Shared Source Code Repository For The Entire Organization

A firm-wide, shared source code repository is one of the most powerful mechanisms used to integrate local discoveries across the entire organization.

Put into the shared source code repository not only source code, but also other artifacts that encode knowledge and learning, including:

• Configuration standards for libraries, infrastructure, and environments
• Deployment tools
• Testing standards and tools, including security
• Deployment pipeline tools
• Monitoring and analysis tools
• Tutorials and standards

Spread Knowledge By Using Automated Tests As Documentation and Communities of Practice

When team have shared libraries being used across the organization, they should enable rapid propagation of expertise and improvements. Ensuring each of these libraries has significant amounts of automated testing included means the libraries become self-documenting and show other engineers how to use them.

The benefit will be nearly automatic if teams practice test-driven development (TDD), where automated tests are written before the code. This discipline turns test suites into a living, up-to-date specification of the system.

Design For Operations Through Codified Non-Functional Requirements

Examples of non-functional requirements include:

• Sufficient production telemetry in applications and environments
• The ability to accurately track dependencies
• Services that are resilient and degrade gracefully
• Forward and backward compatibility between versions
• The ability to archive data to manage the size of the production data set
• The ability to easily search and understand log messages across services
• The ability to trace requests from users through multiple services
• Simple, centralized runtime configuration using feature flags and so forth

Build Reusable Operations User Stories Into Development

Instead of manually building servers and then putting them into production according to manual checklists, automate as much of this work as possible. Ideally, for all recurring Ops work teams will know the following: what work is required, who is needed to perform it, and what the steps to complete it are.

“We know a high availability rollout takes fourteen steps, requiring work from four different teams, and the last five times we performed this, it took an average of three days.”

The DevOps Handbook

Ensure Technology Choices Help Achieve Organizational Goals

When expertise for a critical service resides only in one team, and only that team can make changes or fix problems, this creates a bottleneck.

The goal is to identify the technologies that:

• Impede or slow down the flow of work
• Disproportionately create high levels of unplanned work
• Disproportionately create large numbers of support requests
• Are most inconsistent with the desired architectural outcomes (e.g. throughput, stability, security, reliability, business continuity)

Series Navigation

<< Book Club: The DevOps Handbook (Chapter 19. Enable and Inject Learning into Daily Work)Book Club: The DevOps Handbook (Chapter 21. Reserve Time to Create Organizational Learning and Improvement) >>