來源：京東技術

Tech

導讀

在軟體開發領域，DevOps的理念已經越來越普及，但在實際應用中，卻存在著不少爭議和誤解。本文將從開發者視角出發，質疑DevOps在實際開發過程中的可行性，分享開發人員對於運維工作的真實想法。讓我們一起來看看，究竟是什麼原因讓開發者對DevOps產生牴觸情緒，以及如何化解這一矛盾。閱讀本文，你將獲得對DevOps更深入的理解，以及找到提高開發與運維協作效率的啟示。

01

引言

在今年的敏捷團隊建設中，我透過Suite執行器實現了一鍵自動化單元測試。Juint除了Suite執行器還有哪些執行器呢？由此我的Runner探索之旅開始了！

最初考慮引用“ DevOps 已死，平臺工程才是未來”作為標題，但這樣的表達可能太過於絕對。最終，決定用了“扯淡的”這個詞來描述 DevOps，但這並不是一種文明的表達方式。

文章旨在重新審視 DevOps 和平臺工程，將分別探討 DevOps 和平臺工程的概念，並重點分析平臺工程所倡導的一些核心內容。同時，希望透過本文能夠給從事內部開發平臺（IDP）工作的同學們帶來一些思考。

DevOps的目標

在 2009 年，DevOps 這一概念就被提出，重點強調團隊協作、自動化工具和流程改進，旨在提高軟體開發和部署的速度和質量。然而，提出之後有近 15 年了，發現這一方法並未如預期完美實現了目標。在我們公司內部，我們也會發現軟體交付成本仍然還是較高，從部署釋出工具的角度來看，無論是 J-ONE、JDOS 還是目前的行雲部署，對於研發人員日常部署釋出仍存在一定的成本，但這種現象好像不僅僅是工具層面的問題。

DevOps 本身是一種理念，強調團隊協作，使開發團隊和運維團隊能夠緊密合作。儘管強調了自動化和工具的重要性，但它並沒有明確指出具體的發展方向。因此，出現了平臺工程（Platform Engineering）這一理念。雖然最早是誰提出的已無法考證，但在 2022 年 7 月份，一條Twitter上的訊息“DevOps is dead, long live Platform Engineering” 在國內外的 DevOps 圈子迅速傳播開來，並得到了廣泛的回應。

平臺工程（Platform Engineering）是一種新的運維理念，強調內部開發平臺應該提供技術研發人員自服務的能力。其核心觀點之一是透過遮蔽基礎設施的複雜性，為技術研發人員提供靈活的工具鏈和工作流程。這樣，可以利用平臺的基本能力，自主解決問題，無需依賴平臺層的參與，使得開發團隊能夠更加高效地開展工作，提高軟體交付的速度和質量。

平臺工程的定義

平臺工程是設計和構建工具鏈和工作流的學科，可在雲原生時代為軟體工程組織提供自助服務功能。平臺工程師提供的整合產品通常被稱為“內部開發人員平臺”，涵蓋了應用程式整個生命週期的運營需求。--定義來自 platformengineering.org

（關於平臺工程的定義較多，但大部分意思較一致：主要是倡導自助服務減少底層基礎支撐工具的複雜性和不確定性，減化工作流程，減少終端使用者在使用過程中的認知成本，從而改善了終端使用者的體驗，和提高生產效率）

平臺工程和 DevOps 都是軟體開發和運維領域的概念，它們共同關注提高軟體開發和部署的效率和質量，但它們的重點和方法有所不同。平臺工程著重於構建可重用的平臺架構，提供場景化的能力，提供自助化的體驗。而 DevOps 則側重於團隊協作、自動化工具和流程改進，以提高軟體開發和部署的速度和質量。

在 2023 年，Gartner 已將平臺工程列為頂級戰略趨勢之一。最近釋出的 2024 年十大技術趨勢中，Gartner 再次提到了平臺工程，並且將其提升了一個級別，這表明平臺工程在業界的認可度得到進一步提升。

在過去的幾年中，人們一直追求 DevOps，並從能力成熟度的角度推動提升。然而，對於投入和產出的量化評估卻相對模糊。平臺工程提出了一些衡量其價值產出的方式，包括自助式體驗和儘可能減少人力投入。透過致力於建設自助化、場景化的能力，提供有價值的平臺。

回到本文的標題，我們來談談為什麼開發人員不願意承擔運維的工作。

02

開發為什麼不想做運維

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

DevOps 強調團隊協作，並鼓勵開發人員承擔一定的運維工作。然而，在現實中，為什麼這一點往往難以實現？我認為主要有以下幾個方面的理由：

• 專注於核心開發任務：開發人員通常更傾向於日常軟體開發任務，他們可能沒有太多時間和精力在其他方面，否則會影響日常任務的工作進展。

• 不熟悉或不感興趣：開發人員可能沒有足夠的經驗來處理運維的工作，或者他們對運維工作不感興趣，導致在運維方面缺乏積極性。

• 運維的鍋太重、事太雜：運維工作涉及到生產環境，因此其責任和影響範圍較大。任何運維失誤都可能導致系統故障、服務中斷或資料丟失等嚴重後果。因此，對於開發人員來說，承擔運維工作可能帶來額外的壓力和責任。此外，運維工作通常包括各種瑣碎而繁雜的任務，包括7*24值班。

• 缺乏好用的工具和平臺支援：缺乏易用且高效的自動化工具和平臺，運維工作就會更加依賴手工操作，從而增加了運維的成本和複雜性。

以上可能是開發人員不太願意承擔運維工作的一些可能的理由。我接下來看下運維的本質是什麼？

運維工作的本質

運維工作重點是保障系統的安全和穩定執行。它不僅需要 7x24小時監控線上環境的穩定性，還需要處理各種日常的運維任務。這些任務可能包括資源管理、日常巡檢、故障排查與修復、工單處理等。

一些重大的線上穩定性故障給業界帶來了很大的關注。以下是發生的兩個關注度比較高的P0級故障案例：

• 某雲全球所有區域同時出現故障，由於AK的異常的程式碼存在邏輯缺陷，導致有效請求都不在白名單中，造成相關係列產品共計三個半小時的故障。最終，採取了分批重啟 AK 服務的措施，才陸續進行恢復。
• 某APP出現超長當機，根據網上流傳的資訊，這次故障事件的原因是由於選擇了成本較低的K8S的原地升級方案，由於錯誤的升級操作，導致升級變成了降級，幹掉了所有的pod，直至次日下午，該APP才基本恢復正常。

這些線上故障對整個行業產生了極大的警示，所有企業都一樣面臨著線上穩定性挑戰。

帶來的一些思考

安全生產，警鐘長鳴：面對線上問題，我們絕不能單純地追求速度和省事，對於任何線上操作，都必須保持敬畏之心。

安全生產，人人有責：無論是開發人員編寫的錯誤程式碼邏輯，還是運維人員錯誤的升級操作，最終都有可能給公司帶來無法估量的損失。

生產環境的穩定性，最難得不是技術，而是依賴無數細節的落地，穩定性的保障需要大量的投入，然而這個事最大的問題就是，難被認可，以及怎麼來衡量做的好呢？網上曾經一個段子，大概意思就是“那些程式碼寫的沒有 Bug 的人，往往默默無聞，甚至可能被幹掉；相反，那些經常寫 Bug 的同學，因為日常忙碌於修復 Bug ，反而能風生水起”，當然，開發不願意承擔運維的原因，確實是因為線上穩定性的責任重大，同時運維工作的負擔也很重，並且缺乏適用的工具和平臺來支援。

然而，平臺工程被提出，作為一種新的理念，旨在解決這些問題，並提高軟體交付流程。接下來聊一聊，與 DevOps 相比【平臺工程】的成功關鍵因素有哪些。

03

平臺工程成功的關鍵因素

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

如何在公司內推動平臺工程

作為一個相對新穎的概念，平臺工程已連續兩年獲得 Gartner 的認可，將其推向了我們不得不關注的重要地位。要在公司內推動平臺工程，我認為需明確以下幾個方面：

• 平臺範圍：內部有許多工具，首先要確立權威或認證的工具，進行持續投入與迭代，而非各自發展，以免造成重複建設和成本的浪費。
• 平臺文化：平臺到底是為誰而做，為誰服務，技術研發人員是我們的上帝，建立以服務技術研發人員為主的平臺文化，同時滿足公司管理角度。
• 平臺目標：核心目標是構建場景化的工具，使技術人員能在平臺中自助化使用，把場景化、自助化作為核心目標。
• 平臺Owner：企業內的IPD不可能集中在同一個部門，因此確定特定場景的 Owner 至關重要，可以消除職責邊界不清晰的問題。
• 需求來源：一切以研發需求為主，要兼顧研發人員的使用體驗，避免大而全的版本升級改動，導致研發遷移系統，遷移資源，從而帶來的額外使用成本。
• 平臺API：內部平臺天然就應具備豐富API，滿足內部研發的需求，並也應提供詳細的文件讓技術人員使用。

綜上，從全域性的維度討論瞭如何在內部推動平臺工程。接下來，我們探討一下平臺工程下的工具應具備哪些特質：

平臺工程下建設什麼樣的工具

個人認為，相較於面向消費者的產品，內部工具更為重要。因為消費者產品使用者有選擇權，但內部人員並無太多選擇餘地，最多隻是抱怨幾句，卻仍需繼續使用。要打造令內部人員滿意的工具，個人覺得至少需要以下關鍵屬性：

• 產品化：內部的工具平臺一定要產品化，定位於服務全集團，而非侷限自己所在部門的幾個人，或者幾十人使用，一定要把目標使用者定位是集團內所有研發同學，只有這樣才能把工具做好。
• 使用者體驗：重視使用者體驗，除了提供基礎的GUI介面，API等能力之外，另外也要注意遮蔽複雜的後端邏輯，降低使用者的使用成本。
• 整合化：這裡講整合，不僅是像目前行雲/泰山一樣透過工具市場把各個工具整合到平臺上就行了，這些僅完成了第一步，還是以研發使用場景為目標，以應用為視角工作區，例如在釋出時，整合監控、日誌、預案、告警等可觀測的檢視，讓使用者在一個地方滿足所有該場景的需求。

• 自助化：使用者無需平臺同學的協助，能滿足一切功能，這裡舉個例子，我們去銀行取錢，在櫃檯人工可以取，但需銀行人員的協助，但我們透過ATM，一樣也可以完全自助的取錢。

平臺工程下的內部開發團隊

在平臺工程背景下，內開發團隊可能會有以下共性情況，例如這四方面：

• 產品化：內部工具再需求把控方面特別容易被定製，經過一段時間後，可能會演變成了某個人或者某個小部門的定製產品。
• 優先順序：經常接到或面臨“某C-x老闆”的高優先順序需求。
• 認可性：由於與業務脫節，難以衡量價值，長期下來，對產出的價值認可可能會產生疑慮。
• 重複建設：內部工具和平臺的重複建設問題較為嚴重。

個人覺得內部平臺團隊應要堅持做以下幾件事：

• 持續收集使用者需求，並對平臺長遠規劃路線圖。
• 完善使用者使用手冊和最佳實踐，提升使用者體驗。
• 保持開放心態，一定要提供API。
• 持續推廣和運營所負責的平臺。（生孩子和養孩子）
• 針對重複建設問題，加強合作共建，避免陷入小範圍的自嗨式“個人/部門工具”建設

如何衡量平臺工程的成功呢？

主要在於要從一些指標維度進行衡量評估。如果一個平臺或者工具，在做了一年後，對於自身的使用情況一無所知，而僅專注在做功能開發，那麼怎麼來衡量這個平臺帶來的價值呢？我覺得最關鍵的在於要尋找一個關鍵的指標，這個指標可以是業務維度，也可以是產品維度或組織維度，我丟擲幾個維度僅供參考：

• 使用者維度（第一個就是要使用者維度，提升使用者體驗）：周活躍使用者數、賦能業務數、NPS淨推薦值
• 產品維度：訪問效率、執行效率、執行成功率
• 組織維度：XX週期、XX用時

04

平臺工程的未來

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

針對平臺工程的未來發展，目前國內外的情況如下：

國外的情況

當前，國外各大廠像Google、Spotify、Netflix、Walmart等一大批公司均在積極推動平臺工程在企業內部的實施，11月份，CNCF正式釋出了平臺工程的能力成熟度模型，分別從5個維度上劃分了4個級別，CNCF釋出的成熟度模型維度比較粗粒度，主要從團隊/人員、平臺應用、使用者體驗、自服務以及平臺迭代等方面進行評估，並未對平臺功能維度進行詳細劃分。

國內的情況

在國內，目前平臺工程也逐漸受到大家的關注，特別是原來就負責DevOps工具相關的人員，更加關注平臺工程帶來的新的概念和倡導方向。中國資訊通訊研究院也正在組織行業內的專家，共同梳理一份符合國內現狀的平臺工程能力要求標準，會明確平臺工程功能維度。

最後，放個一個Gartner預測的資料，Gartner預測，到 2026 年， 80% 的軟體工程組織將建立平臺團隊，其中 75% 將包含開發者自助服務門戶。80%的軟體工程組織將建立平臺團隊作為可重複使用的服務、元件和工具的內部提供者，用於應用程式交付。

可見，平臺工程不僅僅是一種趨勢，它是軟體交付的未來。