第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同構維持邊際成本遞增」的相互作用。如下圖，運維對象數量較少時，運維管理的成本占大頭兒，比如建設平臺、人工運營；運維對象數量變大后，同構維持構成主要成本；邊際轉折點，會受到技術、理念等環境因素的影響。

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