作業幫聶安：維運如何轉型，聽聽作業幫的OPaS思路

第1期央請井老闆發表了很多有趣的觀點，有人留言說是維運勸退指南，哈哈，這一期的嘉賓，觀點會有不同，請大家抱著開放的心態，聽百家之言，自己做職業、人生規劃。所謂兼聽則明，偏信則暗，若只聽自己順耳的，大機率不會有深度思考碰撞，憾事也。

這裡是接地氣、有高度的《運維百家講壇》第 2 期，開講！

嘉賓介紹

本期我們邀請的是作業幫的運維負責人聶安，聶安是資深業界老砲，先後履職於阿里、小米、滴滴、作業幫，有10多年的維運/研發/管理經驗。

要點簡述

• 傳統運維，職責是將工業製成品組裝成服務、交付給用戶，並維持服務運作；特點是強依附於業務
• 領域危機，雲端原生時代公有雲大量使用、微服務架構和DevOps真實達成、工具體系持續繁榮，傳統運維的職責不斷被外包、轉移、替代，出現了領域危機
• 組織結構，協作方式從人人協同、逐漸升級為平台自助，運維的主旋律從橫向協同、轉變為服務產品和技術中台
• 運維轉型，技術上透過自助化的平台、對外提供維運服務能力OPaS(OP as Service)，分成物件、場景兩層；底層物件做到同構維持，就構成了一套可持續的維運架構
• 業務運作維，服務化轉型的核心是角色認知，維運人要把自己從依附於業務的營運角色、調整為獨立的維運服務提供方；在超服務視角上，業務運維大有可為
• 組件維，掌控組件本身、比純運維管理更進一步，遵循洋蔥模型，即立足於資源交付、建設管理平台、再深入到組件自身的專業領域
• 運維開發，剝離掉重複的平台迭代工作，聚焦到公共的維運中台，做專技術、做高槓桿

運維階段

互聯網運維，先後經歷了純手工、標準化、平台化、數智化等幾個階段，如下圖。其中，DevOps是科技驅動的組織變革、非專業變革。

從運維的發展歷史，我們可以看到幾個特點：

• 繼承性。新階段往往繼承、發揚老階段的優秀經驗，又會在理念、技術、組織上有所創新

• 比如，平台化繼承、強化了標準化階段的成果，數智化繼承了平台化的成果、同時引進大數據技術

• 職責轉移。 DevOps是運維管理模式的分水嶺，DevOps之後的運維
• 一方面，沿著運維專業化的方向繼續推進，對更高量級的運維對象、保持同構管理的能力
• 另一方面，則強調維運研發融合，維運職責逐步轉移到業務研發

學習某個領域的發展歷史，能夠讓我們以史為鑑、順勢而為。

傳統維運

在傳統的維運模式中，服務對象基本上可以分割成三層。最底層是硬體基礎設施IaaS，主要是運算、網路、儲存組成；中間層是軟體基礎設施，包括了作業系統、虛擬化技術、程式碼架構、中介軟體等；最上層是業務層，主要是應用服務。

傳統運維的職責是，透過一系列的流程、技術、方法，將工業製成品組裝成服務、交付給用戶，並維持服務運作；通常要求達成穩定、成本、安全、效率等多個維度的目標(營運性)。從某種程度上來講，傳統維運需要依附於業務才能產生價值；很多公司，會把是否理解業務、作為運維工作者的主要考核之一(依附性)。

隨著雲端運算、雲端原生技術的普及，傳統的維運模式遇到了許多挑戰。比如，

• 企業使用公有雲後，IaaS/PaaS甚至SaaS基本上都服務化了，透過API即可取得；大量的運維建設工作、由雲端廠商幫忙完成了，例如硬體、系統、網路、資料庫、大數據等，原廠只需要保留少量的專業選型和整合能力(外包)
• 雲原生技術普及後，微服務架構和DevOps大範圍達成，之前由專業運維人員完成的操作、逐步交給業務研發自助完成，例如交付、變更、監控、容量等，維運職責被大量轉移到業務研發(轉移)
• 公有雲的專業聚集效應、以及雲原生的開源體系，提供了持續朝向好的工具化前景。工具化提升效率後，同一崗位所需的人工變少；工具化沉澱了專業能力，對操作人員的技術門檻越來越低；工具進化到自動化、智慧化後，機器就可以取代人工。平台對人工的替代，還在逐步深化(替代)

上面講到的，基礎設施外包給公有雲、雲原生之後運維職責轉移給業務研發、平台替代人工的專業性。面對這樣的趨勢、事實，維運從業人員需要做出一些轉型。

組織架構

先聊聊組織架構。長期看，雲端原生時代的公司組織形態，由下幾個部分構成：

最上面的終端用戶，是企業的甲方客戶、也是潛在的營利族。業務團隊，為終端使用者負責，角色包括了產品、商務、市場、行銷等。業務研發，直接為業務團隊服務，主要提供SaaS化的應用/服務。平台研發，則是為業務研發服務，提供各種各樣的PaaS化能力，對下封裝了雲端廠商。還會有一些跨功能組織，如成本營運FinOps、效率營運EP、行政團隊IT等等。

在新的組織架構中，大家最終的目標是各司其事、服務好終端用戶。業務團隊更重視業務價值，研發體系聚焦在服務品質。隨著資訊化技術的進步，目前由跨功能組織履行的職能、將逐步分解到平台研發團隊，組織協作的主要方式從人人協同、升級為平台自助。運維有了新的職位目標，即：運維的主旋律是管理平台、是資源&技術中台，不是橫向協同，運維要做高技術槓桿、賦能業務、助力企業提升經營效率。

技術架構

維運轉型，目標是：透過自助化的平台，向上層團隊、提供維運管理服務；本質是運維服務化OPaS(OP as Service)。依照內容差異，維運工作可分為物件管理、場景管理兩大類，如下圖所示。

物件管理是縱向模式，圍繞著維運物件、建置生命週期的管理平台。維運對象的分類，可以依照IaaS資源(機器、網路、儲存、雲端服務)、PaaS元件(資料庫、快取、MQ、網關)、SaaS應用(業務中台、業務應用)、服務框架(運行時、代碼框架、名字服務)等維度，不同公司的分類粒度不盡相同。每類物件都有獨立的管理平台(煙囪)，管理平台功能要涵蓋運維物件的完整生命週期，關鍵階段包括建模(元資料)、交付/變更、監控/度量、下線等，跟公有雲端的管理功能類似。物件管理的目標是，產出縱向完備的雲端產品、建成內部雲端平台ICSP。

場景管理是橫向模式，根據維運場景、納管多種維運物件的生命週期階段。維運場景的分類，包括交付/變更、監控/度量、多雲、成本等等，非常貼近業務研發的工作習慣、覆蓋少數高頻場景，不同公司大同小異。每類維運場景，有獨立的場景管理平台，如工單中心、資料中心、FinOps平台等。場景管理建立在物件管理之上，場景管理平台對維運物件的納管方式包括 統一模型、匯聚資料、編排管控API等。場景管理的目標是，提供自助化的業務管理能力、建成內部開發者平台IDP。

維運物件的產生方式，常見的有 自研、開源搭建、外採(公有雲)等。每種運維對象，又能再細分出不同的品類、集群、實例等，規模和複雜度空前巨大。只有維持維運對像管理特性的同構，才能大規模建設、低成本維持維運服務化，進而實現規模運維(技術槓桿效應)，因此運維對象的同構維持是整個運維架構的基本前提。

同構維持

同構維持，針對的是維運物件的管理特徵、不是所有特徵。同構維持，方式為：控制增量、修存量、防裂變。如下圖，透過平台做需求交付、來控增量，透過度量驅動治理、來修存量，透過規範服務框架、來防止技術體系的大範圍裂變；平台、度量嚴格遵循規範，規範也需要度量或平台的問題輸入來完善，三者相輔相成。規範，分為服務規範(對應服務治理)、管理規範(對應運維管控)等類型。

同構維持，依賴主責明確的組織分工。例如，維運專注於管理，剝離業務Toils、將之返還給業務研發，如現狀治理、警報響應、CD；業務研發專注於業務實現，剝離服務框架這部分非業務邏輯、將之交給基礎架構實現，如服務發現、流量控制；基礎架構專注於服務架構等中台能力，剝離管理職能、將之交給運維，如需求交付、變更管控等。文化影響也不能忽視，維運和架構會透過溝通引導的方式，輸出理念、培養使用者習慣，如對個人化需求不提供SLA承諾、對標準應用提供開箱即用的觀測能力等。

以維運對象同構維持為基礎，向上支撐維運服務化技術體系，這就形成了一套可持續的維運架構，如下圖。在目前的技術水準下，以自助平台為主的維運服務能解決70%的需求、剩餘30%仍需要人工，例如需求溝通、問題排除、結果驗收、政策合規等。隨著技術和理念的進步，相信維運服務化的佔比將進一步上升。

備註：本文中的服務框架，包括N年前的程式碼框架、程式碼庫，也包含目前流行的微服務治理，過渡階段、起名捉急。

轉型實踐

維運服務化OPaS

業務維，也有人叫應用運維，離雲原生最近、被衝擊的最大。除卻傳統的規範制定、流程建置、全域管理等跨團隊職責外，業務運作要朝向服務化的方向轉型，路徑如下圖：

• 第一，角色認知要轉變。把自己從依附於業務才能產生價值的營運角色，調整為具有獨立價值的維運服務提供者。角色轉換是關鍵

• 組織上，重新劃分主責。業務研發是應用主責方，維運不是應用主責方、也不是外掛式保姆，而是應用的管理能力提供方，業務研發使用運維服務、自助完成營運工作
• 機制上，重構評鑑體系。業務運作的績效，不再強綁定業務團隊和業務研發、而是更突顯運維服務化，做輕主觀評價、做重技術評價

• 第二，維運轉型四步驟。明確對象--> 抽象共通性--> 建構平台--> 實現規模運維
• 業務運作的對象，首先是應用(也稱為服務)，然後是應用的擴展場景(如業務視角、公司全局視角)
• 抽象共通性是難點，也是關鍵點。應用的數量大、技術堆疊複雜、個人化特徵非常多，要抽像出應用的管理共通性、避免陷入個人化case。嚴格來說，應用的共通性特徵才是運維管理的對象
• 建置平台指的是應用管理平台，規模運維是永續的終態
• 第三，應用對象維持同構。除去服務化能力建構外，維運人員的主要精力應投在同構維持上

維運服務化OPaS(OP as Service)，是我們轉型中期、從業務運作角度提出的目標，指出了大方向、但缺少路徑比較抽象；之後，OPaS逐漸被細化為ICSP IDP 的運維架構，適用範圍擴展到整個維運團隊，才算有了清晰的路徑和抓手。

超服務視角(業務運作)

除了服務化，業務運維還可以主導超服務視角(現已更名為場景)建置。雲端原生下的DevOps技術拼圖並不完整，只搞好了應用計算這一塊、其它方向存在能力空白，特別是向上的業務視角、部門視角、公司視角等，姑且稱為超服務視角。對於超服務視角，業務研發人員通常沒有能力、沒有動力主R(主責)；部門主管或架構師可以照顧到本部門，但受限於崗位職責、很難擴展到全局。反觀，超服務視角是傳統業務運維的老戰場，具備無與倫比的體驗、理解和認知優勢。業務維主導超服務視角建設，既能添補雲原生領域的空白、又能發揮業務運維的專業優勢、借勢轉型，會是雙贏的選擇，如下圖。

超服務視角，包括但不限於：

• 需求交付：工單中心，編排引擎、執行引擎
• 變更管控：五條軍規、集中管控，編排審核、執行審核、服務檢查、變更度量
• 觀察度量：聚合展示業務視角的觀測、度量數據，支援下鑽到應用粒度
• 多雲架構：貫穿整個技術體系的量測、治理、計畫、演練
• 成本管控：公司全部IT資源的計費、分攤、管控、最佳化，獨立為FinOps方向
• 規範制定：公司全局角度的維運規範制定、流程落地監督，避免小團隊煙囪式重複建設
• 等等

##雲原生下的DevOps技術拼圖，向下看也有能力空白，如針對CDN、物件儲存、MQ、EMR等基礎服務支援的並不完善，2022年還處在探索期；站在維運管理角度，只要被服務框架(鑑權、發現、通訊、感知、流控)輻射到了，就算被雲原生納管了。

洋蔥模型(雲端服務、中介軟體、大數據運維)

雲端服務、中介軟體、大數據等維運對象，技術堆疊收斂、專業聚焦。維運人員轉型實施時，可以依照洋蔥模型來。

第一階段，立足於資源交付，把原來的運維對象、轉變為資源實體，向上游交付有保障的服務功能、建立職位價值的底線
• 第二階段，投入大精力、建設管理平台，把資源實體的生命週期管理好、解放自己，平台要能ToC自助化、實現解耦
• 第三階段，深入到組件本身的專業領域，從架構、程式碼、效能、維運等各方面提升專業性。在做到這一步時，維運已經成為該領域的服務專家、而不僅僅是管理員

洋蔥模型，最早在資料庫、大數據、中間件等職位上被驗證，後來被拿過來用到雲端服務上、同樣成功了。例如，我司的雲端服務維運CloudOps團隊，就是依照洋蔥模型、來實施轉型的，具體如下，

這個團隊的對象就是各種雲端服務，分佈在騰訊、阿里、百度等幾家雲端廠商
• 兩年前，透過各種手工的方式，對外提供機器、儲存等資源，支撐了業務的快速發展(資源交付)
• #之後，我們開始建置多雲管理平台，管理機器、頻寬、物件儲存、CDN等雲端服務的生命週期。在這個過程中，CloudOps的管理平台成功轉型為公司內部的二級雲端服務供應商ICSP(平台能力)
• 接下來，我們將持續加強對公有雲產品的學習、認知、選型、演化推動等等，爭取在這個領域建立更多的專業性(組件本身)

運維中台(維運開發)

隨著業務運維、組件維運、系統維運(資源網路雲端服務)等角色開始參與開發工作，留給維運開發DevOps團隊的空間逐漸變少，轉型過程中出現了分工不清晰的狀況。參照組織結構、技術架構的升級預判，我們重新調整了OpDev的崗位定位：OpDev不應該是維運人員的開發外包或附庸、而應該有自己獨立提供的服務。於是乎，原有的維運平台被拆分成了兩部分，一部分偏重功能迭代無法重複使用、交給原使用方自己維護，例如IDP資源控制台、ICSP場景管理工具等；另一部分是公共功能、抽象化為維運中台由OpDev負責，如統一帳號IAM、工單編排引擎、監控指標擷取器等，如下圖。

維運中台是原運維平台的子集，不需要重新建構領域知識，需要重新做一下領域抽象建模、對程式碼品質要求也比較高(同基礎組件)，這正是OpDev童鞋的長處所在。隨著職責的聚化縮減，OpDev要同步瘦身、做到更高的槓桿。

一些教訓

簡單分享下我司的一些轉型教訓，包括

• 轉型和保守要折中。傳統運維轉型到服務提供方，既不會一蹴而就、也不會全員遷徙，總要有人留下來殿後(當前技術水平大概73開)。資源集中後，殿後人員會獲得更多的價值回報
• 研發能力區分梯度。從維運轉型到開發的童鞋能力參差不齊，要從業務需求迭代做起，要嚴控設計和驗收來保質量、要有意識的補齊工程理論，要配備精良的運維中台能力、保證底層乾淨
• 平台不是唯一選擇。平台是服務能力最有力的承接方式，但絕對不是唯一方式。組織、文化、規範、流程、平台，一樣都不能少(但轉移成本可能略高)
• 明確運維管理對象。維運、特別是應用運維，管理對像不是應用本身、而是應用的共性特徵；應用的共通性特徵越多，應用運維的價值才能越大(槓桿)
• 組織保障不容忽視。組織結構是第一生產力，CTO要有所作為、目標明確、清晰分工，如明確主責、設置獨立驗收機構、度量和治理循環等，這是維運轉型的組織保障
• 警惕純粹項目思維。維運還是要參與一些項目，短期內爆發價值、攬獲成就感，但也很容易人走茶涼、價值歸零；需要有意識的設計目標，在項目過程中的沉澱服務能力
• 預防比應急更有效。穩定性問題要在架構領域求解，預防比應急更有效。優先延長MTBF、其次是縮短MTTR

---

以下是附加內容，不是本文核心。

需求交付的演進

無論是公有雲，或是內部的K8S平台，都存在著大量的需求交付作業。這類ToM(ToManager)的交付平台，往往缺乏必要限制、只能對資深人士開放。

為了優化分工、提升效率，可以透過「工單編排審批」的方式、將維運管理面ToC(ToRD)；工作流程/工單本身會大量融入運維管理的最佳實踐，可以安全的開放給研發。這是維運能力服務化的重要方向。交付自助化的演化路徑如下：

目前看，從需求到技術方案的溝通環節，是比較難自助化或自動化的，需要將來更多的嘗試。

規模維運的邊際點

規模運維的經濟學本質是邊際成本，是「維運管理邊際成本遞減vs同構維持邊際成本遞增」的相互作用。如下圖，維運對象數量較少時，維運管理的成本佔大頭兒，例如建造平台、人工營運；維運對象數量變大後，同構維持構成主要成本；邊際轉折點，會受到技術、理念等環境因素的影響。

雲原生技術，降低了同構維持難度(促進同構維持曲線右移)、提升了運維服務化能力(促進維運管理曲線下移)，使得維運人員能夠以更低的成本、管理更多維運對象，因此顯著提升了生產效率。

以上是作業幫聶安：維運如何轉型，聽聽作業幫的OPaS思路的詳細內容。更多資訊請關注PHP中文網其他相關文章！