DevOps Handbook

The sequence of activities an organization undertakes to deliver upon a customer request.

The process required to convert a business hypothesis into a technologyenabled service that delivers value to the customer.

From checking a change into version control to successfully running in production, providing value to the customer and generating useful feedback and telemetry.

Asking downstream customers what percentage of the time they receive work that is ‘usable as is.’

To help us see where work is flowing well and where work is queued or stalled, we need to make our work as visible as possible.

This high level of effort discourages frequent disruptions.

Large batch sizes result in skyrocketing levels of WIP and high levels of variability in flow.

Even under the best circumstances, some knowledge is inevitably lost with each handoff.

Any improvement not made at that constraint is an illusion.

Reduce hardship and drudgery in our daily work through continual learning in order to achieve the organization’s goals.

Design a safe system of work, where we can perform work without fear.

Increase information flow in our system sooner, faster, cheaper, and with clarity between cause and effect.

Converting inevitable up-front ignorance into knowledge.

Having developers share responsibility for the quality of the systems.

Our most important customer is our next step downstream.

When accidents and failures occur, instead of looking for human error, we look for how we can redesign the system to prevent the accident from happening again.

Even more important than daily work is the improvement of daily work.

Convert individual expertise into artifacts that the rest of the organization can use.

High performers achieve the same results (or better) by improving daily operations, continually introducing tension to elevate performance.

Create the conditions so their team can discover greatness in their daily work.

Although many believe that DevOps is primarily for greenfield projects, DevOps has been used to successfully transform brownfield projects of all sorts.

Chronic conflict between “doing it right” and “doing it fast” can be broken with DevOps.

Focus our energy on creating successes with less risk-averse groups.

We must demonstrate early wins and broadcast our successes.

Functional, matrix, and market organizations.

Have many small teams working safely and independently, quickly delivering value to the customer.

As long as everyone in the value stream views customer and organizational outcomes as a shared goal.

Everyone within the team shares a common goal—quality.

We don’t want to create specialists who are “frozen in time.”

Create stable service teams with ongoing funding to execute their own strategy and road map of initiatives.

Software architecture should enable small teams to be independently productive, sufficiently decoupled from each other so that work can be done without excessive or unnecessary communication and coordination.

An architecture that enables small teams of developers to independently implement, test, and deploy code into production safely and quickly, increases and maintain developer productivity and improve deployment outcomes.

Keep our team sizes small, reducing the amount of inter-team communication.

Operations to create a set of centralized platforms and tooling services that any Dev team can use to become more productive.

Embedding Operations engineers within the team, reducing their reliance on centralized Operations.

Assigning a designated liaison for each product team.

When Ops engineers are embedded or assigned as liaisons into our product teams, we can integrate them into our Dev team rituals.

By having Ops engineers attend, Operations can gain an awareness of the Development team’s activities, enabling better planning and preparation.

One of the primary mechanisms where organizational learning and the development of countermeasures occurs.

Put the Operations work that is relevant to product delivery on the shared kanban board.