?撰稿丨千山

審校 | 云昭

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

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

之后不久，Gartner發布2023年十大戰略技術趨勢，“平臺工程”赫然在列。Gartner預測，到2026年，80%的軟件工程組織將建立平臺團隊，其中75%將包含開發者自助服務門戶。

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

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

1、DevOps進化“三難題”

DevOps是一種文化，作為敏捷軟件文化的一部分，它誕生的土壤根植于兩點：以敏捷開發為代表的持續開發方式的出現以及持續開發帶來的運維問題。

從團隊角度看，DevOps往往涵蓋包容、協作、自主和共同責任等要義，彌補了開發與運維間的矛盾；從流程角度看，DevOps旨在構建能滿足持續改進目標的敏捷開發實踐；從工具角度看，DevOps通過擁抱自動化來創建快速反饋循環從而提升質量和敏捷性。

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

第一，當DevOps實踐需要支持許多開發和產品團隊時，擴展問題就會出現，每個團隊都在技術棧、工具、流程、云服務提供商及其特性和功能上做出自己的決定。這不僅會導致效率低下，還會讓管理愈加繁重。

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

正如初創公司Humanitec的首席執行官Kaspar Von Grünberg在公開講話中提到的，在一個微服務和多個分布式部署環境迅速擴散的時代，運營規模與既往不同，應用也要復雜得多，對開發人員要求過多是不現實的。他如是描述，端到端的所有權是“一個崇高的夢想，但對個人貢獻者不公平。我們要求開發者一次性完成這么多工作。然后我們總是抱怨沒有輸出或者交付速度不夠快。但事實卻是我們沒有讓他們輕易兌現承諾。”

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

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

2、平臺工程因何而生

這一現實也引出了DevOps停滯背后的核心矛盾：開發者不想跟基礎設施打交道，但企業在發展過程中又需要專人管控自己的基礎設施。在此背景下，平臺工程應運而生。

Luca Galante將平臺工程定義為“設計和構建工具鏈和工作流的學科，為云原生時代的軟件工程組織提供自助服務功能。平臺工程師提供的集成產品通常被稱為‘內部開發人員平臺（IDP）’，涵蓋了應用程序整個生命周期的運營需求。”

當然，目前來說，平臺工程并無公認的概念。而且由于每個企業的堆棧、文化、代碼庫和工具集的不同，也很難設定標準化的建設方式。

正如ThoughtWorks工程主管Evan Bottcher所說，“很難用語言表示。‘平臺’其實是一個非常模糊的術語，我們用來形容對提高大規模交付速度和效率非常重要的方法。”他更愿意將這一“平臺”形容為：“自助服務API、工具、服務、知識和支持的基礎，被配置為備受關注的內部產品。”

簡單來說，平臺工程面向的是開發人員，作為一套自助式內部開發者平臺的機制和架構，用于構建和運營支持軟件交付和生命周期管理，主要目標是優化開發者體驗，并加快產品團隊為客戶創造價值的速度。

通過建設這樣一個企業內部開發平臺，可以讓開發者以“自助式”實現應用的端到端流程。Grünberg表示，成功的平臺團隊會創建一條“黃金路徑”，將開發人員從不必要的認知負荷中解放出來，同時保留開發人員在需要時偏離路徑的自由。而且對Ops工程師來說，采用平臺工程還可以幫助他們擺脫反復做同樣的任務。

理想狀態下，一個功能完備的內部開發平臺能夠降低系統的復雜性，加快軟件部署周期，提高開發人員的工作效率，同時降低運營負擔。從這一角度看，平臺工程與DevOps并不矛盾。

平臺工程將很多運維操作抽象化，提供簡單易用的操作界面，讓運維這件事情不再需要高級的專業知識，從而讓DevOps的理念有了喘息之機。

以Kubernetes為例。在一些DevOps設置中，開發人員在每次接觸Kubernetes相關的交付設置時往往都會有所顧慮。如果想提高效率，就需要為Kubernetes設置實現真正的自助服務。

開發者自助服務意味著工程師可以自行調配和使用測試、保護和部署應用程序和服務所需的技術，而無需等待Ops提供資源或啟動環境。平臺工程的主要作用就在于此：通過內部開發人員平臺進行抽象，提供了易于使用的構建塊，降低了開發人員完成工作所需的Kubernetes專業知識水平，從而可以花更少的時間擺弄基礎設施，更多的時間專注客戶功能。

此外，在涉及重復性任務時，這種自助服務會減少大量的瓶頸和關鍵人員依賴，進而節省團隊時間和資源，加快交付周期和創新周期。

曾在谷歌從事過內部開發平臺建設的Chris Stephenson曾在博客中提到：“一個有效的內部開發者平臺的關鍵點在于能夠把復雜的問題劃分好。每個人都有自己擅長處理的一部分復雜問題，而其他人完全可以忽略這些問題。”

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

3、開發和運維，可以快樂“玩耍”

DevOps的核心理念是縮短流程長度，實現敏捷化運營。但矛盾的點在于開發和運維本身是有各自專業門檻的角色，即使是在一些真正實踐DevOps的大公司，開發能做的或許也就是部署和監控，更高階的運維操，諸如容器替換等，還是要交給云平臺或架構部來負責。

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

當然也要遵循一些基本的分工邊界。因為開發在DevOps上的痛點不光是技能門檻，還有時間的分配問題。在運維領域，可以將和開發密切相關的工作（比如部署、發布），通過平臺工程將能力開放給開發。但一些耗時較長的周期性工作，監控、巡檢之類，還是交給專業的運維團隊為宜。

總體而言，平臺工程對于彌合開發和運維之間的溝壑是有助益的。內部開發平臺和DevOps團隊的工作會有一定的交集，DevOps工程師也會有一定機會過渡到平臺工程師的角色，在整個組織中產生更廣泛的影響，并將他們的專業知識應用于為開發人員提供更好的體驗。開發人員不必在基礎設施和其他Ops任務上陷入泥沼，運維可以更聚焦向上游轉移到更關鍵的任務。內部開發人員平臺使開發人員和運維人員能夠專注于各自工作的核心職責和優勢，真正實現“術業有專攻”“專人做專事”。

參考鏈接：

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

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

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