The following article is from the official account "The Road of Fullgoal Financial Technology", and it is published with the consent and authorization of the original author Yao Qi. The original title of the article is "The Implementation Experience of Fullgoal Fund's Unified Asset Management Platform (CMDB)" (Author: Yao Qi).
The Concept of CMDB
CMDB (Configuration Management DataBase) is a repository of information related to all components of the IT system. It contains detailed information about the configuration items of the IT infrastructure. It is strongly related to the specific IT software and hardware environment, organizational structure and processes of each enterprise, which determines that the CMDB must be a highly customized system. Although we all know that it is not just a simple database for storing information, there is no unified standard for its specific form.
The Implementation Experience of the First Generation CMDB of Fullgoal Fund
When Fullgoal Fund moved to the new data center of GDS in 2016, a complete ITSM CMDB system was created. At that time, ITIL processes were used more as process specifications, and the CMDB was built on the principle of including everything that should be included. It basically replaced the EXCEL spreadsheets in everyone's hands. The ideal is beautiful, but the reality is harsh. We encountered the same problems as many of our colleagues in the industry. Due to the lack of automated collection capabilities and strong constraints on updating CIs (Configuration Items), the huge amount of data in this online Excel soon faced the problems of untimely updates and no one to consume the data. And these problems in turn caused users to gradually abandon this online EXCEL, and a vicious circle was formed.
After an unpleasant memory, our company also conducted a review operation and summarized the reasons why the benefits of the project did not meet expectations:
1. The fixation of information is not the purpose and has no value. Only when the information flows dynamically does it have value, just like currency. Therefore, the data entered into the CMDB should not be large and comprehensive. Instead, consumption scenarios should be designed first, then the data sources found and the data entered into the database.
The following supporting design work is required:
1) Based on this information, build process specifications, such as server startup, shutdown, maintenance, and installation processes. At the same time, you need to synchronously manage status changes during the process.
2) Visualize and dynamically display the topological relationships, such as the cascade relationships between applications and servers, and the status (normal or faulty), so you can intuitively monitor the status of resource nodes.
2. More energy needs to be focused on the data of applications and upper layers, and the value of the data needs to be brought into play, rather than focusing on the underlying hardware and infrastructure.
If automation is based only on the resource information in the CMDB, the most that can be developed are tools for automated hardware resource discovery, automated installation, generation of network-hardware topological relationships, and other resource-level tools. These tools add value only at the operations and maintenance level and are still far from the business.
Fullgoal Fund's new generation CMDB sets sail
In 2020, after complete summarization and planning, our company launched the reconstruction of the new generation of Fullgoal Fund's unified asset management platform and achieved gradual results.
The following established goals have been achieved in the current project:
1. Reconstruct the CMDB model for scenarios to improve the consumability and collectability of data.
2. Complete the automatic synchronization, automatic discovery and automatic association system of the CMDB in the first stage (the automatic collection rate of CIs is 80.67%)
3. Complete data governance of the CMDB in the first phase (the missing rate of key data has been reduced to 0. By IP scanning to ensure that there are no missing devices, and completing the information through post-audit activities).
4. Completed several consumption scenarios in the first stage: The O&M-related tool platforms have completed the use of the CMDB as the core data source and have realized consumption scenarios such as the person in charge of alarms, the attribution of changes, and the permission control of the Bastion host for O&M personnel.
The Next Step of CMDB Construction
As our company's infrastructure architecture is beginning to lean toward a hybrid cloud, and the application architecture is gradually becoming microservice-oriented and containerized, the new generation of asset management platform still needs to further adapt to the information asset management needs of the cloud-native era. The following issues and consumption scenario requirements need to be urgently addressed:
1. When doing asset management through the CMDB under the traditional architecture, in the cloud-native architecture, the minimum management unit is no longer the physical machine and CVM, but has become pods and containers. Security scanning, security repair and security emergency all rely on asset information (node IP, container name, container ID, person in charge, etc.). Incomplete asset information can lead to the inability to troubleshoot and repair security incidents. Therefore, the CMDB needs to complete the work of docking multiple K8s clusters, constructing the application-namespace-service pod model, etc.
2. Draw the topological diagram of access relationships between applications according to NPM traffic mirroring (set rules to filter out the unimportant network segments, i.e. noise), which is used to analyze the impact relationships of changes.
3. Establish an application level, high availability requirements, and current situation model used for annual changeover exercises and summary scenario consumption.
4. Enrich information about hardware assets such as physical machines that currently have no data sources. Methods such as out-of-band, SNMP, IPMI, Redfish, SSH, etc. are planned.
Infrastructure in the cloud-native era has undergone drastic changes compared to traditional operations and maintenance. The corresponding operation and maintenance tools (monitoring, CMDB, etc.) must all adapt to the changed requirements, conform to the architecture of the cloud-native era, improve the observability, ensure the manageability of assets, and lay a solid foundation for the realization of the digital and intelligent transformation of enterprises and the development of information technology capabilities.
