自 DevOps 推出以來已經有 15 年了。 但對於更傳統的企業來說，為什麼他們的DevOps轉型似乎是無止境的？
翻譯自 企業 DevOps 可以衡量嗎？ ，詹妮弗·裡金斯 （Jennifer Riggins）。 15 年來，我們一直在進行 DevOps 之旅。 然而，許多組織似乎在轉型過程中陷入僵局，面臨比以往任何時候都更多的阻力。 部分問題在於工程學是一門科學，因此它無法改善無法衡量的東西。 衡量任何“轉變”本質上都是困難的。 更複雜的是，儘管它的名字叫DevOps，但它更側重於運營優化，而不是開發人員體驗。 詹妮弗·裡金斯 （Jennifer Riggins） 是一位作家、記者、撰稿人、活動和播客主持人，她講述技術文化的故事，幫助分享技術文化碰撞的故事，並翻譯我們正在構建的技術的影響。 衡量開發人員的工作效率並非易事。 儘管關於DORA，Space框架和去年DevEx指標的積極報告，但很少有公司真正使用類似的工具 - Microsoft和Google - 大多數研究都是在那裡進行的 - 以及Netflix，Spotify，LinkedIn，Atlassian和GitHub等大品牌。 這些傳統公司突然發現自己是科技公司，但他們沒有看到漫長的DevOps隧道盡頭的曙光。
當然，科技巨頭在炒作週期中成為早期採用者的情況並不少見。 但DORA指標已經有10年的歷史了——無論評論員多麼感興趣，它們的採用似乎並不普遍。 是什麼阻礙了這些傳統組織成為DevOps精英？ 我們採訪了 Uplevel 的產品副總裁 Christina Forney，這是真正的絆腳石。 在過去的 10 年裡，Forge 一直在產品和工程之間來回切換，為開發人員開發生產力工具。 在過去的 5 年裡，她與企業客戶密切合作，親眼目睹了這項投資如何通過 DevOps 獲得回報。
她說，大多數組織都陷入了“痛苦三角”中。 這是Uplevel對人類健康的三個關鍵組成部分的測量的名稱：
人員健康- 我們的工作是否可持續？
承諾- 我們是否有效地規劃和兌現了我們的承諾？
交付- 我們是否有效地提供高質量的解決方案？
做好這三件事中的一兩件事是很容易的。 要把這三點都做好是非常困難的，“福尼說，”因為你可以兌現你的承諾，但這會讓你的團隊垮台。 或者你的團隊很高興你已經履行了你的承諾，但這花了非常非常長的時間，所以質量受到影響。 ”
平衡兩者相對簡單，但三角形支架需要三條腿才能站立。
Triangle of Pain，**由 Uplevel 提供。
需要注意的是，阻礙組織轉型的並不是缺乏對DevOps目標的認識。 畢竟，諮詢行業投資了數百萬美元來確保它得到解釋。 正如 Forney 所說：
我們知道我們需要更快地交付。 我們知道我們需要傾聽客戶的反饋。 我們知道我們想要提供商業價值。 我們知道我們應該做客戶研究。 我們知道我們應該更頻繁地發布和獲得反饋，縮短週期，降低拉取請求的複雜性，並進入流式處理狀態。 但我們也應該每天吃沙拉。 不是每個人都喜歡每天吃沙拉。 僅僅因為你知道某件事是真的，並不意味著這就是我們的實際行為方式。 ”
就DevOps而言，它不是這些傳統組織面臨的複雜環境中的靈丹妙藥。
大約 15 年前，有人決定將其稱為 DevOps Transformation，喚起魔法少女 Sabrina 變裝的形象——暗示這將是快速、簡單和**的。 然而，儘管聘請了數千名DevOps顧問和教練，並投資了數百萬美元，但大多數傳統組織仍然沒有離“轉型”更近一步。 他們真正感受到的只是試圖將圓釘塞進他們的方孔的無盡挫敗感。
我看到技術先進的公司和正在轉型的公司之間的鴻溝越來越大，“福尼說。 她指著Meta、Alphabet、亞馬遜和谷歌等科技巨頭繼續說道：“你有這些技術先進的公司引領潮流，最佳實踐建立在它們之上。 ”
但對於科技界所說的“傳統組織”來說，情況完全不同。 這些組織，如銀行和汽車行業，起初並不擅長構建軟體，但最近已經發展成為完全依賴利用和構建軟體的公司。
這些大型組織都在說，“我們想進行這些大規模的轉型”，他們正在招聘在谷歌有過類似經歷的高管和領導者。 他們進入公司後仍然無能為力。 因此，她繼續說，“轉型將需要數年或更長時間。 ”
另一方面，較小的組織可以更加“敏捷”，並且可以相對輕鬆地完成這些所謂的“轉型”，例如雲遷移和打破孤島以實現跨組織協作。 但是，這些成熟的組織在10年後仍在苦苦掙扎——僅僅10年後，DevOps曾經很酷。
是什麼導致了這種慣性？ 福尼將其歸因於技術債務和傳統文化結構的結合。 “這就像如果你長時間不伸展，你站起來想嘗試，你不會立即觸控你的腳趾，”她說。 “這需要時間。 你會看到很多領導層的流失。 特別是在這些以文書工作、官僚主義和法規為特徵的緩慢組織中。 ”
在談到一位財富 100 強客戶時，她說：“這位領導者對我正在嘗試，但一無所獲表示非常沮喪，”儘管她已經成功地轉移到了其他地方。 因此，他們知道DevOps的潛力以及當它被完全接受時會有多好，但他們就是無法讓它在這些受到高度監管的50到100年歷史的公司中發揮作用。
一些人認為，過去18個月大型科技公司的裁員可能是這些傳統組織吸引科技人才的絕佳機會，但同樣，大型科技公司的視角可能不足以駕馭這些業務。 部分問題在於，這些更傳統的企業從大型科技公司那裡吸收了開發人員的生產力指標，但他們的人員、流程和傳統技術並不適合這些衡量標準。 根據 Forney 的說法，開發人員將高達 70% 的時間用於頂級組織的編寫和測試**，其餘時間用於會議和切換上下文。 但是，當你看到這個異常高的70%時，她解釋說，你必須考慮他們花了多少時間在“保持系統執行”，或處理客戶支援，或待命，相對於“他們花了多少時間創造新價值”。 她說，這已經成為乙個“不斷縮小的空間桶”。
她發現，特別是在那些尚未完全遷移到雲、尚未完全從瀑布式開發轉向敏捷開發的成熟組織中，開發人員經常專注於錯誤的工作。 或者，他們在技術債務之上建立快速獲勝的變通方法，而不是基於長期視角來修復它們。
我們看到組織花費大量時間進行規劃，認為這些是組織的首要任務，但實際上發生了什麼？ 開發人員真的把大部分時間花在了你期望的這些事情上嗎？ “大多數時候，你會看到他們把整個組織5%的精力花在這些最重要的事情上。 ”
這個估計來自Uplevel自己的工具，該工具從各種**中提取資料，並嘗試對整個組織花費的實際時間進行建模。
當你開始將整個工程組織視為乙個引擎時，你就開始對工程系統進行工程設計，“Forney 解釋道，這反過來又使你能夠專注於整個工程中最大的瓶頸。 只有系統思維才能改善DevOps結果。 雖然看似流行的 DORA 指標和 Space 框架也在團隊級別及其他級別進行衡量，但它們根本沒有在更傳統的企業場景中被廣泛採用。
太空框架面臨的最大挑戰之一是它不精確和定義明確，“Forney 說。 Space 框架提出了 25 個開發人員生產力指標作為衡量各種社會技術因素的起點，但更側重於如何將這些衡量標準置於情境中，而不是應該使用哪些指標。 “所以，它提供了乙個廣闊的開放方向，你應該在這個領域進行衡量，但要弄清楚什麼對你最有效。 特別是在大型組織中，衡量什麼不是很清楚。 ”
而且，正如我們在之前對 Google 的 Nathen Harvey 和 Michelle Irvine 的採訪中所討論的那樣，DORA 指標遠遠超過四個指標——更像是 50 個，但每個人都痴迷於核心四個指標：部署頻率、更改引導時間、更改失敗率和故障交付恢復時間（以前稱為平均恢復時間，或 MTTR）。
除了需要衡量的四個指標之外，還有很多東西需要衡量，“Forney 說，這讓你”看到乙個平衡人們健康或確保開發人員有足夠的深度來工作的敘述。
她特別指出，需要一種生成性組織文化——一種植根於資訊流和信任的文化。 事實上，2023 年 DevOps 現狀報告發現，具有生成式文化的團隊的績效提高了 30%，生產力和工作滿意度也顯著提高，並在開發人員倦怠減少後將生成式文化作為核心競爭力。 當然，特別是在通常等級森嚴的傳統部門中，培養這種溝通水平然後衡量其增長變得更具挑戰性。 傳統組織中的系統思維通常依賴於大量的官僚主義、大量的對話和故意的障礙。
DORA 和 Space 難以採用的乙個原因是，即使在這些大型科技公司中，它們也以不同的方式定義和衡量 DevOps 的成功。
上個月，DX開發者體驗平台的首席執行官Abi Noda分享了一項針對17家公司的開發者生產力指標的新研究結果，這些公司最初都是作為科技公司成立的。 絕大多數人也不使用 dora 或 space。 “每家公司都有自己量身定製的方法來衡量其工程組織的效率，”他寫道。 ”
對 17 家不同科技公司的工程領導者的採訪結果，**由 DX 提供。
如果已經證明沒有單一的指標可以捕捉開發人員的生產力，那麼任何人如何衡量DevOps？ Foreney 表示，UpLevel 在工程組織層面檢查來自各種來源的元資料，包括：
工作日曆。 鬆弛資訊。
*提交。 Jira 和其他專案跟蹤工具。
事件響應工具和備用計畫。
CI CD 系統。
同步通訊，例如會議。
特別是，她發現現場對話通常是規避官僚主義的一種方式。
你需要對你花了多少時間有乙個現實的衡量標準。 然後，您需要將這些資料用於業務規劃和決策，“Forney 解釋道。 “這將在整個工程組織中建立一致性，以便工程領導者的決策支援實際發生的事情。 ”
她解釋說，組織現在正在設定自上而下的目標，但隨後，特別是在這些傳統業務中，“工程團隊將大部分時間花在保持系統執行或處理客戶支援問題上。 可以說，有各種各樣的東西只是保持整個系統的流動，但實際上並沒有為企業創造價值。 ”
這一切都可以追溯到DevOps的最初目標，即在業務和工程之間建立一致性。 2023 年平台工程激增的部分原因是，它使企業能夠了解工程成本中心的運作，而這些中心通常難以理解，但通常規模很大。
了解這種溝通流程，以及阻止干擾的好方法，可以啟動您的DevOps自動化測量之旅。 但工程勘測是另乙個重要的問題——誰能比他們更了解瓶頸和中斷其流動狀態的主要原因？
這些還應該包括生成性文化對話，以了解“我們的協作方式真的能幫助我們解決客戶問題嗎？ Forney 說，通過將這種情緒與資料相結合，您可以開始釋放開發人員在實際解決實際問題時所感受到的熱情
如果你開始衡量和平衡組織工程的痛苦三角，你就可以開始影響組織內的正確對話。 ”