本書透過一則新上任的IT經理所帶領的IT維運部門故事來闡述一些開發維運（DevOps）的方法論，在提出方法的同時，輔以案例的說明讓這本書不淪於一本純技術手冊。在故事中的主角遇到各個難題的時候，還有一位導師型的角色在過程中一直給予建議，開頭這名導師只是單純股東會候選人，但在結尾公司轉型完成之後，他放棄加入股東會以避免可能遇到的內線交易問題，改成以投資人的方式加入這場轉型，讓這本書的層次從公司營運，提升到了對金融市場的理解。
一、IT維運的四類工作
1. 業務專案：業務部門或是客戶對於IT的需求。
2. 內部專案：內部系統提出的需求。
3. 變更：因為優先度調整導致的工作變更。
4. 計畫外的工作：緊急修復之類本來沒有預期的工作。
如果沒有辦法辨別總共有幾類的工作，將無法對各工作類型做有效的安排。業務專案和內部專案兩者的本質類似，不過需求方不同，所能夠達到的績效也不同。變更任務對工程師（RD、PG）來說所花的時間可能是切換任務的時間，對專案經理（PM）可能是進行專案變更程序。計畫外的工作則是最影響IT維運的，很容易直接切進來打亂前面幾項所有工作，導致業務延後或是花時間在專案變更程序。
二、三步工作法
1. 第一步工作法：建立工作流，從開發到IT維運，最後再到客戶手上。
2. 第二步工作法：改善工作流。
3. 第三步工作法：建立相關文化。
這三步工作法其實和戴明循環（Plan-Do-Check-Action, PDCA）差異也不會太大，簡單來說就是透過第一步的建立工作流，對應到戴明循環的計畫（Plan）和執行（Do），第二步在做的就是查核（Check）和行動（Action），最後多了第三步建立這一個文化，是為了確保這個工作流不會消失。如果導入一套系統只用了一次或是只持續一年，那導入當然不算成功。
三、約束理論(Theory of Constraints, TOC)
1. 找出系統中存在哪些約束
2. 尋找突破這些約束的方法
3. 使企業的相關活動符合突破約束的方法
4. 持續2. 嘗試別的約束突破方法
5. 持續1. 找出其他的約束
四、開發維運（DevOps）
這本書的本質就是在講開發維運的轉型故事，不過捨棄了很多對於理論說明，就用了一則故事來說明如何一個步驟一個步驟將本來混亂的狀況轉變成有理論依據支撐且執行的作業流程。