How to Build a Sustainable CMDB: Three Essential Phases for Reliable Operations

Introduction

The speaker, a technology operations manager at Ping An Bank, shares practical insights on building a durable CMDB that can scale with growing business complexity and support effective incident resolution.

1. Modeling Phase

The first step is to create a simple, three‑layer model that captures physical devices, OS nodes, and application instances. Each domain (e.g., network, storage, database) records only essential management and status information, avoiding unnecessary cross‑domain relationships. This keeps the model lightweight and maintainable.

2. Closure (Data Loop) Phase

After modeling, establishing a data closure loop is critical. Changes must be driven by strong processes—such as service catalogs or workflow engines—so that every modification (e.g., VM scaling) is reported to the CMDB with a matching change record. Without this loop, CMDB data remain untrusted.

3. Solving Stock (Existing Data) Phase

The third phase tackles legacy data by treating each domain as an authoritative source, encouraging upward reporting of incremental changes rather than periodic full‑pull imports. Cross‑validation techniques—such as ARP table comparison, network scans, and TCP‑dump topology analysis—ensure completeness and accuracy of the stored inventory.

Architecture for Fast Retrieval

Change events from the CMDB are streamed to Kafka, processed by Flink, and indexed in Elasticsearch for fuzzy search (by IP, APPID, CI code, etc.). For complex relationship queries and topology visualization, data are also fed into Neo4j, which efficiently handles millions of nodes and edges.

Conclusion

The three‑step approach—simple modeling, reliable closure loops, and diligent stock management—combined with modern streaming and graph technologies, enables a CMDB that remains accurate, scalable, and valuable for operations teams.