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

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

前言

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

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

從一個系統(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è)澜公，我理解這是“分而治之”的策略。但隨著后面應(yīng)用運(yùn)維的運(yùn)維平臺的一體化能力不斷增強(qiáng)(比如說騰訊織云/藍(lán)鯨)喇肋，此時就對底層的運(yùn)維平臺能力開放性要求越來越高坟乾。

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

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

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

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

其實這些角色的需求在不同的平臺中都有存在的，只不過是多與少的問題膜钓，底層的服務(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)維糯彬，這是一個完整的持續(xù)交付鏈凭语。從研發(fā)側(cè)有一個實施/實現(xiàn)過程，在運(yùn)維側(cè)有個監(jiān)控能力撩扒。在對接的能力上似扔，一方面是用戶的需求隊列；Dev和Ops的對接是一個Ops的需求隊列搓谆，從持續(xù)集成上來看就是統(tǒng)一構(gòu)建庫炒辉。

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

三、從域模型的角度來看

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

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

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

2.資源域渤涌。資源是一個泛化的概念，傳統(tǒng)的資源范圍包含了網(wǎng)絡(luò)資源/服務(wù)器資源等物理資源把还，但隨著云計算的逐漸普及实蓬，此時應(yīng)該把資源的概念延伸到一些服務(wù)上茸俭，比如說mysql是一種rds存儲資源；分布式hadoop是一種分布式存儲及計算資源安皱。這個也符合Heroku關(guān)于12factor中一個描述调鬓，把后端服務(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ǔ)蕉世，但是這個內(nèi)容和范疇也需要延伸蔼紧，它的能力不僅僅是作用在OS對象本身，還能過痛過這個平臺能力去操作外部的資源(通過外部服務(wù)實現(xiàn)的)狠轻。

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

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)盗迟，在告警分析的場景下是能過有分析價值的。

7.運(yùn)營分析熙含。它不能構(gòu)成一個域罚缕，只能稱為一種場景≡蹙玻基于很多運(yùn)營場景怕磨，場景化的數(shù)據(jù)分析和應(yīng)用喂饥，通過數(shù)據(jù)來驅(qū)動運(yùn)維優(yōu)化，類似運(yùn)營商的經(jīng)營分析系統(tǒng)肠鲫。

8.用戶域员帮。這個域名很簡單，把DevOps各類角色管理起來导饲，可以和域帳號對接捞高。

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

當(dāng)然這個是一個運(yùn)維內(nèi)部系統(tǒng)硝岗，其實如果是一個外部運(yùn)維SaaS平臺的話，還有客戶域袋毙，計費域型檀、賬務(wù)域等等。不過听盖，在SaaS模型下胀溺，計費和帳務(wù)模型可以簡單，我們當(dāng)前采用的就是“Host.月”的計費模型皆看，這樣的話確保平臺更簡單仓坞。

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

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

一方面：運(yùn)維平臺的能力必須要向上開放，滿足運(yùn)營的快速交付毛雇。沒有理由在構(gòu)筑藩籬嫉称，這是傳統(tǒng)維護(hù)思維的核心障礙。曾經(jīng)一個團(tuán)隊就不愿意開放灵疮，導(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ù)的實時性等等都需要剩胁；性能的優(yōu)化诉植，就需要運(yùn)營系統(tǒng)能夠采集所有的接口性能數(shù)據(jù)；某個頁面的體驗優(yōu)化昵观，就需要把頁面的性能指標(biāo)完整的采集下來晾腔。精細(xì)化/實時/端到端的數(shù)據(jù)采集/處理/分析體系是運(yùn)營價值的核心部分舌稀。

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