DevOps 的失敗持續(xù)推動(dòng)著組織建立平臺團(tuán)隊(duì)。但 Gitpod 和 Humanitec 的最新報(bào)告指出，許多組織并沒有衡量結(jié)果。

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

平臺工程師面臨著艱難的道路，因?yàn)楹苌儆薪M織真正實(shí)現(xiàn)了平臺工程——但如果他們不衡量其結(jié)果，他們怎么可能做到呢？

但如果平臺工程師的薪資等級至少比DevOps工程師高一級，他們很可能會繼續(xù)應(yīng)對這一挑戰(zhàn)。

這些只是今年“平臺工程現(xiàn)狀”報(bào)告中揭示的兩個(gè)最大發(fā)現(xiàn)。

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

平臺工程：仍然是新事物

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

大多數(shù)被調(diào)查的組織——56%——擁有平臺團(tuán)隊(duì)的時(shí)間不到兩年。只有13%的受訪者表示他們在“平臺工程”領(lǐng)域工作超過五年。

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

Barlien說，研究人員對平臺工程的定義是：“在云原生時(shí)代，設(shè)計(jì)和構(gòu)建工具鏈和工作流程，為軟件工程組織提供自助服務(wù)能力的學(xué)科。平臺工程師提供一個(gè)集成產(chǎn)品，通常被稱為內(nèi)部開發(fā)者平臺，涵蓋應(yīng)用程序整個(gè)生命周期的運(yùn)營需求?！?/p>

他說，這故意地足夠廣泛，包括數(shù)據(jù)平臺工程，但它關(guān)注的是為內(nèi)部客戶（絕大多數(shù)是開發(fā)人員）服務(wù)的平臺角色。

先有DevOps，后有IDP

今年的結(jié)果再次表明平臺工程并沒有取代DevOps，而只是數(shù)字轉(zhuǎn)型演進(jìn)的下一階段。平臺幫助工程組織更接近實(shí)現(xiàn)DevOps的承諾。

總的來說，受訪者表示，正在他們組織中構(gòu)建內(nèi)部開發(fā)者平臺來彌補(bǔ)DevOps的不足。自動(dòng)化是DevOps的一個(gè)關(guān)鍵原則，然而，近一半的受訪者抱怨由于缺乏自動(dòng)化而做了太多重復(fù)性任務(wù)。

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

當(dāng)然，13%的受訪者承認(rèn)他們還將DevOps團(tuán)隊(duì)重新標(biāo)記為平臺工程，“聽起來更高級”，因此Gartner可能是對的，這個(gè)學(xué)科已經(jīng)滑入了“幻滅的低谷”。

今年的“DevOps加速狀態(tài)”——更常被稱為DORA報(bào)告——發(fā)現(xiàn)了令人沮喪的結(jié)果。例如，DORA研究人員發(fā)現(xiàn)，使用平臺工程，吞吐量下降了8%，變更穩(wěn)定性下降了14%。

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

從DevOps到平臺工程師

這份年度報(bào)告獨(dú)特地展示了平臺工程作為DevOps在職位角色方面的演變。 這份報(bào)告將基礎(chǔ)設(shè)施平臺工程師和DevEx平臺工程師置于就業(yè)金字塔中基礎(chǔ)設(shè)施、運(yùn)營和開發(fā)角色之上。與DevOps角色相比，負(fù)責(zé)通過標(biāo)準(zhǔn)化和自動(dòng)化來緩解基礎(chǔ)層痛點(diǎn)的這些平臺“價(jià)值驅(qū)動(dòng)者”數(shù)量較少。

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

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

雖然2022年平臺工程師和DevOps角色之間的區(qū)別模糊不清，但這份報(bào)告顯示，到2024年，平臺團(tuán)隊(duì)對其職權(quán)范圍內(nèi)的內(nèi)容有了更清晰的認(rèn)識。平臺工程師告訴研究人員，他們負(fù)責(zé)：

只有一小部分受訪者認(rèn)為，作為平臺工程師，他們的職責(zé)是充當(dāng)開發(fā)者幫助臺（19%）或?yàn)楦吖軇?chuàng)建儀表板（9%）。

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

Barlien推測，“這可能是由于大規(guī)模裁員導(dǎo)致差距縮小，也可能是由于DevOps薪資上漲而平臺工程薪資下降，[目前]尚不確定?！?/p>

過去三年來，這份報(bào)告始終衡量的是，擁有平臺工程師職位的員工比擁有DevOps職位的員工擁有更長的工作經(jīng)驗(yàn)。事實(shí)上，今年接受調(diào)查的平臺工程師中有28%擁有超過15年的科技行業(yè)經(jīng)驗(yàn)。

平臺團(tuán)隊(duì)的成熟度如何？

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

這是一個(gè)衡量平臺工程計(jì)劃并確定改進(jìn)領(lǐng)域的框架，涵蓋：

• 投資
• 采用
• 接口
• 運(yùn)營
• 衡量

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

• 試運(yùn)行
• 運(yùn)行
• 可擴(kuò)展
• 優(yōu)化

去年的“平臺工程現(xiàn)狀報(bào)告第2卷”發(fā)現(xiàn)，平臺工程組織還處于起步階段，尚未實(shí)施最佳實(shí)踐，包括：

• 變更管理流程
• 跨組織的認(rèn)同
• 明確的平臺團(tuán)隊(duì)結(jié)構(gòu)
• 一種產(chǎn)品化平臺思維
• 平臺采用策略

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

簡而言之，大多數(shù)團(tuán)隊(duì)遠(yuǎn)未成熟。

Barlien說：“這里反映的情況是，對于那些做得好的平臺工程人員來說，效果非常好。而對于那些做得不好的人，結(jié)果完全相反?！?/p>

根據(jù)CNCF平臺成熟度模型的標(biāo)準(zhǔn)，只有大約9%的受訪者確實(shí)成熟。與這少數(shù)人相比，Barlien和他的團(tuán)隊(duì)發(fā)現(xiàn)，對于什么是平臺工程，總體上缺乏清晰的認(rèn)識——即使是那些據(jù)稱擔(dān)任平臺工程師的人。

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

報(bào)告指出，雖然許多公司都在采用平臺工程，但只有少數(shù)公司能夠以成熟和可擴(kuò)展的方式實(shí)現(xiàn)其潛力。

但是，如果接受采訪的平均團(tuán)隊(duì)成立時(shí)間在0到24個(gè)月之間，這就不足為奇了。

平臺團(tuán)隊(duì)不知道如何衡量

今年的“平臺工程現(xiàn)狀”報(bào)告揭示了工程或任何科學(xué)領(lǐng)域中最響亮的秘密：你無法改進(jìn)你無法衡量的東西。

大約43%的受訪平臺團(tuán)隊(duì)將他們的反饋機(jī)制描述為“臨時(shí)性”或“不一致”。這與CNCF的定量和定性反饋標(biāo)準(zhǔn)相差甚遠(yuǎn)。

Barlien說：“人們不知道自己在做什么。這大概就是主要的結(jié)論。” 事實(shí)上，45%的平臺團(tuán)隊(duì)根本沒有任何衡量指標(biāo)，而37%的團(tuán)隊(duì)只衡量DORA指標(biāo)。雖然DORA關(guān)注吞吐量和穩(wěn)定性是開發(fā)者體驗(yàn)的重要方面，但這肯定無法全面展現(xiàn)DevEx的細(xì)節(jié)。

“如果你不進(jìn)行衡量，你就不知道你是否真的產(chǎn)生了影響，”Barlien說，“然后突然六個(gè)月后，你進(jìn)行檢查，一切感覺都更糟了?！?/p>

另外26%的調(diào)查參與者報(bào)告說他們收集了數(shù)據(jù)，但實(shí)際上并沒有分析這些數(shù)據(jù)。

當(dāng)被問及自引入平臺工程以來，指標(biāo)是如何改進(jìn)的時(shí)，只有22%的人報(bào)告了顯著改進(jìn)，而32%的人看到了輕微的改進(jìn)。相比之下，17%的人報(bào)告沒有明顯變化，而27%的人表示不確定。

這不僅會損害平臺團(tuán)隊(duì)的積極性——還會讓證明他們已經(jīng)獲得了預(yù)算，并值得保住工作變得困難。

報(bào)告還指出，39%的團(tuán)隊(duì)報(bào)告說他們的平臺“以集中方式啟用，并專注于用戶需求”。但如果他們沒有對此進(jìn)行衡量，那么這種描述可能基于假設(shè)：“這種差距表明，許多組織對自身的評價(jià)遠(yuǎn)高于實(shí)際情況?！?/p>

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

“人們同時(shí)說，‘哦，是的，一切都很棒?！缓笏麄冇终f，‘哦，不，我們什么也沒衡量，’”Barlien反思道?！爱?dāng)你看到像DORA這樣的東西時(shí)，這就不足為奇了——不穩(wěn)定性和認(rèn)知負(fù)荷都在上升。

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

缺少什么？產(chǎn)品思維

“平臺工程是產(chǎn)品管理和一些堅(jiān)定地專注于技術(shù)和工程之間的一步，”Barlien說。但他補(bǔ)充說，許多平臺團(tuán)隊(duì)仍然不明白這一點(diǎn)。

他說，大多數(shù)平臺團(tuán)隊(duì)仍然缺乏產(chǎn)品管理方面的理解，包括：

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

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

這份報(bào)告沒有使用確切的術(shù)語，而是指出平臺即產(chǎn)品思維是少數(shù)做得好的平臺工程受訪者與大多數(shù)做得不好的受訪者之間的主要區(qū)別。

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