How to Build an Effective CMDB for Scalable Operations Management

How to Build a CMDB

In earlier discussions of Baidu's intelligent operations platform (NoahEE), we introduced the service management component. Beyond application management, operations must also handle devices such as servers, switches, and routers, which fall under the scope of an operations CMDB (Configuration Management Database). This article outlines the process of building a complete CMDB from a business‑scenario perspective.

CMDB Construction Steps

Resource Management Model Abstraction: Identify and model various operational objects—data centers, servers, network devices, applications—to support diverse operational scenarios.

Resource Data Integration and Synchronization: Consolidate lifecycle data (e.g., procurement, deployment, monitoring) across assets, deployments, and monitoring platforms to ensure consistency and accuracy.

Support Upper‑Level Business Operations: After the CMDB is built, ensure the data is valuable and consumable for scenarios such as visualization, intelligent automation, and data‑driven operations.

Resource Management Model

Operational objects are divided into two categories: infrastructure (data centers, racks, servers, network and security devices) and services built on top of that infrastructure (applications, middleware, domains, etc.). The model includes both abstract modeling of each resource type and the organization of resources.

Resource Abstraction Model

Example: Server lifecycle (illustrated below).

Server resources contain three types of information:

Basic attributes (e.g., SN, vendor, model, production date, warranty).

Configuration details (e.g., operating system, assigned IP address).

Runtime status (e.g., operational state, resource utilization).

Example: Application lifecycle (illustrated below).

Application resources also contain three types of information:

Basic attributes (e.g., service name, description, owner, maintainer).

Configuration details (e.g., deployment version, path, startup parameters, open ports).

Runtime status (e.g., service health, resource usage).

Both physical and virtual resources share these three information categories, plus relationships that form a resource knowledge graph (e.g., a web service depends on a domain, a MySQL database, and runs on a set of servers).

Resource Organization Management

Resources are organized from a people‑and‑process perspective to improve daily operational efficiency. Large enterprises typically separate infrastructure resources (managed by a systems department) from business resources (managed by an SRE or operations department). The two main categories are:

Infrastructure resources – grouped by dimensions such as vendor, hardware type, or monitoring protocol.

Business resources – grouped by application, subsystem, environment, or other business‑centric dimensions.

Both categories require isolation, often implemented as tenants that act as namespaces for resources. A combined device‑tree and business‑tree model is illustrated below.

Tenant: Provides resource isolation and contains multiple operational resources.

Device Tree: Organizes physical devices (servers, switches, routers, firewalls) into devices and device groups.

Business Tree: Organizes business resources into instances, applications, services, and subsystems.

Example: In a mid‑size e‑commerce company, the systems department handles hardware and network, while the operations department handles business services, each using the model above.

Maintenance Methods

Manual Maintenance

Basic attribute data (e.g., service names, owners) are often defined manually because they change infrequently and have low maintenance cost.

Process Standardization

Human‑involved activities (e.g., server provisioning, renaming, re‑installation, network planning) are governed by strict processes to ensure data consistency across platforms.

Automatic Registration / Discovery

Runtime status and many configuration attributes are automatically collected by monitoring systems; service call graphs are updated via RPC tracing; network topology is discovered through device‑level protocols, reducing manual effort and improving accuracy.

CMDB Support for Upper‑Level Business Operations

After the CMDB is built, its value is realized through scenario integration and data consumption:

Business Panorama: Visual dashboards provide topology, network, and service views for quick global insight.

Operational Scenario Linking: Automated workflows can, for example, mute alerts before a deployment and restore them afterward.

Intelligent Operations: Use topology and change history for fault diagnosis and root‑cause analysis.

Data‑Driven Operations: Enable capacity planning, cost accounting, and usage analytics based on CMDB data.

CMDB offers query APIs for visualization and analysis, change APIs and notification mechanisms for automation, thereby underpinning higher‑level business operations.

Conclusion

This article describes the CMDB construction process from a business‑analysis perspective: start with resource abstraction and modeling, integrate data through processes and automation, and finally leverage the CMDB to support evolving operational scenarios, demonstrating its strategic value for operations.