我寫(xiě)這個(gè)文章的動(dòng)機(jī)，是因?yàn)楹芏嗳藛?wèn)我，“一個(gè)全局的運(yùn)維體系應(yīng)該是什么樣的?”。這篇文章就給大家一個(gè)初步的回答。 

1.價(jià)值體系(value)

我在任何場(chǎng)合都在強(qiáng)調(diào)運(yùn)維價(jià)值/IT價(jià)值和用戶(hù)價(jià)值之間的關(guān)系，在精益運(yùn)維的分享中，我推導(dǎo)過(guò)，用戶(hù)價(jià)值可以通過(guò)IT價(jià)值相互轉(zhuǎn)換的。這種轉(zhuǎn)換的能力，大家現(xiàn)在都可以直接感受得到，根本原因是IT形態(tài)發(fā)生的變化。之前IT中的“I”是information，這個(gè)IT作用傳遞通過(guò)很多線下的渠道去接觸，這個(gè)信息系統(tǒng)是一個(gè)內(nèi)部的管理系統(tǒng)，稱(chēng)之為MIS(管理信息系統(tǒng))。現(xiàn)在IT中的“I”是Internet，是互聯(lián)網(wǎng)，互聯(lián)網(wǎng)本身就是客戶(hù)渠道，已經(jīng)把用戶(hù)和內(nèi)部的IT緊密的結(jié)合在一起了。

運(yùn)維的價(jià)值是什么?質(zhì)量、成本、效率、安全！這些價(jià)值觀的理解和落地有多深有多遠(yuǎn)，就是你對(duì)用戶(hù)價(jià)值的理解有多深又多遠(yuǎn)。

有些人說(shuō)你一直在倡導(dǎo)面向用戶(hù)的價(jià)值交付，好虛啊！說(shuō)實(shí)話，開(kāi)始我也覺(jué)得很虛，即使你的工作中參與了一些實(shí)際的價(jià)值創(chuàng)造，依然還是覺(jué)得很虛。比如我們做用戶(hù)頁(yè)面的體驗(yàn)優(yōu)化，這個(gè)是產(chǎn)品經(jīng)理技術(shù)化理解不了的，他們關(guān)注的是業(yè)務(wù)運(yùn)營(yíng)措施對(duì)用戶(hù)指標(biāo)的影響。其實(shí)技術(shù)同樣是有影響的，老外又來(lái)數(shù)據(jù)證明了，比如網(wǎng)頁(yè)打開(kāi)速度。來(lái)自以下的統(tǒng)計(jì)數(shù)據(jù)：

• 網(wǎng)頁(yè)速度加載超過(guò)3秒，會(huì)損失超過(guò)57%的用戶(hù)，57%的用戶(hù)在3秒后還沒(méi)有加載完，就會(huì)離開(kāi)，除非原因是她的電腦問(wèn)題或網(wǎng)速問(wèn)題。
• PV會(huì)減少11%，用戶(hù)滿(mǎn)意度降低16%，對(duì)話減少7%。
• 亞馬遜網(wǎng)站每延長(zhǎng)1秒的加載時(shí)間，一年就會(huì)減少16億美元的銷(xiāo)售額。

在騰訊的工作經(jīng)歷，嚴(yán)格把網(wǎng)頁(yè)打開(kāi)速度作為和一個(gè)核心的業(yè)務(wù)質(zhì)量考核指標(biāo)，對(duì)應(yīng)的直接是用戶(hù)體驗(yàn)。

我倒是建議大家找一本客戶(hù)關(guān)系管理的書(shū)，看看在客戶(hù)關(guān)系管理的每一個(gè)階段，如何把客戶(hù)創(chuàng)造價(jià)值給提煉出來(lái)的，虛可以變成實(shí)！

用戶(hù)價(jià)值內(nèi)嵌IT價(jià)值！

2.技術(shù)體系(technology)

技術(shù)體系，這個(gè)是對(duì)應(yīng)Dev技術(shù)架構(gòu)的體系，是和研發(fā)建立一致性架構(gòu)標(biāo)準(zhǔn)和服務(wù)化平臺(tái)標(biāo)準(zhǔn)，在避免架構(gòu)失控的同時(shí)，建立一致的架構(gòu)可運(yùn)維性。

這個(gè)地方的難點(diǎn)是很多企業(yè)缺少公共架構(gòu)組，或者說(shuō)有些企業(yè)有公共架構(gòu)組，而他不負(fù)責(zé)實(shí)現(xiàn)和落地，空談架構(gòu)了。我提出的解決辦法是：架構(gòu)組要背上應(yīng)用技術(shù)架構(gòu)服務(wù)化的指標(biāo)，無(wú)論是自上而下的PaaS平臺(tái)化也好，還是自底向上的組件服務(wù)化也好。注意，我講到的名詞是應(yīng)用技術(shù)架構(gòu)服務(wù)化，這個(gè)是要求架構(gòu)組把產(chǎn)生的技術(shù)架構(gòu)能力一定要應(yīng)用到業(yè)務(wù)技術(shù)架構(gòu)中去，空談架構(gòu)是最容易的了。

那Dev技術(shù)架構(gòu)體系和我運(yùn)維有什么關(guān)系呢?他決定了你維護(hù)成本的大與小，維護(hù)質(zhì)量的高與低，維護(hù)效率的快與慢！否則，你只盯著運(yùn)維平臺(tái)，認(rèn)為都是平臺(tái)的事情。

技術(shù)標(biāo)準(zhǔn)有了，業(yè)務(wù)的碎片便沒(méi)有了!

3.平臺(tái)體系(platform)

運(yùn)維的平臺(tái)體系，這個(gè)我在外面講得很多了。我從平臺(tái)的業(yè)務(wù)目標(biāo)也論證過(guò)，他應(yīng)該是什么樣子的;我從平臺(tái)的功能架構(gòu)上也拆解過(guò)(到三級(jí))講過(guò)運(yùn)維平臺(tái)應(yīng)該是長(zhǎng)成什么樣子的。

不過(guò)說(shuō)實(shí)話，對(duì)于很多人來(lái)說(shuō)，看到三級(jí)功能架構(gòu)容易被淹沒(méi)，很理解。所以我的建議重點(diǎn)，你就從cmdb+持續(xù)交付開(kāi)始好了，另外在IaaS層在增加幾個(gè)組件服務(wù)化，比如說(shuō)DNS/F5/操作系統(tǒng)安裝等等?？偟钠脚_(tái)抽象就是自動(dòng)化體系和數(shù)據(jù)化體系。自動(dòng)化體系以持續(xù)交付為核心，數(shù)據(jù)化體系以智能監(jiān)控和運(yùn)營(yíng)分析為核心。

平臺(tái)不是工具！

4.標(biāo)準(zhǔn)體系(standard)

運(yùn)維的標(biāo)準(zhǔn)很重要，并且很難建立統(tǒng)一的一套標(biāo)準(zhǔn)來(lái)適應(yīng)所有的企業(yè)，越往應(yīng)用端靠近，越難統(tǒng)一，但可以抽象統(tǒng)一。

在越靠近運(yùn)維側(cè)的基礎(chǔ)設(shè)施的標(biāo)準(zhǔn)制定上，運(yùn)維完全可以自主控制，像硬件機(jī)型的標(biāo)準(zhǔn)化。但偏向應(yīng)用的標(biāo)準(zhǔn)化上，需要有技術(shù)手段控制和效果呈現(xiàn)。技術(shù)手段的控制不僅僅是運(yùn)維平臺(tái)上，如應(yīng)用的持續(xù)交付平臺(tái)管理，還有技術(shù)體系中，如能力SDK化/組件服務(wù)化等等。技術(shù)手段的效果呈現(xiàn)，這個(gè)是偏向一種數(shù)據(jù)能力。我們都一直在討論日志如何標(biāo)準(zhǔn)化的問(wèn)題，其實(shí)是可以建立一些技術(shù)的標(biāo)準(zhǔn)的，把日志分成幾大類(lèi)，webserver日志/用戶(hù)端日志/應(yīng)用端日志/接口級(jí)日志等等。在定義日志標(biāo)準(zhǔn)的同時(shí)，提供sdk化的能力，最終把數(shù)據(jù)采集回來(lái)呈現(xiàn)的效果要平臺(tái)中看到，在通過(guò)數(shù)據(jù)去驅(qū)動(dòng)決策/驅(qū)動(dòng)優(yōu)化，如此便是閉環(huán)了。

那天在現(xiàn)場(chǎng)也有同學(xué)提問(wèn)這個(gè)問(wèn)題，關(guān)于標(biāo)準(zhǔn)執(zhí)行難的問(wèn)題，其實(shí)原因有兩方面，一個(gè)方面是標(biāo)準(zhǔn)的制定有問(wèn)題，可能有標(biāo)準(zhǔn)定的不對(duì)，或者是標(biāo)準(zhǔn)制定沒(méi)有考慮業(yè)務(wù)需求;另外一個(gè)方面標(biāo)準(zhǔn)缺少有效的技術(shù)手段控制。

標(biāo)準(zhǔn)的層次決定了控制力！

5.過(guò)程體系(process)

我的過(guò)程體系不是流程體系，流程體系是其中的一部分，他還有規(guī)范和制度的要求，目標(biāo)及其roadmap的設(shè)定等等。過(guò)程體系包括為了達(dá)到某種目標(biāo)，我們?cè)O(shè)定的執(zhí)行路徑是什么。這個(gè)路徑有兩個(gè)部分，一部分是基于產(chǎn)品的執(zhí)行路徑;另外一個(gè)是不基于產(chǎn)品的執(zhí)行路徑。

在數(shù)據(jù)化運(yùn)維里面，這個(gè)體現(xiàn)很明顯。在和大家針對(duì)我們的EasyOps產(chǎn)品溝通過(guò)程中，我一直說(shuō)我們的運(yùn)營(yíng)分析平臺(tái)提供的產(chǎn)品，如果不加入運(yùn)維制度和規(guī)范的要求，那就是一個(gè)無(wú)用功能。另外標(biāo)準(zhǔn)化的落地推廣，如果是有平臺(tái)來(lái)承載，他也需要一個(gè)過(guò)程。這就是我理解的基于產(chǎn)品的執(zhí)行路徑。

不基于產(chǎn)品的執(zhí)行路徑，大到你的運(yùn)維目標(biāo)設(shè)定和分解下來(lái)的roadmap，比如說(shuō)運(yùn)維平臺(tái)體系的構(gòu)建;小到你的運(yùn)維流程，比如說(shuō)事件流程、資源池管理流程等等。這個(gè)地方會(huì)沉淀一些制度和規(guī)范要求出來(lái)的，安全的規(guī)范/事件的規(guī)范/配置管理的規(guī)范/發(fā)布的規(guī)范/環(huán)境管理的規(guī)范等等。大家不要害怕規(guī)范，規(guī)范沉淀-》平臺(tái)落地-》規(guī)范改進(jìn)，這個(gè)是目的哈。

運(yùn)維過(guò)程不是運(yùn)維流程!