我寫這個文章的動機，是因為很多人問我，“一個全局的運維體系應(yīng)該是什么樣的?”。這篇文章就給大家一個初步的回答。 

1.價值體系(value)

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

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

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

• 網(wǎng)頁速度加載超過3秒，會損失超過57%的用戶，57%的用戶在3秒后還沒有加載完，就會離開，除非原因是她的電腦問題或網(wǎng)速問題。
• PV會減少11%，用戶滿意度降低16%，對話減少7%。
• 亞馬遜網(wǎng)站每延長1秒的加載時間，一年就會減少16億美元的銷售額。

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

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

用戶價值內(nèi)嵌IT價值！

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

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

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

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

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

3.平臺體系(platform)

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

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

平臺不是工具！

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

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

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

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

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

5.過程體系(process)

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

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

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

運維過程不是運維流程!