我们前面在讲标准化的时候,对关键的运维对象做了识别,主要分为两个部分:
基础设施层面:IDC 机房、机柜、机架、网络设备、服务器等;
应用层面:应用元信息、代码信息、部署信息、脚本信息、日志信息等。
这两部分是整个运维架构的基础部分,运维团队是维护的 Owner,需要投入较大的精力去好好地规划建设。
当我们识别出运维对象和对象间的关系,并形成了统一的标准之后,接下来要做的事情就是将这些标准固化,固化到某个信息管理平台中,也就是我们常说的配置管理,专业一点就叫作 CMDB(Configuration Management DataBase)。
其实,如果我们找准了需求和问题在哪里,你会发现技术手段和平台叫什么就真的不重要了,只要是内部能够达成一个统一共识的叫法就好。
关于如何打造 CMDB 和应用配置管理,我之前有一篇公开的文章《有了 CMDB,为什么还需要应用配置管理》,写得已经比较细致了,会在下一期发布出来,但不占用我们专栏的篇幅。
今天我主要来聊一聊 CMDB 的前世今生,帮助你更加深刻地理解这个运维核心部件,对我们后面开展 CMDB 的建设大有裨益。
CMDB 源起
CMDB 并不是一个新概念,它源于 ITIL(Information Technology Infrastructure Library,信息技术基础架构库)。而 ITIL 这套理论体系在 80 年代末就已经成型,并在当时和后来的企业 IT 建设中作为服务管理的指导理论得到广泛推广和实施。但是为什么这个概念近几年才被我们熟知?为什么我们现在才有意识把它作为一个运维的核心部件去建设呢?