扯淡的DevOps，我們開發根本不想做運維！

引言

最初考慮引用“ 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，並從能力成熟度的角度推動提升。然而，對於投入和產出的量化評估卻相對模糊。平臺工程提出了一些衡量其價值產出的方式，包括自助式體驗和儘可能減少人力投入。通過致力於建設自助化、場景化的能力，提供有價值的平臺。



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

開發爲什麼不想做運維

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

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

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

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

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



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

運維工作的本質

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





最近，一些大廠經歷了重大的線上穩定性故障，這給業界帶來了很大的關注。

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

帶來的一些思考

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

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

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

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

平臺工程成功的關鍵因素

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

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

• 平臺範圍：內部有許多工具，首先要確立權威或認證的工具，進行持續投入與迭代，而非各自發展，以免造成重複建設和成本的浪費。

• 平臺文化：平臺到底是爲誰而做，爲誰服務，技術研發人員是我們的上帝，建立以服務技術研發人員爲主的平臺文化，同時滿足公司管理角度。

• 平臺目標：核心目標是構建場景化的工具，使技術人員能在平臺中自助化使用，把場景化、自助化作爲核心目標。

• 平臺Owner：企業內的IPD不可能集中在同一個部門，因此確定特定場景的 Owner 至關重要，可以消除職責邊界不清晰的問題。

• 需求來源：一切以研發需求爲主，要兼顧研發人員的使用體驗，避免大而全的版本升級改動，導致研發遷移系統，遷移資源，從而帶來的額外使用成本。

• 平臺API：內部平臺天然就應具備豐富API，滿足內部研發的需求，並也應提供詳細的文檔讓技術人員使用。

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

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

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

• 產品化：內部的工具平臺一定要產品化，定位於服務全集團，而非侷限自己所在部門的幾個人，或者幾十人使用，一定要把目標用戶定位是集團內所有研發同學，只有這樣才能把工具做好。

• 用戶體驗：重視用戶體驗，除了提供基礎的GUI界面，API等能力之外，另外也要注意屏蔽複雜的後端邏輯，降低用戶的使用成本。

• 集成化：這裏講集成，不僅是像目前行雲/泰山一樣通過工具市場把各個工具集成到平臺上就行了，這些僅完成了第一步，還是以研發使用場景爲目標，以應用爲視角工作區，例如在發佈時，整合監控、日誌、預案、告警等可觀測的視圖，讓用戶在一個地方滿足所有該場景的需求。

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





 

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

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

• 產品化：內部工具再需求把控方面特別容易被定製，經過一段時間後，可能會演變成了某個人或者某個小部門的定製產品。

• 優先級：經常接到或面臨“某C-x老闆”的高優先級需求。

• 認可性：由於與業務脫節，難以衡量價值，長期下來，對產出的價值認可可能會產生疑慮。

• 重複建設：內部工具和平臺的重複建設問題較爲嚴重。

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

• 持續收集用戶需求，並對平臺長遠規劃路線圖。

• 完善用戶使用手冊和最佳實踐，提升用戶體驗。

• 保持開放心態，一定要提供API。

• 持續推廣和運營所負責的平臺。（生孩子和養孩子）

• 針對重複建設問題，加強合作共建，避免陷入小範圍的自嗨式“個人/部門工具”建設

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

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

• 用戶維度（第一個就是要用戶維度，提升用戶體驗）

◦ 周活躍用戶數

◦ 賦能業務數

◦ NPS淨推薦值

• 產品維度

◦ 訪問效率

◦ 執行效率

◦ 執行成功率

• 組織維度

◦ XX週期

◦ XX用時

平臺工程的未來

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

國外的情況

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





國內的情況

在國內，目前平臺工程也逐漸受到大家的關注，特別是原來就負責DevOps工具相關的人員，更加關注平臺工程帶來的新的概念和倡導方向。中國信息通信研究院也正在組織行業內的專家，共同梳理一份符合國內現狀的平臺工程能力要求標準，會明確平臺工程功能維度。我目前也參與了部分工作，如有對此感興趣的同事，歡迎聯繫我一同參與。

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

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

作者：京東零售 井亮亮

來源：京東雲開發者社區 轉載請註明來源