[[161889]]

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

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

　　前言

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

　　一、從運維角色來看

　　從一個系統(tǒng)的完整運維棧來說，存在很多角色?；A(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)用運維的運維平臺的一體化能力不斷增強(比如說騰訊織云/藍鯨)，此時就對底層的運維平臺能力開放性要求越來越高。

　　當然這個地方我建議分成如下三個階段：

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

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

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

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

　　二、從運維場景來看

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

　　從用戶需求產(chǎn)生到研發(fā)/測試/運維，這是一個完整的持續(xù)交付鏈。從研發(fā)側(cè)有一個實施/實現(xià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ù)運營分析框架之上(持續(xù)反饋，類似PDCA中的C)，任何滯后與非實時的數(shù)據(jù)價值都會大大縮水，數(shù)據(jù)化的運營思路能不斷驅(qū)動產(chǎn)品的質(zhì)量提升。此時我們謹記：運維即IT運營。

　　三、從域模型的角度來看

　　域是一種業(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è)計上是一致的。

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

　　1.應(yīng)用域。是一個面向應(yīng)用的信息管理，是構(gòu)成運維系統(tǒng)場景化的核心元數(shù)據(jù)，在所有的運維系統(tǒng)中都應(yīng)該在這個維度上建立起管理關(guān)聯(lián)。最合理的表達是業(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ù)當作一種附加資源來看待。

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

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

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

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

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

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

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

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

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

　　四、從IT運營價值來看

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

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

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

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