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