|
|
# 06 | 聊聊CMDB的前世今生
|
|
|
|
|
|
我们前面在讲标准化的时候，对关键的运维对象做了识别，主要分为两个部分：
|
|
|
|
|
|
* **基础设施层面**：IDC机房、机柜、机架、网络设备、服务器等；
|
|
|
* **应用层面**：应用元信息、代码信息、部署信息、脚本信息、日志信息等。
|
|
|
这两部分是整个运维架构的基础部分，运维团队是维护的Owner，需要投入较大的精力去好好地规划建设。
|
|
|
|
|
|
当我们识别出运维对象和对象间的关系，并形成了统一的标准之后，接下来要做的事情就是将这些标准固化，固化到某个信息管理平台中，也就是我们常说的**配置管理**，专业一点就叫作 **CMDB**（Configuration Management DataBase）。
|
|
|
|
|
|
其实，如果我们找准了需求和问题在哪里，你会发现技术手段和平台叫什么就真的不重要了，只要是内部能够达成一个统一共识的叫法就好。
|
|
|
|
|
|
关于如何打造CMDB和应用配置管理，我之前有一篇公开的文章《有了CMDB，为什么还需要应用配置管理》，写得已经比较细致了，会在下一期发布出来，但不占用我们专栏的篇幅。
|
|
|
|
|
|
今天我主要来聊一聊CMDB的前世今生，帮助你更加深刻地理解这个运维核心部件，对我们后面开展CMDB的建设大有裨益。
|
|
|
|
|
|
## CMDB源起
|
|
|
|
|
|
CMDB并不是一个新概念，它源于ITIL（Information Technology Infrastructure Library，信息技术基础架构库）。而ITIL这套理论体系在80年代末就已经成型，并在当时和后来的企业IT建设中作为服务管理的指导理论得到广泛推广和实施。但是为什么这个概念近几年才被我们熟知？为什么我们现在才有意识把它作为一个运维的核心部件去建设呢？
|
|
|
|
|
|
我想主要有两个因素，一个起了限制作用，一个起了助推作用。
|
|
|
|
|
|
* CMDB这个概念本身的定义问题，限制了CMDB的实施；
|
|
|
* 互联网技术的发展驱动了运维技术的发展和演进，进而重新定义了CMDB。
|
|
|
|
|
|
## 传统运维思路下的CMDB
|
|
|
|
|
|
我们先来看下第一个原因，按照ITIL的定义：
|
|
|
|
|
|
> CMDB，Configuration Management
|
|
|
> DataBase，配置管理数据库，是与IT系统所有组件相关的信息库，它包含IT基础架构配置项的详细信息。
|
|
|
|
|
|
看完上面这个描述，我们能感觉到，这是一个很宽泛的概念描述，实际上并不具备可落地的指导意义。事实上也确实是这样，稍后我们会讲到。
|
|
|
|
|
|
同时，CMDB是与每个企业具体的IT软硬件环境、组织架构和流程强相关的，这就决定了CMDB一定是高度定制化的体系。虽然我们都知道它不仅仅是一个存储信息的数据库那么简单，但是它的具体形态是什么样子的，并没有统一的标准。
|
|
|
|
|
|
**从传统IT运维的角度来看，运维的核心对象是资源层面**，所谓的基础架构也就是网络设备和硬件设备这个层面；各种关联和拓扑关系，基本也是从服务器的视角去看。所以更多地，我们是把CMDB建设成为一个以设备为中心的信息管理平台。
|
|
|
|
|
|
这也是当前绝大多数公司在建设运维平台时最优先的切入点，因为这些运维对象都是实体存在的，是最容易被识别的和管理的；像应用和分布式中间件这种抽象的逻辑对象反而是不容易被识别的。
|
|
|
|
|
|
这种形态，如果是在软件架构变化不大的情况下，比如单体或分层架构，以服务器为中心去建设是没有问题的。因为无论设备数量也好，还是申请回收这些变更也好，都是很有限的，也就是整个IT基础设施的形态变化不大。
|
|
|
|
|
|
我没有专门调研过国外的实施情况，但就国内的情形，谈下我的经历。
|
|
|
|
|
|
早期，大约是在2009~2013年，我接触了一个省级运营商的全国性项目。2012年的时候日PV就到了5亿左右，日订单创建接近2000万。分层的软件架构，不到千台服务器，对于资源的管理，仍然是用Excel表格来记录的。
|
|
|
|
|
|
运维基于这样一个表格去管理和分配各种资源，问题也不算太大。究其根本，就是基础设施层面的架构形态相对稳定，有稳定的软件模块数量和架构。但是发展到后来，这样的软件架构无法满足业务的快速迭代，还是做了架构上的拆分，这就是后话了。
|
|
|
|
|
|
这里我想表达的是，在那个时期，即使是在IT架构相对先进的运营商体系下面，我也没有太多地听说过CMDB这个概念，包括运营商自身，以及为运营商提供整体技术解决方案的厂商，还有来自方方面面的资深架构师和咨询师等，在做系统架构和运维架构设计时，没有人提及过CMDB，也没有人提出把它作为核心部件去建设，更多的都是从ITIL管理服务的流程体系去给出咨询建议；在落地实施的时候，我们最终见到的大多是一条条的流程规范和约束，后来增加的也多是流程和审批，甚至是纸质的签字审批。
|
|
|
|
|
|
这也从一个侧面说明，CMDB在那个时期更多的还是停留在概念阶段，甚至是无概念状态，也没有什么最佳实践经验的传承，CMDB这个概念本身并不具备实践意义，管理的方式方法也就停留在原始的Excel表格中。
|
|
|
|
|
|
**高大上的ITIL体系更多的是被当做流程规范来落地的，真正体现在技术方案和技术产品上的落地并不多。我想这是实施过程中对ITIL理解和运用的一大误区**。
|
|
|
|
|
|
接下来，我们看第二个原因，也就是互联网运维的助推力。
|
|
|
|
|
|
## 互联网运维体系下的CMDB
|
|
|
|
|
|
值得庆幸的是，进入到互联时代，**随着互联网运维力量的崛起，CMDB这个概念也真正地得到了落地实践，从理论概念的方法论阶段过渡到了具备具体技术方案的可实施阶段，而且得到了业界的持续分享和传播**。我们现在能够看到的CMDB经验分享，基本上都是中大型互联网公司的运维最佳实践。
|
|
|
|
|
|
不过，值得注意的是，“此CMDB”已经非“彼CMDB”。我们前面提到，传统运维阶段，我们更多是以设备为核心进行管理，但是到了互联网技术阶段，这个核心就变了，变成了应用这个核心对象。
|
|
|
|
|
|
至于原因，我们前面已经讲过，主要还是互联网技术的快速发展，大大推进了微服务技术架构的落地和实践，这种场景下，应用各维度的管理复杂度、应用的复杂度就逐渐体现出来了，所以我们的很多运维场景就开始围绕着应用来开展。
|
|
|
|
|
|
与此同时，云计算技术也在蓬勃发展，逐步屏蔽了IDC、网络设备以及硬件服务器这样的底层基础设施的复杂度，有公有云或私有云厂商来专注聚焦这些问题，让我们的运维不必再花过多的精力在这些基础设施上面；同时，单纯以硬件为核心的CMDB形态也被逐步弱化。
|
|
|
|
|
|
所以，此时的CMDB，仍然可以叫做配置管理数据库，但是这个配置管理的外延已经发生了很大的变化。之前所指的简单的硬件资源配置管理，只能算是狭义的理解；从广义上讲，当前的应用以及以应用为核心的分布式服务化框架、缓存、消息、DB、接入层等基础组件，都应该纳入这个配置管理的范畴。
|
|
|
|
|
|
所以在这个时期，我们提到的运维自动化，远不是自动化的服务器安装部署交付或网络自动化配置这种单一场景，而是出现了持续交付、DevOps、SRE等更适合这个时代的对运维职责的定义和新的方法论。
|
|
|
|
|
|
到了这个阶段，**传统运维思路下的CMDB，因为管理范围有限，可以定义为狭义上的CMDB；而互联网运维思路下的CMDB外延更广，我们称它为广义的CMDB**。新的时期，对于CMDB的理解也要与时俱进，这个时候，**思路上的转变，远比技术上的实现更重要**。
|
|
|
|
|
|
## CMDB进行时
|
|
|
|
|
|
如果我们仔细观察，会发现一个很有意思的现象。CMDB源于80年代末的ITIL，源于传统IT运维阶段，但真正让它发扬光大的，确是新兴的互联网运维行业，而且现在很多的传统行业也在向互联网学习运维技术。
|
|
|
|
|
|
与此同时，在中大型的互联网公司中，比如阿里和腾讯，也越来越重视流程规范的管控，开始更多地将严格的流程控制与灵活的互联网运维技术结合起来，以避免在过于灵活多变的环境下导致不可控的事件发生。
|
|
|
|
|
|
所以，从这里我们可以看到，**并不是说ITIL的重流程体系就一定是过时老旧的，也不是说互联网运维技术就一定代表着最先进的技术趋势，而是在这个过程中，不同体系相互借鉴、相互学习、共同进步和发展，在碰撞的过程中，催生出更适合这个时代的技术体系**。
|
|
|
|
|
|
这确实是一个充满了机遇和挑战、但又不乏乐趣的新时代。
|
|
|
|
|
|
今天我们讲了CMDB的前世今生，我所讲到的对ITIL以及其定义下的CMDB的理解，更多的是根据我个人的早期经历，还有和业界同行交流的经验所得，我自己并没有完整系统地学习过，所以理解上和见识上会有一定的局限，也期望你能批评指正，我们一起讨论、共同进步。
|
|
|
|
|
|
如果今天的内容对你有帮助，也请你分享给身边的朋友，我们下期见！
|
|
|
|