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

运维平台之CMDB系统建设

CMDB是運維的基礎核心系統,所有的元數據和共享數據管理源,類似於業務中的賬號平臺的作用。本篇文章,我將從概念篇、模型篇、到實現與實施篇具體的進行闡述。

CMDB也稱配置管理,配置管理一直被認為是 ITIL 服務管理的核心,因為其他所有流程均需要使用配置管理數據庫 (CMDB)。在上篇的平臺體系中,CMDB位於最底層的支持系統位置上,可見其作用。配置管理為什麽起到核心的作用,這個地方不做逐一介紹,簡單舉個例子,比如說變更系統發起了一個部署請求,要部署某個版本到現網,部署完成之後,上層的變更系統會把變更的結果寫到CMDB中,對配置進行歸檔;在某個機器down機,此時可以快速的知道該機器的具體用途,確定影響的業務;當機器需要重新恢復的時候,可以快速的根據CMDB中的信息進行恢復。

一、概念篇

1、配置管理和配置文件管理。

ITIL所講的配置管理是從軟件工程管理角度出發的,把一切對象都當做配置,比如說源代碼、文檔、人員、服務器甚至硬盤和內存等等。所以說他和業務程序的配置管理有著本質的不同,為了有效區分,我們又習慣說業務程序的配置管理叫配置文件管理。但又有著一定的聯系,在ITIL中,業務程序的配置可能會以一個配置項存在,附屬在應用程序上,具體什麽是配置項後面再解釋。

2、配置管理和資產管理

既然把一切資源對象都當做配置來看待,特別是服務器、機房、機櫃等等,那他和我們的資產管理又有著什麽樣的不同呢?其實這兩個系統的區別在很多時候大家都不是很清楚,會混為一談。具體的區別我之前做過一個總結,如下:

在上圖中,你把握核心的區別點就是導向,配置管理是面向業務管理,而非成本,這個會決定配置管理的粒度。當前如果業務非常簡單,不需要對服務器端口進行管理,此時則不需要考慮納入端口的管理,否則增加管理的代價。

3、配置項

配置項是指要在配置管理控制下的資產、人力、服務組件或者其他邏輯資源。從整個服務或系統來說,包括硬件、軟件、文檔、支持人員到單獨軟件模塊或硬件組件(CPU、內存、SSD、硬盤等等)。配置項需要有整個生命周期(狀態)的管理和追溯(日誌)。對配置項的分類,我一般從邏輯資源和物理資源兩個角度來分解,然後層次化分解,這個思路會讓你特別清晰,不會混亂。

 

4、屬性

一個配置項就是一個對象,有對象便有屬性,屬性是一個配置項的具體描述。比如說服務器這個配置項,他的具體描述有在哪個機房、哪個機櫃的哪個位置、現在是否有業務運行、具體誰負責等等。在後面的模型篇裏會對屬性做全面的梳理,完成現實世界到模型世界的轉換。另外配置項和屬性可以轉換,比如說ip地址,他肯定是一個資源對象存在。但是從服務器的角度來說,它作為一個屬性存在,更準確的說是網卡的屬性。

二、模型篇

我為什麽把模型單獨提取出來,因為它是CMDB建設的核心,缺少對業務的準確理解,則沒法準確的提取配置項及其屬性。在這個環節中,模型的核心職責,就是把配置項和屬性逐條的梳理出來。本人在模型整理的時候,重點做了四個方面工作,然後形成規範手冊。

1、配置管理系統的角色

可以簡單分成幾類角色,第一、應用運維,負責服務器上的業務信息維護;第二、基礎運維,負責機房、機櫃及其服務器物理信息的準確性;第三、配置管理員,負責基礎信息的維護,比如說業務分類,人員信息;第四、查詢類角色,比如研發。CMDB是核心的資源信息管理系統,一般不輕易開放權限。

2、配置項識別與定義

這是重點工作,沒有簡單的方法可循,細致活,基於上圖的【配置項】的物理資源和邏輯資源的不斷分解,根據業務需要最終識別出要管理的配置項。然後對每一個配置項進行整理,確定要管理的屬性。形成類似的下表:

就拿最核心的服務器資源來說,會形成如下表的信息整理:

逐個進行整理,在上表中有幾個方面需要註意:

第一、每個配置項目確定了維護角色,他在後續的過程中,需要對這個準確性負責,確定維護的職責邊界。

第二、要整理出配置項的關聯,比如說上表中的所屬機房、所屬機櫃。

第三、這個表不是數據庫的設計表,具體數據庫的設計表是開發人員根據這個模型參考實現。

3、基於場景的配置管理規範

配置管理的核心目的是為了確保配置信息集中管理,並且是準確的管理。在這個裏面需要做兩個核心的工作。

第一、配置項的規範化管理;

第二、面向配置項的流程規範化管理,沒有一套與之匹配的配置流程,最後配置管理都會混亂不堪,這個系統也就形同虛設。

此時沒有捷徑,識別配置管理的場景,把每個流程清晰的畫出來,比如說服務器管理,它就涉及到服務器上架、服務器搬遷、服務器下線、服務器申請、服務器回收等流程。比如拿服務器回收流程來說,流程圖如下:

註意上圖中,在服務器回收的過程中,行是角色,列是階段,在每個階段,服務器的狀態可能發生變化,此時也需要做備註。方便後續開發人員在做相應的流程實現的時候,控制這類狀態。狀態的轉換對監控也有影響。

4、狀態變遷圖

用一張圖來說明資源狀態的變化,便於更好的基於場景和變更來控制配置項狀態的變更,其實也就是它的生命周期管理。舉例如下:

這些方法都是以前面向對象設計裏面的內容,我覺得在CMDB配置管理工作中,有很大的作用,在一張紙上,你就可以看到狀態如何變化,然後是哪個場景促使變化,這些場景最終就會轉換成CMDB的某個功能或者某個流程。

三、實現篇

系統實現非常簡單,簡單理解就是一個配置的信息管理+流程管理,一個開發熟手,一個月就可以開發完成。難點還是在配置項識別,一定要做足功夫,把配置項的屬性、流程、狀態都整理清楚,最後按照這個來系統實現就OK了。不過在系統建設中,有一個經驗大家可以參考:CMDB一定要變成運維和運維研發的共同項目,並且具體的配置項管理人要全程參與,比如說需求討論、測試、上線驗收等等(運維研發項目都可以遵循該模式)。像上面的配置項最好能找一個對全局了解的人來做,不一定是研發。

四、實施篇

其實CMDB真的是非常簡單的系統,至少在兩家公司做的CMDB都是非常短的時間完成,最多兩個月。但是其實施的過程很多經驗可以分享。

1、導致CMDB失敗的因素

A、缺少管理層承諾----沒有管理層的承諾,CMDB不可能成功。

B、在復雜流程上消耗太多的時間---我們是創建一個CMDB庫,不是一個流程系統。

C、沒有創建相應的工作指導文檔---指導如何管理和維護CMDB。

D、沒有指定配置項負責人----確保配置項有人專職維護。

E、目標過大,涵蓋太多的功能----比如說IT采購和預算管理等等。

F、顆粒度不合適----配置合理的CMDB的配置項層次和粒度非常重要。

G、存在組織隔閡----CMDB是一個集成體系,靠流程中的每一個人通力協作,而不是某個人。

2、導致CMDB成功的因素

A、業務導向。比如說我們在CMDB的新的系統中實時加入QR碼技術,為了降低資產盤點的工作量。

B、能自動發現就自動發現,降低配置管理的成本,但自動發現的信息不能用來做告警。

C、配置項的管理員必須全程參與,需求定型、測試及驗收等等。

D、CMDB系統建設完成之後,其他系統必須和他聯動。比如說監控、質量、容量等等,用場景驅動配置項的管理。

E、流程一定要平臺化,不要讓流程脫離CMDB存在,比如說搞一個OA流程,這個是很致命的。

F、CMDB要持續演進,特別是雲端資源的管理。

G、配置項和流程必須要文檔化,後期要進行CMDB培訓。

延伸阅读

评论