DevOps，我們開發者根本就不想做運維！

最初考慮以“DevOps已死，平台工程是未來”為標題，但這樣的表達可能過於絕對。 最終，決定用“”這個詞來形容DevOps，但這不是一種文明的說法。 本文旨在重新審視DevOps和平台工程，並將分別分析DevOps和平台工程的概念，並重點介紹平台工程倡導的一些核心要素。 同時，希望這篇文章能給從事內部開發平台（IDP）工作的同學們帶來一些思考。

DevOps本身就是一種強調團隊合作的理念，它使開發和運營團隊能夠密切合作。 雖然強調了自動化和工具的重要性，但它並沒有明確指出該去哪裡。 因此，平台工程的概念。 雖然無法核實是誰最先提出的，但在2022年7月，一條推特訊息“DevOps已死，平台工程萬歲”迅速在國內外DevOps圈子裡傳播開來，得到了廣泛的反響。

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

平台工程是設計和構建工具鏈和工作流的學科，這些工具鏈和工作流為雲原生時代的軟體工程組織提供自助服務功能。 平台工程師提供整合產品，通常稱為“內部開發人員平台”，可滿足應用程式整個生命週期的運營需求。 - 平台工程的定義org（平台工程的定義有很多，但大多都有相同的含義：主要是提倡自助服務，以降低底層基礎支援工具的複雜性和不確定性，減少工作流程，降低終端使用者在使用過程中的認知成本，從而改善終端使用者體驗，提高生產力）。

2023 年，Gartner 將平台工程列為首要戰略趨勢之一。 在最近發布的《2024 年十大技術趨勢》中，Gartner 再次提到了平台工程，並將其提公升了乙個檔次，這表明行業對平台工程的認可度進一步提高。

在過去的幾年裡，DevOps一直從能力成熟度的角度出發，並被推動。 然而，對投入和產出的定量評估相對模糊。 平台工程提出了多種方法來衡量其價值輸出，包括自助服務體驗和最大限度地減少人工投入。 通過致力於構建自助服務和基於場景的能力，它提供了乙個有價值的平台。

回到本文的標題，我們來談談為什麼開發者不願意承擔運營。

DevOps強調團隊合作，並鼓勵開發人員承擔一些運營工作。 然而，在現實中，為什麼這往往難以實現？ 我認為主要有幾個原因：

專注於核心開發任務：開發人員往往更傾向於日常的軟體開發任務，他們可能沒有太多的時間和精力去關注其他事情，否則會影響日常任務的工作進度。

不熟悉或不感興趣：開發人員可能沒有足夠的經驗來處理操作，或者他們可能對操作不感興趣，導致操作缺乏動力。

操作和維護的鍋太重太複雜：運維涉及生產環境，責任範圍和影響大。 任何操作故障都可能導致系統故障、服務中斷或資料丟失等嚴重後果。 因此，承擔運營工作對開發人員來說可能是乙個額外的負擔和責任。 此外，運維工作通常包括各種瑣碎繁瑣的任務，包括 24/7 值班。

缺乏有用的工具和平台支援：如果沒有易於使用且高效的自動化工具和平台，操作將變得更加手動，從而增加了操作的成本和複雜性。

這些可能是開發人員不願意承擔運營工作的一些可能原因。 運營的本質是什麼？

運維的重點是確保系統的安全穩定執行。 它不僅需要24/7全天候監控線上環境的穩定性，還需要處理各種日常運維任務。 這些任務可能包括資源管理、例行檢查、故障排除和維修以及工單處理。

近日，一些大廠商出現了重大的線上穩定故障，引起了業界的廣泛關注。

最近的這些線上故障給整個行業敲響了巨大的警鐘，所有企業都面臨著線上穩定性的相同挑戰。

安全生產，警鐘敲響：面對線上問題，我們不能單純追求速度和便利，對任何線上操作都要保持敬畏之心。

安全生產是每個人的責任無論是開發人員編寫的錯誤邏輯，還是運營商錯誤的公升級操作，最終都會對公司造成不可估量的損害。

生產環境的穩定性，最難的不是技術，而是看不計其數的細節的實施，穩定性的保障需要大量的投入，但這件事最大的問題是難以被認可，又如何衡量好壞？ 網上曾經流傳著乙個笑話，大致意思是“那些沒有bug的寫作者，往往默默無聞，甚至可能被殺死; 相反，那些經常寫bug的同學，因為每天忙著修復bug，才能茁壯成長“，當然，開發者不願意承擔運維的原因，確實是因為線上穩定責任重，運維工作負擔也很重，缺乏適用的工具和平台支援。

然而，平台工程被提出為乙個新概念，旨在解決這些問題並改進軟體交付過程。 讓我們來談談與DevOps相比，[平台工程]的關鍵成功因素。

作為乙個相對較新的概念，平台工程已連續兩年獲得 Gartner 的認可，使其成為我們關注的焦點。 為了在公司內部推進平台工程，我認為需要明確以下幾個方面：

平台範圍：內部工具很多，首先要做的就是建立權威或認證的工具，並不斷投入迭代，而不是單獨開發，避免重複構建和成本浪費。

平台文化：歸根結底，平台是為誰而造的，為誰服務，技術研發人員就是我們的上帝，建立以服務技術研發人員為基礎的平台文化，同時滿足公司的管理視角。

平台目標：核心目標是構建場景化工具，讓技術人員在平台內自助服務，以場景化、自助化為核心目標。

平台所有者：企業內部的IPD不可能集中在同乙個部門，因此確定特定場景的所有者對於消除責任邊界不清的問題至關重要。

要求**：一切都以研發需求為導向，要兼顧研發人員的經驗，避免大而全面的版本公升級和改動，導致系統和資源的研發遷移，造成額外的使用成本。

平台API：乙個內部平台自然應該有豐富的API，以滿足內部研發的需求，也應該提供詳細的文件供技術人員使用。

綜上所述，本文討論了如何從全球視角在內部推進平台工程。 接下來，我們來看看平台專案下的工具應該具備哪些特徵：

就我個人而言，我認為內部工具比面向消費者的產品更重要。 因為消費品使用者有選擇權，但業內人沒有太多選擇，頂多只是幾句抱怨，但還是需要繼續使用。 要建立乙個讓內部人員滿意的工具，我個人認為您至少需要以下關鍵屬性：

產品化：內部工具平台必須產品化，定位於服務於整個集團，而不是侷限於自己部門的幾個人，或者幾十個人使用，目標使用者必須定位為集團內所有研發生，只有這樣才能把工具做好。

使用者體驗：注重使用者體驗，除了提供基本的GUI介面、API等功能外，除了阻塞複雜的後端邏輯，降低使用者使用成本。

整合：這裡說到整合，不僅僅是像現在的興雲泰山這樣，通過工具市場將各種工具整合到平台中，這只是第一步，而是以開發使用場景為目標，以應用為工作空間的視角，比如在發布的時候， 整合監控、日誌、計畫、告警等可觀測檢視，讓使用者一站式滿足所有場景的需求。

自我服務：使用者不需要平台同學的協助，可以滿足所有功能，這裡舉個例子，我們去銀行取款，在櫃檯人工取款，但是需要銀行工作人員的協助，但是我們通過ATM，同樣也可以完全自助取款。

在平台工程的背景下，內部開發團隊可能有以下常見情況，比如這四個方面：

產品化：內部工具在需求控制方面特別容易定製，經過一段時間後，它們可能會演變成針對某個人或乙個小部門的定製產品。

優先權：經常收到或面臨來自“某個 C-X 老闆”的高優先順序請求。

識別：由於與業務脫節，很難衡量價值，從長遠來看，對產出價值的確認可能會受到懷疑。

重複構造：內部工具和平台重複構建的問題更為嚴重。

我個人認為內部平台團隊應該堅持做以下幾點：

持續收集使用者需求，規劃平台長期路線圖。

改進使用者手冊和最佳實踐，以改善使用者體驗。

保持開放的心態，並確保提供 API。

持續推廣和運營其負責的平台。 （生兒育女）。

針對重複建設問題，要加強合作、共建，避免陷入小規模自吹自擂的“個人部門工具”建設。

最主要的是要從一些指標維度來衡量和評估。 如果乙個平台或工具構建了一年，它對自己的用途一無所知，只專注於功能開發，那麼你如何衡量平台帶來的價值？ 我認為最重要的是尋找乙個關鍵指標，它可以是業務維度、產品維度或組織維度，我丟擲幾個維度僅供參考：

使用者維度（第乙個是按使用者維度改善使用者體驗）。

每週活躍使用者數。

為企業數量賦能。

NPS 淨推薦值。

產品尺寸

訪問效率。 執行效率。

執行成功率。

組織維度

xx 週期。 xx 時間。

鑑於平台工程的未來發展，目前國內外的情況如下：

目前，谷歌、Spotify、Netflix、沃爾瑪等一大批國外廠商等一大批企業都在積極推動企業內部平台工程的實施，11月，CNCF正式發布了平台工程能力成熟度模型，從5個維度劃分為4個層次，CNCF發布的成熟度模型維度更加粗粒度， 主要從團隊人員、平台應用、使用者體驗、自助服務和平台迭代等方面進行考核。平台的功能維度沒有詳細劃分。

在國內，平台工程逐漸吸引了大家的關注，尤其是原本負責DevOps工具的人員，更加關注平台工程帶來的新概念和倡導方向。 中國資訊通訊研究院也在組織業內專家，共同梳理出符合我國現狀的平台工程能力需求標準，明確平台工程的功能維度。 我目前正在參與一些工作，所以如果您有興趣，請隨時與我聯絡。

最後，根據 Gartner 的資料，到 2026 年，80% 的軟體工程組織將擁有平台團隊，其中 75% 將包括開發人員自助服務門戶。 80% 的軟體工程組織將建立平台團隊，作為可重用服務、元件和應用程式交付工具的內部提供商。

可見平台工程不僅是一種趨勢，而且是軟體交付的未來

作者：京東零售 景亮亮.

*：京東雲開發者社群**轉載請註明**。