第十三章 穩定運維，快速交付，以人為本（1）
第四篇 運維管理之道
當運維物件達到一定規模，複雜度會陡增，你會發現哪怕是記錄簡單的管理物件密碼、堡壘機等資訊都要幾個excel，何況各種複雜的配置資源。運維管理的兩個重要職能快速與穩定，既要做得快，又要不出問題，ITIL給了我們一個參考庫，在這一章你將看到具體如何實現，包括配置管理庫的如何設計，監控如何管理，變更實施的安全性如何保證，最後我們將回到人員本身，談一談運維這道手藝，以及ESNS在運維領域的重要性。
第十三章 配置管理
日常運維工作中常會尋找我有哪些運維的元件？它屬於什麼區域？它的IP是什麼？它的變更關聯影響是什麼？能回答以上問題的資料，我們稱之為的配置管理資訊，儲存這些資料的源稱之為配置管理資料庫，簡稱CMDB(Configuration Management Database
CMDB可以說是運維管理的資源地圖，它告訴我們有什麼、在哪裡、什麼狀態、如何關聯。首先定義好CI，包括物理硬體，如交換機、路由器、防火牆、伺服器，也包括邏輯軟體weblogic、apache httpd、nginx。為了準確標識CI，需為其定義屬性，如唯一性、版本、大小、狀態，隨後進行CI的組合與關聯，最終形成業務視角的邏輯實體。在這些資訊外圍還有大量附屬資訊，如登陸的堡壘機、使用者名稱密碼等，建立一套完備而精準的配置管理庫是一個長期的過程。
配置管理是運維管理的基石，它與監控管理、容量管理、事件管理、變更管理直接關聯，向後者輸出有效資訊，支撐資料中心運轉。IDC災難恢復的首個系統往往不是交易系統，而是你的配置管理系統。在後續章節中我們還會詳細說明與其他模組與配置管理的關係。
在新專案、任務建設初期，為了加快整體進度，常常忽略了配置資訊的錄入，通常在一張本地的excel表格中保留相關資訊，隨著專案接近尾聲，專案轉運維進入標準化軌道後，配置資訊的缺失常會引發大大小小的問題。必須建立一個有效的變更管理流程，在其中嵌入配置管理步驟，重視配置，保證配置先行，提前申請、登記好配置項。
實際運維工作中還會出現不加區分的將各類配置項錄入到CMDB中的情況。運維人員不得不做很多繁冗、重複的無效工作，手動錄入低價值的資料，漸漸劣幣趨良幣，有價值的資料淹沒在垃圾浩海之中。CMDB應該只包含那些計劃將要積極去管理的配置項，並且通過各種方式讓運維人員擺脫重複性工作，比如CI自動發現、提升錄入介面使用者體驗等等。
配置管理系統應保持一個持續迭代更新的過程，有專門的開發團隊支援，而不是一個固定不變的產品。小型企業可以通過wiki、資料夾共享等方式臨時性解決問題，中大型企業則必須擁有自己可控的配置管理系統。不應採用封閉、難客戶化的系統，而要求開放自由、易擴充套件。配置管理系統不僅是用來儲存資料，由於它的頻繁使用，更應注重使用者體驗，讓運維人員舒服的使用，從而提升日常工作效率。
13.1 配置管理系統分析
13.1.1 服務模型進行分層
CMDB的構建過程是一個龐大工程，涉及IDC管理團隊與部門非常之多，如果要將整個IDC所有的CI分析、設計並進行關聯生成最終的完整的服務檢視需要花費2~3年時間。一般很難完整的從下往上構建，比如從IDC的機房、機櫃資訊開始分析CI，往上到硬體伺服器、網路裝置，最終一步一步延伸到頂層的服務，如圖1；我們可以看到CI處在服務模型中，我們可以對其進行分層，典型劃分方式包括：物理空間層、物理裝置層、邏輯主機層、邏輯元件層、應用系統層、業務服務層。物理空間層包括機房、機櫃、機架；物理裝置層包括伺服器、網路裝置、防火牆、儲存、加密機硬體等；邏輯主機層主要是附屬在物理裝置上的作業系統，比如redhat、windows、ESXServer，除此之外還有與儲存相關的nas、lun卷資訊；邏輯元件層主要是OS上的一切中介軟體、資料庫；業務系統層則是由下層元件組合而成的業務系統。業務服務層是具體的業務公司對外提供的系列服務。
圖一 IDC管理團隊在分層模型中找到自己的位置
IDC管理團隊必須對CMDB模型分層達成共識，清楚自己所在的位置，一個管理組所運維的CI可能在多個層上都有體現，我們只需要找到大概位置，比如網路小組的管理的CI，網路硬體裝置屬於物理裝置層，網路區域屬於邏輯主機層。
13.1.2 各IDC團隊發現CI
各IDC管理團隊在清楚自己位置，明白上下游關係後，開始尋找自己所管理的CI，通常有以下幾種方式：1.在IDC管理團隊負責的資產清單中整理出CI。資產並不一定由運維團隊負責，有些組織中有專門的資產管理中心，從運維團隊、資產管理團隊日常互動的資訊中可以挖掘出大量的CI，而這些CI一般分佈在物理層面，例如伺服器、網路裝置、儲存裝置等。
2.在IDC管理團隊日常工作面對的元件中整理CI。以系統組、中介軟體組為例，他們每天工作面對得最多就就是作業系統以及執行在OS上的各類中介軟體程序了，運維團隊整理出這些物件，並抽象出能夠表示、承載這些物件的CI。在這裡強調下抽象與實現之間的折中，在面向物件的設計中強調面向介面程式設計，抽象出所有物件的共性，對CMDB而言則無需完全遵循這一點，暫時忽略掉抽象的通用性、擴充套件性，而將CI聚焦在組織中最常用的物件上，如果你組織所使用的90%的中介軟體都是weblogic，你就有必要為weblogic建立一個單獨的CI，將它的基本屬性與關聯關係獨立出來，同時在未來CMDB的介面設計上也要精耕細作，注重使用者體驗。
3.由運營應用管理人員從業務角度定義CI。運營人員所屬的業務服務條線就很好的定義出了業務服務CI，而他們直接管理的子系統則是應用系統CI，應用系統CI又有大大小小的邏輯元件組成，他們之間有叢集、組合關係，這些細節暫時無需關注，重點是找到當前層面的CI，並與下游層級做好對接。
圖二 各管理團隊尋找自己的CI項
配置管理項要與資產管理項嚴格的區分，兩種資訊的用途完全不一樣，配置管理用於日常的運維，而資產關乎於IT成本核算。根據三種方式篩選出各層級、團隊的CI後，開始對CI進行抽象提煉，CI的抽象以功能、組織佔用比來提煉。“硬體裝置”可以看成是物理裝置層最高級別的抽象，我們可以將網路裝置、伺服器等各類具體實現對映到”硬體裝置“這個CI之中，但這種抽象粒度的太過於寬泛會為後續的CMDB表示層設計使用者體驗提升造成很大的阻礙，我們必須以硬體功能將CI項進一步的具體化，"PC伺服器"是執行在x86架構上的伺服器，”交換機"是負責二層網路轉發，“路由器”負責三層網路資料包選路，“防火牆”負責網路安全控制，這些功能特定並在組織內佔有一定比例的CI單獨建立。回到抽象層面上，我們有必要保持一個抽象的”硬體裝置“CI來存放特殊、組織未標準化的裝置，比如加密機、第三方軟硬一體裝置、應用安全控制硬體，這類非標裝置常常因為沒有一個合適的CI定義而造成資訊遺漏。在CMDB中建立CI項只存在關聯關係，而沒有繼承關係，這與面向物件的設計截然相反，儘管我們定義了”伺服器“、”交換機“、”硬體裝置“幾個CI，但它們之間是沒有父子繼承關係的。在CI模型分層中進入邏輯層後，標準粒度的CI應是動態的、執行中的物件，如獨立的作業系統或在單一作業系統上提供同一服務的單程序、程序組，而不是一個軟體。不用擔心物件的粒度無法組成一個完整的服務，在邏輯層面上我們可以通過定義“叢集”、“組合“等各種關係將這些CI物件拼裝層合適的CI。
13.1.3 IDC管理團隊定義CI屬性
很快我們手上有了一批合適的CI清單，我們還有大量資料來說明CI是什麼，這些資料可以用來作為CI的屬性，我們有什麼方法從這些資料中發現屬性資訊？我們將CI的屬性分為六類：核心、附屬、控制、服務、關聯、擴充套件，下面我們對這些屬性類別進行逐一說明。
核心（core）：運維工作中在操作該CI時經常要使用的資訊，具有唯一ID、命名、生命週期、易變化等特徵。核心屬性維持了CI在整個運維管理工作中的有效運轉，其中的每一個屬性都是必要的。
唯一ID：表示當前CI在CI物件集合中的唯一性，資料庫表字段unique id遞增序列保留增長容量空間可以適用大部分CI屬性要求，唯一id與CI本身所代表實體的沒有關係。
命名：命名與唯一編碼的不同之處在於命名是在前臺可見的，它是印在到CI實體內容之中的，命名本身就包含了唯一標識作用，同時還附帶其他說明。我們所說的印在主要指邏輯層面上，比如一個作業系統命名為CNSZ031415，一個weblogic java程序加入SERVER環境變數chs-coreStg7891，這個名稱是“活生生”的，可以通過程式在執行態的實體中動態尋找，這為以後的的自動發現、自動化運維等工作埋下伏筆。命名內容是組裝而成，我們應當精簡命名，命名體現我們最關注的，其他關注點在單獨的屬性中體現，不同層級關注點不同。”CNSZ031415“，"CN"表示中國，”SZ"表示深圳，“03”表示測試環境，1415是主機層面上的序號分配，以上命名資訊解碼可能是一個系統管理員所關注的。而在中介軟體層面與應用系統聯絡的比較緊密，因此命名中要體現出所屬的應用系統，“chs-coreStg7891”中，“chs-core”是子系統名稱，Stg是環境名稱，7891則是序號。
生命週期：一個CI項也有著“從搖籃到墳墓”，從自然中來到自然中去的過程，在不同時期的的管理級別有著不同的要求，生命週期不僅僅作為一個狀態存在，還可以作為一個期限而存在，資源管理中為了保證所有資源合理而有效的利用，常常定義一個資源“釋放”期限幫助我們對CI資源進行管理。
控制（control）：控制屬性與CI本身也沒有關係，它關注與許可權、審計、版本等控制方面，這些屬性在整個CMDB中是通用的。值得我們關注的是許可權、審計、版本這三個控制屬性在對映到資料儲存物件後的位置截然不同。
CI的操作許可權是受到使用者所屬角色、組織、單位限制的，我們在CI元資料中定義此屬性，但此屬性不是說明我屬於誰、屬於那個組織，而是說明我是誰，屬性表示的是“我是銀行的伺服器”，通過後面的關聯，我們可以導航到“我是一個跑著weblogic java程序的伺服器”、“我是一個為銀行信貸應用服務的weblogic java程序伺服器”，在這些屬性說明中沒有做我們那些不該做的事，我屬於誰、屬於哪個組織，我僅僅說明我自己。許可權的切入點不能放在CI之中，比如在CI中定義“銀行”、“信用卡服務組”、“李四”這樣的組織、人員資訊以標識它的許可權，這樣的設計會讓後續CMDB的維護難度大大加大。許可權的切入點要放在"行為”、“屬性”兩個層面，對於伺服器的讀寫許可權中的讀寫是一種“行為“，我們應該做一個行為的攔截器對許可權進行控制，這是放在CI之外的，而”屬性“層面則是通過屬性內容由”規則“去自行判斷的，規則控制這許可權，”規則“有時剝離在CI之外的，”我是一個為銀行信貸應用服務的weblogic
java程序伺服器“，在這個CI配置項的表述過程中它表達的是自己的屬性，而”只有為銀行應用服務組服務的基礎架構人員才能修改銀行機器，且只能修改weblogic java程序的PC server“，這是一條規則，規則是許可權控制的邏輯，而許可權控制的輸入是當前操作人員的所屬屬性、CI控制屬性，輸出是”你是否可以操作“。CI的控制屬性不完成許可權控制工作，它是許可權控制實現的輸入元素之一。
審計告訴我們誰在什麼時候新增、修改、刪除、甚至查詢了CI物件，CI的審計資訊量視情況可大也可小，審計功能可以做成定製化開關，控制資料庫容量。為了做好版本控制，如果每次對CI的變動都儲存完整的CI資訊以及其所有關聯的CI當前版本資訊，這會大大增加開發複雜度以及增加DB資料儲存量，從經驗上看沒有必要在所有的CI上定義版本號，而是通過”變更快照“、”審計對比“功能中附帶的完成版本控制工作，變更快照幫助我們對操作CI的上下游配置資訊進行快照，並儲存在當前變更流程中，由於CI變化只與變更有關係，在變更流程中啟動快照，在資料庫結構化資訊之外儲存CI資訊，即可完成未來異常問題的查詢。另一種做法是在開啟了審計功能的CI上記錄每一步修改的內容，根據這些修改資訊我們一樣可以完成故障資訊的收集以及版本回滾。
服務（service）：運維管理工作最終提供給使用者的是服務，而不是一個主機，一個程序，服務屬性與CI屬性也沒有直接關係，而是與服務流程相結合，分析關聯影響。你可能要問一個屬性怎麼來識別分析影響？首先，服務屬性一般在分層模型中的應用系統層，例如我們對”承保系統“定義：一級核心、運維時間：23:00~24:00、是否凍結等，這些屬性都是圍繞著服務、應用而言的。下一步我們會分析CI之間的關係，這些服務屬性是向下繼承的，當我們安排變更操作一臺伺服器時，進入變更流程後就會自動的發起關聯影響分析，你會收到詢問資訊，”你確定要維護這臺機器嗎？他是承保系統，已經凍結變更，並且維護時間只有一二小時哦？“真正的變更影響分析是通過服務屬性、CI關聯、屬性繼承來進行的。當然，你可以完全忽略這些CI關聯影響評估資訊，但金融類IT運維以風險控制為中，變更安全粒度要求非常嚴格，什麼時間點可以做什麼事要求通過CMDB中的資料進行分析，輸出一份準確報告。
附屬（attached）：這些屬性一般是可選的、固定的，與實際運維工作無直接聯絡，僅僅是幫助我們更進一步瞭解CI。例如CNSZ031415伺服器，它的CPU主頻是3300MHz，這個主頻就是附屬屬性，附屬屬性由於其穩定性，常常批量匯入、預設設定。
關聯（associated）：CI屬性中一個非常重要的種類是關聯，它表示CI之間以一種什麼樣的關係組合在一起，形成一個面向服務、應用的整體。我們認為CI之間的關聯也是一種屬性，這類屬性具有雙向導航特性，可以由一個CI找到上下游、平行層級的關聯CI，關聯屬性的定義我們在下一步詳細討論。
擴充套件（extend）：擴充套件屬性是為一線運維人員服務的，他們以文件、圖形、模板、服務目錄、應用檔案等非結構化資料方式組織起來，關聯到外部的知識庫、運維規約、應用檔案，告訴一線運維人員操作方法、生產風險、一般規則。
13.3.4 確定CI間的關聯
確定CI之間的關聯關係過程也相當具有挑戰，關係的設定決定了以後在使用過程中對配置項的快速定位與影響度分析的有效性。不同的CI之間會有不同的關係型別，相同的兩個CI物件之間還可能有不同的關係，而且關係的確定也需要有適當的粒度，關係的保留採用“有用性”原則，也就是對業務來說是有用的。忽略那些對業務不影響的關係型別。CI之間的關聯關係類別限定在四種範圍內：組合、叢集、使用與依賴，除此四種再無其他關聯關係。
CI之間通過關聯關係最後組成一個一件完整的“產品”，我們不會按照大多數ITIL軟體一樣對這個產品分解成層次結構型體，這種提前定義一個CI所屬層級會讓CMDB失去靈活性，很多情況下一個CI在不同的產品中屬於不同的層級，這裡的層級與服務分層模型層級是不一樣的，這裡的層級是相對於最終拼裝組成的完整產品而言。產品結構層級對於工程領域產品配置項來說非常有效，一個產品的組成部分是固定的，而產品組成的元素關係相對於虛擬軟體而言更靠近現實世界，大部分可以採用依賴關係。而IT“產品”很難用工業產品標準化的方式將服務、應用、程序、OS、硬體資源組合起來，不同的應用有著不同的組成元素，並且隨著IT的演變，組成元件的類別與關係也在不斷變化，另外，即便是同樣的組成形式，IT“產品”組成元素之間的多重性也在變化，在應用訪問量預計大增時，應用伺服器叢集的量會陡增，我們沒有必要用產品層級的方式將CI之間固定起來，而是應以一種靈活而零散的方式自由組合我們CI。
依賴：表示一個CI的存在強依附於另外一個CI，依賴追求CI間完整性，禁止CI獨立存在後產生的垃圾資料。程序與OS之間就有這樣一種依賴關係，在新增一個weblogic程序例項時我們要求必須錄入它所依賴的OS，程序脫離了所執行的OS則沒有任何意義。依賴關係也會產生一些問題，由於強依附關係的存在，CI鏈可能因為某一個CI確實導致整體資訊的錄入延時，回到我們的例子，weblogic和OS物件在不同管理團隊運維，中介軟體組錄入weblogic資訊時強依附到系統組的OS，而系統組不一定錄入了OS資訊，從而中介軟體組也無法錄入。必須在變更管理中建議有效流程保證相互依賴的CI資訊有序錄入。
組合：表示一個CI由哪些其他CI組成，是一種“整體與部分”的關係。組合關係相對於依賴的強制性要稍微弱一些，可以獨立建立一個CI，之後再陸續補充它的組成CI。一旦組合關係建立後，下層被組合CI的生命週期就與上層CI聯絡上，在這裡產生了一種強制關係。車險承保系統由weblogic中介軟體組成，我們可以單獨建立車險承保系統，後續再新增weblogic程序，一旦這種關係建立好後，它們的生命週期就統一起來了，如果要下線車險承保系統，就必須先下線下層的weblogic程序，這種生命週期的傳播是從上至下的。組合關係適用與下層CI唯一服務於上層CI的情況。
使用：標示一個CI將另一個CI作為資源CI使用，這種關係是鬆耦合的，oracle資料庫使用了一個儲存lun卷，即便lun卷不存在，oralce資料庫還是能夠執行，它可以將資料儲存到其他捲上去。現實世界裡不會出現CI間完全鬆耦合情況，提出這種關係，是為了保持CMDB的靈活性，我們無法界定組合、依賴關係時，我們會將CI間定義為使用關係。
叢集：叢集是IT領域常出現的概念，它表示一組物件共同完成一個任務，物件間有主備、並行、優先順序等進一步關係，集群后形成一個邏輯CI，比如10個weblogic程序叢集對外提供服務，他們是並行的，兩臺ESX vmvare裝置互為主備等。在運維領域的叢集會引入負載均衡、容錯、高可用的術語的討論。叢集是4種關係中比較特殊的一種，伴隨著關係的建立，叢集（cluster）中的每一個成員（member）間還有亞層次的關係，如果是優先順序，成員都有一個級別屬性，如果是主備關係，成員會標明為主或備。這在設計CMDB資料模型是要提前考慮。
讀者可能會好奇，為什麼關係只有這四種，下表列出了CMDB中一些常用的關係，現實世界中的關係可以被描述成很多種。CI與面向物件設計不一樣，CMDB並不強調父子繼承關係，即便有這樣的一層關係，也會通過定義兩種不同的CI實現。而對於其它各種關係的描述我們可以對映到“依賴”、”組合“、”使用“與”叢集“上。
| 編號 | 關係 | 說明 | 示例 | 備註 |
| 1 | 安裝在..上 | Install on | 資料庫安裝在主機上 | 依賴 |
| 2 | 連線關係 | Connect with | 主機與網路相連 | 使用 |
| 3 | 依賴關係 | depend on | 應用依賴於中介軟體 | 依賴 |
| 4 | 父CI | parent | 程序與它的一個具體實現，父是程序（process) | 不使用這類關係 |
| 5 | 子CI | child | 程序與它的一個具體實現weblogic，子是weblogic | 不使用這類關係 |
| 6 | 物理關聯 | associate with | 主機與儲存關聯 | 使用 |
| 7 | 文件關聯 | with doc | 某軟體有某文件 | 使用 |
| 8 | 使用關係 | use | 誰使用某PC | 使用 |
| 9 | 監控管理 | admin & monitor | 誰監控某機器 | 使用 |
| 10 | 組成關係 | consist of | 銷售系統由主機、DB和中介軟體組成 | 組合 |
| 11 | 運行於…上 | perform on | 應用運行於OS上 | 依賴 |
| 12 | 備機 | standby | 主機A是B的備機 | 叢集 |
在建立好合適的關係後下一步是確定關聯物件間的多重性，它用來指出可被允許生成的關聯CI數量，即最多可以生成多少數目（上限），最少不得低於多少數目（下限）。關聯的兩端以"下限..上限"的格式標示出多重性。星號（*）代表不指定上限，下限最低為0。CI的關聯關係、多重性確定後，也就完成了CI間導航功能，我們可以根據一個服務CI生成一顆該CI所引用的資源樹。
除了以上四種關係外，還可能有一種獨立的系統層面的關係，比如A系統呼叫B系統，這種關係有助於我們生成應用間服務架構圖，這種關係不是在配置管理層面，如果要做成一套大而全的系統，這種情況的關係則需另外考慮。
13.2 配置管理系統設計
CMDB已擁有一個非常成熟的市場，可以採用商用、開源、自主研發三種方式來實現我們的CMDB系統。從下面的結構圖來討論配置管理系統設計的三個方面：使用者介面、資料模型、附屬功能。
圖~~~
13.2.1 使用者介面設計
使用者介面直接面向配置管理員以及其他IT運維管理人員，他們有職責定義CI、管理與使用CI屬性以及確定它們之間的關係，並將他們關聯上運維操作與管理流程。配置管理系統不是用來儲存冷冰冰的資料的，在運維管理中，配置管理、監控管理系統的使用頻度要遠遠高於其他系統，在介面上關注使用者體驗是無形中提升運維效率方法，好的IT運維經理應該時刻關注一線人員的情況。 CI管理：配置管理員、IT運維管理人員對CI的操作，可以簡單的認為只是日常簡單的增刪改查。使用者體驗的提升就潛藏在這基本功能之中。
對於複雜的一屏下來幾十個欄位的CI，我們應該分屏、嚮導式的一步步引導運維人員錄入資料；具體說來，在進行CMDB介面設計時，要通過各種視覺手法來告訴使用者，這個嚮導過程總共有哪些步驟、使用者已經完成了多少步，以及還有多少步未完成等資訊。這些要求其實是任何資訊導航設計所要達到的一些基本目標。如果一個介面設計達到了這些目標，它就能使得使用者具有一種對整體的把握感。當用戶看到自己所完成的每一步所帶來的進展以及他在整體上正在一步步地向成功接近時，他就會更加有信心並愉快地完成整個任務。在嚮導結束前，將使用者的輸入以某種方式顯示給使用者以便確認，並且越及時越好。這一準則應用了反饋原理。該原理指出，任何同人進行互動的系統，都需要將其內部狀態以某種方式表現出來，尤其是要對使用者的輸入動作進行反饋，只有這樣，使用者才能知道系統是否檢測到並接受了自己的輸入，以及自己的輸入是否正確，這樣使用者才能進行相應的後續操作，比如調整自己的輸入或改正錯誤。缺乏反饋的系統會讓使用者感覺茫然和焦慮。嚮導式介面是一種著眼於幫助人們處理複雜任務或不常見任務的互動策略。為了更有效地達到上述目標，我們需要對其中的很多互動細節加以認真處理。對於常用的輸入，應儘可能採用自動補全的方式，運維管理人員輸入部分有效的資訊後就能自動查詢、關聯到所需CI。CI屬性的選擇是有規則限制的，比如一個WII區安全區域的weblogic就無法運轉在APP區域的host上，這些規則要提前定義好，並提早過濾掉干擾選項。網頁上減少全屏重新整理，通過ajax區域性範圍的更新內容，遞進式層級顯示資料。各CI管理選單應按分析出的服務分層模型歸類。無論底層的資料庫schmea如何靈活的設計，也沒有辦法將CMDB前端完全產品化，使用者體驗的提升是在配置管理系統反覆迭代的開發過程中實現的，IT運維團隊應當有一個專職的開發工具團隊在後端支撐運維工作。
報表與查詢：報表功能可以實現依據不同的屬性組合程序查詢、檢索CI集合，定製IT運維管理所需要的報表清單。在CI查詢上，由於CI的類別特別之多，要提供一個類似於搜尋網站統一查詢頁面，按大類劃分，無論是何種CI關鍵字，都可以在一個查詢介面中搜索到結果。
|
三層展示核心網路骨架
第一層：資料中心(IDC)、職場、租用機房
第二層：安全區域、CORE、其他
第三層：防火牆、核心交換機、F5、其他裝置
層級關係：上層實體可以分解成下一層圖。例如第一層中的IDC實體有第二層中的安全區域、CORE組成。
安全區域的定義：在同一防火牆後被保護的區域，行使單一的功能區域。（通過路由層ACL保護的區域也屬於安全區域，定義在一個子集）。
關聯關係的定義：定義出所有圖層實體之間的關聯。比如直連、專線、cn2等。由於要生成圖形，管理關係是否有方向的定義
最後一層的拓撲圖：進入第三層後是詳細的拓撲圖
圖形與配置管理資料相結合
圖形中的所有實體、關聯都存在於配置管理系統中檢視。 我們所有核心實體都從CMDB中來，例如防火牆、匯聚層交換機、F5等 配置管理中要體現出實體間的關聯、關聯的方向 配置管理中要體現出實體間的包含 圖形是通過配置管理資料中的屬性自動生成的 圖形的檢索和定位 由於和配置管理的關聯，圖形是可以檢索和定位的。 主要檢索的欄位有網路裝置名、保護網段等。 通過檢索網段能夠查到安全區域，並進入檢視拓撲圖。這樣便於確認終端間的邏輯路徑，經過的防火牆。 |
13.2.2 許可權控制與規則定義
許可權控制：CMDB是否擁有完善的許可權控制功能。許可權是服務於整個運維管理系統的，要考慮CMDB中的資料模型是否適用於當前整體的運維管理系統。許可權系統分為授權物件、保護物件。授權物件一般指被授予許可權的使用者，僅僅只有使用者的設計看似簡單，如果所有的使用者對保護物件都關聯一條許可權，則會產生大量冗餘資料，這對於系統管理來說本身也是一件痛苦的事情。為了解決這個問題，我們在在使用者的基礎上建立角色，將一組許可權集合歸為一個角色並賦予使用者。保護物件有功能、資料兩類，功能物件包括選單、按鈕、操作，這類物件可以是對一般的CI物件操作的保護，也可以整合到運維流程管理控制之中。資料包括CI型別、條目，要記住，我們保護的不僅僅是動作，還包括資料的本身。要識別出資料的保護級別，可以通過在CI型別與單個屬性中進行設定。圖~~~
規則定義：CMDB中也需要規則，這個規則用在對CI物件輸入的限定上。“如果是WII區域的weblogic，那麼它所依賴的OS也必須在WII區域”，“當OS的狀態為已上線時，必須輸入該OS的應用管理員”，“主機名是按’cnsz’加上數字的規則定義的，輸入的主機名稱不符合規範”，這些都是基於屬性的規則，我們在輸入一個CI物件的所有資料時，先通過規則來驗證該CI輸入是否正確。如果CMDB具備一個有效、動態、靈活的規則引擎，CMDB資料錄入的準確性可提升一個級別。
OPENAPI：開放的API有兩層意義，一是有利於與內外部系統的CI資料的整合彙總，通常企業會採購一批完整的IT元件裝置，例如vmvare的虛擬機器管理，我們可以通過OPENAPI將資料有vmvare匯入到cmdb。除了完整元件同步外，對於自動發現的CI匯入一樣提供了標準介面。二與直接通過資料庫層面匯入資料相比，OPENAPI在規則、許可權之前，對資料的精準性進行了更嚴密控制。
13.2.3 資料模型的設計
前面是我們將企業、組織內對CI分析全過程，並且對使用者UI、許可權、規則以及對外開放都都提出了設計要求，那麼最核心的CMDB CI schema應當如何設計？我們將問題分解為關鍵的CI資料模型、許可權模型，首先我們討論CI資料模型的設計進行討論。
CI資料模型設計有兩個極端。
將所有的CI放入到一個CI表中，我們稱之為巨嬰表，這個表要解決的第一個問題是對於不同型別的CI有不同的屬性，隨著CI型別越來越多，這個表的欄位要無限擴張，不同的資料庫對錶欄位數量是有限制的。第二個問題則是將所有的CI全部放在一個表中，其效能會出現瓶頸，特別是要求保證事務一致性時。第一個問題的限制是硬性的，而第二個問題我們可以通過通過多種手段緩解甚至解決，例如使用快取提前預熱資料，建立靈活的外部索引表，對於報表資料提前一天夜間執行等。第一個問題的解決方式是預留在巨嬰表上預留欄位數，或者在每次新屬性時加入新欄位，問題逐漸演變成到底我們是該使用面向行的關係型資料庫，還是可以開始在低層使用者分散式的面向列的資料模型。在這裡筆者嘗試過使用hbase儲存CI，並採用面向列的解決方案，最終得出的結論我們的cmdb不適應這種儲存方式，我們的面向列是偽列，是我們把所有CI拼裝起來的列，而我們的本質仍舊是面向行的。
好了，讓我們從一個極端走向另一個，為每一個CI建立一個表，在不斷變化的CI關係中建立關聯表，伺服器是一張表，OS是一張表，交換機又是另外一張表。這可能走向另一個極端，我稱之為芝麻表，整個schema設計下來動輒幾百張表，讓日後的開發人員根本無從維護。或者說本身設計這批schema的維護人員也會陷入到自己設計的痛苦之中，這裡最怕的是尋找我們的邊緣資料，那些在邊角日常不會經常使用的物件我們會問“它在哪裡，它是什麼？”
分析強調的是對問題的需求和調查研究，而不是解決方案。前面我們做了大量的分析工作，分層模型、CI查詢、屬性定義、關聯CI，我們需要依據分析工作中整理的資訊完成設計。設計強調的則是滿足需求的概念上的解決方案。在兩個極端設計方案之間我們選擇平衡。
在巨嬰表的基礎上，我們拆分CI與屬性，CI型別與屬性型別，把他們分解為4張表。對於芝麻表，我們用CI型別控制芝麻表的產生，不允許CI的某一具體定義一個獨立表，最終我們的ER實體圖如下：
我們用8張表儲存CI、CI屬性、CI關係以及版本資訊，相對於芝麻表，我們核心物件、邊緣物件都統一放入到這8張表中。對於特殊CI資源，你會問我是否也要套用這個基礎表模型？我的答案是如果特殊CI資源不屬於邊緣資料，而是在整個IT組織中都需要使用的，時刻被關注的，例如IP資源，那麼為什麼我們不在這簡單的資料模型上做進一步擴張呢？
CI_Type、Attribute、Attribute_Type、CI_Type_Attribute 4張表的作用放在面向物件程式設計中可以認為是類的儲存地，例如一個人，它定義了人這個CI，以及人的屬性，有名字、性別、身高。Configuration_Item、CI_Attribute則是具體的物件，還是以前面的人這個類舉例子，在這兩張表中存放的則是“小明”這個人，它的姓名是小明、性別男。CI_Relationship存放的是CI間的關聯關係，CI_Attribute_History存放屬性的版本資訊。
在討論完CI資料模型的折中設計後，再回頭來看看許可權模型。在許可權控制那一節我們已經談過許可權設計模組基本元素。許可權的授權物件是固定的，一般有使用者和角色。使用者、角色之間是多對多關係。而保護物件是不固定的，一個按鈕、選單、資料項等都是保護物件，而保護行為一般可固定在是否可以讀寫上。誰對什麼可以有怎樣的動作，這就是一個許可權的判斷規則，who、what、how三個元素組成的一條規則。who固定在使用者、角色之上，what不固定，how除了讀寫外也由其他的動作型別。
最終的許可權控制放在了一張表中，表的欄位如下：
圖~~~~
privilege_id是主鍵，privilege_auth_type，privilege_auth_value關聯到使用者或角色表，例如這條許可權規則是使用者的，則privilege_auth_type指向user，而privilege_auth_value是user_id。這兩個欄位代表了規則的who。privilege_protect_type、privilege_protect_value則代表了保護的物件，如果我們保護的是資料CI，那麼privilege_protect_type標識為CI，privilege_protect_value標識為CI的ID，注意，我們在資料保護上可以對一條CI進行保護，也可以對一個CI type進行保護，最後我們看到的是具體保護的行為是什麼，在這裡用privilege_operate表示。
13.3 配置管理資料準確性的保證
13.3.1 識別CI的OWNER
要想保證CI的準確性，首先就得找到誰使用CI、誰維護CI、誰對CI負責、CI的準確性與誰的KPI掛鉤，而不是在大家需要使用CMDB資料時才抱怨。CI的使用者與CI的維護者對資料的準確性要求不一致時就會出現前面的抱怨。這兩個角色可能出現在一個團隊，也可能在不同的團隊，系統服務組的資產負責人是CI的使用者，而系統服務組的運維負責人是CI的維護者，他們在同一個團隊，他們也會因為資料的不一致而產生矛盾。跨團隊間關於資料不一致的問題頻率可能更高，CMDB的某一條資料的準確性可能是無關生死的問題，但如果整個CMDB的大部分資料都荒廢而陳舊，後面的CMDB管理工作將如大廈將傾，岌岌可危，沒有人再對CMDB負責，最終是為了資料準確性而定期的做一次“資產盤點”，重要時刻資料用不上，每隔一段時間還要增加工作負擔，事實上推動另一個團隊人員及時的錄入一條“無關緊要”資訊非常之難。
我們第一個要識別的是CI的OWNER，CI的OWNER對資料的準確性負責。他們不一定是資料的維護者，他們更多的是承擔起對資料準確性的審計、受理資料異常問題、推動資料維護者及時更新、修正資料。對於資料維護者而言，他們的KPI與他們維護的資料準確性是直接掛鉤的，資料維護者的維護動作一般是嵌入在某個變更流程中的。被升級出來的資料異常應以變更質量問題處理。
13.3.2 識別CI的生命週期、關聯運維流程
將CI的維護關聯到運維流程之中是保證CI的資料準確性另一手段。要將CI的維護關聯到運維流程之中就必須先識別CI的生命週期。
不是所有的CI都需建立生命週期，生命週期的出發點是保證資料準確性以及資源的有效利用，只有那些資源寶貴、功能獨一、具有明顯生存期的CI才需要建立。比如硬體伺服器資源、SAN儲存卷資源是很寶貴的。一條生產專線的建設本來就分為提交、勘察、建設、測試、上線等生命週期步驟。對於這些特殊的CI我們應當識別出來，定義其生命週期屬性。
下面流程是一個典型的硬體系統生命週期：
申請：每一個生命週期都是有一個起點的，他可能是有一個運維申請流程引發，這個時候我們定義了一條空資料的CI物件。
受理：申請必須被授權以確保它符合預算和其他要求。大多陣列織都有正式的程式對於新技術要求授權。
安裝：當申請的裝置是符合規格的，那麼運維服務支援團隊開始對它進行安裝部署工作，這部分的內容是巢狀在運維流程之中的。
測試：對新安裝部署的裝置進行測試，確認它滿足生產執行的要求。
上線：一旦裝置經過前期幾步驟，則正式上線執行。
下線：當裝置不再需要或無法滿足我們要求時，安排其下線。
我們在不斷的詢問，下一步做什麼？在某些情況下我們可以設定一個定時器，或者依據一些依賴條件進行自動檢測，不管是定時器還是檢測，他們所要完成的任務都是“提醒”我們需要進入生命週期的下一個階段了。定時器適用於租期到期的情況，而依賴條件則適用與檢測上層依賴資源是否存在，比如一臺已上線的伺服器上沒有應用了，CMDB的報表功能會“提醒”我們是否下線該伺服器。
CI的生命週期可以嵌入到運維管理流程的，在一個具體的變更步驟中可以定義是否修改一個CI的哪些屬性。
13.3.3 資料有效性的審計
在確認CI的OWNER，並將CI生命週期嵌入到運維流程之中後，可能還是無法保證資料的正確性，因此還需要建立起配置管理審計機制來保證資料準確性。
審計工作發生在日常的運維中，CMDB資料的使用者發現數據異常後需要有途徑立即受理，記錄下問題後更新CMDB，而不是置之不理。配置管理審計類似於資產的盤點，企業應根據需要設定週期，一般一年至少展開一次。另外，CMDB還可以就一定的範圍進行專項審計，從而小範圍、細緻地核查某類CI或某項關鍵服務所涉及的CI"賬實相符"的狀況。當CMDB審計發現數據不符時應儘快查明原因，並通過變更工單提請變更，最終修改CMDB資料。CMDB審計流程應該獨立展開，審計員應由專門成立的監管部門擔任。