你所不知道的CMDB | CMDB起源与发展

一、CMDB起源

在今天，配置管理数据库（CMDB，后面均用这个简称，并且暂时不去区分CMDB和CMS）这个名词对于IT从业人员来说一点都不陌生，甚至有点烂熟了。无论是ITIL在企业落地、自动化运维、标准化运维、DevOps、端到端统一监控，甚至最时髦的运维大数据、智能运维（AIops）等都很难绕开CMDB这个概念。说CMDB是企业IT运维标准化、自动化、数据化和智能化的基石，相信现在应该没有多少人反对了。

尽管在此之前，和CMDB类似的信息库已经被IT部门使用了多年，但是CMDB这个名词其实是源自ITIL（Information Technology Infrastructure Library，信息技术基础架构库），CMDB最开始出现应该是在ITIL V2.0中，其中对于配置管理的定义是这样的：

• Identify, record and report all IT components that are under the control and scope of CM
• Provide a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of CIs in existence
• CM is basis for other processes

看不懂，是吧？我也看不懂，没事，有中文翻译，请看下面。

“CMDB，Configuration Management DataBase，配置管理数据库，是与 IT 系统所有组件相关的信息库，它包含 IT 基础架构配置项的详细信息。”——CMDB

“由识别和确认系统的配置项、记录和报告配置项状态和变更请求、检验配置项的正确性和完整性等活动构成的服务管理流程。”——配置管理

• 计量组织和服务中所使用的所有IT资产和配置项的价值；
• 为其它服务管理流程提供有关IT基础架构配置的准确信息；
• 为事件管理、问题管理、变更管理和发布管理的运作提供支持；
• 核实有关IT基础架构的配置记录的正确性并纠正发现的错误。

ITIL理论体系大致经过了下面三个阶段和版本：

• ITIL V1——1986~1999 由英国国家计算机和电信局（CCTA）实践开发的，总共有40多卷图书，出来后很快得到了欧洲的认可；
• ITIL V2——英国商务部（OGC）在1999年推出来的，得到了世界的认可。OGC把它总结为10本图书；它的发展非常快，到2001年，被接纳为英国国家标准BS15000；2005年，被接纳为国际标准ISO20000；
• ITIL V3——到了2007年5月30日颁布了3.0版本，基于服务生命周期与时俱进地融入了IT服务管理领域当前的最佳实践。

可以看到，早在1999年英国国家计算机和电信局（俗称英国电脑局）就推出V2版本和CMDB概念，那么为什么直到最近几年，CMDB才开始在无论传统企业还是互联网企业声名鹊起，并被我们熟知呢？大致分析起来，应该有以下几个原因：

1、中国的IT进程本就落后外国很多年，1999年推出概念到被中国IT界知晓并理解，晚个10年左右是很正常的事情；无论是虚拟化、还是其他技术，基本上都会经历一个大致的延迟才能在中国得到认知；

2、早些年，中国的传统企业要么IT规模和复杂度有限，要么即便IT规模很大但是环境迭代十分缓慢（几年甚至10几年不升级软硬件系统是家常便饭），因此即便用“文档+人肉”的方式，企业IT环境管理也没有多少痛楚；而那个时间的中国互联网公司，普遍处于成长过程中，还没有形成自己特有的配置管理方法论，更谈不上理念和技术输出；

3、随着中国企业IT规模和复杂性的迅速增长，以及业务更新迭代的频率加快，对于IT运维的标准化、统一化和自动化需求水涨船高，传统的“文档+人肉”的方式难以吃得消，纷纷寻找技术解决方案，这个时候躺在角落里，身上覆满灰尘的“CMDB”君重新被挖掘出来，闪亮登场；

4、并且由于中国互联网企业的迅猛发展，导致事实上CMDB这个理念在传统企业和互联网公司中是以不同的方式和面目落地的：

• 传统企业更多的是与ITIL理念结合，作为ITIL中的一部分构建和部署；但由于ITIL的笨重、庞大与臃肿，真正把ITIL用得好的企业很少，导致CMDB后来在传统企业中往往沦为了纯粹的静态资产管理和数据查询，而且这种静态资产往往还是失真的和混乱的；过些年，又要重新梳理或者通过上一套新的系统来重建，再次折腾一遍，下层运维苦不堪言。
• CMDB这个概念在刚刚推出的时候，由于过于宽泛和模糊，即便被企业理解，也注定是难以落地和成功使用的。直到后来BMC等传统软件巨头在自家的ITIL相关产品中推出CMDB管理的产品和解决方案，CMDB才逐渐开始真正在国内外落地开花。而BMC等企业推出比较成熟的CMDB产品，其实已经到了2006年下半年。
• 互联网公司则要务实的多，对于CMDB的使用效果也好得多。在互联网公司，CMDB更多的是以应用发布、变更和管理为目的创建的：将与某个应用相关的从上层的进程、服务到底层的服务器、网络等配置悉数纳管，真正将CMDB的数据用起来；并且由于与应用管理流程打通，基本可以确保数据的质量。 当然，这也是个坎坷前进的过程，都走过不少弯路，并且由于互联网公司天生就不看重ITIL这种重流程的模式，因此CMDB早期在每家互联网企业中的使用注定是个性化的、很难具备通用性，更谈不上技术输出。经过重重演进和互联网界内部的反复交流和重新定义，CMDB逐渐形成大致统一的范式和标准，才有最近几年，互联网公司纷纷将自己对于CMDB最佳实践的理解对外输出到其他行业。

二、CMDB早期使用情况

美丽说的赵成同学，在他的技术专栏中，曾经描绘了与CMDB相关的这么一个案例：

“早期，大约是在2009~2013年，我接触了一个省级运营商的全国性项目。2012年的时候日PV就到了5亿左右，日订单创建接近2000万。分层的软件架构，不到千台服务器，对于资源的管理，仍然是用Excel表格来记录的。

运维基于这样一个表格去管理和分配各种资源，问题也不算太大。究其根本，就是基础设施层面的架构形态相对稳定，有稳定的软件模块数量和架构。但是发展到后来，这样的软件架构无法满足业务的快速迭代，还是做了架构上的拆分，这就是后话了。

这里我想表达的是，在那个时期，即使是在IT架构相对先进的运营商体系下面，我也没有太多地听说过CMDB这个概念，包括运营商自身，以及为运营商提供整体技术解决方案的厂商，还有来自方方面面的资深架构师和咨询师等，在做系统架构和运维架构设计时，没有人提及过CMDB，也没有人提出把它作为核心部件去建设，更多的都是从ITIL管理服务的流程体系去给出咨询建议；在落地实施的时候，我们最终见到的大多是一条条的流程规范和约束，后来增加的也多是流程和审批，甚至是纸质的签字审批。

这也从一个侧面说明，CMDB在那个时期更多的还是停留在概念阶段，甚至是无概念状态，也没有什么最佳实践经验的传承，CMDB这个概念本身并不具备实践意义，管理的方式方法也就停留在原始的Excel表格中。高大上的ITIL体系更多的是被当做流程规范来落地的，真正体现在技术方案和技术产品上的落地并不多。我想这是实施过程中对ITIL理解和运用的一大误区。”

瀚纬科技的合伙人张亮同学曾经在他的一次分享中描述过了他所经历的国内CMDB的发展历史：

• 2004年 我从04年开始参与国内某银行的CMDB建设，这时CMDB的典型场景是资产信息的电子化。配置信息的采集主要采用Excel导入的方式，CMDB模型需要提前预设，不具备动态扩展能力，暂且称之为CMDB1.0。
• 2006年 到了06年，我在某银行主导实施了国内第一个基于BMC Atrium CMDB架构的CMDB项目，这时的CMDB开始侧重于与其他ITSM (IT Service Management，IT服务管理 )流程的协同以及故障、变更影响分析等诊断场景。 但由于配置数据的初始化工作仍然需要手工Excel导入，同时配置信息的更新也不及时（无法在一个变更窗口内更新完成），导致上层场景没有发挥作用。这个阶段我们称之为CMDB2.0。
• 2007年 从07年开始，配置自动化发现工具的引入，帮助企业极大简化了配置数据初始化工作。
• 2008年 紧接着，08年左右业界提出变更闭环的概念，即在变更结束后重新进行配置自动发现并更新配置信息。相比CMDB2.0阶段，配置信息更新实时性有一定程度提高。
• 2012年 12年一些银行开始尝试通过配置自动发现工具实现配置比对场景，尤其是灾备与生产环境配置比对，以及集群环境内任意两节点间的配置比对。
• 近几年 应该说，配置自动发现工具一定程度上降低了配置数据初始化和维护的难度，但限于配置自动发现工具的技术局限，发现时间往往较长，发现的信息也存在一定盲区，同时还需使用root等管理员账号，这些约束一定程度上影响了自动发现工具的实际使用效果。这个阶段我们称之为CMDB3.0。”

而据我个人的了解，即便是腾讯这样在国内和世界上处于技术领先地位的互联网公司，他们的核心业务部门也是在2008年左右开始CMDB系统的建设，并在随后数年反复更迭和演进，最终形成一个稳定的CMDB系统。

三、总结

由上可见，CMDB这个概念虽然早早由英国电脑局在ITIL中提了出来，但由于宽泛、模糊和缺乏工具，中间难以在企业落地；在此期间，企业更多的是以“文档+人肉”的方式实现ITIL中配置管理的一部分功能。

随后，随着ITIL的理念在全球的广泛流行和被认可，BMC等传统软件巨头纷纷跟进推出自有的CMDB产品和解决方案。但那个时候的CMDB依然只是一个静态的配置存储中心，问题一大堆，在2006的腾讯新闻中可以略窥一二：

“目前的CMDB产品还有许多需要改进的地方：首先是缺乏标准，ITIL只是提出要建CMDB，但对于怎么建、建成什么样的CMDB并没有明确的指导性意见，数据的整合、共享非常麻烦。

第二是和ITIL流程的集成性差，限制了CMDB充分发挥其价值，并且造成了CMDB信息无法通过流程提供准确的保障。

第三是和其他系统的集成性差，系统间的信息无法同步，造成信息的矛盾。

第四，缺乏自动化的配置采集，导致很多信息只能手工录入、人工维护，无法及时、准确地提供配置信息。”

（http://tech.qq.com/a/20061025/000443.htm）

之后，经过这些巨头在产品层面的反复迭代，最终CMDB在传统企业中才与ITIL方面的产品一道在传统企业落了家；但由于ITIL本身的厚重和难以驾驭，用好的依然不多。

由于中国的互联网公司从一开始走的就是开源软件和技术自研这条路，并且天生不看重ITIL这种重流程，因此CMDB事实上在互联网公司走的是另外一条以应用和业务管理为出发点和目标的道路。中间也是经历各种坎坷和坑，最终形成了适合互联网公司的一套CMDB建设和管理思路。虽然百花齐放，各自不同，但大体的思路和理念是想通的。

在下一篇文章中，我们一起聊下CMDB目前在传统非互联网企业以及互联网企业中的应用现状是怎样的，敬请期待。