DevOps 為什麼我們永遠疲於奔命?

2021-09-04 13:11:51 字數 2091 閱讀 7869

【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軟體在研發時,更多的是專案型或者產品型的,其發布頻率或者需求變化的頻率是相對較慢的,軟體版本的變化基本上可以按部就班的進行,這也是傳統的...