近在做数据中心基础设施运维的落地工作，突然有了很多的感悟，所以想把此时此刻的想法分享出来。作为一个行业的小学生，还希望各位业内前辈斧正。

 

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

在上古时代，数据中心或者说机房监控系统受制于成本、架构、业务连续性要求以及管理水平的局限，只能停留在对大间隔少量数据源的数据抓取。由于监控模型的构建很粗糙，收集到的数据并不能准确描述数据中心情况，并对运维、后期建设等活动提供有效的指导意见。但随着业务对服务依赖的增加，数据中心越来越不能停，越来越不敢停，基础设施的故障通过网络、主机、数据库等系统的放大效应，会对业务造成不可挽回的损失，因此业主方从业务连续性的需求出发希望机房管理系统能够细化监控的模型，将监控的触手深入各个系统的内部，抓取更多的监控数据，实现更细的监控力度，同时希望数据中心能一定程度的体现算力的需求。这个期望可以分为两类分支，一类是对数据量的渴望，一类是对引入更多变量的需求。对数据量的渴望仍在传统EMS/BMS概念的范畴内，如增加更多的监控点、建立容纳制冷、供电等多子系统的集中式管控平台等。而对更多变量的需求就超出了传统的EMS/BMS的范畴。算力这个元素无法准确有效的安置在现有EMS/BMS框架中，所以行业领先的公司对管理模型进行升级提出了DCIM概念，将算力这个需求与现有监控进行了整合，形成了一个全新的描述模型并配备了相应的落地产品。在我看来DCIM理论的推出是管理水平提升的必然结果，是将算力与支持平台沟通博弈的产物。

 

二、 DCIM落地的困惑

DCIM落地并不好，业主对DCIM产品评价普遍不高，造成这个结果，我个人认为是两个方面的原因。第一个是沟通管理的问题，在传统的IT组织里数据中心管理人员与算力的管理人员通常是数个独立且平等的部门，有着完全平行的汇报路径，这个路径的终点甚至可能是不同的VP。同时由于技术门槛数据中心的管理人员看算力的管理人员完全一个黑盒即不知道他们的需求也不懂他们的痛点，当然算力的管理人员也一样，所以DCIM虽然将算力需求纳入了统一的管理平台，但平台并没有提出一套各方都能听懂的语言进行沟通。第二个是立场问题。市场上现有的DCIM厂商基本都来自于传统动环行业或者传统设备厂商，如施耐德、ABB、艾默生、共济等，这些厂商对DCIM的理解通常都是依托于历史经验，所以这些厂商的DCIM都是从基础设施出发，到基础设施结束，系统试图强行塞给算力管理人员一个结果，而不是听取算力管理人员的需求，并给予正面反馈。这个说起来有点拗口，不如举个栗子，如果一个饭馆想改菜谱优化效率，那么究竟大堂经理更有发言权还是厨师长，我个人认为是大堂经理，因为大堂经理更贴近终用户，更懂得服务的接受者想要什么，所以返回来我觉得DCIM的落脚点应该是算力管理人员，应该从算力管理人员的需求出发建立一套算力与基础设施之间沟通的通道，并将双方听不懂的内容进行有效封装，形成一个可以进行沟通的平台。

三、 DCIM的方向

既然说了DCIM的由来和现状，不如我们再进一步畅想一下DCIM的未来。在畅想前，我们先来来明确一个基本概念，在一个组织中IT运维部门交付的究竟是什么？或者说什么才是IT运维的核心价值。我个人的理解是服务，无论是传统的金融行业、制造业还是新兴的互联网行业，IT运维都是在交付一个可以满足业务需求的算力服务。也就是说考核IT运维的核心SLA就是算力服务的交付程度，包括服务的可用性、服务的响应、服务的能力等各方面。建立了这个基础之后我们回看DCIM，就可以看出目前的DCIM还是存在一定的局限性，这个系统并不能与终的服务进行挂钩，服务的需求需要通过算力平台的翻译传递到基础设施，这即存在响应和交付时效性的问题，也存在传递噪音的问题。所以我觉得DCIM向前发展应该是引入更多需求源，感知算力、感知服务、感知业务，将管控点向上延伸，直达IT运维交付的本质，即为业务提供服务。同时DCIM也应该向下延伸，将数据中心运维工作纳入系统管理，保证系统响应的一致和准确，即补全历史欠账，成为一个可以指导运维的DCOS系统。

 

四、 落地要怎么做

看本文的读者可能也会参加很多行业盛会，大部分的行业盛会有一个共性，就是理念说的多，落地说的少。要做什么说的多，怎么做说的少。这并不是问题，方向在绝大多数情况下要比内容更重要，而且各机构实际情况千差万别，落地各不相同。我个人就在文末抛个砖，斗胆说说我个人对DCIM系统落地的理解。在第三节我简述了一下DCIM向上和向下发展的方向，那落地自然是向这两个方面努力。先说说向上发展和封装。目前的技术在海量监控数据和统一监控平台方面已经有了长足的进步，我在这里安利一个免费接口和一个开源监控系统。接口是由Intel主导HP DELL 超微等众多厂商参与的IPMI接口规范，这个接口规范广泛的存在于各种主机设备中，这个接口的初衷是作为带外管理，但是就我个人的经验这个接口并没有被有效的利用，实际上这个接口可以在不影响服务器运算的情况下吐出温度、电压、风扇转速、功率（待查证）等数据，可以有效的支持数据中心运维团队进行服务器感知并制定相应的运维策略。那么问题来了，怎么取这些数，又怎么将他们与数据中心设施进行有效的链接和互动？这就是我要安利的下个东西，zabbix，zabbix是个经历过分布式考验的监控系统它能很好的支持openIPMI组件对主机进行感知同时也支持SNMP协议对基础设施进行监控。它的采集能力和控制能力由于被云计算洗礼过，因此计算能力完全不会成为瓶颈。个人建议算力运维人员通过这个系统梳理自己的需求，与数据中心运维人员在同一个平台上进行对话。

 

说完了向上的落地，我们再来说说向下，这里我来安利一个开源的流程引擎，activiti。向下管理的关键是一致性服务的交付能力，我个人对服务交付一致性的理解是一套完整落地的运维制度。这个思路来自于Uptime组织，我认为数据中心的运维操作应该是一致的、无异议的、不依赖于个人技术水平的操作交付能力。具体到落地内容，我个人认为是两个方面，一个是把事情做全，参考业内佳实践、厂商维保要求等框架性建议把运维操作的列表做完整。一方面是把事情做对，运维操作每步应该细分到完全无异议且不能再分割，有统一的客观的不依赖人员判断的标准进行衡量。当然这些是只是第一步，持续的改进才是落地的关键，流程应该具备良好的功能和稳定的性能，这个可以参考ITIL佳实践，用一套ITSM进行落地或者用上面提到的那个流程引擎与向上管理的zabbix进行整合。

 

以上就是我个人对数据中心监控管理这件事的理解和畅想。受制于个人能力水平和眼界的限制，本文肯定有很多谬误之处，还忘各位前辈、专家不吝赐教。