【DevOps】爲何咱們永遠疲於奔命？

做者：範軍 （Frank Fan） 新浪微博：@frankfan7   微信：frankfan7

在【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環境。咱們會在下文中詳細介紹。