[[161889]]

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

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

　　前言

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

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

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

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

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

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

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

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

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

　　二、從運(yùn)維場景來看

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

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

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

　　三、從域模型的角度來看

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

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

　　1.應(yīng)用域。是一個(gè)面向應(yīng)用的信息管理，是構(gòu)成運(yùn)維系統(tǒ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ù)上，比如說mysql是一種rds存儲資源；分布式hadoop是一種分布式存儲及計(jì)算資源。這個(gè)也符合Heroku關(guān)于12factor中一個(gè)描述，把后端服務(wù)當(dāng)作一種附加資源來看待。

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

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

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

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

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

　　7.運(yùn)營分析。它不能構(gòu)成一個(gè)域，只能稱為一種場景?；诤芏噙\(yùn)營場景，場景化的數(shù)據(jù)分析和應(yīng)用，通過數(shù)據(jù)來驅(qū)動運(yùn)維優(yōu)化，類似運(yùn)營商的經(jīng)營分析系統(tǒng)。

　　8.用戶域。這個(gè)域名很簡單，把DevOps各類角色管理起來，可以和域帳號對接。

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

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

　　四、從IT運(yùn)營價(jià)值來看

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

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

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

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