What is *The DevOps Handbook* by Gene Kim about?

*The DevOps Handbook* provides a comprehensive guide to implementing DevOps principles, blending culture, automation, and lean practices to streamline software delivery. It introduces the "Three Ways"—Flow (accelerating work), Feedback (improving systems), and Learning (fostering experimentation)—to help organizations achieve agility, reliability, and security. The book combines theoretical frameworks with real-world case studies, emphasizing collaboration across IT teams.

Who should read *The DevOps Handbook*?

IT leaders, developers, operations teams, and product managers seeking to optimize software delivery and organizational culture will benefit most. It’s particularly valuable for those navigating digital transformations, addressing chronic conflicts between speed and stability, or aiming to build high-trust, cross-functional workflows.

Is *The DevOps Handbook* worth reading?

Yes—it’s a seminal resource for DevOps practitioners, offering actionable strategies for breaking silos and embedding continuous improvement. The book’s focus on both technical practices (e.g., CI/CD) and cultural shifts (e.g., blameless postmortems) makes it a practical toolkit for achieving faster deployment cycles and fewer outages.

What are the "Three Ways" in DevOps?

The Three Ways are core principles for DevOps success: 1. **Flow**: Accelerate work from development to operations. 2. **Feedback**: Enable rapid detection and resolution of issues. 3. **Learning**: Cultivate experimentation and risk-taking. These principles align teams around shared goals, reduce bottlenecks, and foster resilience.

How does *The DevOps Handbook* address organizational culture?

The book argues DevOps is as much about culture as technology, advocating for "generative" cultures that prioritize learning over blame. Practices like shared ownership, transparent metrics, and cross-functional collaboration help dismantle silos and build trust.

What technical practices does *The DevOps Handbook* recommend?

Key practices include automated testing, infrastructure-as-code, continuous integration/deployment (CI/CD), and monitoring. These reduce manual errors, accelerate feedback loops, and ensure code deploys safely to production. The authors stress integrating security ("DevSecOps") early in the development process.

How does *The DevOps Handbook* differ from *The Phoenix Project*?

While *The Phoenix Project* uses a fictional narrative to illustrate DevOps challenges, *The DevOps Handbook* serves as a practical field guide with step-by-step strategies. Both books, co-authored by Gene Kim, complement each other—one for storytelling, the other for implementation.

What are common criticisms of *The DevOps Handbook*?

Some note its breadth over depth, particularly in technical execution. Critics suggest it assumes organizational buy-in, which may oversimplify change-management hurdles. However, its case studies and adaptability to different contexts remain strengths.

Manuel DevOps

Comment créer une agilité, une fiabilité et une sécurité de classe mondiale au sein des organisations technologiques

Gene Kim & Jez Humble & Patrick Debois & John Willis & Nicole Forsgren

4.29(5778 Reviews)

Aperçu de Manuel DevOps

Le manuel DevOps (*The DevOps Handbook*) a révolutionné l'informatique grâce à son cadre pratique pour les organisations de haute performance. Approuvé par les leaders de la technologie et présentant des études de cas de Google et Netflix, il a transformé la manière dont des entreprises comme Capital One atteignent la fiabilité. Quel est le principe unique qui a rendu ces géants 10 fois plus agiles ?

Choisissez la façon de le raconter

Un livre. De nombreuses façons de l'écouter.

Les mêmes idées de Manuel DevOps. Choisissez la voix, la profondeur et le rythme qui vous conviennent. Changez à tout moment.

Chapitre 1

From Chaos to Collaboration: The DevOps Revolution

The year was 2011 when four technology visionaries began weekly Skype calls to discuss a radical idea that would transform how organizations deliver software. What started as a companion to "The Phoenix Project" evolved into something far more ambitious-a comprehensive guide to revolutionizing technology organizations through DevOps principles. Five years and two thousand hours later, "The DevOps Handbook" emerged as the definitive playbook for implementing DevOps practices. The book quickly became required reading in technology circles, with luminaries like Netflix's Adrian Cockcroft calling it "essential knowledge for every business and technology leader." Even more telling is how the book resonated with practitioners who found themselves nodding in recognition at the all-too-familiar scenarios of deployment chaos, midnight releases, and the adversarial relationship between Development and Operations that had become the norm in most organizations.

Chapitre 2

Breaking Down the Wall of Confusion Between Dev and Ops

Imagine a world where product owners, developers, QA, operations, and security professionals work together toward common goals. Where small teams can independently develop, test, and deploy code without creating chaos. Where deployments happen during business hours without heroics or downtime. This isn't a fantasy-it's the reality for organizations that have successfully implemented DevOps principles. The DevOps revolution parallels manufacturing's Lean transformation of the 1980s, which dramatically improved productivity and quality. Just as manufacturing plants reduced order lead times from six weeks to three weeks with 95% on-time shipping, technology delivery has similarly accelerated. What once took months or years now takes minutes in organizations adopting DevOps practices. This transformation couldn't be more urgent. As Jeffrey Immelt, former CEO of General Electric, observed: "Every industry and company not bringing software to the core of their business will be disrupted." Today's competitive advantage requires fast experimentation and market delivery-organizations unable to match the hundreds or thousands of daily deployments achieved by DevOps practitioners risk marketplace extinction. The traditional technology organization suffers from what Dr. Eliyahu Goldratt called a "core, chronic conflict"-Development wants to deliver features quickly while Operations prioritizes stability. This creates a downward spiral where work becomes more tightly-coupled, communication slows, approvals multiply, quality declines, and deployments take progressively longer with worse outcomes. The organization loses its ability to respond to market changes or provide reliable service. The human and economic costs are staggering. Employees trapped in failing systems experience powerlessness, burnout, cynicism, and learned helplessness. Long hours, weekend work, and decreased quality of life affect both employees and their families. Beyond human suffering, the economic opportunity cost is approximately $2.6 trillion annually-equivalent to France's entire economic output.

Voyez chaque mot au fil de l'écoute

Suivez facilement la lecture tandis que chaque mot de Manuel DevOps s'illumine en temps réel.

Chapitre 3

The Three Ways: Principles for Transforming Technology Organizations

DevOps is built on three foundational principles known as "The Three Ways," which provide a framework for transforming technology value streams. The First Way focuses on flow-accelerating the delivery of work from Development to Operations to customers. This requires making work visible, limiting work in process (WIP), reducing batch sizes, decreasing handoffs, identifying and elevating constraints, and eliminating waste. By optimizing for global goals rather than local efficiency, organizations can dramatically reduce lead times while improving quality. Unlike manufacturing, technology work is invisible-we can't easily see impeded flow or work piling up. Visual boards make work visible by representing it on cards that move from backlog through work centers to completion. Limiting WIP prevents new work from entering until existing work is completed, exposing problems that prevent work completion rather than starting new tasks. As David J. Anderson quipped, "Stop starting. Start finishing." Small batch sizes are essential for smooth flow. The newsletter mailing simulation demonstrates this dramatically: with large batch processing (folding all papers, then inserting all, then sealing all, then stamping all), the first completed envelope takes 310 seconds and any error requires redoing all ten. With small batch processing (completing one envelope fully before starting the next), the first envelope is done in just 40 seconds-eight times faster-and errors affect only one item. The Second Way establishes fast, constant feedback from right to left throughout the value stream. This creates safer systems by enabling problems to be detected and remediated while they're smaller and easier to fix. In complex systems, it's impossible for any single person to understand how all pieces fit together. As Dr. Sidney Dekker noted, doing the same thing twice won't necessarily yield the same result, making static checklists insufficient for preventing catastrophes. High-performing operations have fast, frequent, high-quality information flow throughout the value stream. In technology, we need feedback at all stages including Product Management, Development, QA, Infosec, and Operations through automated build, integration, and test processes, plus pervasive telemetry to monitor production systems. As Elisabeth Hendrickson noted, "Feedback is critical because it is what allows us to steer." The Third Way focuses on creating a culture of continual learning and experimentation. These principles enable constant creation of individual knowledge that transforms into team and organizational knowledge. In high-performing organizations, workers conduct experiments in daily work to generate improvements, supported by standardized procedures and documentation. A prerequisite for a learning culture is treating accidents as opportunities rather than reasons for punishment. Dr. Sidney Dekker warns that unjust responses to incidents promote fear instead of mindfulness and lead to secrecy and self-protection. The "Bad Apple Theory"-eliminating errors by removing people who cause them-is invalid because human error typically results from tool design problems, not bad people.

Chapitre 4

Starting Your DevOps Journey: Where and How

Choosing the right value stream for DevOps transformation requires careful consideration as it determines transformation difficulty, involved stakeholders, team organization, and individual enablement. As Michael Rembetsy from Etsy noted, "We must pick our transformation projects carefully-when we're in trouble, we don't get very many shots." When implementing DevOps, target teams that already believe in DevOps principles and have demonstrated ability to innovate. Following Geoffrey Moore's technology adoption lifecycle, focus initially on innovators and early adopters rather than trying to convert more conservative groups. Avoid the "big bang approach" of starting everywhere simultaneously, even with executive sponsorship. To expand DevOps successfully, break improvement goals into small, incremental steps that create early wins. Follow a methodical sequence: (1) Find innovators and early adopters who want to help, ideally respected people with organizational influence; (2) Build critical mass by expanding to receptive teams while avoiding political battles; (3) Only after achieving a silent majority, tackle the influential holdouts who might resist change. After selecting a value stream, create a value stream map to document how work flows through the system. This typically begins with customer requests from product owners, continues through development, testing, and deployment. While complex value streams may involve hundreds of steps and people, our goal isn't to document every detail but to identify areas jeopardizing fast flow, short lead times, and reliable outcomes. DevOps transformations inevitably conflict with ongoing business operations. Successful organizations create dedicated transformation teams operating outside normal organizational constraints. These teams should be fully allocated to DevOps transformation, staffed with generalists who maintain respectful relationships with the rest of the organization, and possibly given separate physical space to maximize internal communication.

Profitez davantage de Manuel DevOps

Recevez des idées chaque jour parmi plus de 100 000 leçons
Les mots s'illuminent au rythme de l'audio
Votre bibliothèque sauvegardée sur tous vos appareils

Chapitre 5

Conway's Law: How Team Structure Shapes Architecture

Dr. Melvin Conway's 1968 experiment showed how team structure directly shapes system design-a team of eight people divided to create two compilers resulted in architectures that mirrored their team divisions. Conway's Law states that "organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations." There are three primary organizational structures that affect DevOps value streams: functional-oriented organizations optimize for expertise and cost reduction by centralizing skills in tall hierarchies; matrix-oriented organizations attempt to combine functional and market approaches but often create complicated reporting structures; and market-oriented organizations optimize for customer responsiveness with flat, cross-functional teams that may create redundancies but enable faster delivery. Traditional IT Operations organized by functional specialties (database administrators, network administrators, server administrators) create long lead times for complex activities like deployments. Work must flow through multiple teams with handoffs and queues at every step. Workers often lack visibility into how their tasks connect to value stream goals, while Operations teams serve multiple Development teams competing for limited resources. To achieve DevOps outcomes, organizations should reduce functional orientation and enable market orientation with small teams working independently to deliver customer value. Rather than disruptive reorganizations, this involves embedding functional engineers (Ops, QA, Infosec) into service teams or providing their capabilities through automated self-service platforms. In high-performing organizations, quality, availability, and security become everyone's responsibility rather than belonging to separate departments. Team members share common goals and understand that their daily priorities might include deploying features, fixing production incidents, reviewing code changes, applying security patches, or improving engineering productivity.

Chapitre 6

Building the Technical Foundation for Fast Flow

To create reliable flow from Dev to Ops, we must use production-like environments at every value stream stage. These environments must be created automatically from version-controlled scripts and configurations, entirely self-serviced without manual Operations work. Our goal is to recreate the entire production environment based solely on version control content. Version control becomes our single repository of truth containing the precise intended state of the entire system-both code and environments. This practice must extend to everyone in the value stream: QA, Operations, Infosec, and developers. Puppet Labs' 2014 State of DevOps Report found that Operations' use of version control was the highest predictor of both IT and organizational performance-even higher than Development's use of version control. When we can quickly rebuild applications and environments on demand, we should rebuild rather than repair when problems occur. As Microsoft engineer Bill Baker noted, we're shifting from treating servers like pets (naming them and nursing them back to health) to treating them like cattle (numbering them and replacing sick ones). Without automated testing, the more code we write, the more time and money is required to test it-creating an unscalable business model. Manual testing and infrequent deployments create dangerous situations where developers learn about mistakes months after introducing them, breaking the critical link between cause and effect. Our goal is building quality into products from the earliest stages by having developers create automated tests as part of their daily work. This creates a fast feedback loop that helps find and fix problems quickly. We achieve this by building a deployment pipeline that performs integration of code and environments and triggers tests every time a change enters version control.

Voyez chaque mot au fil de l'écoute

Suivez facilement la lecture tandis que chaque mot de Manuel DevOps s'illumine en temps réel.

Chapitre 7

Enabling Fast, Safe Releases

Facebook's approach to code deployment exemplifies the power of automated, low-risk releases. Chuck Rossi, Facebook's director of release engineering, oversees daily code pushes that deploy across thousands of machines in just twenty minutes with no visible impact to users. By 2012, Facebook had doubled their release frequency to twice daily, enabling engineers worldwide to "move and ship as quickly as any other engineer in the company." To achieve Facebook-like deployment capabilities, we must first document our entire deployment process, then simplify and automate manual steps. This includes packaging code, creating pre-configured VM images, automating middleware deployment, copying files to production servers, restarting services, generating configuration files, running smoke tests, and scripting database migrations. Traditional software launches couple deployments with marketing releases, often leading to production failures under unexpected loads and painful rollback processes. To enable more frequent deployments, we must decouple deployments from feature releases: • Deployment is installing a specific software version to an environment • Release is making features available to customers When we conflate these activities, accountability for success becomes difficult. Decoupling allows Development and Operations to be responsible for fast, frequent deployments, while product owners remain accountable for business outcomes of releases. Feature toggles allow selective enabling or disabling of features without requiring code deployment. Implemented by wrapping application logic or UI elements in conditional statements controlled by configuration settings, they provide several benefits: easy rollback by disabling problematic features, graceful performance degradation during high loads, and increased resilience in service-oriented architectures.

Chapitre 8

Creating Feedback Loops for Continuous Improvement

In complex systems, problems inevitably occur-small changes can trigger unexpected outcomes including global outages affecting all customers. These cascading failures can emerge from seemingly minor code changes, configuration updates, or infrastructure modifications. When production issues arise, we often lack the information needed to determine whether the problem stems from application defects, environmental issues, or external factors like third-party service disruptions or network problems. To enable effective problem detection and resolution, teams must create comprehensive telemetry across all application stack levels and environments. This requires metrics from five key areas: business level (sales transactions, revenue, user signups, conversion rates, customer engagement metrics), application level (transaction times, response times, faults, error rates, queue depths, cache hit ratios), infrastructure level (web traffic patterns, CPU load, memory usage, disk usage, network latency, database performance), client software level (errors, crashes, user-measured transaction times, app load times, client-side JavaScript errors), and deployment pipeline level (build status, deployment lead times, environment status, test coverage, security scan results). By establishing this complete telemetry coverage, teams can monitor service health using data rather than speculation, detect security events through application and infrastructure faults, and identify problems earlier when they're smaller and easier to fix. Real-time dashboards and automated alerts help teams spot emerging issues before they impact customers. Historical metric analysis enables teams to identify patterns and prevent future incidents. To prevent recurring production problems from being deprioritized, everyone in the value stream should share operational incident responsibilities. By putting developers, managers, and architects on pager rotation, teams ensure upstream decisions receive visceral feedback. This shared ownership model creates stronger alignment between development and operations teams. As Patrick Lightbody of New Relic observed, "When we woke up developers at 2 a.m., defects were fixed faster than ever." This approach also helps build institutional knowledge as team members gain direct experience with production systems. Regular incident reviews and blameless postmortems help teams learn from failures and implement systematic improvements. Teams should maintain runbooks documenting common issues and resolution steps, conduct chaos engineering experiments to proactively identify weaknesses, and continuously refine monitoring thresholds based on operational experience. Effective feedback loops require not just collecting data, but establishing processes to act on insights and prevent future problems.

Profitez davantage de Manuel DevOps

Recevez des idées chaque jour parmi plus de 100 000 leçons
Les mots s'illuminent au rythme de l'audio
Votre bibliothèque sauvegardée sur tous vos appareils

Chapitre 9

Building a Learning Organization

Blameless post-mortems serve as crucial learning tools by meticulously recording detailed timelines of incidents, documenting not just what happened but why decisions were made at each step. These sessions capture the complete narrative: initial alerts, response actions, observed system behaviors, investigation paths explored (both successful and unsuccessful), and the reasoning behind chosen resolutions. The "blameless" aspect is critical - it shifts focus from who made mistakes to understanding systemic issues and environmental factors that contributed to the incident. Key stakeholders must attend, including decision-makers, incident responders, those who first identified the issue, technical leads who diagnosed the problem, and representatives from affected teams or business units. After conducting these post-mortems, organizations need robust knowledge-sharing mechanisms. Meeting notes, technical diagrams, timeline reconstructions, and other artifacts should be stored in a centralized, searchable location accessible to all employees regardless of role or department. This transforms localized learnings into organizational wisdom. At Google, as Randy Shoup explains, all post-mortem documents are indexed and searchable through internal tools, enabling teams facing similar incidents to quickly find relevant historical cases. Teams can search by technology stack, error type, impact scope, or resolution approach to learn from past experiences. Rather than relying on traditional documentation in static formats like Word documents or wikis - which engineers often struggle to find or lack time to implement - organizations should convert this knowledge into executable form. This means transforming best practices and learned lessons into reusable code, automated tests, monitoring configurations, and deployment scripts stored in central repositories. These tools become living documentation that teams actively use rather than reference materials that gather dust. A unified, organization-wide source code repository serves as a powerful mechanism for cross-team learning and improvement. When shared libraries, tools, or infrastructure components are enhanced based on incident learnings, these improvements automatically propagate to all dependent services through established deployment pipelines. This ensures that lessons learned in one corner of the organization benefit everyone. Google exemplifies this approach with their monolithic repository containing over one billion files and two billion lines of code, accessed by all 25,000 engineers across products from Search to YouTube to Cloud. This shared codebase enables rapid distribution of security patches, performance improvements, and architectural best practices across the entire technical organization. The repository also serves as a historical record, allowing teams to understand how and why systems evolved over time. Code review comments, commit messages, and associated documentation provide context about past decisions and trade-offs, creating an invaluable learning resource for current and future team members.

Chapitre 10

Integrating Security into the DevOps Pipeline

DevOps presents one of the most effective frameworks for integrating information security into daily technology operations across the entire value stream, despite the common resistance expressed as "Information security and compliance won't let us." When Infosec operates in isolation from Development and Operations, significant challenges emerge, particularly due to the typical engineer ratio of 100:10:1 between Development, Operations, and Infosec. This imbalance often results in security becoming a bottleneck and being viewed as an impediment rather than an enabler. To effectively engage Infosec teams earlier in projects, organizations should implement several key practices. First, security teams should be regular participants in product demonstrations at the end of each development interval or sprint. This involvement serves multiple purposes: helping them understand team goals within broader organizational objectives, allowing them to observe implementations as they're being built, and enabling them to provide guidance when corrections are least expensive and most straightforward to implement. For example, a security team might identify potential vulnerabilities in API authentication methods during a sprint demo, allowing developers to address these issues before they become deeply embedded in the codebase. Security issues should be tracked in the same work management system used by Development and Operations teams, making security work visible and prioritizable alongside other development tasks. Nick Galbreath, former head of Information Security at Etsy, implemented this approach by integrating all security issues into JIRA with clear priority designations: P1 issues requiring immediate attention and P2 issues needing resolution within a week. This integration ensures security doesn't become an afterthought and helps teams maintain a balanced approach to feature development and security requirements. Security mechanisms and tools should be centralized in shared source code repositories, including pre-approved libraries for common security functions such as authentication, encryption, session management, and access control. For instance, teams might maintain a curated collection of security modules that implement industry best practices for password hashing, SSL/TLS configuration, and API security. This approach not only makes security artifacts readily available and searchable but also promotes standardization and reduces the risk of teams implementing their own, potentially flawed security solutions. Organizations should also implement automated security testing as part of their CI/CD pipeline, including: • Static Application Security Testing (SAST) for code analysis • Dynamic Application Security Testing (DAST) for runtime analysis • Software Composition Analysis (SCA) for third-party dependency scanning • Container security scanning for containerized applications This "shift-left" approach to security helps identify and remediate vulnerabilities early in the development cycle, reducing both risk and the cost of fixes.

Voyez chaque mot au fil de l'écoute

Suivez facilement la lecture tandis que chaque mot de Manuel DevOps s'illumine en temps réel.

Chapitre 11

The Path Forward: A Call to Action

Our call to action is simple yet powerful: identify and connect with individuals who are passionate about revolutionizing work practices, build robust coalitions of like-minded thinkers, and actively engage organizational leaders to champion these transformative efforts. While leadership changes may pose risks to ongoing transformations, meaningful innovation inherently requires calculated risk-taking. As DevOps pioneer Jesse Robbins memorably states, "Don't fight stupid, make more awesome" - a reminder to focus energy on creating positive change rather than battling resistance. DevOps benefits ripple throughout the entire technology value stream, fundamentally transforming how organizations operate. It brings joy and purpose back to product development, fostering environments where creativity flourishes. The approach enables truly humane work conditions by eliminating unnecessary stress, reducing burnout, and promoting sustainable practices. Teams working within DevOps frameworks collaborate more effectively, leading to enhanced customer satisfaction and improved organizational outcomes. This is not just theory - it's backed by compelling data from the State of DevOps Report, which surveyed over 25,000 technology professionals. High-performing DevOps organizations consistently demonstrate remarkable advantages: they deploy code 30 times more frequently with 200 times faster lead times, achieve 60 times higher change success rates, and restore service 168 times faster than their traditional counterparts. The transformation journey requires commitment at multiple levels. Organizations must invest in tools and technologies, but more importantly, in people and processes. Success stories from companies like Etsy, Netflix, and Capital One demonstrate that DevOps principles can be effectively implemented across various industries and organizational sizes. Key elements include establishing automated deployment pipelines, implementing comprehensive monitoring systems, and fostering a culture of continuous learning and improvement. By implementing the principles and practices outlined in The DevOps Handbook, organizations can transform their technology value streams from sources of frustration and burnout into powerful engines of innovation and competitive advantage. This transformation affects everything from daily operations to long-term strategic planning, enabling faster market response, improved product quality, and higher employee satisfaction. While the journey may present challenges - from technical hurdles to cultural resistance - countless organizations have demonstrated that the results justify the investment. The evidence shows that organizations embracing DevOps principles not only survive but thrive in today's rapidly evolving technological landscape, making the transformation not just desirable but essential for long-term success.

★★★★★

Vous êtes arrivé au bout de Manuel DevOps

Adopté par plus d'un million d'apprenants

“Cela fait 23 jours et je l'utilise tous les jours. Cette application fait désormais partie de ma routine.”

jayallen

Thèmes clés dans Manuel DevOps

continuous delivery
lean manufacturing principles
organizational flow
feedback loops
software value streams

Citations de Manuel DevOps

Feedback is critical because it is what allows us to steer.
We must pick our transformation projects carefully—when we're in trouble, we don't get very many shots.

Personnages de Manuel DevOps

Gene KimCo-author and technology visionary
Jez HumbleCo-author and technology visionary
Patrick DeboisCo-author and technology visionary
John WillisCo-author and technology visionary
Nicole ForsgrenCo-author and technology visionary

À propos de l'auteur

Gene Kim, Jez Humble, Patrick Debois, John Willis et Nicole Forsgren sont des voix pionnières du DevOps et de la transformation organisationnelle, co-auteurs du best-seller The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations.

Gene Kim, acclamé pour The Phoenix Project et The Unicorn Project, fusionne des récits narratifs avec une expertise technique. Jez Humble, co-auteur d'Accelerate et de Continuous Delivery, apporte des décennies de leadership en ingénierie logicielle, ayant notamment occupé des postes chez Google Cloud et à l'UC Berkeley. Patrick Debois, largement considéré comme le « grand-père du DevOps », a inventé le terme en 2009 et a fondé le mouvement mondial devopsdays. John Willis, stratège chez Red Hat, a aidé à façonner les principes de l'infrastructure-as-code et les méthodologies DevOps. Nicole Forsgren, partenaire chez Microsoft Research, a ancré la deuxième édition du livre dans des analyses basées sur les données issues de ses recherches phares sur le DevOps, notamment son travail récompensé par le prix Shingo dans Accelerate.

Leur collaboration mêle des études de cas réels — de Target à l'U.S. Air Force — avec des cadres exploitables pour mettre le DevOps à l'échelle. La deuxième édition du manuel s'enrichit de 15 nouvelles études de cas et de plus de 100 pages de contenu mis à jour, consolidant son statut de ressource fondamentale pour les leaders technologiques. The Phoenix Project de Kim et Accelerate de Forsgren sont fréquemment cités aux côtés de cet ouvrage, formant une trilogie de la littérature DevOps essentielle. Traduit en plusieurs langues, le livre a guidé des organisations du monde entier dans l'atteinte de mesures de performance révolutionnaires.

Telecharger le resume de Manuel DevOps

Obtenez le resume de Manuel DevOps en PDF ou EPUB gratuit. Imprimez-le ou lisez-le hors ligne a tout moment.

Les utilisateurs ont aussi aimé

The Phoenix Project

Gene Kim & Kevin Behr & George Spafford

The Unicorn Project

Gene Kim

Accelerate: The Science of Lean Software and DevOps

Nicole Forsgren

Wiring the Winning Organization

Gene Kim & Steven J. Spear

Couverture du livre DevOps Foundation: Projects That Build Real Skills

10 Beginner DevOps Projects You Can Build in 2025 (GitHub Actions, Docker, Terraform & More) | Rantideb

Best DevOps Projects For Practical Learning in 2026 - DevOpsCube

6 sources

DevOps Foundation: Projects That Build Real Skills

Implementing lean software development

Mary Poppendieck

Learning Agile

Andrew Stellman & Jennifer Greene

High Growth Handbook

Elad Gil

FAQ sur ce livre

Découvrir plus

PLAN D'APPRENTISSAGE

DevOps

As organizations transition to cloud-native environments, the ability to automate delivery and ensure system reliability has become a critical competitive advantage. This plan is ideal for software engineers and systems administrators looking to master the technical tools and cultural shifts required for modern IT operations.

4 h 37 m•4 Sections

PLAN D'APPRENTISSAGE

The High-Performance Delivery System

This system is designed for leaders and high-performers struggling with burnout and operational bottlenecks. It provides a structural framework to move from reactive firefighting to proactive, outcome-driven delivery.

1 h 36 m•4 Sections

PLAN D'APPRENTISSAGE

The High-Growth Leadership Playbook

In fast-scaling environments, traditional management often leads to burnout and missed deadlines. This playbook is designed for high-growth leaders who need to shift from tactical oversight to strategic empowerment to sustain team performance. It provides the psychological and behavioral tools necessary to build a self-sustaining, high-energy culture.

2 h•4 Sections

PLAN D'APPRENTISSAGE

The 30-Minute Discovery Playbook

In fast-paced retail environments, technical teams often struggle to articulate the business value of observability. This playbook is essential for sales engineers and technical leaders who need to master concise discovery and align technical pain points with executive priorities.

1 h 30 m•3 Sections

PLAN D'APPRENTISSAGE

Become a better operator

Effective operations are the backbone of any successful organization, yet many leaders struggle to bridge the gap between strategy and execution. This plan is designed for aspiring COOs and managers who want to master systems thinking and build scalable processes for high-growth environments.

5 h 13 m•4 Sections

PLAN D'APPRENTISSAGE

The Executive Influence Playbook

In high-stakes corporate environments, technical skill is often secondary to the ability to influence and lead through tension. This playbook is essential for rising leaders and managers who need to command authority, handle resistance, and drive results at the executive level.

35 m•4 Sections

PLAN D'APPRENTISSAGE

The Steve Jobs Keynote Method

This plan distills the specific preparation and management habits that made Steve Jobs a legendary communicator. It is essential for leaders and innovators who need to pitch high-stakes ideas and instill a culture of extreme accountability within their teams.

1 h 30 m•3 Sections

PLAN D'APPRENTISSAGE

The Conqueror’s Code: Strategic Leadership

In an era of constant disruption, traditional management is no longer enough to sustain growth. This plan is designed for aspiring executives and entrepreneurs who need to blend bold vision with tactical agility and robust governance to build lasting organizations.

1 h 30 m•3 Sections

Cree par des anciens de Columbia University a San Francisco

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

Decouvrez comment BeFreed est discute sur le web

Cree par des anciens de Columbia University a San Francisco

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

Decouvrez comment BeFreed est discute sur le web

Commencez votre parcours d'apprentissage, maintenant

Chapitre 3

Manuel DevOps

AperçuAperçu de Manuel DevOps

Un livre. De nombreuses façons de l'écouter.

From Chaos to Collaboration: The DevOps Revolution

Breaking Down the Wall of Confusion Between Dev and Ops

Voyez chaque mot au fil de l'écoute

The Three Ways: Principles for Transforming Technology Organizations

Starting Your DevOps Journey: Where and How

Profitez davantage de Manuel DevOps

Conway's Law: How Team Structure Shapes Architecture

Building the Technical Foundation for Fast Flow

Voyez chaque mot au fil de l'écoute

Enabling Fast, Safe Releases

Creating Feedback Loops for Continuous Improvement

Profitez davantage de Manuel DevOps

Building a Learning Organization

Integrating Security into the DevOps Pipeline

Voyez chaque mot au fil de l'écoute

The Path Forward: A Call to Action

Vous êtes arrivé au bout de Manuel DevOps

Thèmes clés dans Manuel DevOps

Citations de Manuel DevOps

Personnages de Manuel DevOps

À propos de l'auteur

Telecharger le resume de Manuel DevOps

Les utilisateurs ont aussi aimé

FAQ sur ce livre

What is The DevOps Handbook by Gene Kim about?

Who should read The DevOps Handbook?

Is The DevOps Handbook worth reading?

What are the "Three Ways" in DevOps?

Découvrir plus

1,000,000+ curious minds.

1,000,000+ curious minds.

Un livre. De nombreuses façons de l'écouter.

From Chaos to Collaboration: The DevOps Revolution

Breaking Down the Wall of Confusion Between Dev and Ops

Voyez chaque mot au fil de l'écoute

The Three Ways: Principles for Transforming Technology Organizations

Starting Your DevOps Journey: Where and How

Profitez davantage de Manuel DevOps

Conway's Law: How Team Structure Shapes Architecture

Building the Technical Foundation for Fast Flow

Voyez chaque mot au fil de l'écoute

Enabling Fast, Safe Releases

Creating Feedback Loops for Continuous Improvement

Profitez davantage de Manuel DevOps

Building a Learning Organization

Integrating Security into the DevOps Pipeline

Voyez chaque mot au fil de l'écoute

The Path Forward: A Call to Action

Vous êtes arrivé au bout de Manuel DevOps

Les utilisateurs ont aussi aimé

Découvrir plus

Aperçu de Manuel DevOps