實(shí)現(xiàn)一個(gè)運(yùn)維產(chǎn)品的閉環(huán)，比碎片式的產(chǎn)品建設(shè)更有意義。

拋開我最近創(chuàng)業(yè)對(duì)這一問(wèn)題的必要性思考，回歸到一個(gè)企業(yè)內(nèi)運(yùn)維團(tuán)隊(duì)本身，個(gè)人覺(jué)得也需要思考這個(gè)命題。一個(gè)完善的運(yùn)維平臺(tái)才能做到對(duì)業(yè)務(wù)的運(yùn)營(yíng)有效支撐。個(gè)人把產(chǎn)品的水平閉環(huán)思考分解成如下幾個(gè)問(wèn)題，從這些角度下去，發(fā)現(xiàn)很容易找到該問(wèn)題本質(zhì)。

前言

當(dāng)我們建設(shè)一個(gè)運(yùn)維或者業(yè)務(wù)系統(tǒng)的時(shí)候，一定要記得軟件工程方法作用性，比如說(shuō)系統(tǒng)中的角色(Role)、系統(tǒng)的Use Case(注意不是測(cè)試用例)、領(lǐng)域模型(Domain Model)等等。

一、從運(yùn)維角色來(lái)看

從一個(gè)系統(tǒng)的完整運(yùn)維棧來(lái)說(shuō)，存在很多角色?；A(chǔ)設(shè)施層涉及網(wǎng)絡(luò)管理員/服務(wù)器管理員，再往上服務(wù)器資源交付之后，OS層有系統(tǒng)管理員或者基于基礎(chǔ)資源構(gòu)建的OS云平臺(tái)管理員。從應(yīng)用或服務(wù)的角度看過(guò)去，在OS之上承載的公共組件服務(wù)或者業(yè)務(wù)的應(yīng)用服務(wù)等等。

系統(tǒng)建設(shè)開始的時(shí)候，可以按照角色獨(dú)立建設(shè)，我理解這是“分而治之”的策略。但隨著后面應(yīng)用運(yùn)維的運(yùn)維平臺(tái)的一體化能力不斷增強(qiáng)(比如說(shuō)騰訊織云/藍(lán)鯨)，此時(shí)就對(duì)底層的運(yùn)維平臺(tái)能力開放性要求越來(lái)越高。

當(dāng)然這個(gè)地方我建議分成如下三個(gè)階段：

1.獨(dú)立的按照核心角色需求建設(shè)運(yùn)維平臺(tái)。比如說(shuō)GSLB管理平臺(tái)，優(yōu)先考慮域名管理員的管理需求，如域名管理/Zone管理/View管理/IP地址庫(kù)管理等等。

2.某些場(chǎng)景開放給應(yīng)用運(yùn)維平臺(tái)人工處理。依然以DNS管理平臺(tái)為例，這個(gè)地方需要打破“DNS管理平臺(tái)是DNS管理員的平臺(tái)”這一認(rèn)知。逐漸把能力開放出來(lái)，釋放管理員的管理壓力。比如說(shuō)把域名的管理權(quán)限開放給業(yè)務(wù)運(yùn)維角色，畢竟這一需求是因?yàn)闃I(yè)務(wù)而起，但Zone/View/IP地址的管理權(quán)限依然要收斂在核心dns管理員角色這邊。

3.某些場(chǎng)景開放給應(yīng)用運(yùn)維平臺(tái)自動(dòng)化處理，即API化。第二個(gè)階段運(yùn)行逐漸成熟之后，最重要的是理念已經(jīng)達(dá)成一致，此時(shí)可以考慮能力API開放，控制好接口的權(quán)限。上層驅(qū)動(dòng)底層能力服務(wù)化，進(jìn)一步打破“我的事情我做主”的職責(zé)邊界，從而才能實(shí)現(xiàn)“DevOps自動(dòng)化”的目標(biāo)。

其實(shí)這些角色的需求在不同的平臺(tái)中都有存在的，只不過(guò)是多與少的問(wèn)題，底層的服務(wù)化能力越強(qiáng)，上層的自動(dòng)化能力也就愈強(qiáng)；上層的能力整體性越強(qiáng)，越來(lái)依賴和驅(qū)動(dòng)底層的能力服務(wù)化。

二、從運(yùn)維場(chǎng)景來(lái)看

場(chǎng)景是驅(qū)動(dòng)運(yùn)維閉環(huán)的最好方式，核心的維度就是持續(xù)交付。持續(xù)交付是一種PDCA式的運(yùn)維過(guò)程，資源交付/服務(wù)交付/應(yīng)用交付等都可以構(gòu)成一體化的場(chǎng)景吧！拿應(yīng)用交付舉例來(lái)說(shuō)：

從用戶需求產(chǎn)生到研發(fā)/測(cè)試/運(yùn)維，這是一個(gè)完整的持續(xù)交付鏈。從研發(fā)側(cè)有一個(gè)實(shí)施/實(shí)現(xiàn)過(guò)程，在運(yùn)維側(cè)有個(gè)監(jiān)控能力。在對(duì)接的能力上，一方面是用戶的需求隊(duì)列；Dev和Ops的對(duì)接是一個(gè)Ops的需求隊(duì)列，從持續(xù)集成上來(lái)看就是統(tǒng)一構(gòu)建庫(kù)。

從以上的圖可以看出來(lái)，這個(gè)能力是閉環(huán)的，持續(xù)迭代的(類似PDCA環(huán))，這也是持續(xù)交付的典型特征。持續(xù)交付的另外一個(gè)典型特征：把后續(xù)的產(chǎn)品能力優(yōu)化直接體現(xiàn)在實(shí)時(shí)的數(shù)據(jù)運(yùn)營(yíng)分析框架之上(持續(xù)反饋，類似PDCA中的C)，任何滯后與非實(shí)時(shí)的數(shù)據(jù)價(jià)值都會(huì)大大縮水，數(shù)據(jù)化的運(yùn)營(yíng)思路能不斷驅(qū)動(dòng)產(chǎn)品的質(zhì)量提升。此時(shí)我們謹(jǐn)記：運(yùn)維即IT運(yùn)營(yíng)。

三、從域模型的角度來(lái)看

域是一種業(yè)務(wù)域名，降低系統(tǒng)復(fù)雜理解的第一步，不是考慮具體的數(shù)據(jù)和行為實(shí)現(xiàn)。復(fù)雜的業(yè)務(wù)系統(tǒng)如同電信的BOSS系統(tǒng)，也分成了幾個(gè)核心域，如：客戶域/事件域/產(chǎn)品域/營(yíng)銷域/賬務(wù)域/地址域等等。這樣能確保不同的BOSS子系統(tǒng)(如CRM/計(jì)費(fèi)系統(tǒng))等，都可以確保在底層數(shù)據(jù)模型和行為設(shè)計(jì)上是一致的。

以下是我對(duì)運(yùn)維領(lǐng)域模型的一個(gè)分類，如下：

1.應(yīng)用域。是一個(gè)面向應(yīng)用的信息管理，是構(gòu)成運(yùn)維系統(tǒng)場(chǎng)景化的核心元數(shù)據(jù)，在所有的運(yùn)維系統(tǒng)中都應(yīng)該在這個(gè)維度上建立起管理關(guān)聯(lián)。最合理的表達(dá)是業(yè)務(wù)之間的內(nèi)在邏輯關(guān)系，業(yè)界通行的做法是資源tag化。

2.資源域。資源是一個(gè)泛化的概念，傳統(tǒng)的資源范圍包含了網(wǎng)絡(luò)資源/服務(wù)器資源等物理資源，但隨著云計(jì)算的逐漸普及，此時(shí)應(yīng)該把資源的概念延伸到一些服務(wù)上，比如說(shuō)mysql是一種rds存儲(chǔ)資源；分布式hadoop是一種分布式存儲(chǔ)及計(jì)算資源。這個(gè)也符合Heroku關(guān)于12factor中一個(gè)描述，把后端服務(wù)當(dāng)作一種附加資源來(lái)看待。

3.運(yùn)維服務(wù)域。資源及服務(wù)資源的管理都需要抽象成服務(wù)，服務(wù)化的管理能力以平臺(tái)化/可視化管理為基礎(chǔ)的。mysql有mysql管理平臺(tái)，服務(wù)器有服務(wù)器的管理平臺(tái)，cache有cache管理平臺(tái)，這些管理平臺(tái)能力起來(lái)之后，進(jìn)一步服務(wù)化其能力。另外一種服務(wù)化能力，是面向應(yīng)用的場(chǎng)景化服務(wù)能力，比如說(shuō)業(yè)務(wù)的擴(kuò)容/遷移等服務(wù)能力。

4.配置工具域。以配置管理為基礎(chǔ)，但是這個(gè)內(nèi)容和范疇也需要延伸，它的能力不僅僅是作用在OS對(duì)象本身，還能過(guò)痛過(guò)這個(gè)平臺(tái)能力去操作外部的資源(通過(guò)外部服務(wù)實(shí)現(xiàn)的)。

以上的域名能構(gòu)成一個(gè)全自動(dòng)化平臺(tái)的能力體系。

5.監(jiān)控域。無(wú)論是資源還是服務(wù)，都需要很強(qiáng)的監(jiān)控能力，他是能過(guò)直接表達(dá)資源和服務(wù)的狀態(tài)，通過(guò)這些狀態(tài)進(jìn)一步表達(dá)業(yè)務(wù)/應(yīng)用的健康狀況，目標(biāo)是確保業(yè)務(wù)高可用。

6.事件域。無(wú)論是作業(yè)事件/監(jiān)控事件，在分布式系統(tǒng)中都存在著很多的事件，這些事件可以放在統(tǒng)一的事件中心中紀(jì)錄和存儲(chǔ)，注意和ITIL事件系統(tǒng)不一樣。事件集中管理/關(guān)聯(lián)，在告警分析的場(chǎng)景下是能過(guò)有分析價(jià)值的。

7.運(yùn)營(yíng)分析。它不能構(gòu)成一個(gè)域，只能稱為一種場(chǎng)景。基于很多運(yùn)營(yíng)場(chǎng)景，場(chǎng)景化的數(shù)據(jù)分析和應(yīng)用，通過(guò)數(shù)據(jù)來(lái)驅(qū)動(dòng)運(yùn)維優(yōu)化，類似運(yùn)營(yíng)商的經(jīng)營(yíng)分析系統(tǒng)。

8.用戶域。這個(gè)域名很簡(jiǎn)單，把DevOps各類角色管理起來(lái)，可以和域帳號(hào)對(duì)接。

基于這些域可以構(gòu)建不同的功能子系統(tǒng)，比如說(shuō)作業(yè)管理/運(yùn)維調(diào)度系統(tǒng)/持續(xù)部署/監(jiān)控平臺(tái)/CMDB等等。

當(dāng)然這個(gè)是一個(gè)運(yùn)維內(nèi)部系統(tǒng)，其實(shí)如果是一個(gè)外部運(yùn)維SaaS平臺(tái)的話，還有客戶域，計(jì)費(fèi)域、賬務(wù)域等等。不過(guò)，在SaaS模型下，計(jì)費(fèi)和帳務(wù)模型可以簡(jiǎn)單，我們當(dāng)前采用的就是“Host.月”的計(jì)費(fèi)模型，這樣的話確保平臺(tái)更簡(jiǎn)單。

四、從IT運(yùn)營(yíng)價(jià)值來(lái)看

角色+場(chǎng)景能導(dǎo)出對(duì)某一類資源的管理功能需求，從而反映IT對(duì)業(yè)務(wù)運(yùn)營(yíng)的能力支撐。

一方面：運(yùn)維平臺(tái)的能力必須要向上開放，滿足運(yùn)營(yíng)的快速交付。沒(méi)有理由在構(gòu)筑藩籬，這是傳統(tǒng)維護(hù)思維的核心障礙。曾經(jīng)一個(gè)團(tuán)隊(duì)就不愿意開放，導(dǎo)致系統(tǒng)的建設(shè)七零八落，也就無(wú)法滿足DevOps快速交付的能力要求。

另一方面：運(yùn)營(yíng)的精細(xì)化能力要在數(shù)據(jù)上體現(xiàn)出來(lái)，滿足運(yùn)營(yíng)的持續(xù)改進(jìn)。比如說(shuō)對(duì)業(yè)務(wù)質(zhì)量的優(yōu)化，質(zhì)量模型，數(shù)據(jù)的來(lái)源，數(shù)據(jù)的實(shí)時(shí)性等等都需要；性能的優(yōu)化，就需要運(yùn)營(yíng)系統(tǒng)能夠采集所有的接口性能數(shù)據(jù)；某個(gè)頁(yè)面的體驗(yàn)優(yōu)化，就需要把頁(yè)面的性能指標(biāo)完整的采集下來(lái)。精細(xì)化/實(shí)時(shí)/端到端的數(shù)據(jù)采集/處理/分析體系是運(yùn)營(yíng)價(jià)值的核心部分。

堅(jiān)持產(chǎn)品的垂直與水平閉環(huán)體系，才是一個(gè)做出一個(gè)真正好用的運(yùn)維平臺(tái)！

【編輯推薦】