?撰稿丨千山

審校 | 云昭

近年來，部分國外的開發(fā)者公開發(fā)聲：DevOps就是扯淡，開發(fā)根本不想做運(yùn)維。

更有甚者，直言“DevOps已死，平臺(tái)工程才是未來”。

之后不久，Gartner發(fā)布2023年十大戰(zhàn)略技術(shù)趨勢，“平臺(tái)工程”赫然在列。Gartner預(yù)測，到2026年，80%的軟件工程組織將建立平臺(tái)團(tuán)隊(duì)，其中75%將包含開發(fā)者自助服務(wù)門戶。

平臺(tái)工程，即platform engineering，作為流行概念，在開發(fā)領(lǐng)域迅速成為一顆冉冉升起的新星。但出于某種營銷策略，總會(huì)有人將平臺(tái)工程宣告為DevOps的終結(jié)。甚至一些從業(yè)者也在向大眾描述這樣一幅圖景：DevOps走向末路，平臺(tái)工程未來可期。

但事實(shí)上，DevOps和平臺(tái)工程并非這種“你死我活”的關(guān)系，兩者并不矛盾，甚至在某種程度上可以說，平臺(tái)工程有可能為DevOps帶來新生。

1、DevOps進(jìn)化“三難題”

DevOps是一種文化，作為敏捷軟件文化的一部分，它誕生的土壤根植于兩點(diǎn)：以敏捷開發(fā)為代表的持續(xù)開發(fā)方式的出現(xiàn)以及持續(xù)開發(fā)帶來的運(yùn)維問題。

從團(tuán)隊(duì)角度看，DevOps往往涵蓋包容、協(xié)作、自主和共同責(zé)任等要義，彌補(bǔ)了開發(fā)與運(yùn)維間的矛盾；從流程角度看，DevOps旨在構(gòu)建能滿足持續(xù)改進(jìn)目標(biāo)的敏捷開發(fā)實(shí)踐；從工具角度看，DevOps通過擁抱自動(dòng)化來創(chuàng)建快速反饋循環(huán)從而提升質(zhì)量和敏捷性。

早在2006年，亞馬遜CTO沃納·沃格斯（Werner Vogels）就首次提到了“你建立，你運(yùn)行（You build it, you run it.）”的理念，確立了開發(fā)人員應(yīng)該在整個(gè)生命周期中“擁有”他們的應(yīng)用程序。但是等DevOps文化開始盛行，各大公司紛紛進(jìn)行實(shí)踐時(shí)，各色挑戰(zhàn)又不斷浮出水面。

第一，當(dāng)DevOps實(shí)踐需要支持許多開發(fā)和產(chǎn)品團(tuán)隊(duì)時(shí)，擴(kuò)展問題就會(huì)出現(xiàn)，每個(gè)團(tuán)隊(duì)都在技術(shù)棧、工具、流程、云服務(wù)提供商及其特性和功能上做出自己的決定。這不僅會(huì)導(dǎo)致效率低下，還會(huì)讓管理愈加繁重。

第二，隨著云原生技術(shù)的推廣與普及，無論從數(shù)量還是復(fù)雜性來看，工具環(huán)境都在快速增長。過去數(shù)年中，開發(fā)人員對(duì)軟件交付過程中越來越多的部分負(fù)責(zé)。這種復(fù)雜性給開發(fā)人員帶來了極大的認(rèn)知負(fù)擔(dān)，還增加了新功能開發(fā)的啟動(dòng)時(shí)間。

正如初創(chuàng)公司Humanitec的首席執(zhí)行官Kaspar Von Grünberg在公開講話中提到的，在一個(gè)微服務(wù)和多個(gè)分布式部署環(huán)境迅速擴(kuò)散的時(shí)代，運(yùn)營規(guī)模與既往不同，應(yīng)用也要復(fù)雜得多，對(duì)開發(fā)人員要求過多是不現(xiàn)實(shí)的。他如是描述，端到端的所有權(quán)是“一個(gè)崇高的夢想，但對(duì)個(gè)人貢獻(xiàn)者不公平。我們要求開發(fā)者一次性完成這么多工作。然后我們總是抱怨沒有輸出或者交付速度不夠快。但事實(shí)卻是我們沒有讓他們輕易兌現(xiàn)承諾?！?/p>

第三，文化障礙。Puppet發(fā)布的2021年度DevOps狀況調(diào)查報(bào)告指出，83%的IT決策者表明他們的組織正在實(shí)施DevOps實(shí)踐。但與此同時(shí)，絕大多數(shù)組織仍然停留在DevOps演變的中期階段。其中，文化問題是DevOps取得成功的主要障礙，錯(cuò)位的激勵(lì)措施和問責(zé)結(jié)構(gòu)都會(huì)成為成熟度的制約因素。

可以看到，DevOps的興起源于企業(yè)有意彌合運(yùn)維與開發(fā)之間的裂隙，但在實(shí)施過程中有部分企業(yè)簡單粗暴地將其理解為“讓開發(fā)人員去負(fù)責(zé)運(yùn)維的工作”，甚至讓高級(jí)開發(fā)人員接管了運(yùn)維角色，導(dǎo)致了開發(fā)漸漸不堪重負(fù)。

2、平臺(tái)工程因何而生

這一現(xiàn)實(shí)也引出了DevOps停滯背后的核心矛盾：開發(fā)者不想跟基礎(chǔ)設(shè)施打交道，但企業(yè)在發(fā)展過程中又需要專人管控自己的基礎(chǔ)設(shè)施。在此背景下，平臺(tái)工程應(yīng)運(yùn)而生。

Luca Galante將平臺(tái)工程定義為“設(shè)計(jì)和構(gòu)建工具鏈和工作流的學(xué)科，為云原生時(shí)代的軟件工程組織提供自助服務(wù)功能。平臺(tái)工程師提供的集成產(chǎn)品通常被稱為‘內(nèi)部開發(fā)人員平臺(tái)（IDP）’，涵蓋了應(yīng)用程序整個(gè)生命周期的運(yùn)營需求。”

當(dāng)然，目前來說，平臺(tái)工程并無公認(rèn)的概念。而且由于每個(gè)企業(yè)的堆棧、文化、代碼庫和工具集的不同，也很難設(shè)定標(biāo)準(zhǔn)化的建設(shè)方式。

正如ThoughtWorks工程主管Evan Bottcher所說，“很難用語言表示?！脚_(tái)’其實(shí)是一個(gè)非常模糊的術(shù)語，我們用來形容對(duì)提高大規(guī)模交付速度和效率非常重要的方法。”他更愿意將這一“平臺(tái)”形容為：“自助服務(wù)API、工具、服務(wù)、知識(shí)和支持的基礎(chǔ)，被配置為備受關(guān)注的內(nèi)部產(chǎn)品?！?/p>

簡單來說，平臺(tái)工程面向的是開發(fā)人員，作為一套自助式內(nèi)部開發(fā)者平臺(tái)的機(jī)制和架構(gòu)，用于構(gòu)建和運(yùn)營支持軟件交付和生命周期管理，主要目標(biāo)是優(yōu)化開發(fā)者體驗(yàn)，并加快產(chǎn)品團(tuán)隊(duì)為客戶創(chuàng)造價(jià)值的速度。

通過建設(shè)這樣一個(gè)企業(yè)內(nèi)部開發(fā)平臺(tái)，可以讓開發(fā)者以“自助式”實(shí)現(xiàn)應(yīng)用的端到端流程。Grünberg表示，成功的平臺(tái)團(tuán)隊(duì)會(huì)創(chuàng)建一條“黃金路徑”，將開發(fā)人員從不必要的認(rèn)知負(fù)荷中解放出來，同時(shí)保留開發(fā)人員在需要時(shí)偏離路徑的自由。而且對(duì)Ops工程師來說，采用平臺(tái)工程還可以幫助他們擺脫反復(fù)做同樣的任務(wù)。

理想狀態(tài)下，一個(gè)功能完備的內(nèi)部開發(fā)平臺(tái)能夠降低系統(tǒng)的復(fù)雜性，加快軟件部署周期，提高開發(fā)人員的工作效率，同時(shí)降低運(yùn)營負(fù)擔(dān)。從這一角度看，平臺(tái)工程與DevOps并不矛盾。

平臺(tái)工程將很多運(yùn)維操作抽象化，提供簡單易用的操作界面，讓運(yùn)維這件事情不再需要高級(jí)的專業(yè)知識(shí)，從而讓DevOps的理念有了喘息之機(jī)。

以Kubernetes為例。在一些DevOps設(shè)置中，開發(fā)人員在每次接觸Kubernetes相關(guān)的交付設(shè)置時(shí)往往都會(huì)有所顧慮。如果想提高效率，就需要為Kubernetes設(shè)置實(shí)現(xiàn)真正的自助服務(wù)。

開發(fā)者自助服務(wù)意味著工程師可以自行調(diào)配和使用測試、保護(hù)和部署應(yīng)用程序和服務(wù)所需的技術(shù)，而無需等待Ops提供資源或啟動(dòng)環(huán)境。平臺(tái)工程的主要作用就在于此：通過內(nèi)部開發(fā)人員平臺(tái)進(jìn)行抽象，提供了易于使用的構(gòu)建塊，降低了開發(fā)人員完成工作所需的Kubernetes專業(yè)知識(shí)水平，從而可以花更少的時(shí)間擺弄基礎(chǔ)設(shè)施，更多的時(shí)間專注客戶功能。

此外，在涉及重復(fù)性任務(wù)時(shí)，這種自助服務(wù)會(huì)減少大量的瓶頸和關(guān)鍵人員依賴，進(jìn)而節(jié)省團(tuán)隊(duì)時(shí)間和資源，加快交付周期和創(chuàng)新周期。

曾在谷歌從事過內(nèi)部開發(fā)平臺(tái)建設(shè)的Chris Stephenson曾在博客中提到：“一個(gè)有效的內(nèi)部開發(fā)者平臺(tái)的關(guān)鍵點(diǎn)在于能夠把復(fù)雜的問題劃分好。每個(gè)人都有自己擅長處理的一部分復(fù)雜問題，而其他人完全可以忽略這些問題?！?/p>

因此，忽略那些讓DevOps 消亡的雜音，專注于采用有助于企業(yè)在DevOps旅程中更快成熟的方法論，或許會(huì)成為更多人了解和進(jìn)行平臺(tái)工程實(shí)踐的初衷。

3、開發(fā)和運(yùn)維，可以快樂“玩?！?/h4>

DevOps的核心理念是縮短流程長度，實(shí)現(xiàn)敏捷化運(yùn)營。但矛盾的點(diǎn)在于開發(fā)和運(yùn)維本身是有各自專業(yè)門檻的角色，即使是在一些真正實(shí)踐DevOps的大公司，開發(fā)能做的或許也就是部署和監(jiān)控，更高階的運(yùn)維操，諸如容器替換等，還是要交給云平臺(tái)或架構(gòu)部來負(fù)責(zé)。

更重要的是，企圖讓一人承擔(dān)兩角的結(jié)果就是，不但會(huì)減少開發(fā)本職的投入，而且也會(huì)因技能點(diǎn)和時(shí)間所限而無法保障交付質(zhì)量。而平臺(tái)工程的出現(xiàn)提供了新解，它并不試圖解決開發(fā)與運(yùn)維的分工問題，也不會(huì)試圖介入干預(yù)運(yùn)維流程，而是用平臺(tái)工程去抽象專業(yè)化能力，提供更易用的工具，來幫助完成運(yùn)維這件事。

當(dāng)然也要遵循一些基本的分工邊界。因?yàn)殚_發(fā)在DevOps上的痛點(diǎn)不光是技能門檻，還有時(shí)間的分配問題。在運(yùn)維領(lǐng)域，可以將和開發(fā)密切相關(guān)的工作（比如部署、發(fā)布），通過平臺(tái)工程將能力開放給開發(fā)。但一些耗時(shí)較長的周期性工作，監(jiān)控、巡檢之類，還是交給專業(yè)的運(yùn)維團(tuán)隊(duì)為宜。

總體而言，平臺(tái)工程對(duì)于彌合開發(fā)和運(yùn)維之間的溝壑是有助益的。內(nèi)部開發(fā)平臺(tái)和DevOps團(tuán)隊(duì)的工作會(huì)有一定的交集，DevOps工程師也會(huì)有一定機(jī)會(huì)過渡到平臺(tái)工程師的角色，在整個(gè)組織中產(chǎn)生更廣泛的影響，并將他們的專業(yè)知識(shí)應(yīng)用于為開發(fā)人員提供更好的體驗(yàn)。開發(fā)人員不必在基礎(chǔ)設(shè)施和其他Ops任務(wù)上陷入泥沼，運(yùn)維可以更聚焦向上游轉(zhuǎn)移到更關(guān)鍵的任務(wù)。內(nèi)部開發(fā)人員平臺(tái)使開發(fā)人員和運(yùn)維人員能夠?qū)Ｗ⒂诟髯怨ぷ鞯暮诵穆氊?zé)和優(yōu)勢，真正實(shí)現(xiàn)“術(shù)業(yè)有專攻”“專人做專事”。

參考鏈接：

https://baijiahao.baidu.com/s?id=1754504889810005642

https://thenewstack.io/kubernetes-pains-platform-engineering-can-help/

https://baijiahao.baidu.com/s?id=1699154279421899478