最近平臺工程這個概念越來越火爆，Gartner 的預測，到 2026 年，80% 的軟件工程組織將擁有平臺工程團隊，來提供內部服務、組件和應用程序交付工具，作爲可重複使用的資源。本篇文章將帶你走進平臺工程，瞭解它的起源和解決的問題。
平臺工程（Platform Engineering）的趨勢
2022 年，“平臺工程”這個概念很火熱，也在 Gartner 的炒作週期曲線上。 還有很多人鼓吹DevOps已死，平臺工程纔是未來。
國際權威知名調研機構 Gartner 在《2023年最重要的10個技術趨勢》報告中將平臺工程（Platform Engineering）列爲高速發展的技術趨勢之一，並預測到2026年80%的軟件企業都將搭建平臺團隊以爲內部的工程師提供可複用的服務、組件以及工具來幫助應用交付。
在 Gartner 的《2024年最重要的10個技術趨勢》報告中，平臺工程（Platform Engineering）依然上榜，無不體現了這一領域未來的強勁勢頭。國內大廠前幾年也都一直在該領域探索，特別近兩年關於“平臺工程”的技術社區，也都展露頭角。
從DevOps說起，實踐過程本身如同盲人摸象，無法照搬
DevOps是什麼？DevOps的目的是讓開發作運維嗎？是有很多人鼓吹“誰開發誰運維”，但是否深入理解了“誰開發誰運維”的核心內涵？是否想過“誰開發誰運維”要解決什麼問題？
如果僅僅是遵循別人鼓吹的方法，而不去考慮爲什麼，那一定會是教條主義的，一定會和實際有衝突的。不同的環境照搬別人的方法，可能平滑運行嗎？
所以，在採取某種方法的時候一定要根據自身實際來考慮、來剪裁、來調整以使其適應自身的環境和實際。DevOps本質是一種方法論。
DevOps源起於開發和運維的矛盾，但本質解決的是”生產協作關係“
SRE讓運維人員參與開發並通過錯誤預算來協調研發和運維之間的關係，以確保軟件系統的可靠性滿足某項指標要求。這或許給DevOps方法論帶來了啓示，也因此可以說DevOps方法論的核心是協調和平衡研發和運維的利益訴求，而不是去實現一個DevOps平臺或CICD工具鏈。所以DevOps嘗試解決的是生產關係問題，而不是生產工具和生產力問題。
SRE可以看作是DevOps的一種實踐，但SRE是偏運維的，關注的是軟件的可靠性問題。爲了讓運維人員熟悉軟件的處理邏輯和異常處理，以便更快的實現故障定位和故障恢復，SRE被要求其開發工作量不低於50%。這是一種很好的嘗試，嘗試讓運維人員熟悉研發，對軟件架構和設計、軟件代碼和邏輯等有深入的認識和理解，這樣遇到軟件異常和故障時就能快速判斷根因所在，快速的解決問題。
運維人員可以做開發，開發者爲什麼就不能做運維？你不懂運維你如何能設計開發出滿足可靠性要求的軟件？不懂網絡、不懂存儲、不懂部署架構、不懂操作系統等基本內容，如何讓你開發的軟件匹配實際環境要求？不瞭解、不理解基礎設施，就難以設計開發出高可靠性的軟件。就像你不懂數據庫，如何能寫出高優化的SQL語句？
DevOps方法論的目的並不是非要讓開發人員去做運維，特別是運維不熟悉的基礎設施。但開發人員需要對基礎設施有基本認識，需要具備相應的知識和認知，在軟件研發時避免引入低級的錯誤和不必要的麻煩，以提升系統可靠性，減少運行故障。
抽象實體，控制邊界自由，簡化角色間協作，平臺工程的誕生了！
關鍵詞: 抽象，適度控制，簡化生產協作關係
Luca Galante 是平臺工程社區的主要貢獻者和 Humanitec 的產品負責人，他針對這個主題在推特上展開了一次非正式的民意調查。投票的結果凸顯了兩大陣營的分歧：41.8%的開發人員表示願意承擔運維的工作，42.1%的開發人員表示反對，還有16.1%則表示無所謂。
對於DevOps的誤解，導致組織往往會定義爲”一個職位“或者“開發人員需要承擔運維”或者“組建專職DevOps團隊”。 如果團隊無法就開發人員是否應該，或者可否，承擔運維工作這個問題上達成共識，那麼強迫每個人從事開發運維實踐，就會導致災難性的後果。
主要後果是增加了開發人員的認知負擔。一方面是開發人員自助式服務帶來的自由，而另一方面是通過抽象減輕認知負擔，許多團隊不得不重新考慮如何平衡這兩方面。然而，這兩方面都是必要的：自助式服務有助於提高開發速度和工作效率。但隨着現代雲原生世界的複雜性加劇，缺乏適當邊界的自由會產生太大的壓力，結果只能適得其反。
事實證明，對於許多組織來說，找到這種平衡是一項非常艱鉅的任務。然而，一些優秀的組織在這個問題上找到了答案：平臺工程。
平臺工程的定義和能力構成
平臺工程社區的發起人 Luca Galante 在 platformengineering.org 對平臺工程的描述（定義）是這樣的：
平臺工程是一門設計和構建工具鏈與工作流的學科。這些工具鏈和工作流可以爲雲原生時代的軟件工程組織提供自助服務功能。平臺工程師提供集成化產品，通常稱爲“內部開發平臺（Internal Developer Platform - IDP）”，可以涵蓋應用程序整個生命週期的所有操作需求。
平臺工程通過產品方法實現了一定的開發人員自助式服務，併爲各個組織和團隊找到合適的抽象級別。平臺團隊可以結合用戶研究、定期反饋和營銷最佳實踐，瞭解他們的開發人員，創建一個解決常見問題的平臺，並獲得關鍵利益相關者的內部支持。
這些平臺提供了一條金光大道，可將開發人員完成日常任務遇到的阻力降到最低。這些金光大道還提供了推薦的工具和最佳安全實踐，可以減輕開發人員的認知負擔，同時還保留了一定的自由度。所有這些努力都確保了平臺能夠減少認知負擔，並在開發人員對自助式服務和支持的需求之間取得適當的平衡。
簡而言之，平臺是從底層“能力提供者”到平臺用戶（如應用程序開發人員）的橋樑； 並在此過程中實施和執行安全、性能、成本治理和一致體驗所需的實踐。 下圖說明了產品、平臺和能力提供者之間的關係。
平臺工程彌補了組織生產力不足，以及DevOps空心理論化的問題
平臺工程又是一個新概念，但其本質並沒有質變。爲什麼現在很多人提平臺工程而去貶低DevOps？這本身就是因爲兩個概念前後錯位的問題。
平臺工程追求的是自服務敏捷基礎設施能力，這在多年前雲原生中就已經提出來了，只是大家都習慣於單體系統的建設，對底層基礎設施能力沒有統一的要求，但云計算使底層基礎設施成爲一個統一的平臺。雲原生應用的研發和部署運維對統一的平臺支撐能力有了明確的要求，平臺工程才被重視。
由於前期對DevOps的錯誤認知和不重視自服務敏捷基礎設施的建設，把DevOps方法論等同於去構建基礎的研發運維支撐平臺，讓研發人員去做運維但卻沒有基礎設施的支撐和賦能，所以導致開發人員的心裏落差，對DevOps沒有好感。
運維的敏捷才能真正帶來研發的敏捷。沒有自服務敏捷基礎設施的支撐，讓研發人員去做運維會使生產力達不到生產關係的要求。
DevOps是方法論，協調的是生產關係；平臺工程追求的是工具賦能，是生產工具；生產工具體現着生產力。也因此說科技是第一生產力，科技進步會帶來生產工具變革，從而使生產力變變革，推動生產關係變革。正是因爲平臺工程的能力沒有實現就去做DevOps，明顯是生產關係超前了，生產力跟不上，就像曾經的空想社會主義一樣，結果是失敗的。
所以平臺工程是基礎，構建新的生產工具，代表新的生產力，理論上應該先推行，以促進生產力的變革，從而促進生產關係的變革。否則，只會使先進的生產關係是無法適應的，使先進的生產關係水土不服。這也是目前在推不動DevOps的時候開始關注平臺工程。並不是DevOps不好，而是關係錯位了。
DevOps的推行需要良好的自服務敏捷基礎設施的建設，也就是平臺工程所追求和需要實現的。平臺工程的價值在於提供統一的標準的基礎設施，賦能研發、運維等相關人員，從而減少這些人員的重複建設工作量，提升效率和敏捷性，做到運維的敏捷。所以說運維的敏捷是基礎，以更好的支撐研發的敏捷。
平臺工程關注的能力是層次架構分層中的中下層基礎設施能力，DevOps關注的是應用生命週期中的利益平衡和協調問題。DevOps落地需要平臺工程的支撐，或者說，平臺工程是DevOps方法論中的一部分。兩者並不矛盾，不是非此即彼的問題，而是相輔相成的。
平臺工程和“基礎設施、規範、工具”密切相關
說了這麼多，“平臺工程”只是新瓶裝舊酒，在筆者看來，只是優秀的組織將自己的實踐進行了總結，增加了自己的思考之後，衍生了所謂的“平臺工程”。
無論怎麼樣，平臺工程依然和以下三個方面有密切關係，相輔相成。
規範
企業 IT 環境通常會有一系列的規範，例如設施命名、賬號管理、IP 分配等等；另外操作系統、容器集羣等具有極大靈活性的基礎設施，也通常是需要有一定的規範化管理的，這裏提到的規範至少包括：
- 安全規範：平臺團隊負責制定和實施安全規範，以確保平臺和應用程序的安全性。這可能包括訪問控制、身份驗證、數據加密、漏洞管理等方面的規範。
- 部署和發佈規範：平臺團隊可以制定規範，定義部署和發佈流程，並確保它們得到正確執行。這些規範可以包括環境分離、版本控制、持續集成和持續交付等。
- 最佳實踐：各種最佳實踐可以通過規範的形式進行推行和實施。將最佳實踐轉化爲規範的形式可以確保團隊成員共享相同的理解，並提供具體的指導和標準，以便在組織中廣泛應用，例如訪問控制規範、文檔發佈規範、接口管理規範等等。
- 資源規範：例如資源申請和分配、生命週期管理、成本控制、審計和監控等的規範，有助於組織資源的有效利用、成本控制和性能優化。
基礎設施
現代軟件運行需要大量的基礎設施，除了傳統的 網絡、計算、存儲之外，還包括大量的服務化的中間件等能力，OpenStack、Kubernetes 等資源編排工具也屬於是傳統管控難題。平臺團隊可以綜合基礎設施自有的管控運維能力，使用 Terraform、Kubernetes CRD、等資源抽象和自動化手段，爲開發團隊及其產品，規劃、搭建、自動化和優化可靠、安全、高性能的基礎設施，以支持業務的運行和發展。
工具
平臺工程的主要產出就是一個被稱爲 IDP（內部開發平臺）的工具，以此工具爲開發團隊提供支持，在實際工作中，工具部分的工作內容至少包括：
- 外部（開源/商業）軟件的導入：除了採用開源軟件的層層關卡之外，平臺工程團隊還應負責補齊第三方軟件的運維能力、外部軟件和內部平臺的配套對接、開發並實施明確、有效並且成本合理的生命週期管理過程。
- 基礎設施的供給、隔離：在基礎設施自身服務接口和運維能力基礎之上，爲各個開發組織以及產品，規劃並供給基礎設施資源，儘可能讓產品團隊關注資源本身，並提供成本監測、優化等技術支持能力，用隔離手段防止租戶和租戶、租戶和管理之間的不必要的資源訪問。
- Dev(Sec)Ops：包含供應鏈安全、代碼質量、環境管理等的複雜 CI/CD 生命週期相關能力。
- 規範實施：平臺或者工具，除了是業務的加速器，同時也是管理意志的執行者。純文本的規範舉步維艱，只有靠策略保障、工具輔助等方式，才能保障規範背後的管理意圖的達成。
總結
平臺工程解決的問題：
- 開發者不願意和基礎設施打交道，企業發展又需要自己的基礎設施。“平臺工程”統一這兩個矛盾點，或者說“平臺工程”是 DevOps 的下一站。
平臺工程的實現目標：
- 爲企業構建一個協助開發者完成軟件交付過程中與核心業務邏輯開發無關的支撐類操作的平臺。
本篇深入淺出解釋了平臺工程和DevOps的淵源，後續會詳細來闡述平臺工程相關的構成和技術實踐。
術語和概念
DevOps、SRE和平臺工程的概念在不同時期出現，並由不同的個人和組織開發。
- DevOps作爲一個概念是由Patrick Debois和Andrew Shafer在2009年的敏捷會議上提出的。他們試圖通過促進協作文化和在整個軟件開發生命週期中共享責任來彌合軟件開發和操作之間的差距。
- SRE，即站點可靠性工程，是谷歌在21世紀初首創的，用於解決管理大型複雜系統的操作挑戰。谷歌開發了SRE實踐和工具，如Borg集羣管理系統和Monarch監控系統，以提高其服務的可靠性和效率。
- 平臺工程是一個較新的概念，建立在SRE工程的基礎上。平臺工程的確切起源不太清楚，但它通常被理解爲DevOps和SRE實踐的擴展，重點是爲支持整個業務視角的產品開發交付一個全面的平臺。
值得注意的是，雖然這些概念出現在不同的時期。它們都與軟件開發和操作中改進協作、自動化和效率的更廣泛趨勢有關。將SRE、DevOps和平臺工程等結合來看，可以更好的認識和理解系統的建設思路和發展趨勢。我們不能簡單的把這些概念割裂開來去看待，否則就容易得出非此即彼的錯誤認知。