Gartner 預測到 2026 年時，將有 80% 的軟件工程組織會建立平臺團隊
DevOps 與平臺工程
DevOps 是一種文化和理念。平臺工程，是我們實現“誰構建、誰運行”的唯一方式。這是 DevOps 的核心初衷，也是後來企業級規模和雲原生時代的實現基礎。平臺工程關注的不一定是教你怎麼用工具，而是構建起一套能夠實現這種自我服務能力的平臺。有了平臺工程，核心軟件工程部門纔有機會獲得自我服務能力。這種觀念上的轉變，決定我們要把平臺視爲一種產品進行建設。
DevOps 最初的想法非常簡單，基本目標就是消除開發人員和運營人員間的障礙，促進雙方協作。達成目標的方法基本就是做左移，實現“誰構建、誰運行”。當所有這些雲原生趨勢融合在一起之後，就有了雲原生、Kubernets、容器化、基礎設施即代碼和 GitOps 等等，情況已經完全不同了。
爲什麼需要平臺工程
面對複雜的工具鏈，開發者沒必要成爲全面的專家，相反，應該把底層基礎設施的複雜性從開發者那裏抽象出來，爲他們提供一條最佳路徑，由開發者自己決定最適合的上下文層級。
在企業中，平臺工程的推動會遇到困難，特別是認知負荷相關的問題。首先，開發者不知所措從而不斷向運營團隊求助，最終運營團隊成爲業務瓶頸；亦或高級工程師會悄悄用自己的辦法接管了運營任務，成爲“影子運營”，並沒有把全部的精力投入到編碼當中。這兩種方式會陷入惡性循環最終成爲技術債務。因此，我們建議樹立平臺工程團隊的角色、考慮建設和使用工程平臺。
什麼樣的團隊需要工程平臺
如果團隊中只有大約20 名工程師，而且不是每個人都熟悉 helm、IaC、Terraform 或者 Kubernetes，PaaS 是不錯的選擇 。 DevOps 的基本訴求“誰構建、誰運行”可以實現。但 PaaS 只能提供一條路徑，只能通過簡單設置支持相對不那麼複雜的用例。
當企業從幾十名開發者轉變爲成百上千開發者時，平臺有助於解決的痛點纔開始真正出現。痛點出現了，摩擦出現了，如果還沒有任何平臺，那需要行動起來了。如果已經擁有 PaaS 解決方案，不妨考慮逐漸過渡到自建的內部開發者平臺，或者使用價值觀相同的、較爲成熟的外部產品。
如何建設平臺工程
設立平臺工程團隊，平臺工程團隊的使命和願景是構建、成就或引入一款產品，這款產品的客戶就是開發者。
其次，平臺工程團隊要重視溝通能力。在跟開發人員交談時，要強調的是如何縮短等待時間、改善開發體驗。而在跟運營團隊交流時，要告訴他們如何減輕壓力並快速處理工單。而在跟管理層溝通時，最重要的一點就是告知如何縮短產品上市時間，並且能夠降低運營成本。這個指標類似於給平臺設定投資回報率。
開發者平臺的目標是爲工程師們提供類似於 PaaS 的使用體驗和開發體驗。但它基於更復雜的標籤和工具堆棧，搞清楚工具箱裏到底有着怎樣的技術組合。把整個棧接管過來，完成最後一英里的優化，通過微調爲開發者構建起適宜的最佳上下文路徑。
平臺工程不能成爲開發團隊的束縛。一方面，需要通過標準化普及降低認知和使用門檻，實現自服務。同時，還得確保開發者使用基礎設施資源的方式跟平臺標準要求相一致。這裏要麼採用始終如一輸出相同的配置文件，進行動態配置管理，實質在於每次部署時都能動態生成配置文件，包括誰部署了什麼、在哪裏部署、輸出了什麼。動態配置管理還能在每次 Git 推送時執行策略和標準，在部署等環節之間建立約束。如果沒有明確思路且基礎較薄、或不想投入非主營業務成本，可以評估選擇一款外部產品，其具備完整的交互控制檯、踐行一套認同的方法論、最重要的是願意與客戶保持溝通、持續迭代，客戶可以和產品一同走向平臺工程終態。
平臺工程產品化趨勢
在海外，開源社區非常火爆，存在不少開源工具如 Argo CD、Backstage，特別是圍繞 Backstage 的插件體系非常豐富，已經出現了上百種插件；也有平臺編輯類產品 Humanitec， 服務於企業平臺層中內部開發者平臺的核心引擎，是平臺工程、團隊和組織中的解決方案之一。相比之下，國內的工具鏈相對複雜，爲了提升端到端的體驗，通常需要一個整合層或平臺層來更好地組合這些工具。而且在國內平臺工程主要以代碼和自我品牌爲中心，比如騰訊雲的 CODING Orbit 等產品。
以開發者視角爲出發點，圍繞着代碼管理、項目管理、需求設計、缺陷管理、測試管理和製品管理、持續集成、持續交付、應用管理/觀測等核心特性構建。在這些平臺中，代碼和製品形式的流轉更多地發生在不同的產品模塊之間。每個產品內部都有非常豐富的功能機制，這種商業軟件的玩法是開源平臺無法做到的。國內外工具與平臺最終是否按照平臺工程的需求場景演進趨同？讓我們拭目以待。
歡迎掃碼添加 CODING 官方小助手
獲取 2023 平臺工程報告
