從25日開始進行的CMDB的原型，到現在第二稿基本完成。
第一稿純粹是進行資料結構的設計。手工添加資料進行腦力風暴式的驗證。第一稿只做到配置建模資料結構，對配置執行個體並未涉及。
第二稿是對資料結構的原型驗證，對所需技術進行了初步的探索，由於是邊想邊寫，其中過程反覆了幾次。
這裡把簡單的一些思想記錄下來：
什麼是組態管理？組態管理的精髓在哪裡？組態管理，在營運概念中，就是把運行相關的所有外生變數（可以調整、變動的資訊）搜集並加以管理的過程。它與營運的變更、事件、問題、上線等多個活動密不可分。它包括的內容五花八門，有硬體資訊、軟體資訊等等，只要運行相關，影響營運活動並可被營運活動所改變，則都可以記為配置。典型的配置有：主控件類型、主機廠商、主機ip地址，設定檔、核心參數、CPU類型、CPU序號等等。通常可以由配置項-配置值結對組成：例如：主機名稱
：= myhostname主機廠商
：= HP複雜一點的，配置可以是有結構的，例如：主機ID
:= myserver1主機名稱
:= myhostname網卡1
:= intelIP地址
:= 192.168.0.1MASK
:= 255.255.255.0網卡2
:= wanIP地址
:= N/AMASK
:= N/A當然應用程式更是有配置，而且通常以設定檔出現。XX APP
:= xxapp.ini組態管理不是為了配置而配置，它是一個輔助系統，是為其他管理活動服務的。單單考慮組態管理沒有任何意義（也許可以做資產管理使用）。考慮組態管理，一定要從變更、事件、問題等活動中去思考。這是組態管理的精髓，也是營運管理的最痛點。簡單說來，一個變更，如果涉及對配置的修改，那麼它修改了哪些配置，影響範圍有多大，是否是配置完整/一致（沒有遺漏項或不一致項目）的變更，都應當從組態管理中找到答案。無論是否營運單位是否建立了正式的組態管理，只要是實行變更控制，就肯定有自覺/不自覺的組態管理。而組態管理要能協助進行影響分析，就需要對現有設定項目進行建模分析，也就是建立一個立體的配置模型，這，就是組態管理的精髓。配置建模的問題在哪裡？對一個特定系統、特定目的進行配置建模是容易的。例如，為某一個主機的網路進行配置建模是容易的，即主機/網路/網卡配置。每一層都有特定的設定項目，如下即為一個簡單的模型：主機層：主機名稱：網路1：本地網192.168.0.*網卡1:intelmac：pci槽口網路2：遠程網10.0.0.*網卡2:intelmac：pci槽口：那麼對此配置的變更影響分析就較容易分層做出，例如網卡變更、IP地址變更、主機名稱變更的影響範圍（對此主機的影響而言，對此主機所屬網路則不然）容易確定。而如果需要對整個網路進行影響分析，則需要對整個網路進行建模。例如，如果確定某網路就是由兩台主機，一個交換器，一個防火牆組成，而且拓撲方式確定，那麼按此建模後，網路的配置描述起來就相當容易了，也容易進行影響分析。嘗試用一種模型適用於任何網路結構，顯而易見是非常非常困難的。因此配置建模的問題在於，如何方便建立一個描述現有系統的模型。也就是說，組態管理的首要任務是配置模型管理，然後才是設定項目的管理。配置模型用於描述系統結構，設定項目用於配置模型的執行個體化。例如配置模型可以描述：XX類型網路：網路資訊（IP段，用途等）包含主控件類型包含交換器類型包含防火牆類型他們的組成資訊（有多少主機、多少交換器、互聯方式等等）。組成資訊難以通用，可以由一小段程式（指令碼）描述。組態管理可以根據配置模型進行執行個體化，成為設定項目。配置模型+設定項目，很容易為變更控制提供可靠地影響分析。這兩天的工作小結學習了CLR/C++編程，嘗試了動態建立介面。mysql封裝，Python無縫結合，C++/Python資料結構互相使用。.NET CLR是好東西。mysql也不錯。實現了配置模型管理，完成了繼承、引用、包含的模型關係定義和實現。實現了設定項目管理，完成了對配置模型的執行個體化。設定項目執行個體化時，繼承採用包含的實現方式。嘗試改變傳統直接在資料庫操作的習慣，採用load到記憶體，操作完成，寫sql檔案，執行sql檔案提交的模式。下一步工作可以開始著手第三稿了。目標：1、重構目前的實現代碼，從架構上整理清楚模型-執行個體。2、以複雜配置模型為例，實現配置模型=執行個體化，影響分析等操作。3、組態管理引入狀態，線上-->checkout做變更-->check in等待覆核檢查-->變更上線-->上線後線上核對-->線上
