Windows centos 程序员 apache google 云计算 编程 linux 微软 开源 Android Firefox Ubuntu nginx php Python java wordpress shell mysql

優雲運維經驗分享之 – 剖析CMDB的設計過程

15a37a792adbc41678603b033d6802e2315521c7

作為IT管理的核心,CMDB逐漸成為系統管理項目實施的熱點。在很多的案例中,由於忽視了CMDB的因素,ITIL的深入應用受到了極大的挑戰。同時,由於CMDB是IT管理信息的集中,CMDB也是一個重要的工具和手段。

在CMDB落地過程中需要註意的是,CMDB項目不是一個簡單的軟件安裝過程,而是一個咨詢、培訓、實施、優化密切結合的綜合過程,涉及到平臺工具采購、咨詢服務、實施服務、培訓、甚至擴展開發等內容。同時,一個成功的CMDB項目不能一蹴而就,而是一個循序漸進、持續發展的過程,需要企業後續的投入和不斷改進服務。

廣通軟件在2004年就開始ITIL落地的嘗試,並獨立自主持續研發積累,形成CMDB為核心的運維解決方案,這兩年為海關總署、中國航信、鐵路總公司、浙商銀行、黑龍江農信等政企用戶,提供了專業的CMDB咨詢設計及落地實施服務,在整個過程中,筆者深深的體會到,CMDB項目的成功,重中之重在於CMDB模型的頂層設計,下面針對CMDB的設計過程進行深入剖析。

·        了解企業政策

企業政策,是企業管理的行動指南和共同綱領,它使企業在認識上形成統一,減少了不必要的溝通成本,並使企業在流程執行上事半功倍。對於構建CMDB而言,主要有以下兩類政策需要重點關註:

·        宏觀政策:主要是涉及IT部門層面指導性、方向性的政策,其目標是在IT部門自上而下形成統一認識,從而有利於項目的成功。

·        運營政策:主要涉及到流程目標、人員、輸入、輸出、活動以及KPI(關鍵績效指標)等各要素以及流程之間相互協調、信息交互方面的指導原則,其目標是使流程能夠在政策的指引下穩健、有效地執行。

·        確定配置項管理範圍

·        確定CI寬度和深度,建議遵循如下原則:

·        企業IT服務的需要(為什麽要實施CMDB)

·        相關法案和法規對IT管理的需求

·        IT庫存和資產管理的需求

·        服務目錄的需求

·        企業IT服務管理的水平(依據目前的管理水平能做到什麽程度)

·        有沒有制定與配置項相關的管理規範和制度

·        有多少人可以參與管理和維護

·        有沒有一套可落地的變更流程來對CI項必要的維護

·        企業CMDB運營管理成本(後期能夠投入多大的人力成本去維護和管理)

·        為保障CI項的準確性和表單數據的鮮活性,配置項維護的人力成本

·        部門間的內部溝通成本

·        確定CI生命周期

ITIL規範認為,CI的生命周期是從CI的接收到最終報廢退出的全過程,但在具體實施過程中,由於流程管理主體的差異化,不同項目對CI生命周期的劃分和定義會有所不同,主要針對如下兩個問題的確定。

·        何時生?(識別CI並記錄到CMDB)

·        何時滅?(對CI記錄進行刪除)

·        構建符合用戶的CI模型分類

定義配置項屬性(一個原則+一套結構)

·        一個原則:“精而不多”。如果我們將大量的配置項或屬性納入到CMDB中,那麽將存在大量信息需要進行維護,這無疑增加了成本。反之,如果屬性過少,維護工作雖然減輕了,但是CMDB的有效性就大大降低了。因此,“精而不多”就是我們的平衡點,這個‘精’主要體現在對企業有實際意義。

·        一套結構:我們通常可以把一個CI的屬性分為五大來源

模型分類設計樣例:

b1b122dffea1d25c676eba015de62d141c233e01

確定CI項的屬性

針對模型中的每個CI的屬性項進行調研,根據用戶實際需求進行調整、擴充或修改,包括:屬性項采用什麽類型比較合理(易於展現和維護),需要用戶提供哪些資料,例如:字典、默認值等信息。此過程同樣遵循“精而不多”的原則。

屬性設計樣例:

039d97e04e17a7edce18f5f53140dd859e4be4d6

定義CI項之間的關系

所有配置項都有存在的意義,而他們之間的內在關系是CMDB的重要價值體現之一,關系明確了,運維人員就能準確的找到相關實體資源,當發生故障時能夠快速定位故障來源及其影響範圍,從而迅速的解決各種隱患。

定義配置項關系,一般可使用兩種方法:

·        自上而下——通常要求企業先明確對外提供的服務目錄,然後基於服務目錄按照“業務服務→IT服務→IT系統→IT組件”的順序進行梳理

·        自下而上——則是逆流而上,先從對內部IT組件關系開始梳理,然後逐步將IT組件映射到IT服務

CMDB配置項關系設計樣例(以某個業務系統為例):

76d73d635558a8da17cf301aef175436e027ee0c

設計圖中,完整的展現了一個業務系統所有與之相關的配置項,分析如下:

·        邏輯關系——可以了解到,業務系統使用什麽中間件、數據庫用戶、實例以及表空間,運行在哪個操作系統上,使用了什麽ip地址等

·        物理關系——可以了解到,業務系統安裝在哪臺PC服務器上,PC服務器是通過哪臺交換機的什麽端口連接網絡的,同時PC服務器與存儲如何連接的,PC服務器存放在哪個機櫃和機房,以及PC服務器是通過哪個斷路器和UPS供電的等

以上信息對於運維人員來說,能夠更加清晰的掌握業務系統正常運轉的支撐點和來龍去脈,從而做到掌控全局。

結束語:

CMDB的設計過程是一個復雜且與用戶交互性非常強的過程,在此過程中需要充分讓用戶理解CMDB的概念以及相關原則,需要我們將後期維護CMDB可能帶來的風險和成本跟用戶做好充分的溝通,讓用戶去逐一去斟酌、考慮和規劃,從而避免CMDB項目的失敗,同時可以幫助用戶優化和完善CMDB管理制度,定義人員角色,並結合變更流程來保持配置的準確性和鮮活性,真正幫助用戶持續做好CMDB的維護,發揮CMDB應有的價值。

延伸阅读

评论