作者 | 朵曉東（Kusion Creator）
本文基於
KusionStack
技術棧在螞蟻平臺工程及自動化中的實踐，嘗試從平臺工程、專用語言、分治、建模、自動化和協同文化等幾個角度，闡述規模化平臺工程實踐中的收益和挑戰。希望透過把我們平臺工程的理念和實踐分享給更多企業和團隊的方式，大家一起讓一些有意思的變化發生。
平臺工程要解決什麼
DevOps 理念在 10 多年前被提出，從 KVM 到容器再到雲原生時代，大量企業投入 DevOps 運動以期望解決內部規模化運維效率和平臺建設效率的困境。其中大部分公司陷入過某種基於對 DevOps 樸素認知的 Anti-Pattern，同時也有部分公司探索出自己的路徑。
我經歷過如下圖簡示的 Anti-Patterns，Dev 與 Ops 團隊各行其是，或者簡單的強制 Dev 團隊獨立完成 Ops 工作。在
這裡
可以找到更多更典型分類。
企業內規模化 DevOps 難以推行的原因多種多樣，特別是在企業內自持基礎設施、同時採用雲上技術平臺的公司阻力最大。其中以這幾種情況尤為常見：
研發團隊和運維團隊由於部門牆、領導者缺少洞察等原因各自為政，難以達成一致意見；
研發團隊低估了基礎設施技術、運維、穩定性工作的專業性、複雜性和快速變化，以樸素的 DevOps 理解強制應用研發者成為專家；
領導者建立了專職的 DevOps 團隊，但淪為中間的執行者，沒能讓 Dev 和 Ops 團隊各自向前一步、緊密協同；
平臺研發團隊對規模化帶來的業務複雜性以及技術演進帶來的技術複雜性應對不足，無法為應用研發者提供有效的技術支撐；
不同於面向雲上託管基礎設施服務和 DevOps-as-a-Service 產品工作的小型團隊，中大型企業往往需要根據自身團隊架構和文化建立適當的 DevOps 體系。
從成功案例看，無論是 META 公司由 Dev 完全承擔 Ops 職能，還是 Google 公司引入 SRE 團隊作為中間層，平臺工程（
Platform Engineering
）都扮演了非常重要的角色。平臺工程旨在幫助企業構建面向應用研發者的自服務運維體系，嘗試透過工程化的技術手段和工作流程解決以下關鍵問題：
設計合理的抽象層次，幫助應用研發者降低對 Infra、platform 等技術以及運維、穩定性工作的認知負擔；
為應用研發者提供統一的工作介面和空間，避免使用者陷入割裂的平臺產品介面和複雜的工作流中；
幫助研發者透過有效的工作流程和推薦路徑，能夠基於
內部工程平臺
快速開展工作；幫助研發者透過配套的 CI、CD、CDRA 等產品自服務管理應用生命週期；
幫助平臺產品研發團隊簡單、高效、一致地開放其平臺基礎能力；
透過培訓、佈道、運營等手段，營造協同工作和分享的文化。
事實上，不是所有人都應該或者能夠成為這個領域的專家，這非常困難！平臺技術團隊的專家通常也僅擅長自己的專業領域而已。
特別是在雲原生理念和技術廣泛應用的今天，面向大量高度開放、可配置的平臺技術，帶來了成百上千的應用配置，對 PaaS 領域的業務複雜性、高穩定性和統一治理提出更高的要求。平臺工程的目的正是為了讓應用研發者儘可能簡單、無痛地參與到這種規模化的 DevOps 工作中。
在螞蟻的實踐中，我們更趨向於以下這種合作狀態，團隊架構和工作模式更靠近 Google 的最佳實踐：平臺研發者及 SRE 成為 “Enabler” ，支援應用研發者自服務的完成研發及交付運維，同時應用研發者使其應用可交付運維的工作結果也成為運維人員可以接手應用運維工作的基礎。最終，SRE、應用研發及運維人員把工作過程中的問題和痛點反饋給平臺研發者形成正向迴圈。
專用語言：工程化方式的一極
有什麼比一種專用語言更適合開放、自服務、面向領域業務的問題定義，同時需要滿足自動化、低安全風險、低噪音、易治理的企業內部要求嗎？正如記錄音樂有五線譜、儲存時間序列資料有時序資料庫一樣，在平臺工程的特定問題域內有一批配置和策略語言用於編寫和管理規模化複雜配置及策略。
不同於混合編寫正規化、混合工程能力的高階通用語言，這類專用語言的核心邏輯是以收斂的有限的語法、語義集合來解決領域問題近乎無限的變化和複雜，將規模化複雜配置、策略編寫思路和方式沉澱到語言特性中。
在螞蟻的平臺工程實踐中，我們強化了客戶端的工作方式，將圍繞應用運維生命週期的模型、編排、約束和策略穩定、可擴充套件性，透過專用語言
KCL
編寫維護在共享倉庫
Konfig
中。
KCL 是一種面向有程式設計能力的應用研發者的靜態強型別語言，提供現代高階語言的編寫體驗和圍繞領域目的有限功能。在平臺工程實踐中 KCL 不是一種僅用於編寫 K-V 對的語言，而是一種面向平臺工程領域的專用語言。應用研發者、SRE、平臺研發者面向 Konfig 協同研發，透過 KCL 原生功能編寫應用配置，以及在 PaaS 領域更為高頻和複雜的
模型
抽象、
功能函式
和
約束規則
，編寫穩定、可擴充套件的業務模型、業務邏輯、防錯約束和環境規則。Konfig 倉庫則成為統一的程式設計介面，工作空間和業務層載體，而基於 KCL 的安全、低噪音、低副作用、一致的編寫正規化更有利於長期管理和治理。
分治：解構規模化問題
分治思路是解決規模化問題的鑰匙，從 MapReduce 到 Kubernetes，無不體現其功效。
在規模化交付運維領域，經典運維平臺試圖在統一的黑盒平臺產品中，以內建的統一模型、編排、provision 技術來應對全量業務場景。這樣可以快速啟動，並在小範圍內奏效，但隨著不同業務主體採用率的提升會引入差異化需求，並隨著持續變化的平臺技術逐漸進入疲態。
在螞蟻的實踐中，Konfig monorepo 是內部工程平臺向研發者開放的程式設計介面和工作空間，幫助應用研發者以統一的程式設計介面編寫圍繞應用運維生命週期的配置和策略，從而編排和使用存量和新增的平臺基礎設施，按需建立管理雲原生環境以及基於 RBAC 的許可權，並透過 GitOps 方式管理交付過程。Konfig monorepo 為不同場景、專案、應用提供了獨立的白盒的程式設計空間，其內生的擴充套件性來源於：
靈活、可擴充套件、獨立的客戶端的
工程結構設計
；
獨立配置塊
自動合併技術
支援任意分塊、可擴充套件的配置塊組織；
靜態型別系統
技術提供現代程式語言可複用、可擴充套件的型別化建模和約束功能；
專案粒度的GitOps CI 工作流程定義支援；
基於
Kusion
引擎的 provision 技術選擇。
Konfig monorepo 提供了分治的、可組合的工程結構設計、程式碼組織、建模方式、工作流程定義和 provision 技術選擇支援，同時又以一致的研發模式和工作流承載了可擴充套件的業務需求。這樣客戶端的工作方式在保證靈活性、可擴充套件性、可移植性的同時也降低了對服務端擴充套件機制，如 Kubernetes API Machinery，持續增長的壓力。
下圖示意了一種 Konfig monorepo 中，GitOps 方式的典型的自動化工作流程，從面向應用的程式碼變更開始，透過可配置的 CI、CD 過程觸達執行時，這樣的機制相比中心化的黑盒產品方式更加開放、可定製、可擴充套件，也免去了針對不同業務場景、不同專案、應用設計笨拙的配置檔案管理 portal 的必要。
建模：邊際收益和長尾問題
有了分治的白盒化的工程結構設計、程式碼組織方式、建模方式、工作流程定義和 provision 技術選擇，以怎麼的策略面向平臺 API 工作是另一個需要考慮的問題。
在企業內，典型的爭議在於直面平臺細節還是設計一種抽象，甚至會上升到顯式（explicit）和隱式（implict）理念的爭議。
抽象的、隱式的方式是運維平臺工程師們面向非專家型終端使用者的普遍選擇，他們希望能設計出易於理解和使用的應用模型或 Spec 抽象，能與具體的平臺技術細節隔離，降低使用者認知負擔，並透過降低細節感知防錯。
但大部分運維平臺的研發者傾向於設計一種強大的、統一的應用模型或 Spec 抽象，這在實踐中往往會遇到以下阻礙：
隨著企業內不同業務主體採用率的提升，統一建模難以落地。在螞蟻內部，最典型的案例是 Infra 基礎技術類元件和 SaaS 應用間存在巨大的差異：SaaS 應用便於統一，而 Infra 應用往往需要單獨設計。
面向企業內大量的平臺技術，統一模型自身難以穩定，特別是應對持續變化的業務需求和平臺技術驅動的需求增長。在螞蟻的實踐中，交付運維受多種因素影響有較強的不穩定性，同時圍繞應用的 deliverable、runtime、security、instrumentation 的業務需求也在增長。以 instrumentation 為例，近兩年對應用執行時可觀察性、SLO 定義的需求快速增長直接驅動了終端使用者使用的變化。
抽象模型的共性問題是需要面向使用者設計出合理的模型，面向平臺 API 細節保持同步。
面向終端使用者即應用研發者，我們在實踐中採用了抽象模型的方式，透過如下思路解決幾個關鍵問題：
面向典型應用場景（如螞蟻的 Sofa 應用）建模，這些模型由平臺研發者、平臺 SRE 主導開發，與應用研發者共同維護，以此達到使用者體驗、成本和標準相容的平衡。在螞蟻的實踐中，抽象模型的資訊熵收斂比約為 1：5，透過廣泛的高頻使用保證建模投入的邊際收益。
對於非典型使用者場景或應用，由平臺研發者、平臺 SRE 支援應用研發者完成針對應用的模型設計。KCL
schema
和
mixin
等機制幫助使用者建模、抽象、繼承、組合、複用，減少重複程式碼，事實上這樣的建模設計工作也是應用 PaaS 領域的重點之一，但這樣的場景需要更合理的分工。最終，大量 “非標” 平臺技術在螞蟻內部首次以一致的方式被納管，有效解決了長尾問題。在典型協同模式下，平臺研發者、平臺 SRE 編寫平臺能力基礎元件成為 “Enabler”，幫助應用研發者使用平臺能力基礎元件快速“搭積木”，完成其應用模型的研發工作。
面向平臺技術，我們提供了平臺 API Spec 到 KCL 型別程式碼的
生成技術
，並透過
組合編譯技術
原生支援對不同 Kubernetes API 版本的編譯時選擇，在內部實踐中解決了應用抽象模型面向不同版本 Kubernetes 叢集工作的靈活需求。同時，KCL 支援
in-schema 約束
和獨立環境
規則
的編寫。此外，KCL 還提供了
deprecated 裝飾器
支援對已下線模型或模型屬性的標註。透過在客戶端健壯、完備的模型和約束機制，在編譯時暴露如配置錯誤、型別漂移等常見問題。相對於執行時左移的發現問題，避免推進到叢集時發生執行時錯誤或故障，這也是企業內，特別是高風險等級企業，對生產環境穩定性的必須要求。
對於基礎平臺技術的專家型使用者，他們通常非常熟悉特定的技術領域，更希望以直面平臺細節的顯式的方式工作，語言提供必要的動態性和模組化支援，透過型別和約束機制保證穩定性。
但這種顯式的方式無法解決專家使用者不熟悉跨領域平臺技術使用細節的問題，也不能解決面向平臺技術的擴充套件性和複雜性疊加的問題。在螞蟻內部小範圍基於 YAML 的顯式的工程實踐中，面向大量高度開放、可配置的平臺技術，複雜性隨著平臺技術使用率持續疊加，最終陷入難以閱讀、編寫、約束、測試及維護的僵化狀態。
自動化：新的挑戰
運維自動化是基礎設施運維領域的經典技術範疇，隨著雲原生理念及技術的推波助瀾，可以被自動化整合已成為企業運維實踐的基本要求，開源開放、高度可配置的 CI、CD 技術逐步被企業採納，黑盒的、無法被整合的 “產品” 方式逐步被靈活的可編排方式弱化並替代。
這種實踐的主要優勢在於其強大的自定義編排和連結能力，高度可擴充套件性和良好的可移植性。特別是在 Kubernetes 生態，GitOps 方式有更高的採用率，與可配置的 CI、CD 技術有天然的親和性。這樣的變化也在推進以工單和運維產品為中心的工作流逐步轉變為以工程效率平臺為中心的自服務工作流，而生產環境的運維能力則成為了工作流中面向生產自動運維的一個重要環節。在開源社群，面向不同研發效率平臺的抽象層技術創新也在活躍進行中，平臺側研發者希望透過最短的認知和實踐路徑打通應用到雲環境的 CI、CD 過程。
在螞蟻的工程實踐中，工程效率平臺深度參與了 Konfig monorepo 的開放自動化實踐，我們的實踐方向也與工程效率平臺技術演進方向高度一致。
在從幾人到幾十人再到幾百人的協同工作中，面向運維場景的工作流設計、高頻的程式碼提交和 pipelines 執行、實時自動化測試和部署過程，這些對服務於單庫的工程效率平臺造成了很多的挑戰。特別是 monorepo 中多樣化的業務，需要獨立且強大的工作流自定義和操作支援，也需要高實時性、強 SLO 保障的並行的工作流執行能力，這些需求與單庫模式的需求有巨大的差異，也給我們製造了很多麻煩。
目前，我們的大部分配置語言是解釋型語言，而 KCL 被設計為一種編譯型語言，由 Rust、C、LLVM 最佳化器實現，以達到對規模化 KCL 檔案提供
高效能
編譯和執行時執行的目標，同時支援編譯到本地碼和 wasm 以滿足不同執行時的執行要求。
另外，Git 的儲存及架構設計不同於
Citc/Piper
架構，不適用於規模化程式碼的 monorepo，所幸今天我們的程式碼量還沒有遇到很大的問題。我們正在一起努力解決這些問題，希望隨著實踐的深入逐步解決它們。
協同和文化：更重要的事
以上的技術、工具、機制都非常重要，但我必須要說，對於工程化、Devops 而言，更重要的是團體與團隊的協同、合作和分享的文化，因為這是一種由人組成的工作，人和文化是其中的關鍵。
在企業內，如果部門牆、團隊壁壘叢生，流行封閉糟糕的工程文化，我們通常會看到大量私有的程式碼庫和私有文件、小群體的判斷和工作方式，本該緊密合作的團隊以各自目標為導向，各行其是。在這樣的文化下，我認為一切規模化工作都會非常困難。
所以，如果你所在的公司或團隊想採納規模化 Devops，我認為最重要的是做好廣泛的溝通並開始文化的建設，因為這絕對不只是幾個人的事，並且這很有難度且不可控。
螞蟻實踐初期，也總有各種各樣的困難，大家對自服務機制和協同文化的擔心尤為突出。例如， “我居然要寫程式碼？” “我的程式碼居然跟其他團隊在一個倉庫裡？” “我負責的工作可不簡單，這種方式行不通” ，都是很典型的擔憂。
所幸我們最終建立了一個面向共同目標的虛擬組織，合作方和領導者給予了充分的支援，我們在理念和工作方式上達成一致並協同工作。
在實踐過程中，大多數工程師並不是障礙，當然他們會吐槽技術、流程和機制還不夠完善，希望獲得更好的體驗，這無可厚非。
真正的障礙首先來自運維平臺研發團隊自身。我看到一些公司的 Devops 理想最終迴歸到運維平臺團隊替代應用研發者做掉所有工作，甚至不讓使用者接觸到程式碼和工具鏈這些生產工具，急於隱藏已有的 GUI 產品介面，我認為這跑偏了，也低估了使用者自身的能力和創造力。
另外，障礙也來自部分平臺技術團隊的技術負責人，他們很難放下持續多年的已有工作，難以接受轉向到新的使用者服務模式。可行的辦法是讓他們明白這項工作的意義和遠景，逐步、分階段地影響他們。
小 結
經過一年多的實踐，有 400+ 研發者直接研發參與了 Konfig monorepo 的程式碼貢獻，管理了超過 1500 個 projects，其中平臺研發者及平臺 SRE 與應用研發者比例不到 1：9，這些應用研發者有些是應用 owner 本人，有些是應用研發團隊的代表，這由應用團隊自己決定。
透過持續的自動化能力搭建，基於 Konfig monorepo 每天發生 200-300 次 commits，其中大部分是自動化的程式碼修改，以及大約 1k pipeline 任務執行和近 10k KCL 編譯執行。在今天，如果將 Konfig 中全量程式碼編譯一次並輸出，會產生 300W+ 行 YAML 文字，事實上一次釋出運維過程中需要多次不同引數組合的編譯過程。透過輕量化，便於移植的程式碼庫和工具鏈，我們完成了一次意義重大的外部專有云交付，免去了改造、移植輸出一系列老舊運維平臺的痛苦。在螞蟻內部，我們服務了幾種不同的運維場景，目前正在擴大應用規模並探索更多的可能性。
最後我想說說我們的下一步計劃。我們的技術和工具在易用性和體驗上還有很大的提升空間，需要更多的使用者反饋和持續改進，使用者體驗工作沒有快速路徑。在測試方面，我們提供了簡單的整合測試手段，起到了冒煙測試的作用，但這還不夠，我們正在嘗試基於約束、規則而非測試的方式保證正確性。在工作介面方面，我們希望構建基於 IDE 的線下工作空間，持續規約、最佳化內部線上產品體驗和工作流程，同時我們希望持續提升覆蓋範圍和技術能力。另外，我們也希望將實踐方式更廣泛地應用在 CI 構建、自動化運維等場景，縮短終端使用者的資訊感知和端到端工作流程。
目前，KusionStack 還處於剛剛開源的非常早期階段，未來還有大量的工作要做。最重要的是，我們希望把我們平臺工程的理念和實踐分享給更多企業和團隊，一起推動並見證一些有意思的變化發生。
作者簡介
朵曉東，螞蟻集團可信原生技術部資深技術專家，長期工作在基礎技術、雲原生技術領域，專注雲原生網路、運維，程式語言等技術工作，KusionStack 專案發起人。雲原生網路代理 MOSN 發起人，PMC。Apache Kylin 創始工程師，Emeritus PMC。
引用連結：
https：//kusionstack。io/docs/user_docs/intro/kusion-intro
https：//platformengineering。org/blog/what-is-platform-engineering
https：//internaldeveloperplatform。org/what-is-an-internal-developer-platform/
https：//web。devopstopologies。com/#anti-types
https：//github。com/KusionStack/kusion
https：//github。com/KusionStack/KCLVM
https：//kusionstack。io/docs/reference/lang/lang/tour
https：//kusionstack。io/docs/user_docs/concepts/konfig
https：//kusionstack。io/blog/2022-declarative-config-overview#35-performance
https：//cacm。acm。org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext
炒股開戶享福利，入金抽188元紅包，100%中獎！
開啟App看更多精彩內容