DevOps 為什么我們永遠疲于奔命？
在【DevOps】誰說大象不能跳舞?一文之后，本文對DevOps的理念作進一步探討。
最近在讀一本書《Project Phoenix》，用小說的方式來描述了作為IT部門總裁的主人公臨危受命，面對IT開發和運維中出現的種種危機，在險峻的情況下采用新的管理理念，從而帶領IT團隊從低谷走向成功的故事。書中的一些場景，我是再熟悉不過了。有時候也不禁想，如果自己身在其中，會如何應對呢?
這本書也引用了很多DevOPs的理念，故事一波三折，其中的道理很耐人尋味。
話說該公司的IT部門是最備受責難的一個部門。很多商業計劃因為IT不給力而拖延，IT環境極其不穩定，大小問題接連不斷。IT每天忙于救火而疲于奔命。人員士氣低落，各部門各自為戰。出了事互相指責。
主人公在一位高人的指點下，開始了卓有成效的改革之旅。其中很重要的一個課題就是，到底根本問題出在哪里呢？為什么永遠都覺得在疲于奔命？
他們從把工作分類開始，一步步得找到了癥結所在。大體分四類工作：
Business Projects
比如其他部門的要上一個商業應用或者新的商業流程，需要IT提供軟硬件環境，實施設計開發并運維。這類項目是有其他部門為實現某種商業目的來驅動的。
Internal Projects
往往指由IT內部驅動的項目，軟件更新換代、擴容、安全措施、提高IT環境的穩定性、性能等等。
Change
ProductionEnvironment的有計劃的升級，改動等等
Unplanned Work
一些突發情況，比如系統或應用的中斷等等
上面的圖揭示了一個惡性循環。
第一象限：因為商業計劃往往時間緊、任務急，IT手忙腳亂把活干了，為了節省時間人力走了很多捷徑，造成了系統穩定性的降低。為日后埋下了隱患。
第二象限：因為忙著趕第一象限的活兒，本來應該做的InternalProject就被拖延了。軟件補丁和升級不及時，系統沒有很好的優化和長期的計劃，直接造成的系統穩定性、性能等的降低。
第三象限：因為沒有很有效的ChangeControl，部門之間對改動互不知曉，還由于系統不穩定造成很多計劃中的Change失敗。從而累積了越來越多的問題
第四象限：由于前三個象限中問題產生的雪球效應，很多意外情況就不可避免的發生了。解決這些意外情況的成本是非常高的，因為打亂了本來的計劃，造成了其他三個象限工作的拖延。從而又產生了新的一輪的惡性循環。
問題的癥結找到了，那么如何入手解決呢。主人公Bill一連下了幾記重拳：
建立高效的ChangeControl流程
這個流程開始的時候很不容易，因為人們習慣了各行其是，覺得Change Control太繁瑣復雜。但這個流程是必須的，它可以評估改動的風險，防止出現意外情況。
暫時凍結Business Projects
短期的凍結，給了IT人員調整優化系統的喘息之機，從而能實施一些Internal Project來穩定IT環境。同時為新的BusinessProjects做好準備。
定位瓶頸
該書中描述了一位技術大拿Brent，總是在關鍵時候力挽狂瀾。在很多情況下，少了Brent事情就干不成。主人公Bill意識到了如果不解決這個瓶頸，整個IT團隊的生產力都要受到個人的影響。于是采取了一系列的措施解決這個問題。比如：最佳合理利用Brent的時間，避免很多瑣事的干擾；培養一個梯隊來承擔Brent的任務，做好知識和經驗的傳承。
幾套組合拳下來，很明顯的減少了Unplanned Work，從而遏制住了惡性循環，為下一步的流程優化打下了基礎。更重要的是增加了團隊間的凝聚力和信心。
除此之外，書中反復強調了一個有重大意義的理念，就是以流水線的方式來開發和管理IT環境。我們會在下文中詳細介紹。
