定義的煩惱
在某一次系統監控的討論會議上，我隨便提出了個問題：“如何定義一個系統？”，結果答案就五花八門起來了，會議也跑題了。
為什么問這個問題，是因為某些同事覺得某個系統比較大，就往下分為子系統、組件等，往上分業務群等。有時候仔細一看，什么業務群，明擺着就是一個大的系統而已。當然，我隨便說說，我也沒有對這個問題有明確的定義。我想說的就是，包括系統、組件、子系統等等，這些定義我們從來沒想過——流程也是這樣，區別是，我們想過，但是只是湊合着用而已，定義並不清晰。
這些屬於那種只可意會不可言傳的東西，這就導致外部公司常常將我們“以為”的一個系統拆分為多個系統進行收費……
當然，這個問題至今仍為明確，我提出過，但是大家都認為沒必要搞清楚這個問題。
CMDB分類
和上面一樣，CMDB的分類也是這樣。
我舉個例子：有人問過，服務器為啥不是網絡設備……我覺得這個問題其實還是不太好回答的。
CMDB的分類，最好能夠窮盡但又不交叉，你不能讓一個CI同時屬於兩個分類。
----------中斷一下，我再提個問題，如何定義CI，什么是CI，什么不是？----------
我需要回顧一下現在收集到的類別。
環境：
建築、機房
動力設備：配電櫃、列頭櫃、UPS、PDU、機櫃
空調設備：空調
消防設備：現在沒有，以后會有的
門禁設備：現在沒有，以后會有的
網絡：
線路：互聯網線路、廣域網線路、局域網線路
資源：IP、域名、數據接口
網絡設備：路由器、網絡交換機、無線設備、安全設備
網絡設備配件：現在沒有，以后會有的
通信：
通信設備：語音設備
虛擬化：
虛擬資源池、虛擬機
計算機相關：
計算機整機：PC服務器、刀片服務器、小型機、中型機、大型機、工控機
計算機配件：現在沒有，以后會有的
存儲設備：磁盤陣列、集中存儲、磁帶庫、光纖交換機
專用設備：刀片機箱
其他設備：現在沒有，以后會有的
軟件：
業務群、系統群集、應用群集、數據庫群集、業務系統
中間件：Tomcat、IIS、Apache、Jboss、Weblogic、Websphere
數據庫實例：DB2、Sybase、Oracle、MySQL、MSSQL
總感覺實體資源中的建築和機房不應該放在這里來，雖然確實互為實體，但是屬性好像不同，所以先移除了。
----------繼續----------
CI就是CI，做好業務系統的定義，而具體與服務掛鈎的地方則在服務管理的部分去處理。
對於CI來說，狀態只有兩種，正常和故障，正如數字0和1的區別。
剛才思考的時候也繞到百分比影響傳遞的問題上了，這一塊的內容扔到服務里面去處理。
CI中記錄的是靜態信息，動態的信息從監控來，展示時調用接口即可。
分類與屬性掛鈎，必然某些分類會有具體的屬性集。
屬性定義-->屬性集定義-->屬性與分類掛鈎
在考慮之后，我認為服務的模型的建立應當從基本服務（即與某CI直接相關的最小服務）開始，在服務管理中應該可以引入服務相關的概念，這樣可以簡化CMDB本身的功能。而業務的模型則是直接展示CI和服務。
CMDB本來就是一個比較懸的概念，不能讓過度復雜的功能讓它雪上加霜了。