最近平臺工程這個概念越來越火爆，Gartner 的預(yù)測，到 2026 年，80% 的軟件工程組織將擁有平臺工程團(tuán)隊(duì)，來提供內(nèi)部服務(wù)、組件和應(yīng)用程序交付工具，作為可重復(fù)使用的資源。本篇文章將帶你走進(jìn)平臺工程，了解它的起源和解決的問題。

平臺工程（Platform Engineering）的趨勢

2022 年，“平臺工程”這個概念很火熱，也在 Gartner 的炒作周期曲線上。 還有很多人鼓吹DevOps已死，平臺工程才是未來。

國際權(quán)威知名調(diào)研機(jī)構(gòu) Gartner 在《2023年最重要的10個技術(shù)趨勢》報告中將平臺工程（Platform Engineering）列為高速發(fā)展的技術(shù)趨勢之一，并預(yù)測到2026年80%的軟件企業(yè)都將搭建平臺團(tuán)隊(duì)以為內(nèi)部的工程師提供可復(fù)用的服務(wù)、組件以及工具來幫助應(yīng)用交付。

在 Gartner 的《2024年最重要的10個技術(shù)趨勢》報告中，平臺工程（Platform Engineering）依然上榜，無不體現(xiàn)了這一領(lǐng)域未來的強(qiáng)勁勢頭。國內(nèi)大廠前幾年也都一直在該領(lǐng)域探索，特別近兩年關(guān)于“平臺工程”的技術(shù)社區(qū)，也都展露頭角。

從DevOps說起，實(shí)踐過程本身如同盲人摸象，無法照搬

DevOps是什么？DevOps的目的是讓開發(fā)作運(yùn)維嗎？是有很多人鼓吹“誰開發(fā)誰運(yùn)維”，但是否深入理解了“誰開發(fā)誰運(yùn)維”的核心內(nèi)涵？是否想過“誰開發(fā)誰運(yùn)維”要解決什么問題？

如果僅僅是遵循別人鼓吹的方法，而不去考慮為什么，那一定會是教條主義的，一定會和實(shí)際有沖突的。不同的環(huán)境照搬別人的方法，可能平滑運(yùn)行嗎？
所以，在采取某種方法的時候一定要根據(jù)自身實(shí)際來考慮、來剪裁、來調(diào)整以使其適應(yīng)自身的環(huán)境和實(shí)際。DevOps本質(zhì)是一種方法論。

DevOps源起于開發(fā)和運(yùn)維的矛盾，但本質(zhì)解決的是”生產(chǎn)協(xié)作關(guān)系“

SRE讓運(yùn)維人員參與開發(fā)并通過錯誤預(yù)算來協(xié)調(diào)研發(fā)和運(yùn)維之間的關(guān)系，以確保軟件系統(tǒng)的可靠性滿足某項(xiàng)指標(biāo)要求。這或許給DevOps方法論帶來了啟示，也因此可以說DevOps方法論的核心是協(xié)調(diào)和平衡研發(fā)和運(yùn)維的利益訴求，而不是去實(shí)現(xiàn)一個DevOps平臺或CICD工具鏈。所以DevOps嘗試解決的是生產(chǎn)關(guān)系問題，而不是生產(chǎn)工具和生產(chǎn)力問題。
SRE可以看作是DevOps的一種實(shí)踐，但SRE是偏運(yùn)維的，關(guān)注的是軟件的可靠性問題。為了讓運(yùn)維人員熟悉軟件的處理邏輯和異常處理，以便更快的實(shí)現(xiàn)故障定位和故障恢復(fù)，SRE被要求其開發(fā)工作量不低于50%。這是一種很好的嘗試，嘗試讓運(yùn)維人員熟悉研發(fā)，對軟件架構(gòu)和設(shè)計、軟件代碼和邏輯等有深入的認(rèn)識和理解，這樣遇到軟件異常和故障時就能快速判斷根因所在，快速的解決問題。
運(yùn)維人員可以做開發(fā)，開發(fā)者為什么就不能做運(yùn)維？你不懂運(yùn)維你如何能設(shè)計開發(fā)出滿足可靠性要求的軟件？不懂網(wǎng)絡(luò)、不懂存儲、不懂部署架構(gòu)、不懂操作系統(tǒng)等基本內(nèi)容，如何讓你開發(fā)的軟件匹配實(shí)際環(huán)境要求？不了解、不理解基礎(chǔ)設(shè)施，就難以設(shè)計開發(fā)出高可靠性的軟件。就像你不懂?dāng)?shù)據(jù)庫，如何能寫出高優(yōu)化的SQL語句？
DevOps方法論的目的并不是非要讓開發(fā)人員去做運(yùn)維，特別是運(yùn)維不熟悉的基礎(chǔ)設(shè)施。但開發(fā)人員需要對基礎(chǔ)設(shè)施有基本認(rèn)識，需要具備相應(yīng)的知識和認(rèn)知，在軟件研發(fā)時避免引入低級的錯誤和不必要的麻煩，以提升系統(tǒng)可靠性，減少運(yùn)行故障。

抽象實(shí)體，控制邊界自由，簡化角色間協(xié)作，平臺工程的誕生了！

關(guān)鍵詞: 抽象，適度控制，簡化生產(chǎn)協(xié)作關(guān)系
Luca Galante 是平臺工程社區(qū)的主要貢獻(xiàn)者和 Humanitec 的產(chǎn)品負(fù)責(zé)人，他針對這個主題在推特上展開了一次非正式的民意調(diào)查。投票的結(jié)果凸顯了兩大陣營的分歧：41.8%的開發(fā)人員表示愿意承擔(dān)運(yùn)維的工作，42.1%的開發(fā)人員表示反對，還有16.1%則表示無所謂。

對于DevOps的誤解，導(dǎo)致組織往往會定義為”一個職位“或者“開發(fā)人員需要承擔(dān)運(yùn)維”或者“組建專職DevOps團(tuán)隊(duì)”。 如果團(tuán)隊(duì)無法就開發(fā)人員是否應(yīng)該，或者可否，承擔(dān)運(yùn)維工作這個問題上達(dá)成共識，那么強(qiáng)迫每個人從事開發(fā)運(yùn)維實(shí)踐，就會導(dǎo)致災(zāi)難性的后果。
主要后果是增加了開發(fā)人員的認(rèn)知負(fù)擔(dān)。一方面是開發(fā)人員自助式服務(wù)帶來的自由，而另一方面是通過抽象減輕認(rèn)知負(fù)擔(dān)，許多團(tuán)隊(duì)不得不重新考慮如何平衡這兩方面。然而，這兩方面都是必要的：自助式服務(wù)有助于提高開發(fā)速度和工作效率。但隨著現(xiàn)代云原生世界的復(fù)雜性加劇，缺乏適當(dāng)邊界的自由會產(chǎn)生太大的壓力，結(jié)果只能適得其反。
事實(shí)證明，對于許多組織來說，找到這種平衡是一項(xiàng)非常艱巨的任務(wù)。然而，一些優(yōu)秀的組織在這個問題上找到了答案：平臺工程。

平臺工程的定義和能力構(gòu)成

平臺工程社區(qū)的發(fā)起人 Luca Galante 在 platformengineering.org 對平臺工程的描述（定義）是這樣的：

平臺工程是一門設(shè)計和構(gòu)建工具鏈與工作流的學(xué)科。這些工具鏈和工作流可以為云原生時代的軟件工程組織提供自助服務(wù)功能。平臺工程師提供集成化產(chǎn)品，通常稱為“內(nèi)部開發(fā)平臺（Internal Developer Platform - IDP）”，可以涵蓋應(yīng)用程序整個生命周期的所有操作需求。

平臺工程通過產(chǎn)品方法實(shí)現(xiàn)了一定的開發(fā)人員自助式服務(wù)，并為各個組織和團(tuán)隊(duì)找到合適的抽象級別。平臺團(tuán)隊(duì)可以結(jié)合用戶研究、定期反饋和營銷最佳實(shí)踐，了解他們的開發(fā)人員，創(chuàng)建一個解決常見問題的平臺，并獲得關(guān)鍵利益相關(guān)者的內(nèi)部支持。
這些平臺提供了一條金光大道，可將開發(fā)人員完成日常任務(wù)遇到的阻力降到最低。這些金光大道還提供了推薦的工具和最佳安全實(shí)踐，可以減輕開發(fā)人員的認(rèn)知負(fù)擔(dān)，同時還保留了一定的自由度。所有這些努力都確保了平臺能夠減少認(rèn)知負(fù)擔(dān)，并在開發(fā)人員對自助式服務(wù)和支持的需求之間取得適當(dāng)?shù)钠胶狻?/p>

簡而言之，平臺是從底層“能力提供者”到平臺用戶（如應(yīng)用程序開發(fā)人員）的橋梁； 并在此過程中實(shí)施和執(zhí)行安全、性能、成本治理和一致體驗(yàn)所需的實(shí)踐。 下圖說明了產(chǎn)品、平臺和能力提供者之間的關(guān)系。

平臺工程彌補(bǔ)了組織生產(chǎn)力不足，以及DevOps空心理論化的問題

平臺工程又是一個新概念，但其本質(zhì)并沒有質(zhì)變。為什么現(xiàn)在很多人提平臺工程而去貶低DevOps？這本身就是因?yàn)閮蓚€概念前后錯位的問題。
平臺工程追求的是自服務(wù)敏捷基礎(chǔ)設(shè)施能力，這在多年前云原生中就已經(jīng)提出來了，只是大家都習(xí)慣于單體系統(tǒng)的建設(shè)，對底層基礎(chǔ)設(shè)施能力沒有統(tǒng)一的要求，但云計算使底層基礎(chǔ)設(shè)施成為一個統(tǒng)一的平臺。云原生應(yīng)用的研發(fā)和部署運(yùn)維對統(tǒng)一的平臺支撐能力有了明確的要求，平臺工程才被重視。
由于前期對DevOps的錯誤認(rèn)知和不重視自服務(wù)敏捷基礎(chǔ)設(shè)施的建設(shè)，把DevOps方法論等同于去構(gòu)建基礎(chǔ)的研發(fā)運(yùn)維支撐平臺，讓研發(fā)人員去做運(yùn)維但卻沒有基礎(chǔ)設(shè)施的支撐和賦能，所以導(dǎo)致開發(fā)人員的心里落差，對DevOps沒有好感。
運(yùn)維的敏捷才能真正帶來研發(fā)的敏捷。沒有自服務(wù)敏捷基礎(chǔ)設(shè)施的支撐，讓研發(fā)人員去做運(yùn)維會使生產(chǎn)力達(dá)不到生產(chǎn)關(guān)系的要求。
DevOps是方法論，協(xié)調(diào)的是生產(chǎn)關(guān)系；平臺工程追求的是工具賦能，是生產(chǎn)工具；生產(chǎn)工具體現(xiàn)著生產(chǎn)力。也因此說科技是第一生產(chǎn)力，科技進(jìn)步會帶來生產(chǎn)工具變革，從而使生產(chǎn)力變變革，推動生產(chǎn)關(guān)系變革。正是因?yàn)槠脚_工程的能力沒有實(shí)現(xiàn)就去做DevOps，明顯是生產(chǎn)關(guān)系超前了，生產(chǎn)力跟不上，就像曾經(jīng)的空想社會主義一樣，結(jié)果是失敗的。
所以平臺工程是基礎(chǔ)，構(gòu)建新的生產(chǎn)工具，代表新的生產(chǎn)力，理論上應(yīng)該先推行，以促進(jìn)生產(chǎn)力的變革，從而促進(jìn)生產(chǎn)關(guān)系的變革。否則，只會使先進(jìn)的生產(chǎn)關(guān)系是無法適應(yīng)的，使先進(jìn)的生產(chǎn)關(guān)系水土不服。這也是目前在推不動DevOps的時候開始關(guān)注平臺工程。并不是DevOps不好，而是關(guān)系錯位了。
DevOps的推行需要良好的自服務(wù)敏捷基礎(chǔ)設(shè)施的建設(shè)，也就是平臺工程所追求和需要實(shí)現(xiàn)的。平臺工程的價值在于提供統(tǒng)一的標(biāo)準(zhǔn)的基礎(chǔ)設(shè)施，賦能研發(fā)、運(yùn)維等相關(guān)人員，從而減少這些人員的重復(fù)建設(shè)工作量，提升效率和敏捷性，做到運(yùn)維的敏捷。所以說運(yùn)維的敏捷是基礎(chǔ)，以更好的支撐研發(fā)的敏捷。
平臺工程關(guān)注的能力是層次架構(gòu)分層中的中下層基礎(chǔ)設(shè)施能力，DevOps關(guān)注的是應(yīng)用生命周期中的利益平衡和協(xié)調(diào)問題。DevOps落地需要平臺工程的支撐，或者說，平臺工程是DevOps方法論中的一部分。兩者并不矛盾，不是非此即彼的問題，而是相輔相成的。

平臺工程和“基礎(chǔ)設(shè)施、規(guī)范、工具”密切相關(guān)

說了這么多，“平臺工程”只是新瓶裝舊酒，在筆者看來，只是優(yōu)秀的組織將自己的實(shí)踐進(jìn)行了總結(jié)，增加了自己的思考之后，衍生了所謂的“平臺工程”。
無論怎么樣，平臺工程依然和以下三個方面有密切關(guān)系，相輔相成。

規(guī)范

企業(yè) IT 環(huán)境通常會有一系列的規(guī)范，例如設(shè)施命名、賬號管理、IP 分配等等；另外操作系統(tǒng)、容器集群等具有極大靈活性的基礎(chǔ)設(shè)施，也通常是需要有一定的規(guī)范化管理的，這里提到的規(guī)范至少包括：

• 安全規(guī)范：平臺團(tuán)隊(duì)負(fù)責(zé)制定和實(shí)施安全規(guī)范，以確保平臺和應(yīng)用程序的安全性。這可能包括訪問控制、身份驗(yàn)證、數(shù)據(jù)加密、漏洞管理等方面的規(guī)范。
• 部署和發(fā)布規(guī)范：平臺團(tuán)隊(duì)可以制定規(guī)范，定義部署和發(fā)布流程，并確保它們得到正確執(zhí)行。這些規(guī)范可以包括環(huán)境分離、版本控制、持續(xù)集成和持續(xù)交付等。
• 最佳實(shí)踐：各種最佳實(shí)踐可以通過規(guī)范的形式進(jìn)行推行和實(shí)施。將最佳實(shí)踐轉(zhuǎn)化為規(guī)范的形式可以確保團(tuán)隊(duì)成員共享相同的理解，并提供具體的指導(dǎo)和標(biāo)準(zhǔn)，以便在組織中廣泛應(yīng)用，例如訪問控制規(guī)范、文檔發(fā)布規(guī)范、接口管理規(guī)范等等。
• 資源規(guī)范：例如資源申請和分配、生命周期管理、成本控制、審計和監(jiān)控等的規(guī)范，有助于組織資源的有效利用、成本控制和性能優(yōu)化。
  

基礎(chǔ)設(shè)施

現(xiàn)代軟件運(yùn)行需要大量的基礎(chǔ)設(shè)施，除了傳統(tǒng)的 網(wǎng)絡(luò)、計算、存儲之外，還包括大量的服務(wù)化的中間件等能力，OpenStack、Kubernetes 等資源編排工具也屬于是傳統(tǒng)管控難題。平臺團(tuán)隊(duì)可以綜合基礎(chǔ)設(shè)施自有的管控運(yùn)維能力，使用 Terraform、Kubernetes CRD、等資源抽象和自動化手段，為開發(fā)團(tuán)隊(duì)及其產(chǎn)品，規(guī)劃、搭建、自動化和優(yōu)化可靠、安全、高性能的基礎(chǔ)設(shè)施，以支持業(yè)務(wù)的運(yùn)行和發(fā)展。

工具

平臺工程的主要產(chǎn)出就是一個被稱為 IDP（內(nèi)部開發(fā)平臺）的工具，以此工具為開發(fā)團(tuán)隊(duì)提供支持，在實(shí)際工作中，工具部分的工作內(nèi)容至少包括：

• 外部（開源/商業(yè)）軟件的導(dǎo)入：除了采用開源軟件的層層關(guān)卡之外，平臺工程團(tuán)隊(duì)還應(yīng)負(fù)責(zé)補(bǔ)齊第三方軟件的運(yùn)維能力、外部軟件和內(nèi)部平臺的配套對接、開發(fā)并實(shí)施明確、有效并且成本合理的生命周期管理過程。
• 基礎(chǔ)設(shè)施的供給、隔離：在基礎(chǔ)設(shè)施自身服務(wù)接口和運(yùn)維能力基礎(chǔ)之上，為各個開發(fā)組織以及產(chǎn)品，規(guī)劃并供給基礎(chǔ)設(shè)施資源，盡可能讓產(chǎn)品團(tuán)隊(duì)關(guān)注資源本身，并提供成本監(jiān)測、優(yōu)化等技術(shù)支持能力，用隔離手段防止租戶和租戶、租戶和管理之間的不必要的資源訪問。
• Dev(Sec)Ops：包含供應(yīng)鏈安全、代碼質(zhì)量、環(huán)境管理等的復(fù)雜 CI/CD 生命周期相關(guān)能力。
• 規(guī)范實(shí)施：平臺或者工具，除了是業(yè)務(wù)的加速器，同時也是管理意志的執(zhí)行者。純文本的規(guī)范舉步維艱，只有靠策略保障、工具輔助等方式，才能保障規(guī)范背后的管理意圖的達(dá)成。

總結(jié)

平臺工程解決的問題：

• 開發(fā)者不愿意和基礎(chǔ)設(shè)施打交道，企業(yè)發(fā)展又需要自己的基礎(chǔ)設(shè)施。“平臺工程”統(tǒng)一這兩個矛盾點(diǎn)，或者說“平臺工程”是 DevOps 的下一站。

平臺工程的實(shí)現(xiàn)目標(biāo)：

• 為企業(yè)構(gòu)建一個協(xié)助開發(fā)者完成軟件交付過程中與核心業(yè)務(wù)邏輯開發(fā)無關(guān)的支撐類操作的平臺。

本篇深入淺出解釋了平臺工程和DevOps的淵源，后續(xù)會詳細(xì)來闡述平臺工程相關(guān)的構(gòu)成和技術(shù)實(shí)踐。

術(shù)語和概念

DevOps、SRE和平臺工程的概念在不同時期出現(xiàn)，并由不同的個人和組織開發(fā)。

• DevOps作為一個概念是由Patrick Debois和Andrew Shafer在2009年的敏捷會議上提出的。他們試圖通過促進(jìn)協(xié)作文化和在整個軟件開發(fā)生命周期中共享責(zé)任來彌合軟件開發(fā)和操作之間的差距。
• SRE，即站點(diǎn)可靠性工程，是谷歌在21世紀(jì)初首創(chuàng)的，用于解決管理大型復(fù)雜系統(tǒng)的操作挑戰(zhàn)。谷歌開發(fā)了SRE實(shí)踐和工具，如Borg集群管理系統(tǒng)和Monarch監(jiān)控系統(tǒng)，以提高其服務(wù)的可靠性和效率。
• 平臺工程是一個較新的概念，建立在SRE工程的基礎(chǔ)上。平臺工程的確切起源不太清楚，但它通常被理解為DevOps和SRE實(shí)踐的擴(kuò)展，重點(diǎn)是為支持整個業(yè)務(wù)視角的產(chǎn)品開發(fā)交付一個全面的平臺。

值得注意的是，雖然這些概念出現(xiàn)在不同的時期。它們都與軟件開發(fā)和操作中改進(jìn)協(xié)作、自動化和效率的更廣泛趨勢有關(guān)。將SRE、DevOps和平臺工程等結(jié)合來看，可以更好的認(rèn)識和理解系統(tǒng)的建設(shè)思路和發(fā)展趨勢。我們不能簡單的把這些概念割裂開來去看待，否則就容易得出非此即彼的錯誤認(rèn)知。

參考

• https://tag-app-delivery.cncf.io/whitepapers/platforms/
• https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
• https://thenewstack.io/devops-is-dead-embrace-platform-engineering/
• https://thenewstack.io/platform-engineering/sre-vs-devops-vs-platform-engineering/