在
【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環境。我們會在下文中詳細介紹。
本文出自 「坐看雲起」 部落格，請務必保留此出處
DevOps 為什麼我們永遠疲於奔命？
在 devops 誰說大象不能跳舞?一文之後，本文對devops的理念作進一步 最近在讀一本書 project phoenix 用 的方式來描述了作為it部門總裁的主人公臨危受命，面對it開發和運維中出現的種種危機，在險峻的情況下採用新的管理理念，從而帶領it團隊從低谷走向成功的故事。書中的一些場景...
DevOps 為什麼我們永遠疲於奔命？
在 devops 誰說大象不能跳舞?一文之後，本文對devops的理念作進一步 最近在讀一本書 project phoenix 用 的方式來描述了作為it部門總裁的主人公臨危受命，面對it開發和運維中出現的種種危機，在險峻的情況下採用新的管理理念，從而帶領it團隊從低谷走向成功的故事。書中的一些場景...
為什麼要DevOps？
boss 專案經常延期 做東西太慢 產品 開發 測試 運維 上面的這些問題在做網際網路應用時，我們都深有體會。為什麼說是網際網路應用，而不是傳統的it軟體？傳統it軟體在研發時，更多的是專案型或者產品型的，其發布頻率或者需求變化的頻率是相對較慢的，軟體版本的變化基本上可以按部就班的進行，這也是傳統的...