運維百家講壇第2期:作業幫聶安 - 運維如何轉型,聽聽作業幫的OPaS思路

語言: CN / TW / HK

運維百家講壇,通過採訪和約稿的方式,請運維領域老炮輸出深刻洞見,共同碰撞,以期形成一些先進的共識,推動行業更好得前進。

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

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