第1期央請井老闆發表了很多有趣的觀點，有人留言說是維運勸退指南，哈哈，這一期的嘉賓，觀點會有不同，請大家抱著開放的心態，聽百家之言，自己做職業、人生規劃。所謂兼聽則明，偏信則暗，若只聽自己順耳的，大機率不會有深度思考碰撞，憾事也。
這裡是接地氣、有高度的《運維百家講壇》第 2 期，開講！
本期我們邀請的是作業幫的運維負責人聶安，聶安是資深業界老砲，先後履職於阿里、小米、滴滴、作業幫，有10多年的維運/研發/管理經驗。
互聯網運維，先後經歷了純手工、標準化、平台化、數智化等幾個階段，如下圖。其中，DevOps是科技驅動的組織變革、非專業變革。
從運維的發展歷史，我們可以看到幾個特點：
學習某個領域的發展歷史，能夠讓我們以史為鑑、順勢而為。
在傳統的維運模式中，服務對象基本上可以分割成三層。最底層是硬體基礎設施IaaS，主要是運算、網路、儲存組成；中間層是軟體基礎設施，包括了作業系統、虛擬化技術、程式碼架構、中介軟體等；最上層是業務層，主要是應用服務。
傳統運維的職責是，透過一系列的流程、技術、方法，將工業製成品組裝成服務、交付給用戶，並維持服務運作；通常要求達成穩定、成本、安全、效率等多個維度的目標(營運性)。從某種程度上來講，傳統維運需要依附於業務才能產生價值；很多公司，會把是否理解業務、作為運維工作者的主要考核之一(依附性)。
隨著雲端運算、雲端原生技術的普及，傳統的維運模式遇到了許多挑戰。比如，
上面講到的，基礎設施外包給公有雲、雲原生之後運維職責轉移給業務研發、平台替代人工的專業性。面對這樣的趨勢、事實，維運從業人員需要做出一些轉型。
先聊聊組織架構。長期看，雲端原生時代的公司組織形態，由下幾個部分構成：
最上面的終端用戶，是企業的甲方客戶、也是潛在的營利族。業務團隊，為終端使用者負責，角色包括了產品、商務、市場、行銷等。業務研發，直接為業務團隊服務，主要提供SaaS化的應用/服務。平台研發，則是為業務研發服務，提供各種各樣的PaaS化能力，對下封裝了雲端廠商。還會有一些跨功能組織，如成本營運FinOps、效率營運EP、行政團隊IT等等。
在新的組織架構中，大家最終的目標是各司其事、服務好終端用戶。業務團隊更重視業務價值，研發體系聚焦在服務品質。隨著資訊化技術的進步，目前由跨功能組織履行的職能、將逐步分解到平台研發團隊，組織協作的主要方式從人人協同、升級為平台自助。運維有了新的職位目標，即：運維的主旋律是管理平台、是資源&技術中台，不是橫向協同，運維要做高技術槓桿、賦能業務、助力企業提升經營效率。
維運轉型，目標是：透過自助化的平台，向上層團隊、提供維運管理服務；本質是運維服務化OPaS(OP as Service)。依照內容差異，維運工作可分為物件管理、場景管理兩大類，如下圖所示。
物件管理是縱向模式，圍繞著維運物件、建置生命週期的管理平台。維運對象的分類，可以依照IaaS資源(機器、網路、儲存、雲端服務)、PaaS元件(資料庫、快取、MQ、網關)、SaaS應用(業務中台、業務應用)、服務框架(運行時、代碼框架、名字服務)等維度，不同公司的分類粒度不盡相同。每類物件都有獨立的管理平台(煙囪)，管理平台功能要涵蓋運維物件的完整生命週期，關鍵階段包括建模(元資料)、交付/變更、監控/度量、下線等，跟公有雲端的管理功能類似。物件管理的目標是，產出縱向完備的雲端產品、建成內部雲端平台ICSP。
場景管理是橫向模式，根據維運場景、納管多種維運物件的生命週期階段。維運場景的分類，包括交付/變更、監控/度量、多雲、成本等等，非常貼近業務研發的工作習慣、覆蓋少數高頻場景，不同公司大同小異。每類維運場景，有獨立的場景管理平台，如工單中心、資料中心、FinOps平台等。場景管理建立在物件管理之上，場景管理平台對維運物件的納管方式包括 統一模型、匯聚資料、編排管控API等。場景管理的目標是，提供自助化的業務管理能力、建成內部開發者平台IDP。
維運物件的產生方式，常見的有 自研、開源搭建、外採(公有雲)等。每種運維對象，又能再細分出不同的品類、集群、實例等，規模和複雜度空前巨大。只有維持維運對像管理特性的同構，才能大規模建設、低成本維持維運服務化，進而實現規模運維(技術槓桿效應)，因此運維對象的同構維持是整個運維架構的基本前提。
同構維持，針對的是維運物件的管理特徵、不是所有特徵。同構維持，方式為：控制增量、修存量、防裂變。如下圖，透過平台做需求交付、來控增量，透過度量驅動治理、來修存量，透過規範服務框架、來防止技術體系的大範圍裂變；平台、度量嚴格遵循規範，規範也需要度量或平台的問題輸入來完善，三者相輔相成。規範，分為服務規範(對應服務治理)、管理規範(對應運維管控)等類型。
同構維持，依賴主責明確的組織分工。例如，維運專注於管理，剝離業務Toils、將之返還給業務研發，如現狀治理、警報響應、CD；業務研發專注於業務實現，剝離服務框架這部分非業務邏輯、將之交給基礎架構實現，如服務發現、流量控制；基礎架構專注於服務架構等中台能力，剝離管理職能、將之交給運維，如需求交付、變更管控等。文化影響也不能忽視，維運和架構會透過溝通引導的方式，輸出理念、培養使用者習慣，如對個人化需求不提供SLA承諾、對標準應用提供開箱即用的觀測能力等。
以維運對象同構維持為基礎，向上支撐維運服務化技術體系，這就形成了一套可持續的維運架構，如下圖。在目前的技術水準下，以自助平台為主的維運服務能解決70%的需求、剩餘30%仍需要人工，例如需求溝通、問題排除、結果驗收、政策合規等。隨著技術和理念的進步，相信維運服務化的佔比將進一步上升。
備註：本文中的服務框架，包括N年前的程式碼框架、程式碼庫，也包含目前流行的微服務治理，過渡階段、起名捉急。
業務維，也有人叫應用運維，離雲原生最近、被衝擊的最大。除卻傳統的規範制定、流程建置、全域管理等跨團隊職責外，業務運作要朝向服務化的方向轉型，路徑如下圖：
維運服務化OPaS(OP as Service)，是我們轉型中期、從業務運作角度提出的目標，指出了大方向、但缺少路徑比較抽象；之後，OPaS逐漸被細化為ICSP IDP 的運維架構，適用範圍擴展到整個維運團隊，才算有了清晰的路徑和抓手。
除了服務化，業務運維還可以主導超服務視角(現已更名為場景)建置。雲端原生下的DevOps技術拼圖並不完整，只搞好了應用計算這一塊、其它方向存在能力空白，特別是向上的業務視角、部門視角、公司視角等，姑且稱為超服務視角。對於超服務視角，業務研發人員通常沒有能力、沒有動力主R(主責)；部門主管或架構師可以照顧到本部門，但受限於崗位職責、很難擴展到全局。反觀，超服務視角是傳統業務運維的老戰場，具備無與倫比的體驗、理解和認知優勢。業務維主導超服務視角建設，既能添補雲原生領域的空白、又能發揮業務運維的專業優勢、借勢轉型，會是雙贏的選擇，如下圖。
超服務視角，包括但不限於：
維運中台是原運維平台的子集，不需要重新建構領域知識，需要重新做一下領域抽象建模、對程式碼品質要求也比較高(同基礎組件)，這正是OpDev童鞋的長處所在。隨著職責的聚化縮減，OpDev要同步瘦身、做到更高的槓桿。
簡單分享下我司的一些轉型教訓，包括
以下是附加內容，不是本文核心。
無論是公有雲，或是內部的K8S平台，都存在著大量的需求交付作業。這類ToM(ToManager)的交付平台，往往缺乏必要限制、只能對資深人士開放。
為了優化分工、提升效率，可以透過「工單編排審批」的方式、將維運管理面ToC(ToRD)；工作流程/工單本身會大量融入運維管理的最佳實踐，可以安全的開放給研發。這是維運能力服務化的重要方向。交付自助化的演化路徑如下：
目前看，從需求到技術方案的溝通環節，是比較難自助化或自動化的，需要將來更多的嘗試。
規模運維的經濟學本質是邊際成本，是「維運管理邊際成本遞減vs同構維持邊際成本遞增」的相互作用。如下圖，維運對象數量較少時，維運管理的成本佔大頭兒，例如建造平台、人工營運；維運對象數量變大後，同構維持構成主要成本；邊際轉折點，會受到技術、理念等環境因素的影響。
雲原生技術，降低了同構維持難度(促進同構維持曲線右移)、提升了運維服務化能力(促進維運管理曲線下移)，使得維運人員能夠以更低的成本、管理更多維運對象，因此顯著提升了生產效率。
以上是作業幫聶安：維運如何轉型，聽聽作業幫的OPaS思路的詳細內容。更多資訊請關注PHP中文網其他相關文章！
