(深度好文)重構CMDB，避免運維之恥

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

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

1、組織的設計問題

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

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

A、中間件。

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

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

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

2、Excel是最好的管理工具

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

3、去簡就繁

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

首先必須要解決產品易用性的問題，易用性不夠，你怎么讓能用戶有使用的欲望呢，以下是來自于UC做的CMDB系統產品截圖：

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

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

很多配置的變更都是因為場景變更引起的，比如說機器搬遷導致機器的物理位置信息發生變化，那就搞一個機器搬遷流程吧；機器上的業務下線了，但進程信息沒有清理，那是業務下線流程的問題....

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

很有意思的現象：客戶的監控系統中監控的應用主機信息都是該系統中自行維護的，從來沒有考慮從CMDB獲取。也就是因為CMDB是另外一家產品，為啥呢？如果資源和應用關聯起來了，并且由他來驅動監控，這個維護的動力是不是不一樣呢？

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

其實還有很多原因，比如說物理世界和邏輯世界是獨立的，物理世界發生的過程沒法直接映射到CMDB系統中（有些配置信息需要進入固件中）；CMDB的對象Owner沒有或者過多（Owner很累）；過分強調CMDB的基線作用，引入對比（動態變化的環境基線的作用應該下降）；夸大CMDB自動發現的作用等等。

說了很多的失敗的原因，接下來就需要討論一下解決方案了，既然講重構，老王的重構邏輯是什么樣的？

第一、重構你的CMDB思維

建議大家不要把CMDB稱之為CMDB了，那叫什么，就叫資源管理吧。為什么你要從改名字開始？老是叫CMDB，大家都回到過去的思維上了，道不清說不明的，或者各執己見。

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

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

從上層的業務資源來說，建立以應用為中心的資源管理邏輯，把 一切都看成應用的資源來看待。比如說Host，應用包、權限、RDS服務、cache資源等等。

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

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

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

第二、重構你的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提供的數據能力，實現自身的場景化系統能力。

第三、重構你的CMDB組織

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

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

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

這兩者沒有先后之分，當然如果有底層的基礎設施的資源管理，在其上構建業務的資源管理系統之后，數據的關聯性會更強一些。

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

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

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

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

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

第五、重構你的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