第1期央請井老板發(fā)表了很多有趣的觀點(diǎn)，有人留言說是運(yùn)維勸退指南，哈哈，這一期的嘉賓，觀點(diǎn)會有不同，請大家抱著開放的心態(tài)，聽百家之言，自己做職業(yè)、人生規(guī)劃。所謂兼聽則明，偏信則暗，如果只聽自己順耳的，大概率不會有深度思考碰撞，憾事也。

這里是接地氣、有高度的《運(yùn)維百家講壇》第 2 期，開講！

嘉賓介紹

本期我們邀請的是作業(yè)幫的運(yùn)維負(fù)責(zé)人聶安，聶安是資深行業(yè)老炮，先后履職于阿里、小米、滴滴、作業(yè)幫，有10多年的運(yùn)維/研發(fā)/管理經(jīng)驗(yàn)。

要點(diǎn)簡述

• 傳統(tǒng)運(yùn)維，職責(zé)是將工業(yè)制成品組裝成服務(wù)、交付給用戶，并維持服務(wù)運(yùn)轉(zhuǎn)；特點(diǎn)是強(qiáng)依附于業(yè)務(wù)
• 領(lǐng)域危機(jī)，云原生時(shí)代公有云大量使用、微服務(wù)架構(gòu)和DevOps真實(shí)達(dá)成、工具體系持續(xù)繁榮，傳統(tǒng)運(yùn)維的職責(zé)不斷被外包、轉(zhuǎn)移、替代，出現(xiàn)了領(lǐng)域危機(jī)
• 組織結(jié)構(gòu)，協(xié)作方式從人人協(xié)同、逐漸升級為平臺自助，運(yùn)維的主旋律從橫向協(xié)同、轉(zhuǎn)變?yōu)榉?wù)產(chǎn)品和技術(shù)中臺
• 運(yùn)維轉(zhuǎn)型，技術(shù)上通過自助化的平臺、對外提供運(yùn)維服務(wù)能力OPaS(OP as Service)，分成對象、場景兩層；底層對象做到同構(gòu)維持，就構(gòu)成了一套可持續(xù)的運(yùn)維架構(gòu)
• 業(yè)務(wù)運(yùn)維，服務(wù)化轉(zhuǎn)型的核心是角色認(rèn)知，運(yùn)維人要把自己從依附于業(yè)務(wù)的運(yùn)營角色、調(diào)整為獨(dú)立的運(yùn)維服務(wù)提供方；在超服務(wù)視角上，業(yè)務(wù)運(yùn)維大有可為
• 組件運(yùn)維，掌控組件本身、比純運(yùn)維管理更進(jìn)一步，遵循洋蔥模型，即立足于資源交付、建設(shè)管理平臺、再深入到組件自身的專業(yè)領(lǐng)域
• 運(yùn)維開發(fā)，剝離掉重復(fù)的平臺迭代工作，聚焦到公共的運(yùn)維中臺，做專技術(shù)、做高杠桿

運(yùn)維階段

互聯(lián)網(wǎng)運(yùn)維，先后經(jīng)歷了純手工、標(biāo)準(zhǔn)化、平臺化、數(shù)智化等幾個(gè)階段，如下圖。其中，DevOps是技術(shù)驅(qū)動(dòng)的組織變革、非專業(yè)變革。

從運(yùn)維的發(fā)展歷史，我們可以看到幾個(gè)特點(diǎn)：

• 繼承性。新階段往往繼承、發(fā)揚(yáng)老階段的優(yōu)秀經(jīng)驗(yàn)，又會在理念、技術(shù)、組織上有所創(chuàng)新

• 比如，平臺化繼承、強(qiáng)化了標(biāo)準(zhǔn)化階段的成果，數(shù)智化繼承了平臺化的成果、同時(shí)引入大數(shù)據(jù)技術(shù)

• 職責(zé)轉(zhuǎn)移。DevOps是運(yùn)維管理模式的分水嶺，DevOps之后的運(yùn)維
• 一方面，沿著運(yùn)維專業(yè)化的方向繼續(xù)推進(jìn)，對更高量級的運(yùn)維對象、保持同構(gòu)管理的能力
• 另一方面，則強(qiáng)調(diào)運(yùn)維研發(fā)融合，運(yùn)維職責(zé)逐步轉(zhuǎn)移到業(yè)務(wù)研發(fā)

學(xué)習(xí)某個(gè)領(lǐng)域的發(fā)展歷史，能夠讓我們以史為鑒、順勢而為。

傳統(tǒng)運(yùn)維

在傳統(tǒng)的運(yùn)維模式中，服務(wù)對象基本可以劃分為三層。最底層是硬件基礎(chǔ)設(shè)施IaaS，主要是計(jì)算、網(wǎng)絡(luò)、存儲構(gòu)成；中間層是軟件基礎(chǔ)設(shè)施，包括了操作系統(tǒng)、虛擬化技術(shù)、代碼框架、中間件等；最上層是業(yè)務(wù)層，主要是應(yīng)用服務(wù)。

傳統(tǒng)運(yùn)維的職責(zé)是，通過一系列的流程、技術(shù)、方法，將工業(yè)制成品組裝成服務(wù)、交付給用戶，并維持服務(wù)運(yùn)轉(zhuǎn)；通常要求達(dá)成穩(wěn)定、成本、安全、效率等多個(gè)維度的目標(biāo)(運(yùn)營性)。從某種程度上來講，傳統(tǒng)運(yùn)維需要依附于業(yè)務(wù)才能產(chǎn)生價(jià)值；很多公司，會把是否理解業(yè)務(wù)、作為運(yùn)維工作者的主要考核之一(依附性)。

隨著云計(jì)算、云原生技術(shù)的普及，傳統(tǒng)的運(yùn)維模式遇到了很多挑戰(zhàn)。比如，

• 企業(yè)使用公有云后，IaaS/PaaS甚至SaaS基本都服務(wù)化了，通過API即可獲??；大量的運(yùn)維建設(shè)工作、由云廠商幫忙完成了，比如硬件、系統(tǒng)、網(wǎng)絡(luò)、數(shù)據(jù)庫、大數(shù)據(jù)等，原廠只需要保留少量的專業(yè)選型和集成能力(外包)
• 云原生技術(shù)普及后，微服務(wù)架構(gòu)和DevOps大范圍達(dá)成，之前由專業(yè)運(yùn)維人員完成的操作、逐步交給業(yè)務(wù)研發(fā)自助完成，比如交付、變更、監(jiān)控、容量等，運(yùn)維職責(zé)被大量轉(zhuǎn)移到業(yè)務(wù)研發(fā)(轉(zhuǎn)移)
• 公有云的專業(yè)聚集效應(yīng)、以及云原生的開源體系，提供了持續(xù)向好的工具化前景。工具化提升效率后，同一崗位需要的人工變少；工具化沉淀了專業(yè)能力，對操作人員的技術(shù)門檻越來越低；工具進(jìn)化到自動(dòng)化、智能化后，機(jī)器就可以替代人工。平臺對人工的替代，還在逐步深化(替代)

上面講到的，基礎(chǔ)設(shè)施外包給公有云、云原生之后運(yùn)維職責(zé)轉(zhuǎn)移給業(yè)務(wù)研發(fā)、平臺替代人工的專業(yè)性。面對這樣的趨勢、事實(shí)，運(yùn)維從業(yè)者需要做出一些轉(zhuǎn)型。

組織結(jié)構(gòu)

首先聊聊組織結(jié)構(gòu)。長期看，云原生時(shí)代的公司組織形態(tài)，由如下幾部分構(gòu)成：

最上面的終端用戶，是企業(yè)的甲方客戶、也是潛在的營利人群。業(yè)務(wù)團(tuán)隊(duì)，為終端用戶負(fù)責(zé)，角色包括了產(chǎn)品、商務(wù)、市場、營銷等。業(yè)務(wù)研發(fā)，直接為業(yè)務(wù)團(tuán)隊(duì)服務(wù)，主要是提供SaaS化的應(yīng)用/服務(wù)。平臺研發(fā)，則是為業(yè)務(wù)研發(fā)服務(wù)，提供各種各樣的PaaS化能力，對下封裝了云廠商。還會有一些跨功能組織，如成本運(yùn)營FinOps、效率運(yùn)營EP、行政團(tuán)隊(duì)IT等等。

在新的組織結(jié)構(gòu)中，大家最終的目標(biāo)是各司其事、服務(wù)好終端用戶。業(yè)務(wù)團(tuán)隊(duì)更關(guān)注業(yè)務(wù)價(jià)值，研發(fā)體系聚焦在服務(wù)質(zhì)量。隨著信息化技術(shù)的進(jìn)步，當(dāng)前由跨功能組織履行的職能、將逐步分解到平臺研發(fā)團(tuán)隊(duì)，組織協(xié)作的主要方式從人人協(xié)同、升級為平臺自助。運(yùn)維有了新的崗位目標(biāo)，即：運(yùn)維的主旋律是管理平臺、是資源&技術(shù)中臺，不是橫向協(xié)同，運(yùn)維要做高技術(shù)杠桿、賦能業(yè)務(wù)、助力企業(yè)提升經(jīng)營效率。

技術(shù)架構(gòu)

運(yùn)維轉(zhuǎn)型，目標(biāo)是：通過自助化的平臺，向上層團(tuán)隊(duì)、提供運(yùn)維管理服務(wù)；本質(zhì)是運(yùn)維服務(wù)化OPaS(OP as Service)。按照內(nèi)容差異，運(yùn)維工作可以分為對象管理、場景管理兩大類，如下圖所示。

對象管理是縱向模式，圍繞運(yùn)維對象、建設(shè)生命周期的管理平臺。運(yùn)維對象的分類，可以按照IaaS資源(機(jī)器、網(wǎng)絡(luò)、存儲、云服務(wù))、PaaS組件(數(shù)據(jù)庫、緩存、MQ、網(wǎng)關(guān))、SaaS應(yīng)用(業(yè)務(wù)中臺、業(yè)務(wù)應(yīng)用)、服務(wù)框架(運(yùn)行時(shí)、代碼框架、名字服務(wù))等維度，不同公司的分類粒度不盡相同。每類對象都有獨(dú)立的管理平臺(煙囪)，管理平臺功能要覆蓋運(yùn)維對象的完整生命周期，關(guān)鍵階段包括 建模(元數(shù)據(jù))、交付/變更、監(jiān)控/度量、下線等，跟公有云的管理功能類似。對象管理的目標(biāo)是，產(chǎn)出縱向完備的云產(chǎn)品、建成內(nèi)部云平臺ICSP。

場景管理是橫向模式，根據(jù)運(yùn)維場景、納管多種運(yùn)維對象的生命周期階段。運(yùn)維場景的分類，包括交付/變更、監(jiān)控/度量、多云、成本等等，非常貼近業(yè)務(wù)研發(fā)的工作習(xí)慣、覆蓋少數(shù)高頻場景，不同公司大同小異。每類運(yùn)維場景，有獨(dú)立的場景管理平臺，如工單中心、數(shù)據(jù)中心、FinOps平臺等。場景管理建立在對象管理之上，場景管理平臺對運(yùn)維對象的納管方式包括 統(tǒng)一模型、匯聚數(shù)據(jù)、編排管控API等。場景管理的目標(biāo)是，提供自助化的業(yè)務(wù)管理能力、建成內(nèi)部開發(fā)者平臺IDP。

運(yùn)維對象的產(chǎn)生方式，常見的有 自研、開源搭建、外采(公有云)等。每種運(yùn)維對象，又能再細(xì)分出不同的品類、集群、實(shí)例等，規(guī)模和復(fù)雜度空前巨大。只有維持運(yùn)維對象管理特征的同構(gòu)，才能大規(guī)模建設(shè)、低成本維持運(yùn)維服務(wù)化，進(jìn)而實(shí)現(xiàn)規(guī)模運(yùn)維(技術(shù)杠桿效應(yīng))，因此運(yùn)維對象的同構(gòu)維持是整個(gè)運(yùn)維架構(gòu)的基本前提。

同構(gòu)維持

同構(gòu)維持，針對的是運(yùn)維對象的管理特征、不是所有特征。同構(gòu)維持，方式是：控增量、修存量、防裂變。如下圖，通過平臺做需求交付、來控增量，通過度量驅(qū)動(dòng)治理、來修存量，通過規(guī)范服務(wù)框架、來防止技術(shù)體系的大范圍裂變；平臺、度量嚴(yán)格遵循規(guī)范，規(guī)范也需要度量或平臺的問題輸入來完善，三者相輔相成。規(guī)范，分為服務(wù)規(guī)范(對應(yīng)服務(wù)治理)、管理規(guī)范(對應(yīng)運(yùn)維管控)等類型。

同構(gòu)維持，依賴主責(zé)明確的組織分工。比如，運(yùn)維專注于管理，剝離業(yè)務(wù)Toils、將之返還給業(yè)務(wù)研發(fā)，如現(xiàn)狀治理、報(bào)警響應(yīng)、CD；業(yè)務(wù)研發(fā)專注于業(yè)務(wù)實(shí)現(xiàn)，剝離服務(wù)框架這部分非業(yè)務(wù)邏輯、將之交給基礎(chǔ)架構(gòu)實(shí)現(xiàn)，如服務(wù)發(fā)現(xiàn)、流量控制；基礎(chǔ)架構(gòu)專注于服務(wù)框架等中臺能力，剝離管理職能、將之交給運(yùn)維，如需求交付、變更管控等。文化影響也不能忽視，運(yùn)維和架構(gòu)會通過溝通引導(dǎo)的方式，輸出理念、培養(yǎng)用戶習(xí)慣，如對個(gè)性化需求不提供SLA承諾、對標(biāo)準(zhǔn)應(yīng)用提供開箱即用的觀測能力等。

以運(yùn)維對象同構(gòu)維持為基礎(chǔ)，向上支撐運(yùn)維服務(wù)化技術(shù)體系，這就形成了一套可持續(xù)的運(yùn)維架構(gòu)，如下圖。在當(dāng)前的技術(shù)水平下，以自助平臺為主的運(yùn)維服務(wù)能解決70%的需求、剩余30%仍需要人工，比如需求溝通、問題排查、結(jié)果驗(yàn)收、政策合規(guī)等。隨著技術(shù)和理念的進(jìn)步，相信運(yùn)維服務(wù)化的占比將進(jìn)一步上升。

備注：本文中的服務(wù)框架，既包括N年前的代碼框架、代碼庫，也包括當(dāng)前流行的微服務(wù)治理，過渡階段、起名捉急。

轉(zhuǎn)型實(shí)踐

運(yùn)維服務(wù)化OPaS

業(yè)務(wù)運(yùn)維，也有人叫應(yīng)用運(yùn)維，離云原生最近、被沖擊的最大。除卻傳統(tǒng)的規(guī)范制定、流程建設(shè)、全局管理等跨團(tuán)隊(duì)職責(zé)外，業(yè)務(wù)運(yùn)維要朝著服務(wù)化的方向轉(zhuǎn)型，路徑如下圖：

• 第一，角色認(rèn)知要轉(zhuǎn)變。把自己從依附于業(yè)務(wù)才能產(chǎn)生價(jià)值的運(yùn)營角色，調(diào)整為具有獨(dú)立價(jià)值的運(yùn)維服務(wù)提供方。角色轉(zhuǎn)變是關(guān)鍵

• 組織上，重新劃分主責(zé)。業(yè)務(wù)研發(fā)是應(yīng)用主責(zé)方，運(yùn)維不是應(yīng)用主責(zé)方、也不是外掛式保姆，而是應(yīng)用的管理能力提供方，業(yè)務(wù)研發(fā)使用運(yùn)維服務(wù)、自助完成運(yùn)營工作
• 機(jī)制上，重構(gòu)評價(jià)體系。業(yè)務(wù)運(yùn)維崗位的績效，不再強(qiáng)綁定業(yè)務(wù)團(tuán)隊(duì)和業(yè)務(wù)研發(fā)、而是更突出運(yùn)維服務(wù)化，做輕主觀評價(jià)、做重技術(shù)評價(jià)

• 第二，運(yùn)維轉(zhuǎn)型四步走。明確對象 --> 抽象共性 --> 建設(shè)平臺 --> 實(shí)現(xiàn)規(guī)模運(yùn)維
• 業(yè)務(wù)運(yùn)維的對象，首先是應(yīng)用(也稱為服務(wù))，然后是應(yīng)用的擴(kuò)展場景(如業(yè)務(wù)視角、公司全局視角)
• 抽象共性是難點(diǎn)，也是關(guān)鍵點(diǎn)。應(yīng)用的數(shù)量大、技術(shù)棧復(fù)雜、個(gè)性化特征非常多，要抽象出應(yīng)用的管理共性、避免陷入個(gè)性化case。嚴(yán)格來說，應(yīng)用的共性特征才是運(yùn)維管理的對象
• 建設(shè)平臺指的是應(yīng)用管理平臺，規(guī)模運(yùn)維是一個(gè)可持續(xù)的終態(tài)
• 第三，應(yīng)用對象維持同構(gòu)。除去服務(wù)化能力建設(shè)外，運(yùn)維人員的主要精力應(yīng)該投在同構(gòu)維持上

運(yùn)維服務(wù)化OPaS(OP as Service)，是我們轉(zhuǎn)型中期、從業(yè)務(wù)運(yùn)維角度提出的目標(biāo)，指出了大方向、但缺少路徑比較抽象；之后，OPaS逐漸被細(xì)化為 ICSP+IDP 的運(yùn)維架構(gòu)，適用范圍擴(kuò)展到整個(gè)運(yùn)維團(tuán)隊(duì)，才算有了清晰的路徑和抓手。

超服務(wù)視角(業(yè)務(wù)運(yùn)維)

除了服務(wù)化，業(yè)務(wù)運(yùn)維還可以主導(dǎo)超服務(wù)視角(現(xiàn)已更名為場景)建設(shè)。云原生下的DevOps技術(shù)拼圖并不完整，只搞好了應(yīng)用+計(jì)算這一塊、其它方向存在能力空白，特別是向上的業(yè)務(wù)視角、部門視角、公司視角等，姑且稱為超服務(wù)視角。對于超服務(wù)視角，業(yè)務(wù)研發(fā)人員通常沒有能力、沒有動(dòng)力主R(主責(zé))；部門主管或架構(gòu)師可以照顧到本部門，但受限于崗位職責(zé)、很難擴(kuò)展到全局。反觀，超服務(wù)視角是傳統(tǒng)業(yè)務(wù)運(yùn)維的老戰(zhàn)場，具備無與倫比的體驗(yàn)、理解和認(rèn)知優(yōu)勢。業(yè)務(wù)運(yùn)維主導(dǎo)超服務(wù)視角建設(shè)，既能添補(bǔ)云原生領(lǐng)域的空白、又能發(fā)揮業(yè)務(wù)運(yùn)維的專業(yè)優(yōu)勢、借勢轉(zhuǎn)型，會是一個(gè)雙贏的選擇，如下圖。

超服務(wù)視角，包括但不限于：

• 需求交付：工單中心，編排引擎、執(zhí)行引擎
• 變更管控：五條軍規(guī)、集中管控，編排審批、執(zhí)行審批、服務(wù)檢查、變更度量
• 觀察度量：聚合展示業(yè)務(wù)視角的觀測、度量數(shù)據(jù)，支持下鉆到應(yīng)用粒度
• 多云架構(gòu)：貫穿整個(gè)技術(shù)體系的度量、治理、預(yù)案、演練
• 成本管控：公司全部IT資源的計(jì)費(fèi)、分?jǐn)?、管控、?yōu)化，獨(dú)立為FinOps方向
• 規(guī)范制定：公司全局角度的運(yùn)維規(guī)范制定、流程落地監(jiān)督，避免小團(tuán)隊(duì)煙囪式重復(fù)建設(shè)
• 等等

云原生下的DevOps技術(shù)拼圖，向下看也有能力空白，如針對CDN、對象存儲、MQ、EMR等基礎(chǔ)服務(wù)支持的并不完善，2022年還處在探索期；站在運(yùn)維管理角度，只要被服務(wù)框架(鑒權(quán)、發(fā)現(xiàn)、通信、感知、流控)輻射到了，就算被云原生納管了。

洋蔥模型(云服務(wù)、中間件、大數(shù)據(jù)運(yùn)維)

云服務(wù)、中間件、大數(shù)據(jù)等運(yùn)維對象，技術(shù)棧收斂、專業(yè)聚焦。運(yùn)維人員轉(zhuǎn)型實(shí)施時(shí)，可以按照洋蔥模型來。

• 第一階段，立足于資源交付，把原來的運(yùn)維對象、轉(zhuǎn)變?yōu)橘Y源實(shí)體，向上游交付有保障的服務(wù)功能、建立崗位價(jià)值的底線
• 第二階段，投入大精力、建設(shè)管理平臺，把資源實(shí)體的生命周期管理好、解放自己，平臺要能ToC自助化、實(shí)現(xiàn)解耦
• 第三階段，深入到組件自身的專業(yè)領(lǐng)域，從架構(gòu)、代碼、性能、運(yùn)維等方方面面提升專業(yè)性。做到這一步時(shí)，運(yùn)維已經(jīng)成為該領(lǐng)域的服務(wù)專家、而不僅僅是管理員

洋蔥模型，最早在數(shù)據(jù)庫、大數(shù)據(jù)、中間件等崗位上被驗(yàn)證，后來被拿過來用到云服務(wù)上、同樣成功了。比如，我司的云服務(wù)運(yùn)維CloudOps團(tuán)隊(duì)，就是按照洋蔥模型、來實(shí)施轉(zhuǎn)型的，具體如下，

• 這個(gè)團(tuán)隊(duì)的對象就是各種云服務(wù)，分布在騰訊、阿里、百度等幾家云廠商
• 兩年前，通過各種手工的方式，對外提供機(jī)器、存儲等資源，支撐了業(yè)務(wù)的快速發(fā)展(資源交付)
• 之后，我們開始建設(shè)多云管理平臺，管理機(jī)器、帶寬、對象存儲、CDN等云服務(wù)的生命周期。在這個(gè)過程中，CloudOps的管理平臺成功轉(zhuǎn)型為公司內(nèi)部的二級云服務(wù)提供商ICSP(平臺能力)
• 接下來，我們還會不斷加強(qiáng)對公有云產(chǎn)品的學(xué)習(xí)、認(rèn)知、選型、演化推動(dòng)等等，爭取在這個(gè)領(lǐng)域建立更多的專業(yè)性(組件自身)

運(yùn)維中臺(運(yùn)維開發(fā))

隨著業(yè)務(wù)運(yùn)維、組件運(yùn)維、系統(tǒng)運(yùn)維(資源網(wǎng)絡(luò)云服務(wù))等角色開始參與開發(fā)工作，留給運(yùn)維開發(fā)DevOps團(tuán)隊(duì)的空間逐漸變少，轉(zhuǎn)型過程中出現(xiàn)了分工不清晰的情況。參照組織結(jié)構(gòu)、技術(shù)架構(gòu)的升級預(yù)判，我們重新調(diào)整了OpDev的崗位定位：OpDev不應(yīng)該是運(yùn)維人員的開發(fā)外包或附庸、而應(yīng)該有自己獨(dú)立提供的服務(wù)。于是乎，原有的運(yùn)維平臺被拆分成了兩部分，一部分偏重功能迭代無法復(fù)用、交給原使用方自己維護(hù)，比如IDP資源控制臺、ICSP場景管理工具等；另一部分是公共功能、抽象為運(yùn)維中臺由OpDev負(fù)責(zé)，如統(tǒng)一賬號IAM、工單編排引擎、監(jiān)控指標(biāo)采集器等，如下圖。

運(yùn)維中臺是原運(yùn)維平臺的子集，不需要重新構(gòu)建領(lǐng)域知識，需要重新做一下領(lǐng)域抽象建模、對代碼質(zhì)量要求也比較高(同基礎(chǔ)組件)，這正是OpDev童鞋的長處所在。隨著職責(zé)的聚化縮減，OpDev要同步瘦身、做到更高的杠桿。

一些教訓(xùn)

簡單分享下我司的一些轉(zhuǎn)型教訓(xùn)，包括

• 轉(zhuǎn)型和保守要折中。傳統(tǒng)運(yùn)維轉(zhuǎn)型到服務(wù)提供方，既不會一蹴而就、也不會全員遷徙，總要有人留下來殿后(當(dāng)前技術(shù)水平大概73開)。資源集中后，殿后人員會獲得更多的價(jià)值回報(bào)
• 研發(fā)能力區(qū)分梯度。從運(yùn)維轉(zhuǎn)型到開發(fā)的童鞋能力參差不齊，要從業(yè)務(wù)需求迭代做起，要嚴(yán)控設(shè)計(jì)和驗(yàn)收來保質(zhì)量、要有意識的補(bǔ)齊工程理論，要配備精良的運(yùn)維中臺能力、保證底層干凈
• 平臺不是唯一選擇。平臺是服務(wù)能力最有力的承接方式，但絕對不是唯一方式。組織、文化、規(guī)范、流程、平臺，一樣都不能少(但轉(zhuǎn)移成本可能略高)
• 明確運(yùn)維管理對象。運(yùn)維、特別是應(yīng)用運(yùn)維，管理對象不是應(yīng)用本身、而是應(yīng)用的共性特征；應(yīng)用的共性特征越多，應(yīng)用運(yùn)維的價(jià)值才能越大(杠桿)
• 組織保障不容忽視。組織結(jié)構(gòu)是第一生產(chǎn)力，CTO要有所作為、目標(biāo)明確、清晰分工，如明確主責(zé)、設(shè)置獨(dú)立驗(yàn)收機(jī)構(gòu)、度量和治理循環(huán)等，這是運(yùn)維轉(zhuǎn)型的組織保障
• 警惕純粹項(xiàng)目思維。運(yùn)維還是要參與一些項(xiàng)目，短期內(nèi)爆發(fā)價(jià)值、攬獲成就感，但也很容易人走茶涼、價(jià)值歸零；需要有意識的設(shè)計(jì)目標(biāo)，在項(xiàng)目過程中的沉淀服務(wù)能力
• 預(yù)防比應(yīng)急更有效。穩(wěn)定性問題要在架構(gòu)領(lǐng)域求解，預(yù)防比應(yīng)急更有效。優(yōu)先延長MTBF、其次才是縮短MTTR

以下是附加內(nèi)容，不是本文核心。

需求交付的演進(jìn)

無論是公有云，還是內(nèi)部的K8S平臺，都存在著大量的需求交付操作。這類ToM(ToManager)的交付平臺，往往缺少必要約束、只能對資深人士開放。

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

目前看，從需求到技術(shù)方案的溝通環(huán)節(jié)，是比較難自助化或者自動(dòng)化的，需要將來更多的嘗試。

規(guī)模運(yùn)維的邊際點(diǎn)

規(guī)模運(yùn)維的經(jīng)濟(jì)學(xué)本質(zhì)是邊際成本，是「運(yùn)維管理邊際成本遞減vs同構(gòu)維持邊際成本遞增」的相互作用。如下圖，運(yùn)維對象數(shù)量較少時(shí)，運(yùn)維管理的成本占大頭兒，比如建設(shè)平臺、人工運(yùn)營；運(yùn)維對象數(shù)量變大后，同構(gòu)維持構(gòu)成主要成本；邊際轉(zhuǎn)折點(diǎn)，會受到技術(shù)、理念等環(huán)境因素的影響。

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