企業DevOps為何難以進步?

原创 岱军

DevOps推出已經15年了。但對於較傳統的企業,他們的DevOps轉型為何看似沒完沒了?

譯自Can Enterprise DevOps Ever Measure Up? ,作者 Jennifer Riggins。

我們踏上稱為DevOps的旅程已有15年多。然而,許多組織在轉型過程中似乎陷入僵局,比以往面臨更多阻力。部分問題在於,工程是一門科學,因此無法改善未能測量之物。任何「轉型」的測量本來就很困難。更複雜的是,儘管名為DevOps,但它更專注於營運優化,而非開發者體驗。

Jennifer Riggins 是一位講述技術文化故事的作家、記者、撰稿人和活動及播客主持人,她幫助分享技術文化碰撞的故事,並翻譯我們正在建立的技術的影響。開發者生產力的測量並不簡單。儘管媒體喜報DORA指標、SPACE框架與去年的DevEx指標,但實際應用類似工具的公司寥寥無幾——微軟與谷歌——大多數研究的發源地——以及Netflix、Spotify、領英、Atlassian與GitHub等大品牌。這些傳統企業也突然發現自己成了科技公司,卻覺得沒有看到漫長DevOps隧道盡頭的曙光。當然,在炒作週期中,科技巨頭作為早期採用者並不罕見。但DORA指標已經10歲了——無論評論員多麼感興趣,它們的採用範圍似乎都不廣。是什麼阻礙這些傳統組織成為DevOps菁英?我們與Uplevel產品副總裁Christina Forney對話,探討真正的絆腳石。陷入痛苦三角在過去的10年裡,Forney在產品和工程之間來回切換,一直致力於為開發者開發生產力工具。在過去的5年裡,她與企業客戶密切合作,親身見證了這種投入卻看不到DevOps的回報。她說,大多數組織都陷入了「痛苦三角」。

這是Uplevel對三個關鍵人員健康組成部分測量的命名:人員健康- 我們的工作是否可持續?承諾- 我們是否有效地規劃並兌現承諾?交付- 我們是否有效率地交付優質解決方案? 「在這三件事中做好一兩件非常容易。要做好全部三件非常困難,」Forney說,「因為你可以按質交付完成承諾,但會拖垮你的團隊。或者你的團隊對你完成承諾很滿意,但這需要非常非常長的時間,所以品質在受損。

痛苦三角,圖片由Uplevel提供。
值得注意的是,阻礙企業轉型的不是對DevOps目標的認知不足。畢竟,諮詢行業投入了數百萬美元來確保它得到解釋。
正如Forney所說:「我們知道我們需要更快地交付。我們知道我們需要聽取客戶回饋。我們知道我們想要交付業務價值。我們知道我們應該進行客戶研究。我們知道我們應該更頻繁地發布和獲取回饋,且週期更短,降低拉取請求的複雜度,進入串流工作狀態。
但是我們也應該每天吃沙拉。並不是每個人都喜歡每天吃沙拉。僅僅因為你知道某事為真並不意味著這就是我們的實際行為。 「就DevOps來說,在這些傳統組織面臨的複雜環境中,它並非魔法治療藥。
大約15年前,有人決定將其稱為DevOps轉型,喚起了魔法少女薩布麗娜變裝的畫面——暗示它會快速、輕鬆又無痛。
然而,儘管聘請了成千上萬的DevOps顧問和教練,投入了數百萬美元,大多數傳統企業距離感覺「轉型」卻仍沒有更近一步。他們真正感受到的只是在試圖將圓釘塞進他們的方孔中時的無盡挫折。 「我看到越來越大的鴻溝在科技進步的公司和正在轉型的公司之間,」Forney說。她指著Meta、Alphabet、亞馬遜(Amazon)和谷歌(Google)等科技巨頭繼續說道:「你有這些科技先進的公司引領潮流,最佳實踐就是建立在他們的基礎之上的。」但是對於科技圈稱為「傳統組織」的完全不同。這些組織像是銀行和汽車產業,起初並不擅長建立軟體,但最近已經進化成完全依賴利用和建構軟體的公司。 “
這些大型組織在說,‘我們想要進行這些大規模的轉型’,於是他們聘請了在谷歌有過類似經歷的高管和領導者。他們進入公司後仍然事不成。她繼續說道,這導致「轉型需要數年乃至更久的時間。 「而較小的組織可以更“敏捷”,並可以相對輕鬆地完成這些所謂的“轉型”,如雲端遷移和打破孤島實現跨組織協作。但這些老牌組織10年後仍在掙扎——就在DevOps曾經很酷的10年後。
是什麼導致了這種慣性? Forney將其歸因於技術債和傳統文化結構的組合。 「就像如果你長時間不伸展身體,然後起床想試試,你不會立刻就能碰到腳趾,」她說。 「這需要時間。你會看到許多領導層的流失。特別是在這些以文書工作、官僚主義和法規為特徵的緩慢組織中。」她反思一個財富100強客戶時說:「這位領導者表達了極大的沮喪,我在努力,但沒有任何成果”,儘管在其他地方曾成功轉型過。所以他們知道潛力以及當DevOps被全面接納時可以多好,但他們就是無法在這些存在高度監管、有50至100年曆史的公司中使其奏效。
有些人認為過去18個月大型科技公司裁員可以成為這些傳統組織吸引科技人才的大好機會,但同樣,大型科技公司的視角可能不具備導航這些企業的能力。衡量企業DevOps的成功部分問題在於,這些較傳統的企業吸收了大型科技公司的開發者生產力指標,但他們的人員、流程以及通常的遺留技術不適合這幾項測量。
在Forney看來,在頂尖組織中,開發者花費長達70%的時間編寫和測試程式碼,其餘時間用於開會和切換上下文。但當你檢視這個異常高的70%時,她解釋道,你然後不得不考慮他們花了多少時間僅僅是“保持系統運行”,或處理客戶支持,或處於待命狀態,相對於“他們花了多少時間創造新的價值」。
她說這變成了一個「不斷縮小的空間桶」。尤其是在那些還沒有完全遷移到雲端、還沒有完全從瀑布開發轉向敏捷開發的老牌組織,她發現開發者經常關注錯誤的工作。或者他們在技術債之上建立快速獲勝的變通方法,而不是基於長期視角進行修復。 「我們看到組織花費大量時間進行計劃,認為這些是組織的首要任務,但實際上發生了什麼?開發人員是否真的花費了你預期的大部分時間來做這些事情?”
Forney說,「大多數情況下,你會看到他們花了全組織層級努力的5%時間來做這些最重要的事情。」這種估計來自Uplevel自己的工具,它從各種來源拉取數據,並試圖對組織範圍內的時間實際花費進行建模。 “當你開始把整個工程組織看作是一個引擎,你就開始對工程系統進行工程化”,Forney解釋說,這反過來讓你能夠關注整體工程的最大瓶頸。只有系統思維才能改進DevOps結果。
DORA指標與SPACE框架不緣?雖然看似流行的DORA指標和SPACE框架也是在團隊層面及以上進行測量,但它們在更傳統的企業場景中根本沒有廣泛採用。 「對於SPACE框架,最大挑戰之一在於它不夠精準和明確定義,」Forney表示。
SPACE框架提出了25項開發者生產力指標,作為衡量各種社會技術因素的起點,但更注重如何為這些測量創造情境,而非應使用哪些指標。 “因此,它給出了一個寬泛的開放方向,即應在此領域進行測量,但要弄清楚什麼最適合你。特別是在大型組織中,人們不太清楚應測量什麼。”
而且,正如我們之前採訪谷歌的Nathen Harvey和Michelle Irvine時討論過的,DORA指標遠不止4項——更像50項,但每個人都執著於核心4項:部署頻率、變更引導時間、變更失敗率和故障交付恢復時間(先前稱為平均恢復時間,即MTTR)。 「你需要測量的指標遠不止4項,」
Forney表示,這些指標讓你「看到平衡人員健康或確保開發者有足夠深度工作時間的敘事」。她特別指出需要生成式組織文化——該文化植根於資訊流動和信任。
事實上,2023年DevOps狀態報告在發現擁有生成式文化的團隊表現提升30%的同時,生產力和工作滿意度也大幅提高,開發者職業倦怠降低後,將生成式文化作為核心能力加入其中。
當然,尤其在典型的等級制傳統部門,培養這種程度的溝通,然後衡量其成長變得更具挑戰性。傳統組織的系統思維通常依賴大量官僚主義和許多對話以及刻意的障礙。
是時候測量所花時間了DORA和SPACE難以採用的一個原因是,即使在這些大型科技公司,它們也都在以不同的方式定義和衡量DevOps的成功。上個月,DX開發者體驗平台的CEOAbi Noda分享了對17家公司開發者生產力指標的最新研究結果,所有這些公司最初都是作為科技公司設立的。絕大多數也沒有使用DORA或SPACE。他寫道:“每家公司都有自己量身定制的方法來衡量其工程組織的效率。”

17家不同科技公司的工程領導訪談結果,圖片由DX提供。如果已經證明不存在能捕捉開發者生產力的單一指標,那麼任何人怎麼能衡量DevOps呢?
Forney說,Uplevel在工程組織層面檢查來自多種管道的元數據,包括:工作日曆Slack資訊代碼提交JIRA和其他項目追蹤工具事故響應工具和待命時間表CI/CD系統同步溝通,如會議她特別發現,現場對話通常是試圖規避官僚主義的一種方式。 “
你需要對時間的花費有一個真實的測量。然後你需要在計劃和對業務的決策中使用這些數據,”
Forney解釋。 「這將在你的整個工程組織中產生一致性,以便工程領導者的決策支持實際發生的情況。」組織現在正在製定自上而下的目標,但隨後,她解釋說,尤其是在這些傳統在企業中,「工程團隊花費絕大部分時間僅僅是保持系統運作或處理客戶支援問題。可以說是各種僅僅使整個系統保持流動的事情,而沒有實際為企業創造價值。」這一切又回到了DevOps最初的目標,即在業務和工程之間建立一致性。
2023年平台工程的飆升部分原因在於,它使業務能夠理解通常難以理解但規模通常很大的工程成本中心的運作情況。理解這個溝通流程以及阻礙幹擾的好方法,可以啟動你的DevOps自動化測量之旅。
但工程調查也是另一個重要來源——誰比他們更了解導致瓶頸和打斷他們的流動狀態的主要原因呢?這些還應該包括生成性文化對話,以了解:“我們的協作方式是否真正幫助我們解決客戶問題?”
Forney說,透過將這種情緒與數據結合,你可以開始釋放開發者在真正解決實際問題時感受到的熱情:「如果開始測量和平衡工程組織的痛苦三角,你可以開始影響組織內正確的對話。