重構CMDB，避免運維之恥

• CMDB，幾乎是每一個運維人都繞不過去的字眼，但又是不少運維人的痛，由於CMDB不多有成功的，所以我也把它稱之爲運維人的恥辱。
• 那麼到底錯在哪兒了？該如何去重構它？
• 今天我想從個人角度來和你們探討一下業務失敗的緣由，基於失敗再去看重構的邏輯，也許會成功。

從失敗中尋找成功的邏輯，每每是最有效的，那咱們就來逐一看看：

一、組織的設計問題

我必須把核心緣由歸結成這一條，不少公司把CMDB的建設責任放到基礎設施建設部門，由他們主導承建。最後他們梳理出來的核心邏輯是面向基礎設施資源的管理，你在他們的CMDB中都能看到以下菜單，AIX主機是哪些，中間件有哪些，大小機有哪些，Oracle有哪些等等，這些都是和公司的IT運維部門組織結構是一一對應的。組織的隔離是CMDB失敗的核心緣由！

這個裏面能看到一些CMDB管理能力錯位，拿兩個例子來講一下：

A、中間件。

一直搞不明白爲何中間件要做爲一個單獨的對象來管理，「皮之不存，毛將附焉」。沒有主機，沒有業務這個皮，哪來的中間件。把他單獨拿出來管理，純粹就是爲了知足組織的一個管理視角。歷來沒人想過，這是主機上的一個資源對象，應該是一個附屬資源，其實對他的信息管理和機器上的CPU、網卡同樣。

B、進程對象，好比說數據庫

這個是另一種管理錯位，是專業的管理平臺應該去履行的管理職責，結果放到CMDB平臺中了，而後CMDB管理了大量的動態屬性，好比主備關係，服務狀態等等，太複雜了。最簡單的看，從主機的角度來講，他就是服務器上運行的一個進程而已。管它死活幹嗎，那是監控系統作的事情，管它狀態幹嗎，那是**組件管理平臺乾的事情。

二、Excel是最好的管理工具

當組織隔離，不可以造成有效的信息互動以後，Excel更是之上的一次痛擊。可能從外圍思考，爲何不去解決現實層面上的問題，而選擇了Excel？Excel很簡單，特別是IT服務對象很少的狀況下，幾百個仍是可以應對的。我就拿個Excel記錄一下，而後svn上小組內共享一下就行了，反正個人信息也就我使用，別的小組也不用（組織的隔離性）。對它的思考，仍是要回歸的第一點，使用Excel是結果，但我比較反對Excel作法。每次建設cmdb的第一個目標，就說要消滅掉Excel。

三、去簡就繁

這個是從產品自己說的，我看了幾個開源的產品，oneCMDB和iTOP（建議你們都體驗一下），界面都是複雜的要命，還有商業的產品（具體哪家不說了）

首先必需要解決產品易用性的問題，易用性不夠，你怎麼讓能用戶有使用的慾望呢，如下是來自於UC作的CMDB系統產品截圖：

 

其次還有一種信息複雜帶來的易用性降低的問題。我看不少產品都管理了一些無光的信息，信息的管理歸類也是有考究的，沒歸類好，用戶又被淹沒了。

 

 

拿主機來講，維護其核心須要的信息就行了，好比說固資編號、所在機房的位置信息、廠家信息、上架信息、進程端口信息、維護信息等等。這些信息都是有運維場景的，好比說位置信息+固資信息在駐場須要操做的時候有用；上架信息對於過保維修有用；進程端口對於監控有用；維護信息在運維申請資源的時候有空，誰也不想用常常故障的機器吧；主機狀態位是用來作資源池管理+監控使用的。

 

不少配置的變動都是由於場景變動引發的，好比說機器搬遷致使機器的物理位置信息發生變化，那就搞一個機器搬遷流程吧；機器上的業務下線了，但進程信息沒有清理，那是業務下線流程的問題….

五、和應用沒有關聯，更別提場景關聯了，就更別提主動場景了

頗有意思的現象：客戶的監控系統中監控的應用主機信息都是該系統中自行維護的，歷來沒有考慮從CMDB獲取。也就是由於CMDB是另一家產品，爲啥呢？若是資源和應用關聯起來了，而且由他來驅動監控，這個維護的動力是否是不同呢？

哪怕是你的CMDB系統可以支撐一下我上圖中的工具盒子的能力，CMDB維護的動力不至於那麼糟糕，它的數據也不至於那麼糟糕。以前和人探討過是先有操做系統安裝把信息寫到CMDB仍是先有CMDB的信息而後再有操做系統安裝的動做？固然是後者了。事實上在服務器採購分配上機架的時候，其實全部的信息都分配完畢，此時入庫，就能夠啓動遠程自動安裝了。

其實還有不少緣由，好比說物理世界和邏輯世界是獨立的，物理世界發生的過程無法直接映射到CMDB系統中（有些配置信息須要進入固件中）；CMDB的對象Owner沒有或者過多（Owner很累）；過度強調CMDB的基線做用，引入對比（動態變化的環境基線的做用應該降低）；誇大CMDB自動發現的做用等等。

說了不少的失敗的緣由，接下來就須要討論一下解決方案了，既然講重構，老王的重構邏輯是什麼樣的？

第1、重構你的CMDB思惟

建議你們不要把CMDB稱之爲CMDB了，那叫什麼，就叫資源管理吧。爲何你要從更名字開始？總是叫CMDB，你們都回到過去的思惟上了，道不清說不明的，或者互不相讓。

一切皆資源！！！一切皆資源！！！一切皆資源！！！

從基礎設施的對象來講，計算資源、存儲資源、網絡資源、IP資源、機房資源等等，在CMDB的管理上，把你的資源對象羅列出來，關係梳理清楚，就能夠構建其能力管理了。

從上層的業務資源來講，創建以應用爲中心的資源管理邏輯，把 一切都當作應用的資源來看待。好比說Host，應用包、權限、RDS服務、cache資源等等。

老王如今作的產品把CMDB一分爲二，底層的基礎資源層CMDB能夠不要。在不要的狀況下，我能夠構建上層應用的信息管理平臺（業務CMDB），它能夠獨自構造場景來驅動上層運維。如下是優維EasyOps產品截圖：

 

隨着應用相關的一些支撐資源雲化以後，面向應用的資源管理能力要不斷增強。我常常和你們舉的一個例子，是IaaS公有云平臺中的Mysql實力已是一個資源對象：實例域名。如何實現的對他們的管理，你只能把他當成一個附加資源來進行管理，不是麼？

此時有意義的事情來了，你管理的業務資源信息越豐富，你的自動化驅動能力就越強。別再繞回去了，說讓自動化來幫我維護這些信息。相輔相成、互相促進的事情，就不應設定前提，而是關注那個上升式的過程。

第2、重構你的CMDB方法

標準的CMDB方法是教你如何迭代進行一個CMDB項目，這個沒有錯誤，但我會指出有些方法是你必需要堅持的，不然你的系統會面臨失敗。

A、放棄你的excel

excel是一個CMDB失敗的佐證，必須去除它的存在，不少時候你們說是系統很差用引發的，但個人觀察是你們的習慣引發的。改變習慣很難，有些時候須要藉助組織自上而下的力量。沒有集中的平臺依賴，平臺是沒有人去驅動優化的。

B、構建CMDB的微內核和彈性CMDB模型庫

CMDB的微內核很小，其實你只須要應用、集羣和主機三個概念就能夠構建起一個CMDB，基於這三個概念，能夠不斷去向周邊擴散。應用能夠往用戶側的概念不斷靠攏，造成業務的概念。主機能夠在其關聯或者擁有的資源上不斷去擴展，好比說主機所在的機櫃、機櫃所在的機房、機器關聯的交換機等等。

 

這個微內核，我想是能夠適用一切場景了，但還不夠呢，如何保證這個模型對全部企業作到落地可適配的？這個時候就是彈性模型的做用了。彈性模型由對象的彈性和對象CI及其關聯的彈性定義實現的。簡單的理解，你就是實現了一個業務數據庫的可視化定義，下圖是對象的彈性定義：

 

下圖是對象的CI及其關聯關係的彈性定義：

 

C、構建「自動發現+標準流程+人工維護」的CMDB數據庫

自動發現是下降維護成本的一種有效方式，但我認爲確保一個CMDB庫信息的有效性，仍是須要其餘幾個手段，標準化的流程和人工維護。

標準化的流程是運維資源信息變動的場景化流程梳理，好比說機房搬遷，服務器搬遷，服務器下架等等，這個流程須要識別出來，並肯定相應的CMDB配置項狀態變動過程。

人工維護，在有些流程沒有構建起來的狀況下，則須要經過人工變動的能力把CMDB信息維護準確，好比說主機所屬負責人變動，這個時候不建議流程了，能夠經過人工直接變動完成。那如何確保維護準確呢？經過外圍系統來控制，好比說告警信息，若是負責人沒有變動告警是直達原有負責人，致使告警不許確。

D、CMDB是持續迭代的過程

貪大求全求細、一步到位都是它的反義詞，建議以微內核和核心需求爲中心，快速實現，而後在此基礎上快速迭代。隨着底層雲平臺的出現，對CMDB都提出了新的要求，咱們都知道，每個IaaS都有一個本身的CMDB，如何實現對IaaS雲的CMDB管理？Docker和其餘相似服務化平臺出現以後，又如何實現這類資源的管理？

E、邊界、邊界、邊界

CMDB實現拓撲是爲了故障定位，但不能實現故障定位；CMDB實現資源管理，能夠去評估故障影響，但不能實現故障和變動影響評估；CMDB實現業務拓撲是爲了快速的故障定位，但不能實現故障根因分析；一切都是由於在CMDB提供的數據基礎之上，周邊系統（變動、監控、發佈）藉助的CMDB提供的數據能力，實現自身的場景化系統能力。

第3、重構你的CMDB組織

圍繞業務能力重構你的CMDB！！！

分離CMDB建設的層次和結構，獨立建設不是沒有可能，至少應該分離出兩個CMDB系統–面向基礎設施的資源管理系統和麪向業務的資源管理系統。

面向基礎設施的資源管理系統能夠由數據中心的同事來建設，而面向業務的資源管理系統是由應用運維部門來構建。

這二者沒有前後之分，固然若是有底層的基礎設施的資源管理，在其上構建業務的資源管理系統以後，數據的關聯性會更強一些。

若是在兩個職能管理分離的組織中，這個獨立建設的必要性就更強了。好比騰訊，CMDB就是分兩層的，一層是有網絡平臺部建設的面向基礎資源的CMDB管理平臺，另外一層是業務的CMDB（是否叫CMDB已經不重要了），是各個業務部門建設的。

第4、重構你的CMDB產品形態

創建面向應用的資源管理CMDB！！！

核心是面向應用的CMDB產品思路要發生重大變化，僅僅聚焦在資源管理是遠遠不夠的，資源是靜態的。必需要創建一個逆向思惟，不要從資源的角度維護資源，而是從應用的角度來維護資源。主機是什麼？是應用的一個資源；Docker是什麼？能夠當作應用的附屬資源；PaaS平臺中分佈式RDS服務是什麼？是應用的附加資源等等。

這個形態要突出應用的核心位置，並以此爲核心打造CMDB的管理入口，把資源管理、應用的場景維護等能力緊密集成起來。

第5、重構你的CMDB服務場景

常常你們都在說CMDB場景化，那真正的場景化究竟是什麼？

• 基於流程的場景識別

這是最傳統的場景識別方式，經過ITIL認識到IT服務管理的核心流程，這些流程其實就是運維的場景。這個場景還有兩個方面須要改進，第一在企業落地的過程當中要結合實際，細分紅一些核心流程；第二，具體的場景流程須要基於角色進行分類細化，好比說網絡運維、服務器運維、機房運維、業務運維等等。

• 基於服務化的場景識別

我本身以爲這個場景很好歸類，把角色+維護的IT服務對象二維考慮起來，把自動化+可視化當作目標，服務化（API化）的能力結果就是必然。同一個角色可能維護了不少IT服務對象，把這個IT服務對象的管理能力API化，供外部服務集成，IaaS雲平臺就提供了很好的示範。

• 基於應用交付流的場景識別

這個是應用運維場景的垂直識別。若是按照雲計算的三個層次來講，IaaS和PaaS依然是底層的運維支撐能力，面向應用的運維能力纔是真正直接做用於用戶的。面向用戶的價值流梳理對應的就是應用交付流的識別。裏面有幾個核心的場景：應用上線場景、應用維護升級場景、應用遷移場景、應用下線場景等等，貫穿了整個應用交付的生命週期管理。

最後，其實CMDB就是「資源+動做+狀態」造成的統一入口

CMDB究竟是什麼？什麼可讓CMDB成功？最近不斷在思考這個問題。有天我回到了以前在UC維護的一些代理遊戲業務，看過Gameloft的遊戲管理後臺，才找到CMDB的答案。後來又對照咱們公司CTO黎明以前在騰訊作的織雲全自動化平臺，對這個答案就更加具體而明確了。

 

在遊戲運維管理系統中，幾個信息是關鍵且必不可少的：

• 遊戲關聯的資源。遊戲運行的主機有哪些？主機上啓動哪些進程和端口?進程和端口分別屬於哪些區服（通常用端口來劃分）？
• 遊戲關聯的運維場景。開區開服、合區合服等等。
• 遊戲當前的狀態。查看區服的用戶數量，鏈接數，資源的狀態等等。

由此就已經構成了一個強入口，這個強入口不斷吸引遊戲運維參與信息的維護，同時參與信息的變動過程。所以我也下斷言，CMDB應該成爲運維人的入口，不只僅是靜態信息的入口，並且是一個動態變動和狀態管理的入口，把面向場景的運維編排集成到CMDB之中才是將來，不然在一個IT快速變化和組織弱約束的環境中，CMDB的失敗仍是不可避免。

誰讓CMDB成爲入口，誰就可讓CMDB成功！不過那時CMDB是否是叫CMDB就真的無所謂了！

文章來自互聯網運維雜談

原文連接：http://www.yunweipai.com/archives/6856.html