第一頁——聽說 DevOps 死了

2022 年底，InfoQ 發了一篇爆款文，《DevOps 已死，平台工程才是未來》，這裡總結了一個太長不看版：

開發者並不想做運維，工程師不僅編寫代碼，還要運行他們編寫的代碼；
反模式：
高級工程師現在要負責環境配置，並需要處理比較初級的同事的請求；
除了 CICD 之外，還有很多複雜的運維場景：
配置管理、依賴管理、跨環境部署、統一的安全管控..
雖然對於像谷歌、亞馬遜、Airbnb 這些比較先進的組織來說，上述方法很有效，但對於其他大多數團隊而言，要在實踐中複製真正的 DevOps 並不簡單。

還提到 Gartner 的炒作周期圖，將平台工程定義為正在上升期的技術，並且會在 2-5 年達到平台期。

其實這部分回答了我一直以來的一個小迷惑——所謂大一統的運維平台/工具，到底有沒有存在的意義？是不是說假設 DevOps 團隊成長起來了，就不需要這種集中產出的工具和規範了？

首先，我們來看看 DevOps，DevOps 是一種文化，而非一種角色。在 DevOps 文化中，開發和運維團隊需要更緊密地協作，共同為業務提供更好的服務。但這並不意味著所有開發人員都需要成為運維專家，或者所有運維人員都需要成為開發專家。

在實踐中，即使是 DevOps 團隊，也需要有明確的職責劃分和專業分工。大一統的運維平台/工具的存在意義就在於它可以提供一種標準化和自動化的方式，使得 DevOps 團隊能更高效地進行日常工作，而不需要過度關注具體的運維細節。這並不是說 DevOps 團隊成長起來就不需要這種工具了，相反，隨著團隊的成熟，這種工具的價值會更加明顯。

再來看看高級工程師組成的 DevOps 夢之隊。雖然有一些高級工程師在多個技術領域都有深厚的造詣，但是他們的存在並不能解決所有問題。專家本身的技術一定是有所側重和偏愛的，而且在多個不同種類的工作之間進行頻繁切換會嚴重影響效率。而且，聘用多個領域的專家組成全職能 DevOps 團隊的成本非常高，這對於大多數公司來說是不切實際的。

最後，我們來看看平台工程。平台工程將複雜的運維任務抽象為平台服務，由專門的平台工程團隊提供支持。這樣，開發團隊就可以將更多的精力投入到業務開發上，而不是被運維問題所困擾。平台工程團隊一般由具有深厚運維經驗和開發能力的高級工程師組成，他們可以為開發團隊提供高質量的平台服務，從而提高整個組織的開發效率。因此，平台工程才是未來的趨勢。

關於平台工程的文章中一般還會提到一本書：《Team Topologies》，這本書中，詳細描述了通常被稱為成本中心的平台團隊的服務範圍、交付模式、運營內容等做了一番闡述，建議 SRE 工具建設領域的朋友們閱讀本書增強自信。根據本書描述，有四種基本的拓撲結構，團隊應該圍繞這些拓撲結構進行：

業務導向團隊：
與業務領域某個部分的工作流相匹配，處理核心業務邏輯。
賦能團隊：
幫助業務導向團隊克服障礙並檢測缺失的功能。
複雜子系統團隊：
在嚴重依賴數學/技術方面的專業知識時組建。
平台團隊：提供一個令人信服的內部平台，提高業務導向團隊的交付速度。

各自為政有什麼問題

下面說點常見的場景。

第三方軟體選型和採用

首先說的是雲原生，很多人都領略過 Cloudscope Landscape 的宏偉壯觀。選型時無從下手，尤其是面對同類項目（例如 ELK 棧和 Loki 棧，Docker 和 Podman 等）時，社交網絡定選型是個常態。

然而大家心裡應該都清楚，引入一個「看上去不錯」開源軟體進入企業系統，是有很多需要考慮的內容的，例如：

項目健康度如何？
例如社區活躍程度、Issue 響應速度、社區多樣性等。
是否有商業公司提供支持？
軟體本身是否滿足其 License 要求？
軟體的 License 是否能夠滿足企業內使用的場景需求？
軟體及其依賴項合法合規嗎？
除了功能之外，穩定性、可靠性、安全性等非功能特性是否滿足企業需要？
運維特性，例如倒換、擴縮容、升級、備份恢復等是否完善方案，用於支撐長期運行？
…

軟體選定之後還面臨世界對接的問題，常見的問題包括認證、可觀測性、存儲等的對接，這些還是一些點狀的功能，在雲原生體系里，還有一個更嚴重的體系衝突問題。

我常用這張圖來把「普通」開源軟體和雲原生軟體的採用過程進行對比：

一個有一定規模的企業的 IT 體系，條條框框是相對固定的，軟體規模不管大小，都可以服服帖帖、按部就班的落到代表體系規則的魚骨圖裡，而以 Kubernetes 為代表的雲原生生態則不同，其中自帶了各種條條框框，不光是改了改你的部署運行方式，還對你的運維方式產生深遠影響，甚至對你的應用架構指指點點。如果不照章辦事，就可能和生態不兼容。因此雲原生進入企業，通常會跟 IT 系統的現存規則交纏在一起，形成一種相互影響和制約的新體系。

用戶又亂搞了

以我熟悉的 Kubernetes 為例，一些用戶的操作，可能造成各種奇怪的不良後果，例如：

濫用節點反親和導致無法調度
引入網絡惡意鏡像損失算力甚至被盜取機密
誤用本地存儲，Pod 漂移後數據損失
錯誤配置引發集群異常

Kubernetes 對象的易用性，隨手可得的各種技巧，都給誤操作和危險行為以可乘之機，然而實際情況是，如果是多個團隊自行進行運維，可能就會產生五花八門的不同風格的集群，如下圖所示：

很明顯，不同團隊因為各自的業務目標、技能水平等，會產生各種不同風格的集群，自然而然，不同的集群，有機會進行不同的「亂搞」，也會出現不同的問題。

我看平台工程

根據流行定義：平台工程是一門設計和構建工具鏈和工作流的學科，在雲原生時代為軟體工程組織提供自助服務能力。平台工程師提供一個集成的產品，通常被稱為「內部開發者平台」，涵蓋了應用程式整個生命周期的操作需要。

以我所見，平台工程面在三個方面為組織提供支持基礎設施、規範和工具：

基礎設施

現代軟體運行需要大量的基礎設施，除了傳統的網絡、計算、存儲之外，還包括大量的服務化的中間件等能力，OpenStack、Kubernetes 等資源編排工具也屬於是傳統管控難題。平台團隊可以綜合基礎設施自有的管控運維能力，使用 Terraform、Kubernetes CRD、等資源抽象和自動化手段，為開發團隊及其產品，規劃、搭建、自動化和優化可靠、安全、高性能的基礎設施，以支持業務的運行和發展。

規範

企業 IT 環境通常會有一系列的規範，例如設施命名、帳號管理、IP 分配等等；另外作業系統、容器集群等具有極大靈活性的基礎設施，也通常是需要有一定的規範化管理的，這裡提到的規範至少包括：

安全規範：
平台團隊負責制定和實施安全規範，以確保平台和應用程式的安全性。
這可能包括訪問控制、身份驗證、數據加密、漏洞管理等方面的規範。
部署和發布規範：
平台團隊可以制定規範，定義部署和發布流程，並確保它們得到正確執行。
這些規範可以包括環境分離、版本控制、持續集成和持續交付等。
最佳實踐：
各種最佳實踐可以通過規範的形式進行推行和實施。
將最佳實踐轉化為規範的形式可以確保團隊成員共享相同的理解，並提供具體的指導和標準，以便在組織中廣泛應用，例如訪問控制規範、文檔發布規範、接口管理規範等等。
資源規範：
例如資源申請和分配、生命周期管理、成本控制、審計和監控等的規範，有助於組織資源的有效利用、成本控制和性能優化。

工具

平台工程的主要產出就是一個被稱為 idp（內部開發平台）的工具，以此工具為開發團隊提供支持，在實際工作中，工具部分的工作內容至少包括：

外部（開源/商業）軟體的導入：
除了前面提到的採用開源軟體的層層關卡之外，平台工程團隊還應負責補齊第三方軟體的運維能力、外部軟體和內部平台的配套對接、開發並實施明確、有效並且成本合理的生命周期管理過程。
基礎設施的供給、隔離：
在基礎設施自身服務接口和運維能力基礎之上，為各個開發組織以及產品，規劃並供給基礎設施資源，儘可能讓產品團隊關注資源本身，並提供成本監測、優化等技術支持能力，用隔離手段防止租戶和租戶、租戶和管理之間的不必要的資源訪問。
Dev(Sec)Ops：
包含供應鏈安全、代碼質量、環境管理等的複雜 CI/CD 生命周期相關能力。
規範實施：
平台或者工具，除了是業務的加速器，同時也是管理意志的執行者。
純文本的規範舉步維艱，只有靠策略保障、工具輔助等方式，才能保障規範背後的管理意圖的達成