?撰稿丨千山
審校 | 云昭
近年來(lái)，部分國(guó)外的開(kāi)發(fā)者公開(kāi)發(fā)聲：DevOps就是扯淡，開(kāi)發(fā)根本不想做運(yùn)維。
更有甚者，直言“DevOps已死，平臺(tái)工程才是未來(lái)”。
之后不久，Gartner發(fā)布2023年十大戰(zhàn)略技術(shù)趨勢(shì)，“平臺(tái)工程”赫然在列。Gartner預(yù)測(cè)，到2026年，80%的軟件工程組織將建立平臺(tái)團(tuán)隊(duì)，其中75%將包含開(kāi)發(fā)者自助服務(wù)門戶。
平臺(tái)工程，即platform engineering，作為流行概念，在開(kāi)發(fā)領(lǐng)域迅速成為一顆冉冉升起的新星。但出于某種營(yíng)銷策略，總會(huì)有人將平臺(tái)工程宣告為DevOps的終結(jié)。甚至一些從業(yè)者也在向大眾描述這樣一幅圖景：DevOps走向末路，平臺(tái)工程未來(lái)可期。
但事實(shí)上，DevOps和平臺(tái)工程并非這種“你死我活”的關(guān)系，兩者并不矛盾，甚至在某種程度上可以說(shuō)，平臺(tái)工程有可能為DevOps帶來(lái)新生。
1、DevOps進(jìn)化“三難題”
DevOps是一種文化，作為敏捷軟件文化的一部分，它誕生的土壤根植于兩點(diǎn)：以敏捷開(kāi)發(fā)為代表的持續(xù)開(kāi)發(fā)方式的出現(xiàn)以及持續(xù)開(kāi)發(fā)帶來(lái)的運(yùn)維問(wèn)題。
從團(tuán)隊(duì)角度看，DevOps往往涵蓋包容、協(xié)作、自主和共同責(zé)任等要義，彌補(bǔ)了開(kāi)發(fā)與運(yùn)維間的矛盾；從流程角度看，DevOps旨在構(gòu)建能滿足持續(xù)改進(jìn)目標(biāo)的敏捷開(kāi)發(fā)實(shí)踐；從工具角度看，DevOps通過(guò)擁抱自動(dòng)化來(lái)創(chuàng)建快速反饋循環(huán)從而提升質(zhì)量和敏捷性。
早在2006年，亞馬遜CTO沃納·沃格斯（Werner Vogels）就首次提到了“你建立，你運(yùn)行（You build it, you run it.）”的理念，確立了開(kāi)發(fā)人員應(yīng)該在整個(gè)生命周期中“擁有”他們的應(yīng)用程序。但是等DevOps文化開(kāi)始盛行，各大公司紛紛進(jìn)行實(shí)踐時(shí)，各色挑戰(zhàn)又不斷浮出水面。
第一，當(dāng)DevOps實(shí)踐需要支持許多開(kāi)發(fā)和產(chǎn)品團(tuán)隊(duì)時(shí)，擴(kuò)展問(wèn)題就會(huì)出現(xiàn)，每個(gè)團(tuán)隊(duì)都在技術(shù)棧、工具、流程、云服務(wù)提供商及其特性和功能上做出自己的決定。這不僅會(huì)導(dǎo)致效率低下，還會(huì)讓管理愈加繁重。
第二，隨著云原生技術(shù)的推廣與普及，無(wú)論從數(shù)量還是復(fù)雜性來(lái)看，工具環(huán)境都在快速增長(zhǎng)。過(guò)去數(shù)年中，開(kāi)發(fā)人員對(duì)軟件交付過(guò)程中越來(lái)越多的部分負(fù)責(zé)。這種復(fù)雜性給開(kāi)發(fā)人員帶來(lái)了極大的認(rèn)知負(fù)擔(dān)，還增加了新功能開(kāi)發(fā)的啟動(dòng)時(shí)間。
正如初創(chuàng)公司Humanitec的首席執(zhí)行官Kaspar Von Grünberg在公開(kāi)講話中提到的，在一個(gè)微服務(wù)和多個(gè)分布式部署環(huán)境迅速擴(kuò)散的時(shí)代，運(yùn)營(yíng)規(guī)模與既往不同，應(yīng)用也要復(fù)雜得多，對(duì)開(kāi)發(fā)人員要求過(guò)多是不現(xiàn)實(shí)的。他如是描述，端到端的所有權(quán)是“一個(gè)崇高的夢(mèng)想，但對(duì)個(gè)人貢獻(xiàn)者不公平。我們要求開(kāi)發(fā)者一次性完成這么多工作。然后我們總是抱怨沒(méi)有輸出或者交付速度不夠快。但事實(shí)卻是我們沒(méi)有讓他們輕易兌現(xiàn)承諾。”
第三，文化障礙。Puppet發(fā)布的2021年度DevOps狀況調(diào)查報(bào)告指出，83%的IT決策者表明他們的組織正在實(shí)施DevOps實(shí)踐。但與此同時(shí)，絕大多數(shù)組織仍然停留在DevOps演變的中期階段。其中，文化問(wèn)題是DevOps取得成功的主要障礙，錯(cuò)位的激勵(lì)措施和問(wèn)責(zé)結(jié)構(gòu)都會(huì)成為成熟度的制約因素。
可以看到，DevOps的興起源于企業(yè)有意彌合運(yùn)維與開(kāi)發(fā)之間的裂隙，但在實(shí)施過(guò)程中有部分企業(yè)簡(jiǎn)單粗暴地將其理解為“讓開(kāi)發(fā)人員去負(fù)責(zé)運(yùn)維的工作”，甚至讓高級(jí)開(kāi)發(fā)人員接管了運(yùn)維角色，導(dǎo)致了開(kāi)發(fā)漸漸不堪重負(fù)。
2、平臺(tái)工程因何而生
這一現(xiàn)實(shí)也引出了DevOps停滯背后的核心矛盾：開(kāi)發(fā)者不想跟基礎(chǔ)設(shè)施打交道，但企業(yè)在發(fā)展過(guò)程中又需要專人管控自己的基礎(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)部開(kāi)發(fā)人員平臺(tái)（IDP）’，涵蓋了應(yīng)用程序整個(gè)生命周期的運(yùn)營(yíng)需求。”
當(dāng)然，目前來(lái)說(shuō)，平臺(tái)工程并無(wú)公認(rèn)的概念。而且由于每個(gè)企業(yè)的堆棧、文化、代碼庫(kù)和工具集的不同，也很難設(shè)定標(biāo)準(zhǔn)化的建設(shè)方式。
正如ThoughtWorks工程主管Evan Bottcher所說(shuō)，“很難用語(yǔ)言表示。‘平臺(tái)’其實(shí)是一個(gè)非常模糊的術(shù)語(yǔ)，我們用來(lái)形容對(duì)提高大規(guī)模交付速度和效率非常重要的方法。”他更愿意將這一“平臺(tái)”形容為：“自助服務(wù)API、工具、服務(wù)、知識(shí)和支持的基礎(chǔ)，被配置為備受關(guān)注的內(nèi)部產(chǎn)品。”
簡(jiǎn)單來(lái)說(shuō)，平臺(tái)工程面向的是開(kāi)發(fā)人員，作為一套自助式內(nèi)部開(kāi)發(fā)者平臺(tái)的機(jī)制和架構(gòu)，用于構(gòu)建和運(yùn)營(yíng)支持軟件交付和生命周期管理，主要目標(biāo)是優(yōu)化開(kāi)發(fā)者體驗(yàn)，并加快產(chǎn)品團(tuán)隊(duì)為客戶創(chuàng)造價(jià)值的速度。
通過(guò)建設(shè)這樣一個(gè)企業(yè)內(nèi)部開(kāi)發(fā)平臺(tái)，可以讓開(kāi)發(fā)者以“自助式”實(shí)現(xiàn)應(yīng)用的端到端流程。Grünberg表示，成功的平臺(tái)團(tuán)隊(duì)會(huì)創(chuàng)建一條“黃金路徑”，將開(kāi)發(fā)人員從不必要的認(rèn)知負(fù)荷中解放出來(lái)，同時(shí)保留開(kāi)發(fā)人員在需要時(shí)偏離路徑的自由。而且對(duì)Ops工程師來(lái)說(shuō)，采用平臺(tái)工程還可以幫助他們擺脫反復(fù)做同樣的任務(wù)。
理想狀態(tài)下，一個(gè)功能完備的內(nèi)部開(kāi)發(fā)平臺(tái)能夠降低系統(tǒng)的復(fù)雜性，加快軟件部署周期，提高開(kāi)發(fā)人員的工作效率，同時(shí)降低運(yùn)營(yíng)負(fù)擔(dān)。從這一角度看，平臺(tái)工程與DevOps并不矛盾。
平臺(tái)工程將很多運(yùn)維操作抽象化，提供簡(jiǎn)單易用的操作界面，讓運(yùn)維這件事情不再需要高級(jí)的專業(yè)知識(shí)，從而讓DevOps的理念有了喘息之機(jī)。
以Kubernetes為例。在一些DevOps設(shè)置中，開(kāi)發(fā)人員在每次接觸Kubernetes相關(guān)的交付設(shè)置時(shí)往往都會(huì)有所顧慮。如果想提高效率，就需要為Kubernetes設(shè)置實(shí)現(xiàn)真正的自助服務(wù)。
開(kāi)發(fā)者自助服務(wù)意味著工程師可以自行調(diào)配和使用測(cè)試、保護(hù)和部署應(yīng)用程序和服務(wù)所需的技術(shù)，而無(wú)需等待Ops提供資源或啟動(dòng)環(huán)境。平臺(tái)工程的主要作用就在于此：通過(guò)內(nèi)部開(kāi)發(fā)人員平臺(tái)進(jìn)行抽象，提供了易于使用的構(gòu)建塊，降低了開(kāi)發(fā)人員完成工作所需的Kubernetes專業(yè)知識(shí)水平，從而可以花更少的時(shí)間擺弄基礎(chǔ)設(shè)施，更多的時(shí)間專注客戶功能。
此外，在涉及重復(fù)性任務(wù)時(shí)，這種自助服務(wù)會(huì)減少大量的瓶頸和關(guān)鍵人員依賴，進(jìn)而節(jié)省團(tuán)隊(duì)時(shí)間和資源，加快交付周期和創(chuàng)新周期。
曾在谷歌從事過(guò)內(nèi)部開(kāi)發(fā)平臺(tái)建設(shè)的Chris Stephenson曾在博客中提到：“一個(gè)有效的內(nèi)部開(kāi)發(fā)者平臺(tái)的關(guān)鍵點(diǎn)在于能夠把復(fù)雜的問(wèn)題劃分好。每個(gè)人都有自己擅長(zhǎng)處理的一部分復(fù)雜問(wèn)題，而其他人完全可以忽略這些問(wèn)題。”
因此，忽略那些讓DevOps 消亡的雜音，專注于采用有助于企業(yè)在DevOps旅程中更快成熟的方法論，或許會(huì)成為更多人了解和進(jìn)行平臺(tái)工程實(shí)踐的初衷。
3、開(kāi)發(fā)和運(yùn)維，可以快樂(lè)“玩耍”
DevOps的核心理念是縮短流程長(zhǎng)度，實(shí)現(xiàn)敏捷化運(yùn)營(yíng)。但矛盾的點(diǎn)在于開(kāi)發(fā)和運(yùn)維本身是有各自專業(yè)門檻的角色，即使是在一些真正實(shí)踐DevOps的大公司，開(kāi)發(fā)能做的或許也就是部署和監(jiān)控，更高階的運(yùn)維操，諸如容器替換等，還是要交給云平臺(tái)或架構(gòu)部來(lái)負(fù)責(zé)。
更重要的是，企圖讓一人承擔(dān)兩角的結(jié)果就是，不但會(huì)減少開(kāi)發(fā)本職的投入，而且也會(huì)因技能點(diǎn)和時(shí)間所限而無(wú)法保障交付質(zhì)量。而平臺(tái)工程的出現(xiàn)提供了新解，它并不試圖解決開(kāi)發(fā)與運(yùn)維的分工問(wèn)題，也不會(huì)試圖介入干預(yù)運(yùn)維流程，而是用平臺(tái)工程去抽象專業(yè)化能力，提供更易用的工具，來(lái)幫助完成運(yùn)維這件事。
當(dāng)然也要遵循一些基本的分工邊界。因?yàn)殚_(kāi)發(fā)在DevOps上的痛點(diǎn)不光是技能門檻，還有時(shí)間的分配問(wèn)題。在運(yùn)維領(lǐng)域，可以將和開(kāi)發(fā)密切相關(guān)的工作（比如部署、發(fā)布），通過(guò)平臺(tái)工程將能力開(kāi)放給開(kāi)發(fā)。但一些耗時(shí)較長(zhǎng)的周期性工作，監(jiān)控、巡檢之類，還是交給專業(yè)的運(yùn)維團(tuán)隊(duì)為宜。
總體而言，平臺(tái)工程對(duì)于彌合開(kāi)發(fā)和運(yùn)維之間的溝壑是有助益的。內(nèi)部開(kāi)發(fā)平臺(tái)和DevOps團(tuán)隊(duì)的工作會(huì)有一定的交集，DevOps工程師也會(huì)有一定機(jī)會(huì)過(guò)渡到平臺(tái)工程師的角色，在整個(gè)組織中產(chǎn)生更廣泛的影響，并將他們的專業(yè)知識(shí)應(yīng)用于為開(kāi)發(fā)人員提供更好的體驗(yàn)。開(kāi)發(fā)人員不必在基礎(chǔ)設(shè)施和其他Ops任務(wù)上陷入泥沼，運(yùn)維可以更聚焦向上游轉(zhuǎn)移到更關(guān)鍵的任務(wù)。內(nèi)部開(kāi)發(fā)人員平臺(tái)使開(kāi)發(fā)人員和運(yùn)維人員能夠?qū)Ｗ⒂诟髯怨ぷ鞯暮诵穆氊?zé)和優(yōu)勢(shì)，真正實(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
