這本書是以小說形式講解DevOps工作方式，講的是主人公比爾臨危受命，突然升職為公司分管IT運維的副總裁，升職并沒有帶來他和家人喜悅只有驚嚇，他面臨著處理公司業務系統時而發生的一級故障，面臨著一周之內處理完安全部門內部審計提出的幾百頁問題，面臨著一周后決定公司生死存亡的鳳凰項目部署發布，面臨著100多個業務項目，面臨著每天新增加的幾百個變更，還有公司高層的政治斗爭。（感覺這人真是太慘了！）
幸運的是，主人公思路清晰、沉著冷靜，遇到高人指點“三步工作法”，又有給力的下屬。他建立了可視化變更流程，改變了大家（尤其開發人員）對于變更流程的厭惡，避免了因為不受控的變更而導致的業務系統故障。他找到了部門的約束點或者稱為瓶頸，一個叫布倫特的工程師，鳳凰項目、其他重要項目、業務系統故障、很多變更都依賴于布倫特，比爾采取了一系列措施，包括建立三級工程師庫、改變工作到達布倫特的流程，保護布倫特，避免很多工作卡在布倫特這里無法流轉到下一個工作中心。他建立了一套工作流，運用自動化工具提高部署效率，使公司更快響應市場需求。最終扭轉自己的困局和公司的困局。
對于之前沒有接觸過DevOps的我來說，感覺看完這本書對于DevOps還沒有一個整體的、清晰的認識，只有一個模糊的概念，以及對于一些細節方面的感受。
書中提到了一個等待時間的計算公式。
等待時間取決于資源使用率。等待時間是忙碌時間百分比除以空閑時間百分比。如果一個資源的忙碌時間是50%，那么它的空閑時間也是50%。等待時間就是50%除以50%，即一個時間單位。如果一個資源的忙碌時間是90%，那么它的空閑時間也是10%。等待時間就是90%除以10%，即9個時間單位。將是資源有50%空閑時的9倍。因此，每個人都需要空閑時間，否則半成品會卡在隊列里干等著。
在工作中，雖然沒有去計算過忙碌時間和空閑時間，但是回憶起來，在比較空閑的階段，一件工作任務過來，我可以很快交付，目前比較忙碌，在我的待辦清單里有些工作任務已經卡在那里兩到三周了。
我應該怎么辦？
我嘗試過規定自己每周至少處理一項積壓的工作任務，但是這個計劃卻很難執行。
一方面，我的確承擔了太多的工作任務，很少有空閑時間；其實我并沒有充分利用資源，有些流程化的工作，我應該整理好并移交出去，可是一直拖延，把這件事的優先級永遠的排在了后面。整理后不能移交的部分，我也可以為以后節省自己重復思考的時間。
一方面，我經常會有計劃外任務。
在計劃外工作面前，所有計劃內工作都被熾熱的怒火點燃，燒毀周圍的一切。
主人公比爾采取的很多措施，都成功避免了很多計劃外任務。事實上，我也深受計劃外任務之害，很多計劃內任務不能按時完成。
那么我的計劃外任務都來源于什么呢？首先是領導安排的，其次是應付檢查，最后是不可控的反反復復的文檔審核。
領導安排的事情不可避免，不過我可能需要改進我的歸檔系統，例如寫方案時能夠快速找到相關的參考資料。感覺又要開一個大坑，接下來要看關于整理術的書。
對于檢查，我需要思考如何將檢查內容落實在平時的工作中，并且把相關資料歸集整理，不再需要臨時抱佛腳，每次面對檢查，不再需要各種加班補材料。
最后，是不可控的文檔審核。我需要思考如何減少項目組對我的依賴，如何確保文檔到我這里時，質量較高，不再需要反反復復的修改和復審。
參考書籍：
《鳳凰項目：一個IT運維的傳奇故事》Gene kim, kevin behr, george spafford 人民郵電出版社
