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

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

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

二、 DCIM落地的困惑

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

三、 DCIM的方向

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

四、 落地要怎么做

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

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

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