DevOps 的失敗持續推動著組織建立平臺團隊。但 Gitpod 和 Humanitec 的最新報告指出，許多組織并沒有衡量結果。

譯自The 2024 State of Platform Engineering? Fledgling at Best，作者 Jennifer Riggins。

平臺工程師面臨著艱難的道路，因為很少有組織真正實現了平臺工程——但如果他們不衡量其結果，他們怎么可能做到呢？

但如果平臺工程師的薪資等級至少比DevOps工程師高一級，他們很可能會繼續應對這一挑戰。

這些只是今年“平臺工程現狀”報告中揭示的兩個最大發現。

The New Stack在今年報告發布之前與Platform Engineering的社區負責人Sam Barlien進行了座談。他反思了為什么組織未能實現長期投資以及解鎖平臺成熟度的策略，包括內部開發者平臺 (IDP) 在 DevOps 組織中的作用，也許最重要的是改進，以及為什么要衡量所有這些。

平臺工程：仍然是新事物

這是第三份年度報告，由Humanitec和Gitpod贊助；研究人員調查了281名平臺工程專業人員。

大多數被調查的組織——56%——擁有平臺團隊的時間不到兩年。只有13%的受訪者表示他們在“平臺工程”領域工作超過五年。

為什么突然增加？是什么驅使組織采用平臺工程？

Barlien說，研究人員對平臺工程的定義是：“在云原生時代，設計和構建工具鏈和工作流程，為軟件工程組織提供自助服務能力的學科。平臺工程師提供一個集成產品，通常被稱為內部開發者平臺，涵蓋應用程序整個生命周期的運營需求。”

他說，這故意地足夠廣泛，包括數據平臺工程，但它關注的是為內部客戶（絕大多數是開發人員）服務的平臺角色。

先有DevOps，后有IDP

今年的結果再次表明平臺工程并沒有取代DevOps，而只是數字轉型演進的下一階段。平臺幫助工程組織更接近實現DevOps的承諾。

總的來說，受訪者表示，正在他們組織中構建內部開發者平臺來彌補DevOps的不足。自動化是DevOps的一個關鍵原則，然而，近一半的受訪者抱怨由于缺乏自動化而做了太多重復性任務。

另一個DevOps原則是貫穿整個生命周期的責任驅動——你構建它，你擁有它。但是平均技術棧呈指數級增長，通常有七層之厚。這分散了開發人員的注意力，使其無法真正為客戶創造價值。IDP可以抽象掉云原生復雜性，以減少開發人員倦怠和認知負荷。它還可以進一步將產品、流程和人員結合在一起。

當然，13%的受訪者承認他們還將DevOps團隊重新標記為平臺工程，“聽起來更高級”，因此Gartner可能是對的，這個學科已經滑入了“幻滅的低谷”。

今年的“DevOps加速狀態”——更常被稱為DORA報告——發現了令人沮喪的結果。例如，DORA研究人員發現，使用平臺工程，吞吐量下降了8%，變更穩定性下降了14%。

由于這是DORA團隊成員首次嘗試衡量平臺工程，因此他們并沒有聲稱擁有答案——盡管他們假設，上市速度可能僅僅意味著總體上發布了更多變更，這可能會降低整體穩定性。

從DevOps到平臺工程師

這份年度報告獨特地展示了平臺工程作為DevOps在職位角色方面的演變。 這份報告將基礎設施平臺工程師和DevEx平臺工程師置于就業金字塔中基礎設施、運營和開發角色之上。與DevOps角色相比，負責通過標準化和自動化來緩解基礎層痛點的這些平臺“價值驅動者”數量較少。

(來源：“平臺工程現狀報告，第3卷”，Gitpod和Humanitec)

報告顯示，考慮到這一點，2024年，歐洲的平臺工程師的收入比DevOps角色高出23%，北美高出27%。

雖然2022年平臺工程師和DevOps角色之間的區別模糊不清，但這份報告顯示，到2024年，平臺團隊對其職權范圍內的內容有了更清晰的認識。平臺工程師告訴研究人員，他們負責：

只有一小部分受訪者認為，作為平臺工程師，他們的職責是充當開發者幫助臺（19%）或為高管創建儀表板（9%）。

平臺工程師和DevOps工程師之間的薪資差距自去年報告以來已縮小了一半，去年報告顯示平臺工程師的收入比DevOps工程師高出42%。這可能再次表明平臺工程仍然很重要，但也許不像業界最初認為的那樣重要。

Barlien推測，“這可能是由于大規模裁員導致差距縮小，也可能是由于DevOps薪資上漲而平臺工程薪資下降，[目前]尚不確定。”

過去三年來，這份報告始終衡量的是，擁有平臺工程師職位的員工比擁有DevOps職位的員工擁有更長的工作經驗。事實上，今年接受調查的平臺工程師中有28%擁有超過15年的科技行業經驗。

平臺團隊的成熟度如何？

僅僅一年多前，云原生計算基金會發布了其平臺工程成熟度模型。

這是一個衡量平臺工程計劃并確定改進領域的框架，涵蓋：

• 投資
• 采用
• 接口
• 運營
• 衡量

這些方面從最低成熟度到最高成熟度量化如下：

• 試運行
• 運行
• 可擴展
• 優化

去年的“平臺工程現狀報告第2卷”發現，平臺工程組織還處于起步階段，尚未實施最佳實踐，包括：

• 變更管理流程
• 跨組織的認同
• 明確的平臺團隊結構
• 一種產品化平臺思維
• 平臺采用策略

隨著平臺工程進入其作為熱門科技話題的第三年，今年的報告試圖量化其成熟度。

簡而言之，大多數團隊遠未成熟。

Barlien說：“這里反映的情況是，對于那些做得好的平臺工程人員來說，效果非常好。而對于那些做得不好的人，結果完全相反。”

根據CNCF平臺成熟度模型的標準，只有大約9%的受訪者確實成熟。與這少數人相比，Barlien和他的團隊發現，對于什么是平臺工程，總體上缺乏清晰的認識——即使是那些據稱擔任平臺工程師的人。

他說，對于他認為是簡單的平臺工程問題，“很多問題的答案是‘其他’，他們的回答是‘我不理解’”。

報告指出，雖然許多公司都在采用平臺工程，但只有少數公司能夠以成熟和可擴展的方式實現其潛力。

但是，如果接受采訪的平均團隊成立時間在0到24個月之間，這就不足為奇了。

平臺團隊不知道如何衡量

今年的“平臺工程現狀”報告揭示了工程或任何科學領域中最響亮的秘密：你無法改進你無法衡量的東西。

大約43%的受訪平臺團隊將他們的反饋機制描述為“臨時性”或“不一致”。這與CNCF的定量和定性反饋標準相差甚遠。

Barlien說：“人們不知道自己在做什么。這大概就是主要的結論。” 事實上，45%的平臺團隊根本沒有任何衡量指標，而37%的團隊只衡量DORA指標。雖然DORA關注吞吐量和穩定性是開發者體驗的重要方面，但這肯定無法全面展現DevEx的細節。

“如果你不進行衡量，你就不知道你是否真的產生了影響，”Barlien說，“然后突然六個月后，你進行檢查，一切感覺都更糟了。”

另外26%的調查參與者報告說他們收集了數據，但實際上并沒有分析這些數據。

當被問及自引入平臺工程以來，指標是如何改進的時，只有22%的人報告了顯著改進，而32%的人看到了輕微的改進。相比之下，17%的人報告沒有明顯變化，而27%的人表示不確定。

這不僅會損害平臺團隊的積極性——還會讓證明他們已經獲得了預算，并值得保住工作變得困難。

報告還指出，39%的團隊報告說他們的平臺“以集中方式啟用，并專注于用戶需求”。但如果他們沒有對此進行衡量，那么這種描述可能基于假設：“這種差距表明，許多組織對自身的評價遠高于實際情況。”

此外，在承認他們不知道自開始平臺工程以來指標變化程度的組織（27%）與回答他們根本不進行衡量（44%）的組織之間，存在近18%的差異。這表明18%的受訪者可能是基于軼事證據、非正式觀察或臨時測量來評估情況的。

“人們同時說，‘哦，是的，一切都很棒。’然后他們又說，‘哦，不，我們什么也沒衡量，’”Barlien反思道。“當你看到像DORA這樣的東西時，這就不足為奇了——不穩定性和認知負荷都在上升。

“好吧，如果這些人什么都不衡量，他們就不清楚自己在做什么。那么，為什么有些事情無法按照他們想要的方式運作就很容易理解了。”

缺少什么？產品思維

“平臺工程是產品管理和一些堅定地專注于技術和工程之間的一步，”Barlien說。但他補充說，許多平臺團隊仍然不明白這一點。

他說，大多數平臺團隊仍然缺乏產品管理方面的理解，包括：

• 用戶研究
• 衡量改進情況
• 了解客戶（你的開發者）想要什么
• 了解你的開發者是否正在使用你的平臺
• 他們是如何使用的

“與DevOps或敏捷方法不同，DevOps或敏捷方法需要工程師已經熟悉的思維方式，”Barlien反思道，“平臺工程往往要求工程師進入一個全新的思維空間。”

這份報告沒有使用確切的術語，而是指出平臺即產品思維是少數做得好的平臺工程受訪者與大多數做得不好的受訪者之間的主要區別。

你呢？你是否想分享你平臺工程之旅的故事？PlatformCon演講征集正在進行中。