上周，我参加了一场运维数据治理的结项汇报。这个项目已经完成了两期。汇报会上大家回顾了这两三年在运维数据治理走过的路。从懵懵懂懂到找到感觉，再到步入正轨，感慨颇多。

是不是很奇怪，我们准备谈CMDB，为什么会从运维数据治理开始？因为从现在开始，我们做产品线的时候，对CMDB做了一次类别上的重新划分。不再把CMDB归入运维类产品线，而是换个维度去看CMDB，将其归入数据治理类。大家可以思考一下：ITSM建设+CMDB建设 Vs 运维数据治理+CMDB建设，哪一个结合更香？

越来越多的IT组织在重建ITSM系统时，往往是把CMDB建设单独看待。这是对的，而且是英明的决定！为什么呢？因为时代变了，形势变了，对ITSM的需求也变了。大家已经不满足于CMDB只为流程服务，只为工单服务。CMDB承担的责任、期望正变得越来越大，越来越超出传统定义的范畴。但ITSM工具的本质没有变，而且也不需要变，那么能变的就只有拿CMDB开刀了！

CMDB我之前说过，这个只是配置管理体系的（CMS）的代名词。配置管理体系虽然相对来说比较庞大，但其管理核心只有一个，即确保运维数据的完整、准确。所有体系的运作都是围绕运维数据展开。比如配置管理流程，收集和使用运维数据；CMDB采集、存储和创建运维数据的拓扑关系；定期审计确保运维数据的账实相符等等。

ITSM建设+CMDB建设是传统运维的思路，寄希望于ITSM产品的重构带来CMDB的重生。运维数据治理+CMDB建设是基于数据运维的思路，希望通过数据运维的方式，以数据治理为手段，先标准化、再场景化、最后工具建模，实现“以数据质量为核心，以场景为导向，以消费为价值”的运维数据治理。

在运维数据治理的大框架下，配置管理体系从属于运维数据管理能力，CMDB从属于运维数据保障能力里的平台能力。这就是我们要对CMDB重新分类的原因。因为我们必须从数据运维的角度重新看待CMDB的现实价值和未来的发展潜力！

以上代表我们运维数据治理产品线对CMDB的思考。