CMDB開發

淺談ITIL

TIL即IT基礎架構庫(Information Technology Infrastructure Library, ITIL，信息技術基礎架構庫)由英國政府部門CCTA(Central Computing and Telecommunications Agency)在20世紀80年代末制訂，現由英國商務部OGC(Office of Government Commerce)負責管理，主要適用於IT服務管理（ITSM）。ITIL爲企業的IT服務管理實踐提供了一個客觀、嚴謹、可量化的標準和規範。

一、事件管理（Incident Management）

事故管理負責記錄、歸類和安排專家處理事故並監督整個處理過程直至事故獲得解決和終止。事故管理的目的是在儘量最小地影響客戶和用戶業務的狀況下使IT系統恢復到服務級別協議所定義的服務級別。

目標是：在不影響業務的狀況下，儘量快速的恢復服務，從而保證最佳的效率和服務的可持續性。事件管理流程的創建包括事件分類，肯定事件的優先級和創建事件的升級機制。

二、問題管理（Problem Management）

問題管理是指經過調查和分析IT基礎架構的薄弱環節、查明事故產生的潛在緣由，並制定解決事故的方案和防止事故再次發生的措施，將因爲問題和事故對業務產生的負面影響減少到最低的服務管理流程。與事故管理強調事故恢復的速度不一樣，問題管理強調的是找出事故產生的根源，從而制定恰當的解決方案或防止其再次發生的預防措施。

目標是：調查基礎設施和全部可用信息，包括事件數據庫，來肯定引發事件發生的真正潛在緣由，一塊兒提供的服務中可能存在的故障。

三、配置管理（Configuration Management）

配置管理是識別和確認系統的配置項，記錄和報告配置項狀態和變動請求，檢驗配置項的正確性和完整性等活動構成的過程，其目的是提供IT基礎架構的邏輯模型，支持其它服務管理流程特別是變動管理和發佈管理的運做。

目標是：定義和控制服務與基礎設施的部件，並保持準確的配置信息。

四、變動管理（Change Management）

變動管理是指爲在最短的中斷時間內完成基礎架構或服務的任一方面的變動而對其進行控制的服務管理流程。變動管理的目標是確保在變動實施過程當中使用標準的方法和步驟，儘快地實施變動，以將由變動所致使的業務中斷對業務的影響減少到最低。

目標是：以受控的方式，確保全部變動獲得評估、批准、實施和評審。

五、發佈管理（Release Management）

 發佈管理是指對通過測試後導入實際應用的新增或修改後的配置項進行分發和宣傳的管理流程。發佈管理之前又稱爲軟件控制與分發。

目標是：在實際運行環境的發佈中，交付、分發並跟蹤一個或多個變動。

實際工做場景中自動化工具舉例：

CMDB

CMDB --Configuration Management Database 配置管理數據庫, CMDB存儲與管理企業IT架構中設備的各類配置信息，它與全部服務支持和服務交付流程都緊密相聯，支持這些流程的運轉、發揮配置信息的價值，同時依賴於相關流程保證數據的準確性。

在實際的項目中，CMDB經常被認爲是構建其它ITIL流程的基礎而優先考慮，ITIL項目的成敗與是否成功創建CMDB有很是大的關係。

70%～80%的IT相關問題與環境的變動有着直接的關係。實施變動管理的難點和重點並非工具，而是流程。即經過一個自動化的、可重複的流程管理變動，使得當變動發生的時候，有一個標準化的流程去執行，可以預測到這個變動對整個系統管理產生的影響，並對這些影響進行評估和控制。而 變動管理流程自動化的實現關鍵就是CMDB。

CMDB工具中至少包含這幾種關鍵的功能： 整合、調和、同步、映射和可視化。

• 整合是指可以充分利用來自其餘數據源的信息，對CMDB中包含的記錄源屬性進行存取，將多個數據源合併至一個視圖中，生成連同來自CMDB和其餘數據源信息在內的報告；
• 調和能力是指經過對來自每一個數據源的匹配字段進行對比，保證CMDB中的記錄在多個數據源中沒有重複現象，維持CMDB中每一個配置項目數據源的完整性；自動調整流程使得初始實施、數據庫管理員的手動運做和現場維護支持工做降至最低；
• 同步指確保CMDB中的信息可以反映聯合數據源的更新狀況，在聯合數據源更新頻率的基礎上肯定CMDB更新日程，按照通過批准的變動來更新 CMDB，找出未被批准的變動；
• 應用映射與可視化，說明應用間的關係並反應應用和其餘組件之間的依存關係，瞭解變動形成的影響並幫助診斷問題。

---

  　 CMDB是運維自動化項目，它可以減小人工干預，下降人員成本。

　　功能：自動裝機、實時監控、自動化部署軟件，創建在它們的基礎上是資產信息變動記錄（資產管控自動進行彙報）

 

1、在對獲取資產信息時，簡述有四種方案。

一、Agent  （基於shell命令實現）

 

 

　　　　　　　　　　　　　　　　　　原理圖

 

Agent方式，能夠將服務器上面的Agent程序做定時任務，定時將資產信息提交到指定API錄入數據庫

優勢：速度快 缺點：須要爲每臺服務器部署一個Agent程序

 二、Paramiko類 （SSH形式，基於Paramiko模塊）

中控機在獲取未採集資產信息的服務器（服務器主機名，密碼），依賴於Paramiko（py模塊）經過SSH方式去獲取

優勢：無Agent  缺點：速度慢

若是在服務器較少的狀況下，可應用此方法

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

import  paramiko     # 建立SSH對象 ssh  =  paramiko.SSHClient() # 容許鏈接不在know_hosts文件中的主機 ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy()) # 鏈接服務器 ssh.connect(hostname = 'c1.salt.com' , port = 22 , username = 'dfsdgi' , password = '123' )     # 執行命令 stdin, stdout, stderr  =  ssh.exec_command( 'df' ) # 獲取命令結果 result  =  stdout.read()     # 關閉鏈接 ssh.close()

 

三、SaltStack

　　此方案本質上和第二種方案大體是差很少的流程，中控機在獲取到未採集資產信息的服務器（主機名），再而將命令放入一個隊列中，服務器來獲取。服務器將結果放入另外一個隊列中，中控機獲取將服務信息發送到API進而錄入數據庫。

基於SaltStack的master上的pillar以及遠程執行命令實現

1 2 3

import  salt.client local  =  salt.client.LocalClient() local.cmd( '*' ,  'cmd.run' , [ 'whoami' ])

優勢：快，開發成本低  缺點：依賴於第三方工具

 

四、Puppet（ruby語言開發）
基於Puppet的factor和report功能實現

小結：

• 採集資產信息有四種不一樣的形式（但puppet是基於ruby開發的）
• API提供相關處理的接口
• 管理平臺爲用戶提供可視化操做

2、開發cmdb程序

開發程序設計爲可插拔機制。（好處：擴展性強）

開發一套程序時，要使其有充分的擴展性。接下來能夠寫一些僞代碼...

一、假設項目名爲AutoClient, 目錄結構以下：

AutoClient/
|-- bin/ | |-- auto_client.py |-- config/ | |-- settings.py |-- lib/
| |--
|-- log/ | |-- error.log | |-- run.log |-- src/ | |-- plugins/
| |-- __init__.py
| |-- base.py
| |-- cpu.py
| |-- ...
| |-- scripts.py |-- README

例如，採集資產信息有三種形式，而將要作的一件事就是要讓程序兼容這三種形式 

3、CMDB數據庫設計