极客时间已完结课程限时免费阅读

06 | 聊聊CMDB的前世今生

06 | 聊聊CMDB的前世今生-极客时间

06 | 聊聊CMDB的前世今生

2018-01-03 赵成 来自北京
《赵成的运维体系管理课》
课程介绍

讲述：黄洲君

时长10:12大小4.67M

我们前面在讲标准化的时候，对关键的运维对象做了识别，主要分为两个部分：
基础设施层面：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 的理解，更多的是根据我个人的早期经历，还有和业界同行交流的经验所得，我自己并没有完整系统地学习过，所以理解上和见识上会有一定的局限，也期望你能批评指正，我们一起讨论、共同进步。
如果今天的内容对你有帮助，也请你分享给身边的朋友，我们下期见！
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 13

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
05 | 如何从生命周期的视角看待应用运维体系建设？
下一篇
07 | 有了CMDB，为什么还需要应用配置管理？
 写留言

精选留言(8)

  • 宵伯特
    2018-01-04
    是不是可以理解为如今的大部分的资源编排服务，持续集成持续交付服务都属于CMDB的范畴？

    作者回复: 是的，广义上理解是这样的，现在的CMDB应该是一个体系。 不过现实场景中我们不会从这么大的一个概念入手，还是从前面讲的运维对象入手，这样更容易理解和执行。

    7
  • 技术修行者
    2020-05-27
    CMDB - Configuration Management DataBase 这篇文章在一定程度上回答了我之前提的问题，当我们的解决方案完全通过公有云进行托管时，和基础设施相关的维护工作，例如虚机、网络等，由云厂商来维护，对于研发和运维团队来说，更多的关注点是在应用上面。 CMDB的焦点由硬件转向应用，我理解是一个进步。
    6
  • Hulk Wu
    2018-03-31
    赵哥好，我不是做运维工作的，但是希望能了解下 CMDB 的相关工具可以吗，比如 excel 以外有哪些工具可以实施 CMDB 呢，谢谢赵哥。

    作者回复: 没有现成的工具，基本都是自研

    共 4 条评论
    3
  • 怀揣梦想的学渣
    2022-02-08
    文中提到的某公司，依旧存在excel表格管理资产的情况，直观原因是资金，人力需要足够的资金投入，资金投入就会纳入部门收益考核，这种非明显收益的投入，会影响部分领导升职，所以不会被关注，上级领导不推动，下面部门领导不关注。下级部门即便有实力推动，也局限于校招生推动，因为社招大部分不能签集团或者省公司，收益低于付出，少做就会少错。 能推动CMDB落地的，还是依赖各产品供应商免费赠送或者打包销售，捆绑在服务器，存储这类领导可以直观看到的资产上。
    展开
    共 1 条评论
    1
  • 若丶相依
    2021-02-21
    最开始没有理解这些概念，到了新公司运维人员多了之后慢慢去思考什么是运维架构，重新再看课程，学习了很多。
    1
  • 衣申人
    2018-07-21
    你好，我还是没搞清楚cmdb和itil的概念，以及应该做成什么样子？某些大型公司做成了什么样子？可以分享更多吗？
    1
  • Star
    2022-11-06 来自广东
    我感觉cmdb也在演进，互联网cmdb算2.0版，接下来物联网cmdb就是3.0
  • 林柏
    2022-02-19
    运营商像广东电信，在2001年就有完整的cmdb数据库和管理系统，远比互联网企业要早。