近在做數(shù)據(jù)中心基礎設施運維的落地工作，突然有了很多的感悟，所以想把此時此刻的想法分享出來。作為一個行業(yè)的小學生，還希望各位業(yè)內前輩斧正。

一、 EMS/BMS到DCIM過度的必然性

在上古時代，數(shù)據(jù)中心或者說機房監(jiān)控系統(tǒng)受制于成本、架構、業(yè)務連續(xù)性要求以及管理水平的局限，只能停留在對大間隔少量數(shù)據(jù)源的數(shù)據(jù)抓取。由于監(jiān)控模型的構建很粗糙，收集到的數(shù)據(jù)并不能準確描述數(shù)據(jù)中心情況，并對運維、后期建設等活動提供有效的指導意見。但隨著業(yè)務對服務依賴的增加，數(shù)據(jù)中心越來越不能停，越來越不敢停，基礎設施的故障通過網(wǎng)絡、主機、數(shù)據(jù)庫等系統(tǒng)的放大效應，會對業(yè)務造成不可挽回的損失，因此業(yè)主方從業(yè)務連續(xù)性的需求出發(fā)希望機房管理系統(tǒng)能夠細化監(jiān)控的模型，將監(jiān)控的觸手深入各個系統(tǒng)的內部，抓取更多的監(jiān)控數(shù)據(jù)，實現(xiàn)更細的監(jiān)控力度，同時希望數(shù)據(jù)中心能一定程度的體現(xiàn)算力的需求。這個期望可以分為兩類分支，一類是對數(shù)據(jù)量的渴望，一類是對引入更多變量的需求。對數(shù)據(jù)量的渴望仍在傳統(tǒng)EMS/BMS概念的范疇內，如增加更多的監(jiān)控點、建立容納制冷、供電等多子系統(tǒng)的集中式管控平臺等。而對更多變量的需求就超出了傳統(tǒng)的EMS/BMS的范疇。算力這個元素無法準確有效的安置在現(xiàn)有EMS/BMS框架中，所以行業(yè)領先的公司對管理模型進行升級提出了DCIM概念，將算力這個需求與現(xiàn)有監(jiān)控進行了整合，形成了一個全新的描述模型并配備了相應的落地產(chǎn)品。在我看來DCIM理論的推出是管理水平提升的必然結果，是將算力與支持平臺溝通博弈的產(chǎn)物。

二、 DCIM落地的困惑

DCIM落地并不好，業(yè)主對DCIM產(chǎn)品評價普遍不高，造成這個結果，我個人認為是兩個方面的原因。第一個是溝通管理的問題，在傳統(tǒng)的IT組織里數(shù)據(jù)中心管理人員與算力的管理人員通常是數(shù)個獨立且平等的部門，有著完全平行的匯報路徑，這個路徑的終點甚至可能是不同的VP。同時由于技術門檻數(shù)據(jù)中心的管理人員看算力的管理人員完全一個黑盒即不知道他們的需求也不懂他們的痛點，當然算力的管理人員也一樣，所以DCIM雖然將算力需求納入了統(tǒng)一的管理平臺，但平臺并沒有提出一套各方都能聽懂的語言進行溝通。第二個是立場問題。市場上現(xiàn)有的DCIM廠商基本都來自于傳統(tǒng)動環(huán)行業(yè)或者傳統(tǒng)設備廠商，如施耐德、ABB、艾默生、共濟等，這些廠商對DCIM的理解通常都是依托于歷史經(jīng)驗，所以這些廠商的DCIM都是從基礎設施出發(fā)，到基礎設施結束，系統(tǒng)試圖強行塞給算力管理人員一個結果，而不是聽取算力管理人員的需求，并給予正面反饋。這個說起來有點拗口，不如舉個栗子，如果一個飯館想改菜譜優(yōu)化效率，那么究竟大堂經(jīng)理更有發(fā)言權還是廚師長，我個人認為是大堂經(jīng)理，因為大堂經(jīng)理更貼近終用戶，更懂得服務的接受者想要什么，所以返回來我覺得DCIM的落腳點應該是算力管理人員，應該從算力管理人員的需求出發(fā)建立一套算力與基礎設施之間溝通的通道，并將雙方聽不懂的內容進行有效封裝，形成一個可以進行溝通的平臺。

三、 DCIM的方向

既然說了DCIM的由來和現(xiàn)狀，不如我們再進一步暢想一下DCIM的未來。在暢想前，我們先來來明確一個基本概念，在一個組織中IT運維部門交付的究竟是什么？或者說什么才是IT運維的核心價值。我個人的理解是服務，無論是傳統(tǒng)的金融行業(yè)、制造業(yè)還是新興的互聯(lián)網(wǎng)行業(yè)，IT運維都是在交付一個可以滿足業(yè)務需求的算力服務。也就是說考核IT運維的核心SLA就是算力服務的交付程度，包括服務的可用性、服務的響應、服務的能力等各方面。建立了這個基礎之后我們回看DCIM，就可以看出目前的DCIM還是存在一定的局限性，這個系統(tǒng)并不能與終的服務進行掛鉤，服務的需求需要通過算力平臺的翻譯傳遞到基礎設施，這即存在響應和交付時效性的問題，也存在傳遞噪音的問題。所以我覺得DCIM向前發(fā)展應該是引入更多需求源，感知算力、感知服務、感知業(yè)務，將管控點向上延伸，直達IT運維交付的本質，即為業(yè)務提供服務。同時DCIM也應該向下延伸，將數(shù)據(jù)中心運維工作納入系統(tǒng)管理，保證系統(tǒng)響應的一致和準確，即補全歷史欠賬，成為一個可以指導運維的DCOS系統(tǒng)。

四、 落地要怎么做

看本文的讀者可能也會參加很多行業(yè)盛會，大部分的行業(yè)盛會有一個共性，就是理念說的多，落地說的少。要做什么說的多，怎么做說的少。這并不是問題，方向在絕大多數(shù)情況下要比內容更重要，而且各機構實際情況千差萬別，落地各不相同。我個人就在文末拋個磚，斗膽說說我個人對DCIM系統(tǒng)落地的理解。在第三節(jié)我簡述了一下DCIM向上和向下發(fā)展的方向，那落地自然是向這兩個方面努力。先說說向上發(fā)展和封裝。目前的技術在海量監(jiān)控數(shù)據(jù)和統(tǒng)一監(jiān)控平臺方面已經(jīng)有了長足的進步，我在這里安利一個免費接口和一個開源監(jiān)控系統(tǒng)。接口是由Intel主導HP DELL 超微等眾多廠商參與的IPMI接口規(guī)范，這個接口規(guī)范廣泛的存在于各種主機設備中，這個接口的初衷是作為帶外管理，但是就我個人的經(jīng)驗這個接口并沒有被有效的利用，實際上這個接口可以在不影響服務器運算的情況下吐出溫度、電壓、風扇轉速、功率（待查證）等數(shù)據(jù)，可以有效的支持數(shù)據(jù)中心運維團隊進行服務器感知并制定相應的運維策略。那么問題來了，怎么取這些數(shù)，又怎么將他們與數(shù)據(jù)中心設施進行有效的鏈接和互動？這就是我要安利的下個東西，zabbix，zabbix是個經(jīng)歷過分布式考驗的監(jiān)控系統(tǒng)它能很好的支持openIPMI組件對主機進行感知同時也支持SNMP協(xié)議對基礎設施進行監(jiān)控。它的采集能力和控制能力由于被云計算洗禮過，因此計算能力完全不會成為瓶頸。個人建議算力運維人員通過這個系統(tǒng)梳理自己的需求，與數(shù)據(jù)中心運維人員在同一個平臺上進行對話。

說完了向上的落地，我們再來說說向下，這里我來安利一個開源的流程引擎，activiti。向下管理的關鍵是一致性服務的交付能力，我個人對服務交付一致性的理解是一套完整落地的運維制度。這個思路來自于Uptime組織，我認為數(shù)據(jù)中心的運維操作應該是一致的、無異議的、不依賴于個人技術水平的操作交付能力。具體到落地內容，我個人認為是兩個方面，一個是把事情做全，參考業(yè)內佳實踐、廠商維保要求等框架性建議把運維操作的列表做完整。一方面是把事情做對，運維操作每步應該細分到完全無異議且不能再分割，有統(tǒng)一的客觀的不依賴人員判斷的標準進行衡量。當然這些是只是第一步，持續(xù)的改進才是落地的關鍵，流程應該具備良好的功能和穩(wěn)定的性能，這個可以參考ITIL佳實踐，用一套ITSM進行落地或者用上面提到的那個流程引擎與向上管理的zabbix進行整合。

以上就是我個人對數(shù)據(jù)中心監(jiān)控管理這件事的理解和暢想。受制于個人能力水平和眼界的限制，本文肯定有很多謬誤之處，還忘各位前輩、專家不吝賜教。