國際權威知名調研機構 Gartner 在《2023年最重要的10個技術趨勢》報告中將平臺工程（Platform Engineering）列為高速發展的技術趨勢之一，並預測到2026年80%的軟體企業都將搭建平臺團隊以為內部的工程師提供可複用的服務、元件以及工具來幫助應用交付。
圖源：Gartner
何謂平臺工程（Platform Engineering）？
平臺工程是一門新興技術，專注於透過減少現代軟體交付的複雜性和不確定性來提高開發人員的生產力。它解決了規模化DevOps的一些最大挑戰，包括減少在整個應用生命週期內管理複雜工具和基礎設施網路的負擔。無論是基礎設施配置、流水線、監控還是容器管理等，自助服務平臺將所有這些複雜的問題放入黑盒中，進而為開發人員提供開箱即用的所有必要工具。
平臺團隊將基礎設施管理自動化，並使開發人員能夠從一個集中管理的技術平臺上自助獲取可靠的工具和工作流程。由於減輕了開發團隊的認知負擔，平臺工程是雲原生軟體交付的一個重要轉向。
平臺工程 vs DevSecOps
正如我們之前諸多文章中闡述的那樣，DevSecOps 將安全左移到開發流程中，藉助各類工具簡化部署、管理、監控以及安全治理等工作，在獲得 DevOps 敏捷交付優勢的同時還能保障軟體開發的安全。而平臺工程會借鑑 DevSecOps 的做法，採用這些工具、流程和最佳實踐，並將其產品化為可重複使用的服務和工具，以便在企業內部的不同開發團隊和實際場景中使用。
舉個例子，企業裡的每個產品團隊都有證書輪換的需求，此時如果有一個統一的服務能解決這一需求將會省下許多麻煩，也就是需要解決方案可重複。那麼如果有多個需求都與此類似，那麼表明企業內部需要一個平臺來統一解決此類問題，而不是讓每個團隊都重複造輪子。
平臺工程是隨著DevOps的成熟和規模的擴大而出現的。在DevOps（或 DevSecOps）的前期階段企業內部的每個開發團隊都會創造符合其自身需求的實踐。例如，交付物可以是 Terraform 模板或 Terraform 模組，工程師隨後可以 clone 並新增他們的配置，但在 clone 之後，就不再維護最初的那套模板或模組了。於是如果產生問題，那麼問題的解決方案通常存在於各個團隊內部。
隨著企業的成熟和發展壯大，DevSecOps 會走向後期成熟階段。在此階段，企業開始收集資料點並瞭解 DevSecOps 工具和實踐的影響，此時會發現不同團隊正在分別解決同樣的問題，這十分低效，因此企業內部各團隊需要藉助統一的共享平臺來避免重複造輪子。
平臺工程的主要優勢
如上文所述，平臺工程可以為研發團隊提供更好的開發體驗，這一小節我們將詳細聊聊平臺工程的主要優勢。
加速開發週期
在沒有平臺工程的情況下，許多開發流程是手動的。無論是手動建立和配置程式碼倉庫，管理雲基礎設施，還是建立CI/CD流水線，手動過程都需要時間，而且容易出錯，許多安全問題恰恰由於配置錯誤產生。
平臺工程非常注重流程的自動化。因此，在自動化平臺的幫助下，開發人員可以更快地傳輸他們的程式碼。現在，開發人員可以透過自助服務來啟動環境和交付他們的軟體版本，進而大大加快開發週期。一個與自動化測試整合的程式碼流水線將可以在不影響質量或進度的情況下為你的客戶提供商業價值。因此，產品進入市場的時間將被縮短。
消除操作的複雜度
基礎設施和應用程式的自助服務部署將會消除流程中的複雜度。平臺工程會自動化整個 DevOps 週期，進而提升生產力以及減輕開發人員的負擔。在傳統方法裡，開發人員依賴於 DevOps 團隊建立和維護軟體部署。現如今，藉助自助服務門戶，開發人員可以自主、快速交付新版本。這將會簡化企業內部的開發流程。
將產品開發提升到新水準
有這樣一個場景：開發者需要對微服務應用程式進行一個微小的更改，首先進入 staging 階段，其次再進入生產環境。這是一個多叢集 Kubernetes 環境。只有掌握了 Kubernetes、Helm chart 以及 Terraform 模組的開發者才能夠自己完成所有的部署流程。但是規模較小的企業可能沒有預算來招聘這麼多的資深開發者。那麼，此時藉助平臺工程師的幫助，開發人員無需將此類工作推卸給運維團隊，而僅需點選幾下即可將程式碼推送到任意環境，而無需瞭解複雜的底層架構。這改善了不同團隊成員之間的反饋迭代，使產品更加完善，進而為客戶帶來巨大的商業價值。
透過環境自動化擴充套件應用程式
當前大多數 CI/CD 設定主要聚焦於容器映象的更新。CI server 在配置中構建映象並更新映象路徑。然而，當你需要完成以下事項時，則變得有些複雜：
- 啟動新環境
- 移除環境映象或更改現有環境的配置
- 回滾新配置的環境
- 從環境中新增/移除資源
平臺工程師為開發環境提供全面的環境自動化，開發人員可以建立、複製、移除和更新部署環境而無需瞭解底層架構知識。這意味著，甚至初級的UX開發也可以自助使用環境，這個環境已經完全配置了開發者需要部署和測試的一切。自動化環境的能力可以讓業務快速、高效增長。
上文所提到的平臺工程團隊的優勢十分誘人，那麼是否每個企業都需要採用呢？
企業何時需要平臺工程團隊？
如果企業內部已經有團隊跨職能來管理應用基礎設施、部署以及運維等工作，那麼企業應該開始考慮平臺工程，因為這在不知不覺之間已經完成了平臺工程的部分內容。
另外，如果企業已經有一個成熟的產品，一個清晰的發展願景並計劃開始擴充套件市場，那麼此時也是搭建平臺團隊的好時機。
如果企業管理者希望開發團隊專注於產品的開發，而不是被基礎設施配置、程式碼流水線設定、金鑰管理等工作牽扯精力，那麼企業需要一個平臺工程團隊。藉助該團隊的幫助，應用開發人員可以輕鬆將程式碼推送到生產環境中。
如果企業內部的工程團隊人數正在增長，同時雲原生應用也需要擴充套件，那麼僅僅有技術專家是不夠的，還需要團隊之間的合作。在一個開發團隊中，並不是所有的團隊成員在技術上都善於處理擴充套件操作。團隊中的一個薄弱環節會降低團隊的速度，減慢整個開發週期的速度。在這種情況下，平臺工程團隊將是理想的選擇。
另一方面，如果企業規模不大，僅有屈指可數的幾位開發人員來構建一個單體應用，那麼平臺團隊對於該企業來說收益並不大。此時，企業需要首先專注於實現產品與市場的契合，並將任何重複的任務自動化，使開發人員能夠專注於創新。此後，開始將應用程式分割成單獨的服務，需要由多個工程團隊交付不同的價值時，可以開始引入平臺團隊，他們可以幫助你實現效率和穩定性的最佳平衡。
平臺工程的實踐原則
平臺工程的原則和理論總結起來可以用一句話概括，即真正重要的是將平臺工程付諸實踐。平臺團隊一開始可以先從小處著手，聚焦於所有團隊都會用到的技術棧。換言之，平臺團隊不應該構建一個類似於“萬金油”的平臺，而是關注某個具體的技術，比如容器和K8S。
平臺搭建初期需要先確立目標，比如在不增加認知負荷的情況下實現開發者自助服務，或者在不強迫開發者學習以基礎設施為中心的技術的情況下實現運維工單數量的減少。
構建平臺最好的方式是採用產品的方法，即Platform as a Product，透過使用者研究、徵求使用者反饋、獲得內部相關方的認可，進而平臺團隊可以全面瞭解開發者的痛點和整個組企業所面臨的共同挑戰。這些決定了開發人員需要什麼特性，進而構建包含這些解決方案的黃金通道。
但平臺不止於此，成功的平臺團隊會持續保持與開發人員的溝通並跟蹤一些指標（如部署頻率、交付時間、穩定性等）以確保開發人員採用了平臺並且對其開發體驗有所改善。
平臺團隊及其所提供的黃金路徑是將所有複雜設定黏合在一起的膠水，但由於平臺團隊只面向內部工作，許多企業錯誤地將其視為成本控制中心。平臺團隊應該努力爭取利益相關者群體的內部認同，以確保其內部平臺專案的長效性。
最後，也許也是最重要的一點，成功的平臺團隊應儘量避免重複造輪子。平臺工程的 landscape 正在不斷髮展壯大，以解決廣泛的問題。平臺團隊可以透過儘可能地定製現成的解決方案來節省時間和創造更多價值。
總結
本文我們詳細介紹了平臺工程（Platform Engineering）這一新興技術，包括其與 DevSecOps 的關係、主要優勢以及實踐原則，作為 DevSecOps 成熟化、規模化的產物，平臺工程可以幫助企業減輕開發人員的認知負擔和基礎運維的負擔，避免重複造輪子，幫助企業提升開發效率，進而產生更大的商業價值。