我喜欢配置管理数据库(CMDB),但并不是大家手上拥有的配置管理数据库(CMDB)。同时,我也喜欢配置,但我对配置的定义似乎与大多数人的定义有所不同。

配置管理数据库(CMDB)非常有趣,是IT基础架构库(ITIL)和服务器/IT“管理”系统的标配。大多数配置管理数据库(CMDB)都具有自动发现功能。您只需安装代理,它们便能够识别服务器类型和服务器内容,比如中央处理器(CPU)、随机存取存储器(RAM)、磁盘、安装软件、以及其他相关事物。

需要指出的是,这里并没有我所理解的“配置”,即系统、软件、服务等是如何配置的。配置管理数据库(CMDB)似乎将配置看作是硬件以及所安装的事物,仅此而已。作为一个铁杆运维迷,这对于我来说有点意思,不过我真正感兴趣的还是服务、服务器以及运维设备的配置。

配置管理数据库(CMDB)行业似乎受制于老旧的IT/PC管理范式,需要了解所拥有的资产、资产位置、资产类型以及资产内容。如果您在多个办事处拥有数千台电脑、打印机等设备的话,这对于您执行杀毒、安全、更新等操作来说还是非常有用的。

不过,这对于真正的互联网运维团队来说并没有什么用处。真正的互联网运维团队需要对位于云端或数据中心的一系列服务器进行管理,而这些服务器时刻都在发生变化,特别是服务器版本和“配置”。我从未见过真正拥有配置数据的配置管理数据库(CMDB)系统。这着实令人吃惊。

我真的需要知道我的Nginx是如何配置的,启用了什么版本的SSL,我的数据清理MySQL选项,我的HAProxy池cookie设置,以及我的Kernel连接跟踪时间等待超时——这些对我的大规模系统具有深刻影响,因此我需要知道它们,报告它们,跟踪它们的历史,对变化做出提醒。

是的,没有人能够帮我们做到这一点。因此我们决定自己动手。

我们的配置管理数据库(CMDB)能够做到这一点——深度发现、收集并存储一切事物的所有配置,分析内核和所有已知服务的所有配置,深入到最低的Apache虚拟主机目录级别、第三tomcat实例程序信息等。它无所不知,无所不晓,其中包括所有配置。当然了,它还能够掌握中央处理器(CPU)、随机存取存储器(RAM)、磁盘、安装软件、运行软件等琐碎信息。

此外,我们的审计规则还能够向我们报告最佳实践偏离情况,发现多个服务器之间的不同之处(非常常见)。它能够为每项服务自动创建运行手册和元数据,对设计规格进行反复核对,对服务器上的任何变化发出提醒。它甚至能够提供附有建议的多语种反报告。

我们可以对任何变化进行版本控制,提醒以及跟踪,不论是在我们的中央OpsStack系统中,还是在工程师常常进行故障排除和ssh作业的服务器命令行上。我们在这方面才刚刚起步,而这则是运维工程师梦寐以求的。

系统每天都能够以按需的方式收集数据,甚至包括我们刚刚接管的新系统,从而帮助我们制定迁移和管理计划。当系统无所不知,无所不晓的时候,这就变得非常容易。

这才是正确的配置管理数据库(CMDB),是我们OpsStack运维平台的一部分,是我们正确的运维实践。

如果希望深入了解真正的配置管理数据库(CMDB)将如何帮助您进行系统管理,请与我们取得联系。