長文 | 重構CMDB，避免運維之恥

• 2019 年 11 月 20 日
• 筆記

CMDB，幾乎是每個運維人都繞不過去的字眼，但又是很多運維人的痛，因為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系統產品截圖：

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

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

4、配置管理流程，而非業務管理流程

是業務變更觸發配置變更，而非配置管理觸發變更流程。下圖是一個典型配置管理流程圖，看懂的，請舉個手！！！

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

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就真的無所謂了！

優維的EasyOps產品棧會在六月份Release這樣的一個顛覆性CMDB版本，敬請期待。