CMDB是Configuration Management Database的简称，中文翻译成配置管理数据库。

只是这样的解释，一般人很难理解CMDB到底是一个什么东西，其真实情况是，每个人理解的CMDB可能都有所差异。用不着惊讶，CMDB本质上是一个数据库，存什么东西，当然是因人而异的。和计算机术语中“数据库”的差别是，CMDB不仅包含真实的数据库，而且隐含了管理者对资源的抽象和建模的逻辑。每个管理者所处环境不同，所以他所管理的资源的类型，数量和关系也不同，因此就不难理解，为什么市面上没有一款CMDB产品能够适应大部分场景。因此，自研CMDB的需求，也就愈发明显。

运维认为的CMDB

运维人员的工作内容，更注重于业务的发布和运行，因此，CMDB中至少需要管理的有：主机、IP、端口、应用和域名。如果使用了Kubernetes集群，还要关注Kubernetes集群资源。

如无特殊说明，以下讨论的CMDB都指运维认为的CMDB

CMDB中资源管理的原则

基础性

存储到CMDB中的资源，应是最基础的资源。

由于使用CMDB的人员大多隶属运维或基础设施部门，因此，CMDB中不应该存储抽象层很高或者较复杂的的资源。一来是用不到，二来是这会让CMDB的设计过于复杂，第三个是难以维护数据。

CMDB中可以存储的资源有：服务器、人员、应用、域名等。

不建议存储的资源：公司组织结构、业务调用逻辑等。

另外，基础性的解释，还可以用于调用关系。CMDB应该提供基础资源服务接口，并被另外的工具所调用，尽量不或者少调用其他基础服务，不能主动调用中、高级服务，避免环形调用出现调用循环问题。

权威性

存储到CMDB中的数据，应该是最准确的，这样一来，建立了权威性之后，才拥有了对CMDB的运营推动能力。

一旦CMDB中的数据并非最准确的，那么用户就会考虑通过其他渠道获取数据，甚至是自行维护一套数据，这样一来，CMDB就失去了存在的意义。

完整性

考虑权威性之后，还要考虑完整性。虽然CMDB中的数据是准确的，但是一旦数据的覆盖面不够全，也会导致使用的时候出现问题。

例如，当我在CMDB中查找一台IP地址为10.0.0.1的服务器时，没有查找到。如果CMDB中服务器数据是完整的，那么我可以认为不存在这样一台服务器；反之，我还要通过其他渠道来核实是否真的不存在这样一台服务器，效率下降明显。

CMDB应该有什么功能

资源管理功能

简单的来说，就是资源的增删查改功能，这是必须的基础功能。

资源关系梳理

不同资源不是孤立存在的，相互之间存在一定的关系。

比如说一条服务器资源数据，有一个字段是其负责人，这个负责人就是人员资源的一条数据。

特殊情况下，同一种资源之间也存在关系，例如人员资源，可以有上下级关系，如果要维护这个关系，就需要对其关系进行梳理和存储。

对外提供数据服务

CMDB建立之初，需要管理员维护数据。当数据维护达到权威性和完整性的标准之后，就具备了对外提供服务的能力。

常规对外提供服务的方式可以有：

开发Web界面，对真实用户提供服务
开发标准API接口，对第三方工具提供服务

CMDB不应该有哪些功能

工单流程管理

工单流程管理是一种流程管理手段，通过提交工单，逐级审批的方式，实现流程的流转，并可以提供回调Hook来自动执行某些操作。

这样一个工单流程管理的功能，不仅需要对工单流程有详尽的了解，还需要对每个流程进行定制。实际上这样的一个功能不属于资源管理的范畴，徒增了项目的复杂度，还会导致定位不清晰。

数据版本管理

数据版本管理一般要求存储数据的历史版本和变更信息，并利用这些信息进行版本管理。而CMDB的数据管理原则要求了权威性和完整性，存储历史版本的需求不大，徒增复杂性。

CMDB可用于那些服务和流程

监控管理

使用CMDB我们可以获得完整的主机列表，并对这些主机进行监控。

发布管理

使用CMDB和监控我们可以选择在合适的主机发布应用

批量执行

使用CMDB我们可以有的放矢地进行批量操作