醜話說在前這本書的翻譯品質並不好，一來可能是譯者的翻譯問題二來可能是本書原文作者用字方式較特別。我本人並沒有看過原文，但看過原文的朋友曾表示這本書的英文並不好理解。
撇開翻譯品質的問題，這本書是以小說方式解譯devops，故當成小說來閱讀應該不會有太大問題。因為我只有在硬體系統廠工作的經驗，閱讀時對於這本書常碰到的「deploy」問題較沒有概念，一些專有名詞如ITIL, ITSM也就略過不研究。
這本書以「第一人稱」來描寫比爾這個中階經理在CIO被FIRE後被拉上公司技術總管理人，負責理管全公司約100名工程師。書中的公司雖為一家汽車零件公司，但有許多複雜的IT系統負責生產管理、庫存、零售、薪資、財務等功能。
比爾上任後要接續開發問題重重的「鳳凰」計畫，但公司其他系統已如危樓一般。第一天上任就碰到薪資資料庫毀損，造成薪水無法正確發出。比爾發現公司中最有能力的工程師「布倫特」反而造成了最大的問題，因為公司各系統發生何何問題皆需「布倫特」處理，若「布倫特」處理A系統問題就會使其他發生問題B、C、D的系統持續停擺，造成了一個效率瓶頸。故作者要求「布倫特」專心處理「最重要」的鳳凰專案並拒絕任何其他系統問題或是其他單位打斷布倫特工作，強制所有問題與需求必須先由另一個團隊處理，只有在確定無法處理時才可以詢問布倫特，也要求經布倫特處理的問題都要詳加記錄並寫出完整文件，以減少公司系統對布倫特的過度依賴。
上圖是故事中唯一出現的圖表，作者表示一個資源的佇列時間為「忙碌時間比例/閒置時間比例」。也就是說一個50%忙錄的資源處理任務所需的佇列時間為50/50=1，而一個90%忙碌的資源就會產生9倍(90/10=9)的佇列時間。作者強調Y軸時間只是一個比例，而非絕對的時間。假如一個50%忙碌的工程師解決一個新問題要1天，若他現在處於90%忙碌的狀態下解決一個同樣的新問題就要等待9天。這就是本書的第一個重點：
找出「約束點constraint」或稱「瓶頸」並提升他的效能直到他不再是瓶頸，
解決舊的瓶頸後接繼續尋找下一個瓶頸，周而復始。
接下來作者理解了四個IT的主要工作類型：
1.業務專案
就是一般高階主管、PM管理的正式專案
2.IT的內部專案
這是IT部門為了達到「業務專案」需求所衍生的內部專案，也有可能是公司其他內部要求的改善專案(自動化…等)。這類型專案可能沒有被集中管理。
3.變更
通常由上述兩個工作所引起，往往由工單系統追縱。我想在系統廠裡可能就是bug跟bug tracker的型式吧。
4.救火
通常由上述三個工作所引起，發生這類工作時會犧牲其他計畫內的工作。
過去因身為高階管理人比爾只看到「1.業務專案」，而沒有注意到2.3.4類工作也會使用大量工作時間，尤其是公司系統處在不穩定狀態下額外產生的問題會嚴重影響新專案發展，也就是要償還所謂的「技術債」。
比爾使用看板(kanban)/白板/索引卡片來「視覺化」上述四項工作，以決定優先順序。因為布倫特是明顯的瓶頸，故會「影響到布倫特工作」的「工作」需訂為最優先。這也是本書最強調的「三步工作法(The three Ways)」裡的第一步。
雖然找出了第一個瓶頸點與第一步工作法，成功讓鳳凰專案上線，但也爆發存貨與帳務系統停擺的大問題，比爾繼續學習三步工作法來改善鳳凰計劃，作者強調這三步可以推衍出devops的基礎：
1.第一步工作法關乎開發維運到客戶的工作流(flow of work)。為了最大化流量，作者認為要小批次短時間的工作。這會需要連續部署、整合等，建立能夠安全測試與變更的系統和組織。
2.第二步工作法是在價值流的階段中快速回饋，要求能夠夠發現及修復問題。故需建立快速的自動化測試，並建立產品的測量機制，讓每個人都能知道程式是否照設計運行，以及是否達到客戶目標。
3.第三步工作法是創造公司文化，形成兩種風氣：雖然必然有風險但公司仍須持續不斷地實驗，從成功和失敗中學習經驗；體認反覆和綀習是達成精通的基本前提。作者強調要建立創新、勇於冒險(相對於畏或盲目服從命令)以及高度信任的文化(相對於低信任度的指揮控制文化)，把至少20%的開發時分配給非功能性需求，持續強化及鼓勵進行改善活動。
比爾在改善鳳凰計劃後發現主管最重要工作並非完成交辦的「業務專案」。為幫助企業完成目標，高階主管應將立場拉高，站在公司觀點每天向自己詢問下列問題：
我們具競爭力嗎？
了解客戶的需求和期望：我們知道要創造什麼嗎？
產品組合：我們有正確的產品嗎？
研發效能：我們能夠有效地建立產品嗎？
產品上市時間：我們能夠盡快把產品推向市場，並且搶佔一席之地嗎？
銷售管道：我們的產品能夠觸及感興趣的潛在客戶嗎？
我們的做法有效嗎？
按時交貨：我們恪守對客戶的承諾嗎？
顧客維繫：我們正在增加客戶，還是流失客戶？
銷售預測準確率：我們可以把銷售預測準確率納入銷售計劃流程嗎？
CFO的目標
- 公司體質健全
- 營收
- 市占率
- 平均訂單規模
- 盈利能力
- 資產收益率
- 財務狀況
- 訂單轉化成現金的週期
- 應收帳款
- 準確且及時的財務服告
- 借貸成本
作者最後成功拯救公司並不是靠「鳳凰計劃」，而是一套完整的系統監控與自動化開發環境，讓開發與部署可以順暢且可靠。新開發的「獨角獸計劃」則得益於此，讓過往數個月才能完成的專案部署改變成每周部署。而「獨角獸計劃」在收到顧客與銷售部門的的回饋後針對顧客真正需求快速改善，銷售部門也能從IT系統獲得正確與必要的銷售資訊，讓銷售部門可以正確預測與規劃。成功讓公司營收突破歷史新高！
本書故事中並沒有提到敏捷開發，作者在後記強調敏捷開發並不是devops的先決條件，但我的確在這本書看到多許敏捷開發的影子，作者也認為devops是敏捷開發的合理延伸。另外這本也很強調工廠管理可以運用在IT管理，可以感覺出作者觀點較偏高階管理者與商業顧問的角度，而非工程師的軟體工程角度來看devops。作者所用的工廠管理很明顯的是「豐田式」的生產方式，強調快速反應與修改。故事中也提到了豐田經典的「快速換模技術(single-minute exchange of die)」，套到IT上就是連續部署與快速修正，下表是書中指出知名公司的部署頻率：
