Other Posts

Kevin Cui

crazy enough to be creative



Book Review: The DevOps Handbook


😀 Something interesting

Deployment Lead Time

DevOps focuses on optimizing “deployment lead time”. The definition of “deployment lead time” is not explained clearly in this book. As my understanding, a lead time is a latency between the initiation and execution of a process, then “deployment lead time” should be the time between deployment initiation is required and the product in production.

The Three Ways

As described in the book, The Phoenix Project presents the Three Ways as the principles underpinning DevOps:

  1. The technical practices of flow: it enables fast left-to-right flow of work from Devs to Ops, so that value can be quickly and safely delivered to customers.
  2. The technical practices of feedback: it enables the fast and constant flow of feedback from right to left at all stages of the value stream.
  3. The technical practices of continual learning and experimentation: it enables the creation of a culture of learning and experimentation.

I see the 3 ways as 3 focuses in different phases:

  • Initialization: Build a right pipeline
  • Improvement: Get quick feedback to adjust pipeline to a right direction
  • Interaction: Create a culture to learn from experimentation, to increase safety


I found the appendices in this book are quite interesting. Appendices contain copious additional materials with short descriptions. Some of them are worth to know more. Then I search for some additional information and list them here:

  • History of movements: the Lean movement, the Agile movement, the Agile infrastructure and velocity movement, the Continues Delivery movement, the Toyota Kata movement, the Lean Startup movement, the Lean UX movement…
  • Some myths of industrial safety: by revealing 5 common myths about safety, it guides people to think different types of outcomes: adverse outcomes and successful outcomes. Furthermore, it introduces 2 types of safety defined by 2 different perspectives: “no lack of safety” or “resilient safety management”.
  • The Toyota Andon Cord: it’s one of the quality control method invented by Toyota. Andon Cord is a notify system with signal lights hanging on the cord. When a defect was suspected in the production line, the worker should light up the signal and the whole system will be stopped. By stopping the system, you will get an immediate opportunity for improvement, or solving the root cause.
  • The Netflix Simian Army: based on the idea of monkey testing, Netflix built an army of “skilled monkeys”. Once these monkeys are unleashed, they will start to randomly disable the service and destroy the system. It’s an interesting way to test the robustness of service and system. One day, these monkeys cannot cause any noticeable troubles, you will trust that your system is fail-safe.

🙈 Something boring

Lack of depth

After finishing this book, my first feeling is “This book could go deeper”. The true ideas and thoughts are heavily covered by quotes and stories. Actually, stories are good and interesting, but they are used in the book so often like the case study, instead of being used to explain a conception. Some chapters are based on one shallow story. After reading one chapter, I could only roughly tell the story. What about the idea behind it? It was not expressed clearly. At the end, I feel more like “emh.. ok…”. The surprise, which I expected from this book at the beginning, is missing.

Maybe it’s the purpose to go breadth by throwing conceptions without deeper explanations, in order to cover more readers.

Repeated Terms

This is maybe only my personal OCD. Some terms appearing repeatedly make me feel annoyed. It happens at the very beginning of the book. For example, “Product owners, development, QA, IT Operation and Infosec…” This chain of terms appears at least twice on some pages. Once I noticed it, I totally faint out…

🔮 Something for future

For me, this book is an introduction to DevOps world. I think there are many valuable things to learn in DevOps. Therefore, I will continue to take a look at other interesting DevOps books. Perhaps I would pick first another book from the same author. It’s called “The Phoenix Project”. It’s an interesting novel and I trust the author’s storytelling skill.

👉 Recommendation

Who do I recommend to read “The DevOps Handbook”?

  • Someone knows nothing about DevOps, like Jon Snow
  • Someone has huge resource to manage and wants to create a great company culture
  • Someone is doing DevOps but blocked and needs some decent ideas