作者 | 楊振濤
策劃 | Tina
編者按：平台工程并非 2022 年度首次出現，最早可以追溯到 2017 年的技術雷達。經過 6 年多的發展，Gartner 于去年将平台工程列為了 2023 年度 10 大戰略技術趨勢之一。當我們回頭去梳理平台工程相關技術的萌芽、現狀以及早期實踐者的部分經驗和教訓時，我們發現國外已經有了不少案例和實踐，以及非常濃厚的技術讨論氛圍，但從國内視角來看鮮少有相關案例。對于中大型組織而言，要想更加高效穩健地進行軟體開發和釋出，平台工程是一個非常重要的考慮項，是以我們希望此文能給企業管理者、CTO 及技術 Leader 與技術從業者帶來新的思維啟示與戰略規劃參考。本文原标題為“平台工程的 2022：助力雲原生重構研發組織文化與組織架構”。
平台工程正當時
随着雲計算行業的持續發展，企業内部的業務需求方和研發團隊已越來越不滿足于對計算、存儲、網絡資源的可程式設計封裝與服務化，也不再局限于 IaaS、PaaS 和 SaaS，而是在雲原生的加速下，包括開發人員在内期待更高程度的自動化和更智能的彈性，尤其是在多雲、跨雲場景下。基于此趨勢，結合目前全球經濟與地緣政治形勢，大型企業和中小企業都在不同程度上收緊 IT 技術與數字化方面的投入但又要求更高的傳遞效率和可用性，如何更好有效緩解甚至化解其中的沖突呢？
咨詢公司 Gartner 之前釋出過 2023 年 10 大戰略技術趨勢：
圖檔來自 https://www.gartner.com/en/articles/gartner-top-10-strategic-technology-trends-for-2023
Gartner 期望這些趨勢将通過使組織能夠解決下列四個主題的關鍵優先事項來影響未來三年的企業戰略：
- 優化彈性、營運或信任
- 擴充垂直解決方案、産品傳遞或無處不在
- 開創性的客戶參與、加速響應或機會
- 尋求可持續的技術解決方案
其中平台工程（Platform Engineering）在細分的優化技術傳遞和擴充性方面為我們帶來了新的啟示。Gartner 認為：
- “平台工程旨在提供一組精心設計的工具、功能和流程，經過打包後便于開發人員和最終使用者使用。它将提高最終使用者的生産力并減輕開發團隊的負擔。 ”
- “平台工程是為軟體傳遞和生命周期管理而建構和營運自服務的内部開發者平台（IDP）的學科。”
我們再來看看平台工程在技術成熟度曲線中的位置：
圖檔來自 https://www.gartner.com/en/articles/what-s-new-in-the-2022-gartner-hype-cycle-for-emerging-technologies
Gartner 預測，到 2026 年，80% 的軟體工程組織将建立平台團隊，其中 75% 将包含開發者自助服務門戶。
本文将借此機會帶領大家回顧平台工程及内部開發者平台相關技術領域的現狀和進展，并對未來趨勢略予以分析和初判，希望為你和你的團隊帶來更多啟發，助力于未來年度的戰略更新和技術規劃。
回顧平台工程的發展
平台工程并非 2022 年度首次出現，最早可以追溯到 2017 年的技術雷達；但在此之前也已經有人使用這個詞了，即便當時的指代可能與目前并不相同；而且也有很早就關注和讨論關于軟體開發團隊中的平台和工程效率等話題。
Gartner 在 2022 年度把平台工程列為了 2023 年度 10 大戰略技術趨勢之一，也不僅說明了這一年大家對它的關注度在上升，也說明了企業對軟體傳遞效率和品質有了更高的追求。于大型企業而言平台工程的 ROI 和絕對收益可能都更高，這也是大型企業成為早期實踐者的重要原因之一。讓我們把眼光分别放到海外和國内，來關注下企業實踐方面的資訊以及相關案例的詳細情況。
從全球視角來看，國外已經有了不少案例和實踐（可參看 PlatformCon 2022 會議）。大型企業如 Google、Amazon、Netflix 等都很熱衷于建設自己的企業内部開發者平台（簡稱為 IDP），這是平台工程落地的典型産物之一。
拿 Google 舉例來說，他們的内部平台的開發方認為“關鍵點在于能夠把複雜的問題劃分好，每個人都有自己擅長處理的一部分複雜問題，而其他人完全可以忽略這些問題”。内部開發者平台的好處是，能夠降低現代軟體系統的複雜性，加快軟體部署周期，建立更穩定的版本，提高開發人員的滿意度和工作效率，同時降低營運負擔。IDP 一般有兩類使用者，分别是平台/運維 SRE/DevOps 團隊和開發人員團隊，是以與 PaaS 并不完全相同，PaaS 往往由供應商或内部提供方規定開發人員應怎樣工作，是基于開發人員團隊已經熟悉的工具和流程建構的，但抽象性和一緻性更好。而對于如何開始采用 IDP，Puppet 的 Kersten 是谷歌前 SRE，他認為“更大的問題是能夠了解使用者，并做出文化上的變革”，他與其他很多專家都建議“從小處着手”。
從國内視角來看，缺少但也有公開宣講的案例。如 2022 年 10 月，螞蟻金服發表文章總結了他們過去兩年在平台工程上的探索和實踐，闡述了規模化平台工程實踐中的收益和挑戰。螞蟻金服認為 10 多年前提出的 DevOps 理念，在經曆虛拟機、容器以及雲原生時代後，大部分公司陷入了某種基于對 DevOps 樸素認知的 Anti-Pattern，并分析了企業規模化 DevOps 難以推行的常見原因。基于這些原因，在螞蟻的實踐中，更傾向于鼓勵多方合作，進而讓 Dev、Ops、SRE、Plat 各方之間形成一個正回報循環。通過平台工程、專用語言、分治、模組化、自動化和協同文化等幾個角度的詳細介紹，讓我們了解到了各次元遇到的挑戰及對應收益。最終，平台通過了 500+項目的驗證，其中平台研發者及平台 SRE 與應用研發者比例不到 1：9，實作了高效輕量化的傳遞和釋出，并服務了内部的多個運維場景，目前正在持續擴大應用規模來探索更多可能性。
對于國内的軟體業而言，其實我們有更好的參照物，那就是大陸在大基建方面積累的“大國重器”經驗；在看似完全不相同的工程領域，道路、橋梁、建築、水利、礦藏等行業的工程師們為了更好地傳遞他們的産品，建構了領先的平台、工具和标準，為一線工程師提供了更好的工作體驗和效率，這也是大基建領域的工程文化之一。本文探讨的平台工程，其思路異曲同工，但如果更大程度地發揮軟體工程的優勢，那麼開發人員對軟體開發、傳遞、運作的更高要求和期待，絕不僅僅局限在 DevOps、工具鍊、流水線層面，而是從基礎設施到中間件、微服務、IDE 等不同層次的更大彈性、更好體驗，從平台工程的角度，就重點關注在自服務 API、内部開發者平台、開發者體驗。
是以，平台工程的價值應當是在簡化開發者體驗，而不是複雜化；降低對開發人員的全棧知識要求，而不是要求開發人員從業務到代碼到容器都要成為專家；通過平台産品來實作知識轉移，而不是讓知識成為開發人員和平台之間的鴻溝。最終，我們發現平台工程的本質是提倡“Developer First”的文化，這對于一些研發組織而言，可能是一種文化沖擊，是以重塑文化可能會成為一個待選項。
在了解完國内外的基本現狀之後，我們再來關注下相關的解決方案和産品及其背後的公司團隊。 實際上，已經有不少專注在平台工程領域尤其是内部開發者平台或門戶方向的創新産品，也有一些是從 PaaS 方向逐漸演化而來，如以下幾個參考案例（不是所有的）：
- https://mia-platform.eu/ Don’t waste time setting up your platform, just push the code!
- https://humanitec.com/ Powering your Internal Developer Platform
- https://backstage.io/ An open platform for building developer portals
基于現有的解決方案，接下來有一個更重要的問題：我的企業适合開始嘗試平台工程的實踐嗎？ 其實，很難通過某一個簡單的标準判斷某企業或某團隊是否要/正在實踐平台工程，因為在現階段，我們并沒有嚴格的定義和區分标準，甚至也沒有太大的必要去區分，重點是企業是如何組織軟體開發活動，以及如何分工協作來達成軟體傳遞的目标。
平台工程适合什麼樣的企業以及什麼樣的發展階段和發展規模呢？ 你的團隊是否要現在就擁抱平台工程？這取決于你的團隊規模、發展階段，更重要的是你的技術戰略和當下的協作模式。 這也決定了早期實踐者的經驗是否對你能夠提供足夠的幫助。
雲原生之火燒到了研發組織文化
通過以上回顧和現狀的梳理，我們會發現，從工具到平台最終落地依然是圍繞着開發者及開發團隊之間的協作，這就回歸到人和團隊本身了。那麼今天所讨論的平台工程将如何助力雲原生時代的研發團隊文化重塑與組織架構重構呢？首先，我們來看下與平台工程有關的幾件事：
- 軟體工程
- 研發效能
- DevOps
- SRE
- IDP
- DevEx
以上 6 件事情，在我們讨論平台工程時，或多或少都會提到，而且去年已經有不少的文章在讨論平台工程與它們的各種關系。這至少說明，作為新事物出現的平台工程，目前依然沒有一個高共識度的确定概念和範圍定義，它還在從已有概念中持續進化，這種進化的動力既來自先鋒企業的早期實踐經驗，也來自于對現狀不滿的企業的多元度探索。
需要明确的是，平台與産品的差別和關系，這決定了所謂平台到底是否需要專業的營運。一般而言本文提到的平台主要局限在企業内部，提供給内部開發者使用的平台。事實上，To D 的産品和服務從來不需要依賴所謂營運推廣，這是非常典型的 PLG 場景，用優秀的開發者體驗擷取内外部使用者青睐與認同，要比再多的市場推廣更有效。換個角度，我們需要讓開發者與平台類産品與服務的的提供者成為 Allyship ，而不是 consumer-producer 關系。這些對于平台以及平台使用者的深入洞察和了解，直接影響到我們的團隊文化和協作方式。
雲原生持續發展，從早期以容器為代表的單點突破，到如今 CNCF 的技術全景圖 l.cncf.io ，已覆寫應用定義與開發、編排與管理、運作時、配置、平台、可觀測性與分析等。有不少企業已經在産品環境擁抱雲原生且從中受益。那麼雲原生的下一個階段是什麼呢？随着服務網格、不可變基礎設施及聲明式 API 等越發趨于成熟，有觀點認為我們需要重構研發團隊的文化群組織架構，通過開發者控制面來加強對開發者體驗的重視，以更好地适配雲原生，這也可以稱為雲原生時代的研發文化群組織架構。這意味着什麼呢？
如果我們回顧下軟體工程的發展曆程，可以找到一些信号類型的資訊，比如靈活實踐、DevOps、CICD 等，人們對于軟體開發過程和軟體傳遞的關注焦點，除了 code、ship、run 之外，還有人的因素，工程師們的崗位類型越來越多，協作方式越來越複雜，以至于有人喊出了“要什麼 DevOps，我們開發者根本不想做運維！” 而人的因素，放到組織的環境裡面，就上升為文化的因素，人們是否有着相同的使命、共同的願景，且追求共同的價值觀？ 這在技術的不同發展階段、組織的不同發展階段，都是需要做出與時俱進的文化重構，而且最終影響到組織架構，因為後者決定了開發團隊之間以及開發人員之間如何高效協作。 我們在實踐中看到非常典型的現象：業務團隊對雲原生充滿好奇，而又對容器平台團隊提供的服務不滿意。
是以，對于擁抱雲原生的研發團隊而言，現在可能是你重視并思考如何重塑研發文化和重構組織架構的最佳時機，對于後者，團隊拓撲是被頻繁提到的一種理論指導，它定義了 4 中團隊類型和 3 中服務關系：
圖檔出自 https://teamtopologies.com/
實踐中很多研發團隊已經采納或部分采納了這種團隊拓撲，但如果結合平台工程的實踐，這種組織架構将會讓你的團隊目标和定位更加清晰，演進也更加貼合需求，進而最大限度持續提升協作效率。
平台工程依然不是盡頭
回頭看看去年平台工程成為年度熱門技術話題之一，中文技術圈最典型的代表當屬這篇 “DevOps 已死，平台工程才是未來” ，霸榜 InfoQ 熱點 3 個月以上，加上自媒體傳播引起多方廣泛關注，并且帶來了後續一波又一波的熱烈讨論。為什麼人們如此關注平台工程？可否解釋為天下苦 DevOps 久矣？非也。恰恰是 DevOps 的持續實踐為平台工程創造了契機，開發和運維并不想對工作邊界非要争來争去的了，也并不認為一個人/一個角色能對軟體的全生命周期負責。雲原生時代的微服務規模将越來越大，關系也越來越複雜，平台産品将成為大規模微服務穩健運作、随時更新的有力保障。這就好像一艘現代化的超大噸位艦船，人們已經不再去争論到底這艘船由哪一個人或哪一個角色來掌舵，而是大家按照約定的分工，通過一套“自動駕駛平台”來協作完成對整個艦船的操控，確定始終正确且穩定運作。
展望平台工程在未來一兩年内的發展，筆者認為平台工程不會成為誰的盡頭，它隻是研發團隊和研發工程師持續追求高效、體驗更佳的軟體傳遞過程路上的一個站點。當然，平台工程的趨勢也不可阻擋，盡管在當下，依然缺乏一套體系化的邏輯清晰的定義和邊界，是以 Field CTO at Puppet 在接受InfoQ的采訪時指出平台工程需要有一套發展願景和藍圖，以避免 DevOps 等實踐踩過的一些坑。
Daniel Bryant 作為 Ambassador Labs 的開發者關系負責人，也分享了他眼中 2023 年的平台工程及其發展趨勢，他認為開發者平台并不會幹掉 DevOps，而是提倡升開發者體驗優先，并做出的 4 大預測：
- Prediction 1: The Growth of Developer-First Kubernetes
- Prediction 2: Developer Platforms to Unlock Developer Productivity
- Prediction 3: Developers Coexist with DevOps; DevOps Is Not Dead
- Prediction 4: The API Strikes Back – Microservices Testing
寫在最後
對于一項新技術、新實踐或新趨勢來說，鼓吹和唱衰都會顯得過于魯莽，筆者更傾向于基于事實和案例來做出理性的分析與判斷，并基于個人認知和觀點做出感性的建議或倡導。對于平台工程來說，基于上文的資訊，2022 年度無疑是在一個冉冉上升的起始階段，它顯示出研發組織和團隊對于當下軟體開發模式和實踐的更高要求和預期。
随着雲計算尤其是雲原生的持續發展與進化，開發者希望更加靈活、便捷且彈性地使用基礎設施，而這種希望現在開始不局限于傳統的基礎設施，也上升且涉及到了工程、架構、中間件，甚至更進一步，希望一切都可以服務化，按需按量去調用、組裝，召之即來揮之即去！
如果我們把這種期望當作願景的話，首要難題就是研發工程師對于這個願景的共識度，這就不可避免地涉及到研發文化群組織架構。基于靈活、DevOps 等實踐的發展經驗，從今天回看過往，我們不必重複走彎路和踩坑，而是以更高視角總結經驗，吸取教訓，不必糾結誰對 code、ship、run 等環節負責，而是借助新技術、新實踐、新趨勢，與時俱進地重構與之比對的組織文化群組織架構，進而完成研發組織自身的同步進化和适配。
通過本文的内容，在面對平台工程時，希望給讀者帶來下列啟示：
- 結合團隊發展階段和當下現狀，大膽嘗試，謹慎入局；
- 文化先行，重視開發者體驗，從人的角度平衡長期主義和當下挑戰 ；
- 讓組織和技術互相适配，開放心态，根據國内外發展動态和行業案例經驗，适時重構組織架構。
擁抱雲原生，不隻是一個技術戰略和技術規劃問題，更是一個研發組織持續進化的問題。對于中大型組織而言，要想更加高效穩健地進行軟體開發和釋出，平台工程是一個非常重要的考慮項。讓我們共同期待平台工程的 2023 。
作者簡介：
楊振濤，vivo 網際網路研發總監，目前關注開源治理、技術社群與工程文化建設。具有 15 年多個領域的軟體研發經驗，此前先後從事生物資訊與基因測序領域的科研工作、電商與 IM 架構以及搜尋引擎研發。開源技術與技術傳播愛好者，先後參與和負責 Circos、Redis、Jenkins、Elasticsearch 等社群的本土化，也是 TED Translator & Reviewer。為了更加系統地收集并記錄平台工程主題的技術趨勢及發展曆程，我整理并建立了一個 awesome list 供大家參考，歡迎各位參與貢獻和維護。Github 位址：https://github.com/toptechevangelist/awesome-platform-engineering
本文轉載來源：
https://www.infoq.cn/article/5JuuFYFFNH0WT2aDJgA3