引言
最初考慮引用“ 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%的軟體工程組織將建立平臺團隊作為可重複使用的服務、元件和工具的內部提供者，用於應用程式交付。
可見，平臺工程不僅僅是一種趨勢，它是軟體交付的未來
作者：京東零售 井亮亮
來源：京東雲開發者社群 轉載請註明來源