Data center asset checking method based on operation and maintenance system and computing device

Abstract

The embodiment of the invention relates to a data center asset checking method based on an operation and maintenance system and computing equipment. The method comprises the following steps: acquiring first asset data and second asset data; wherein the first asset data is obtained based on static asset account data provided by an asset management system, the static asset account data records reference information of data center hardware assets, the second asset data is obtained based on actual asset data obtained by an operation and maintenance system, and the actual asset data represents the current state of the data center hardware assets; checking the first asset data and the second asset data to generate an asset checking result; and generating a data synchronization instruction based on the asset checking result. Therefore, through linkage and automatic checking of the asset data, the record of the asset management system and the actual condition reflected by the operation and maintenance system are kept dynamic and consistent, the problems of high manual checking cost, low efficiency, high error rate and the like in related technologies can be effectively solved, and the accuracy of asset management can be remarkably improved.

Description

Technical Field

[0001] This application relates to the field of server technology, and in particular to a data center asset inventory method and computing equipment based on an operation and maintenance system. Background Technology

[0002] Data center asset inventory is crucial for ensuring stable and efficient operations. Currently, the main technologies used are manual verification, barcode or RFID scanning, etc.

[0003] Therefore, the relevant technologies rely heavily on manual on-site operations, which is not only inefficient and costly, but also prone to inaccurate inventory data due to human negligence, label obstruction, or instrument misreading. Summary of the Invention

[0004] This application provides a data center asset inventory method and computing device based on an operation and maintenance system, which can improve the accuracy of asset inventory data.

[0005] According to a first aspect of the embodiments of this application, an asset inventory method is provided, the method comprising: The process involves acquiring first and second asset data. The first asset data is obtained from static asset ledger data provided by the asset management system, which records baseline information about the data center hardware assets. The second asset data is obtained from actual asset data obtained from the operations and maintenance system, representing the current state of the data center hardware assets. The first and second asset data are then compared to generate an asset inventory result. This result indicates the differences between the first and second asset data. Based on the inventory result, a data synchronization command is generated. This command corrects the static asset ledger data corresponding to the first asset data based on the second asset data, ensuring consistency between the static asset ledger data and the actual asset data.

[0006] This solution performs asset inventory by acquiring static asset ledger data from the asset management system and actual asset data from the operations and maintenance system. Based on the inventory results, data synchronization instructions are generated to drive the static ledger data in the asset management system towards the actual state. This implementation enables the linkage and automatic verification of asset data, ensuring dynamic consistency between the records in the asset management system and the actual situation reflected in the operations and maintenance system. It fundamentally solves the problem of discrepancies between records and actual assets caused by system isolation, effectively overcoming the high cost, low efficiency, and error-prone nature of manual inventory in related technologies, and significantly improving the accuracy of asset management.

[0007] In one possible implementation, acquiring the first asset data includes: The original static asset ledger data is obtained from the asset management system and converted into a standardized asset model with unified field definitions as the second asset data to obtain the first asset data. The standardized asset model includes a unique identifier field to identify the asset, an asset category field to describe the asset type, and a location field to indicate the physical location of the asset.

[0008] This solution, through the aforementioned data standardization and transformation process, unifies the original ledger data from different systems and with varying formats into standardized data with a clear structure and semantics. This fundamentally eliminates the data heterogeneity barrier between systems and provides a data foundation for subsequent asset reconciliation.

[0009] In one possible implementation, acquiring the second asset data includes: Real-time asset status information is obtained from the operations and maintenance system, which monitors and collects the actual status and circulation information of assets in real time. Secondary asset data is then derived based on this real-time status information. This circulation information represents the status and location changes of the asset during its movement through the warehouse. This solution ensures that the secondary asset data not only has a high degree of real-time accuracy, accurately reflecting the instantaneous status of assets, but also, through standardized processing, enables precise and automated verification with static ledger data within a unified framework. This solves the problems of inefficiency and frequent errors caused by data lag and inconsistent formats in traditional inventory methods.

[0010] In one possible implementation, the real-time status information includes: information on the complete units and components of managed equipment obtained through out-of-band management, and / or information on the flow of individual components and complete units in the warehouse. Here, a complete unit is an independent device deployed in a data center and in operation; a component is an identifiable device installed inside the complete unit; and individual components are independent materials stored in the warehouse but not installed in the complete unit.

[0011] This solution enables unified, real-time, and refined management of data center assets, effectively eliminating management blind spots.

[0012] In one possible implementation, the first asset data and the second asset data are compared to generate an asset inventory result, including: Obtain the inventory strategy, which guides the verification process between the first asset data and the second asset data; based on the inventory strategy, verify the first asset data and the second asset data to obtain the asset inventory results.

[0013] In this solution, users can flexibly formulate the most suitable inventory plan according to the control priorities, resource status or audit requirements, so as to meet the diverse management needs in complex operation and maintenance environments while ensuring the accuracy of the inventory.

[0014] In one possible implementation, the inventory strategy includes one or more of the following: inventory scope, inventory object type, and inventory triggering conditions.

[0015] In this solution, users can flexibly formulate the most suitable inventory plan according to the control priorities, resource status or audit requirements, so as to meet the diverse management needs in complex operation and maintenance environments while ensuring the accuracy of the inventory.

[0016] In one possible implementation, the scope of the inventory includes the region and location of the assets; The types of items to be inventoried include one or more of the following: complete equipment, loose materials, and equipment components. Complete equipment, loose materials, and equipment components together constitute the hardware assets of the data center. Complete equipment is a complete unit with independent operating functions, equipment components are the parts that make up the complete equipment, and loose materials are spare or replaceable units that exist independently of complete equipment. Complete equipment includes servers, switches, or storage devices; equipment components include CPUs, memory, hard drives, or network interface cards.

[0017] The inventory count is triggered by either a timed event or an event; events include asset receipt, asset release, or asset information change operations.

[0018] In one possible implementation, the method further includes: Generate a visual interface to output the asset inventory results. The visual interface is used to display the details of inventory discrepancies and / or provide the function of exporting inventory results.

[0019] This solution transforms complex verification data into easily understandable information through a visual interface, significantly reducing the user's interpretation costs and facilitating rapid decision-making.

[0020] According to a second aspect of the embodiments of this application, an asset inventory apparatus is provided, the apparatus comprising: The asset data acquisition module is used to acquire first asset data and second asset data; wherein, the first asset data represents static asset ledger data, and the second asset data represents current actual asset data; The asset inventory result generation module is used to verify the first asset data and the second asset data and generate the asset inventory result; the asset inventory result is used to represent the difference between the first asset data and the second asset data.

[0021] According to a third aspect of the embodiments of this application, a computing device is provided. The computing device includes a memory and a processor, the memory storing a computer program, and the processor executing the program to implement the method as described above.

[0022] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the methods described in the embodiments of this application.

[0023] According to a fifth aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the methods described above in the embodiments of this application. Attached Figure Description

[0024] Further details, features, and advantages of this application are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1A A schematic diagram of an asset inventory system architecture provided for an exemplary embodiment of this application; Figure 1B A structural architecture diagram of a data center provided as an exemplary embodiment of this application; Figure 2 A flowchart illustrating a data center asset inventory method based on an operation and maintenance system provided in an exemplary embodiment of this application; Figure 3 A flowchart of a data center asset inventory method based on an operation and maintenance system, provided as yet another exemplary embodiment of this application; Figure 4 A schematic block diagram of the functional modules of a data center asset inventory device based on an operation and maintenance system provided for an exemplary embodiment of this application; Figure 5 A structural block diagram of a computing device provided for an exemplary embodiment of this application. Detailed Implementation

[0025] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0026] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0027] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0028] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more". The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0029] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device. It is understood that the above notification and user authorization process is merely illustrative and does not limit the implementation of this application; other methods that comply with relevant laws and regulations may also be applied to the implementation of this application.

[0030] In the embodiments provided in this application, such as Figure 1A As shown, Figure 1A This is a schematic diagram of the asset inventory system architecture provided in an embodiment of this application. The system may include a terminal 11 and a server 12. The server 12 is equipped with a database that stores first asset data and second asset data, or the first asset data and second asset data may be stored in different databases within the server 12. The server 12 has operation and maintenance management functions, asset management functions, asset inventory functions, and data synchronization functions. It should be noted that, depending on the functions of the server 12, multiple servers may be deployed, and the embodiment is not limited to this.

[0031] Terminal 11 is used to receive the user's asset inventory operation, generate an asset inventory request, and send the asset inventory request to server 12.

[0032] For example, when a user needs to assess assets within a company, platform, or system, they can trigger an asset inventory through an interface provided by terminal 11. Terminal 11 will then send the asset inventory request to server 12. The data center is the underlying physical infrastructure upon which the company, platform, or system relies, providing essential core support services such as computing power, storage, and network connectivity for the company's digital business, the platform's online services, and the stable operation of various software systems.

[0033] For example, such as Figure 1B As shown, Figure 1B This application provides a structural architecture diagram of a data center. A data center typically includes several main server rooms, each including multiple server racks, and each rack containing multiple IT (information technology) devices. These IT devices may include servers, switches, and storage devices, among other related equipment. In some possible scenarios, the number of server racks in a data center may exceed 1000, and the number of IT devices may exceed 5000.

[0034] As the core infrastructure of cloud computing, data centers house a large number of TI devices and undertake critical tasks such as centralized data storage, computation, and exchange.

[0035] Combination Figure 1B As shown, a standard data center typically includes the following core hardware assets, which are the main objects to be inventoried and managed in this implementation example: Server racks: Multiple neatly arranged server racks in a computer room are the infrastructure for installing IT equipment.

[0036] Complete server equipment: Various independently operating devices installed in server racks, which are the core computing and network units of the data center, mainly including: Servers are used to perform computing tasks and process data.

[0037] Switch: Responsible for data exchange and network connectivity between devices.

[0038] Storage devices: used for centralized storage and management of data.

[0039] Equipment components: Identifiable and manageable core components built into the aforementioned complete equipment, such as processors, memory, hard drives, and network cards.

[0040] In addition, data centers may also include support facilities, which are the environmental and power equipment necessary to ensure the normal operation of IT equipment, such as precision air conditioners, power distribution cabinets, uninterruptible power supplies (UPS), etc. These are also important components of data center assets.

[0041] Server 12 is used to receive an asset inventory request sent by terminal 11, and to obtain the first asset data and the second asset data stored in the local database according to the asset inventory request.

[0042] In this embodiment, server 12 may be deployed with an operation and maintenance system. This operation and maintenance system manages the equipment, acquires the actual real-time asset information of the entire device and its components out of the band, and converts the acquired data into a defined asset model.

[0043] In addition, the operation and maintenance system has the ability to provide warehouse management, which can put parts / complete machines into the warehouse, provide flow management capabilities such as inbound and outbound, and borrowing, and obtain asset details data and convert them into a defined asset model.

[0044] In this embodiment, the operation and maintenance system can update the saved asset model data by monitoring changes in information about the entire machine and its components. Additionally, the operation and maintenance system provides the ability to transfer warehouse assets, and can update the saved asset model data based on the status of the transferred assets.

[0045] In this embodiment, the asset model can be stored in the database of server 12. When server 12 receives an asset acquisition request, it can use the asset model stored in the database as the first asset data.

[0046] In this embodiment, server 12 may be equipped with an asset management system, which can retrieve stored second asset data from the database on server 12. This second asset data may include static asset ledger data, which is then converted into a corresponding asset model.

[0047] Server 12, through the acquired first asset data and second asset data respectively, verifies the first asset data and second asset data according to the asset inventory strategy defined by the user, obtains the inventory result, and sends the inventory result to terminal 11. Based on the inventory result, it corrects the ledger data and online dynamic data to achieve asset consistency.

[0048] Terminal 11 is also used to receive the inventory results and display them on the display interface.

[0049] It should be noted that an asset model can be a predefined, standardized data structure or data template. The purpose of an asset model is to transform raw asset information from different sources and in various formats into a standardized format that all systems can understand and process.

[0050] For example, first asset data obtained through the operation and maintenance system, including data from out-of-band management, is designed for hardware monitoring and may include fields such as: device SN (serial number), device model, IP (internet protocol) address, CPU (central processing unit) model / quantity, memory size / slot information, hard disk SN / capacity, etc.

[0051] Data from warehouse management is designed for logistics flow and may include fields such as: material code, material name, inbound time, storage location number, borrower, and status (in stock / borrowed).

[0052] The second asset data comes from the asset management system, and its data structure is designed for financial and ledger management. It may include fields such as: asset number, asset name, purchase date, value, department using the asset, responsible person, and storage location.

[0053] If the three types of data with different formats are directly compared, it is not possible to perform the comparison; they need to be converted into an asset model with a unified format.

[0054] This asset model abstracts the most core and common attributes of related assets (such as complete machines, loose parts, and components), as shown in Table 1. Table 1 is an exemplary asset model provided in this embodiment:

[0055] In this embodiment, raw data from the operation and maintenance system and the asset management system can be mapped (converted) to the fields defined in the asset model, thereby eliminating data heterogeneity and enabling automated and accurate data verification.

[0056] In this embodiment, when a record is obtained from the asset management system, such as {Asset Number: "AST-2023001", Asset Name: "Dell Server", Location: "A Data Center-03 Rack-10U"}, the plugin will convert it into an asset model format: {Type: "Server", Serial Number: "XXX", Location: {Data Center: "A", Rack: "03", U-position: "10"}}.

[0057] When the operations and maintenance system collects information {SN: "XXX", Model: "PowerEdgeR750", CPU: "2×Gold 6330"} from a server, it will also be converted into the same asset model format.

[0058] During asset inventory, since both sets of data are transformed into data models with relevant formats (i.e., standardized asset models), server 12 can easily associate them based on serial numbers or unique identifiers and compare whether fields such as location and configuration are consistent.

[0059] Therefore, the asset model in the embodiment can be a standardized data middleware that defines unified attribute fields to convert raw data from heterogeneous systems (such as asset management systems, out-of-band management, warehouse management, etc.) into a mutually comparable format, thereby providing a data foundation for achieving automated and accurate asset inventory.

[0060] In the embodiments provided in this application, combined with Figure 1A As shown, the execution phases can specifically include the following: Inventory task initiation phase: The user sends an asset inventory request to the server 12 through the operating interface on the terminal 11, such as a personal computer or mobile device. This asset inventory request may include user-defined inventory strategies, such as the inventory scope, the type of inventory object, and the inventory triggering conditions.

[0061] In this embodiment, the scope of the inventory includes one or more of the following dimensions: data center, server room, warehouse, room, shelf, cabinet, department or user; The types of items to be inventoried include one or more of the following: complete equipment, loose materials, and equipment components; among which, complete equipment includes servers, switches, or storage devices; and equipment components include CPUs, memory, hard drives, or network cards.

[0062] The inventory count is triggered by either a timed event or an event; events include asset receipt operations, asset issuance operations, or asset information change operations.

[0063] Data Acquisition Phase: After receiving the inventory request, server 12 initiates two types of data acquisition operations in parallel: Obtaining the target data source: Server 12 queries the required real-time asset information from its local database. This information includes the status of equipment / components collected through out-of-band management and asset flow data recorded through warehouse management. Specifically, the target data source can be the first asset data mentioned above.

[0064] Obtaining the benchmark data source: Simultaneously, the database in server 12 serves as the authoritative source of the benchmark data source. Server 12 queries static asset ledger information from its local database. Specifically, this benchmark data source can be the second asset data mentioned above.

[0065] Core processing and comparison: Server 12 will standardize the target data source and benchmark data source obtained respectively, and perform automated verification and comparison analysis according to the inventory strategy.

[0066] In this embodiment, server 12 can automatically compare the standardized (uniformly converted into the aforementioned asset model) target data (actual state) with the benchmark data (book status) item by item. The comparison content may include the existence, quantity, configuration information, location status, etc. of the assets. The asset inventory server 12 identifies and records all discrepancies, such as "inventory surplus" (physical existence but no record in the ledger), "inventory shortage" (recorded in the ledger but not physically present), and "information mismatch" (such as inconsistent configuration models), etc.

[0067] Results Generation and Feedback: After verification, server 12 generates detailed asset inventory results, such as a discrepancy list and a consistency report, and sends these results back to the user's terminal 11 for visualization. The user can then understand the discrepancies between the accounting records and the actual inventory, and trigger subsequent data synchronization processes.

[0068] In this embodiment, the verified comparison results can be used to generate a detailed inventory report. The report can clearly display the details of discrepancies, inventory accuracy, and other statistical information in a visual format. Users can view the report through their terminals and export it to various file formats for archiving or auditing. Based on the inventory results, this embodiment can trigger a data synchronization process. For example, for confirmed discrepancies, after authorization, an update command can be automatically or semi-automatically sent to the asset management system to correct the corresponding ledger information, thereby achieving real-time consistency of asset data.

[0069] In the embodiments, as shown in Table 2, Table 2 provides an exemplary inventory result.

[0070] Table 2:

[0071] The embodiments provided in this application can greatly improve the accuracy and efficiency of asset management by transforming the traditional manual and discrete inventory activities into a configurable, triggerable, and traceable standardized workflow.

[0072] Based on the above embodiments, in another embodiment provided in this application, an asset inventory method is also provided, such as... Figure 2 As shown, the method may include the following steps: Step S210: Manage / import equipment material assets.

[0073] In this embodiment, an operation and maintenance system is added to the equipment to obtain real-time asset data. Materials are then imported into the operation and maintenance system to acquire asset data.

[0074] Step S220: Connect to the customer asset management system.

[0075] Before starting the inventory count, the system connects with the customer's asset management system through a plug-in interface to obtain the baseline data source, namely the static asset ledger information within a specified range.

[0076] Step S230: Create an inventory list.

[0077] Creating an inventory list is the initial configuration phase for launching the automated inventory process in this embodiment. This step receives user-inputted inventory parameters through the system's interactive interface and saves these parameters in a structured manner as an executable inventory task instance. Its specific implementation is as follows: (1) Inventory Scope: Users can specify the spatial scope of the inventory through a tree structure or drop-down selection box, including but not limited to specific data centers, server rooms, regions, server racks, or warehouses. The system will filter the assets to be verified based on this scope.

[0078] (2) Asset Category: Users can select the granularity and type of assets to be inventoried, including but not limited to: Complete equipment: such as servers, switches, storage devices, and other complete functional units. Device components: such as CPU, memory, hard drive, and other components installed inside the machine. Loose parts: Spare spare parts in stock or complete units not yet deployed When users create a new inventory list through the system interface, they need to configure the following core parameters: (3) Execution strategy: Users can set: Execute immediately: The verification process is triggered immediately after the inventory list is submitted.

[0079] Scheduled execution: Automatically executes at a preset future time.

[0080] Periodic execution: Repeatedly execute according to a preset period (such as monthly).

[0081] Advanced configuration (optional): Assets designated under a specific department or person in charge.

[0082] Set up an approval process for handling discrepancies.

[0083] Associate custom asset filtering criteria.

[0084] After receiving user configuration, the example generates an inventory sheet with a unique number. This sheet will serve as the unified basis for subsequent data acquisition, verification operations, and result recording. This standardized configuration method ensures both the standardization of the inventory process and provides flexibility to adapt to different management needs.

[0085] By creating a standardized entry point for inventory count sheets, complex asset inventory requirements are transformed into quantifiable and executable system tasks, providing accurate input for subsequent automated processes and effectively avoiding operational ambiguities and execution deviations caused by verbal communication or non-standard records in traditional inventory counts.

[0086] Step S240: Initiate asset inventory.

[0087] In this embodiment, after the user confirms the task configuration, the inventory process is initiated. The system will perform the core automated verification operations: according to the inventory strategy, it will obtain the target data source (real-time equipment information and warehouse status) from the operations and maintenance system. The baseline data and target data will be converted into a unified model and compared.

[0088] Step S201: Obtain the baseline data source.

[0089] By selecting a benchmark data source – the customer asset system, it is possible to select multiple customer asset systems as benchmark data sources simultaneously.

[0090] Step S202: Select the inventory type.

[0091] Users must first determine the macro scope of the inventory check: is it the data center (for deployed and online equipment) or the warehouse (for unused spare parts assets)? This choice will determine subsequent options.

[0092] Step S203: Import inventory standards.

[0093] Users can import predefined inventory standard templates or directly set specific rules for this inventory.

[0094] Step S204: Determine if it is a server room. If it is a server room, proceed to step S206. If it is a warehouse, proceed to step S205.

[0095] If it is a data center, select the specific data center, region, and even server rack; if it is a warehouse, select the specific warehouse and shelving.

[0096] Step S205: Specify the inventory location, such as the data center room, server rack, etc.

[0097] Step S206: Specify the inventory location, such as warehouse shelves.

[0098] Step S207: Select asset category. Users can select the granularity of the assets to be inventoried.

[0099] Step S208: Determine whether it is a complete machine. If it is a complete machine, proceed to step S209; if it is a component, proceed to step S210.

[0100] Step S209: Obtain the asset category of the entire machine.

[0101] In this embodiment, if a complete machine is selected, the specific asset category of the complete machine must be further selected, such as a server or network device.

[0102] Step S210: Obtain the category of individual parts.

[0103] In this embodiment, if individual components are selected, the category of the individual component asset must be specified. Examples include memory, CPU, hard drive, GPU, or network card.

[0104] Step S211: Designate the person in charge of the inventory count.

[0105] Step S212: Determine the planned inventory count time.

[0106] For example, execute immediately or later, such as weekly + time, monthly + time, specified time, etc.

[0107] Step S213: Make a note.

[0108] In this example, users can designate the person in charge of the inventory, determine the planned inventory time, and add notes to form a complete and traceable inventory task sheet.

[0109] Step S250: Display and export inventory results.

[0110] Generate inventory reports and present them to users in a visual manner (such as discrepancy lists and statistical charts). The reports can highlight discrepancies such as "inventory surplus," "inventory shortage," and "information discrepancies," and support exporting to common file formats for easy archiving and analysis.

[0111] Step S260: Inventory results are pushed out.

[0112] The implementation example can automatically push inventory results to relevant responsible persons or management systems. This step ensures timely information delivery and lays the foundation for subsequent processing actions.

[0113] For significant discrepancies automatically identified (such as shortages of high-value equipment), or according to preset rules, the process can trigger a manual verification step. Inventory personnel, following system prompts, go to the site to physically verify the specific asset. This step constitutes a hybrid "human-machine collaboration" inventory model, ensuring automation efficiency while also taking into account the prudent handling of critical anomalies.

[0114] Step S270, physical asset verification.

[0115] Physical asset verification is an optional manual confirmation step included in the automated inventory process in this embodiment. This step is triggered when the system identifies significant discrepancies through automatic comparison (such as shortages of high-value equipment or anomalies in critical configurations).

[0116] In this stage, the system generates a verification task sheet containing the detailed location of the discrepancies and anomaly descriptions, assigning relevant personnel to conduct on-site verification of the equipment. Operators receive the task via a terminal, travel to the designated computer room or warehouse shelf, and verify the actual equipment's model, serial number, configuration parameters, etc., on-site, then report the verification results back to the system via the terminal.

[0117] This step establishes a hybrid inventory management model that combines human and machine collaboration. While maintaining the high efficiency of automated inventory management, the manual intervention at key points ensures the reliability of the results for handling significant discrepancies, thus forming a complementary advantage between automated screening and precise manual verification.

[0118] Finally, the implementation can also provide result feedback and system synchronization (closed-loop management).

[0119] After manual verification and confirmation, the final inventory results are fed back to the system. Based on the confirmed results, the system can automatically or semi-automatically update the ledger data in the asset management system after authorization, thereby completing a complete closed loop from discovering discrepancies to correcting them, and ultimately achieving consistency between the accounts and the actual inventory.

[0120] The asset inventory method provided in this application not only covers the entire process from task creation to result synchronization, but also demonstrates the high flexibility and reliability of the embodiment while achieving automation and high efficiency through configurable inventory strategies and optional manual confirmation steps, which can meet the diverse inventory needs in complex real-world scenarios.

[0121] Based on the above embodiments, this application also provides a data center asset inventory method based on an operation and maintenance system, such as... Figure 3 As shown, the method may include the following steps: In step S310, first asset data and second asset data are obtained. The first asset data is obtained based on static asset ledger data provided by the asset management system, which records the baseline information of the data center hardware assets; the second asset data is obtained based on actual asset data obtained by the operation and maintenance system, which represents the current status of the data center hardware assets.

[0122] In this embodiment, the method first acquires two types of key data in parallel. The first type of asset data comes from static asset ledger data provided by the asset management system. This data constitutes the "baseline ledger" for data center hardware asset management, recording the theoretical configuration and location information of devices such as servers and switches. The second type of asset data is acquired in real-time through the operation and maintenance system, reflecting the actual operating status and physical existence of hardware assets within the data center. This includes real-time device configuration information acquired through out-of-band management and asset transfer records acquired through the warehouse management system. After acquisition, both types of data undergo standardization processing, converting them into a unified asset model format to provide data support for subsequent comparisons.

[0123] In this embodiment, the first asset data representation can be theoretical baseline data (i.e., "ledger") from the asset management system, typically including static ledgers such as asset procurement information, financial attributes, and theoretical location. The second asset data representation can be target data (i.e., "actual") from the operation and maintenance monitoring system, reflecting the actual state of the assets, emphasizing its real-time nature and accuracy. Obtaining these two types of data is a prerequisite for achieving automated inventory counting.

[0124] In this embodiment, the first asset data refers to static asset ledger data. This data typically originates from a company's dedicated asset management system and consists of its recorded, theoretical asset information, forming the baseline data source for inventory checks. The first asset data may include, for example, one or more relatively static attributes such as the asset's code, model, purchase date, theoretical storage location, and responsible party.

[0125] The second asset data represents the current actual asset data. This data can originate from the operations and maintenance system, which collects dynamic information reflecting the true state of assets through real-time monitoring, forming the target data source for inventory checks. This data is acquired through out-of-band management, warehouse management logs, and other methods, ensuring that the data reflects the latest status of the assets, such as the actual shelving location of equipment, real-time configuration information, and the current status of components.

[0126] In step S320, the first asset data and the second asset data are verified to generate an asset inventory result. The asset inventory result is used to represent the differences between the first asset data and the second asset data.

[0127] In this step, standardized first and second asset data are automatically compared and analyzed. The comparison process is based on the unique identifiers of the assets (such as serial numbers) to comprehensively check the existence, configuration accuracy, and location consistency of the assets. This can automatically identify discrepancy types such as "inventory surplus" (physical assets not recorded), "inventory shortage" (recorded assets not physically present), and "information discrepancies," and generate structured asset inventory results that accurately reveal the specific circumstances and details of discrepancies between the recorded and actual assets.

[0128] The implementation example utilizes a specialized inventory engine, which essentially compares the "accounts" with the "actual" assets, identifying differences in existence, quantity, configuration, location, and other aspects. The generated asset inventory results can specifically include details such as inventory surpluses, shortages, and mismatches between account and actual inventory information.

[0129] Specifically, the key identifiers used for verification can be the asset's unique serial number, asset code, etc. The comparison covers multiple dimensions, including the asset's existence, quantity, configuration details, and location information. The generated asset inventory results are used to quantify the differences between the first and second asset data.

[0130] Specifically, the asset inventory results will identify and categorize various discrepancies, such as: Inventory surplus: Assets that exist in the second asset data but are not recorded in the first asset data, i.e., "existing but not recorded in the books".

[0131] Inventory shortage: The asset is recorded in the first asset data, but the corresponding physical asset cannot be found in the second asset data, that is, "the account exists but the actual asset is not".

[0132] Information mismatch: The asset exists in two types of data, but key attributes (such as configuration and location) are inconsistent.

[0133] In step S330, a data synchronization instruction is generated based on the asset inventory results.

[0134] The data synchronization instruction is used to correct the static asset ledger data corresponding to the first asset data based on the second asset data, so as to achieve consistency between the static asset ledger data and the actual asset data.

[0135] For example, the synchronization instruction may include a data addition instruction, a data deletion instruction, and / or a data modification instruction.

[0136] The data addition instruction is used to handle "inventory surplus" discrepancies. When an actual asset is identified that is not registered in the static asset ledger, the system generates this instruction to drive the asset management system to create a new asset record, ensuring that the new asset is recorded in a timely manner.

[0137] The data deletion command is used to handle "inventory shortage" discrepancies. When it is detected that an asset recorded in the ledger does not exist in the actual environment, the system generates this command, which drives the asset management system to mark the corresponding asset record as invalid or remove it, thus avoiding the inflated assets.

[0138] The data modification command is used to handle discrepancies in information. When the system detects that the actual asset information is inconsistent with the ledger record, it generates this command to drive the asset management system to update relevant fields, such as asset location and configuration parameters, to ensure the accuracy of the ledger.

[0139] By specifying synchronization instructions into three basic data operation types—add, delete, and modify—a precise mapping relationship between inventory results and system operations was established, realizing a complete closed loop from automated difference identification to automated data correction, significantly improving the accuracy and timeliness of asset data maintenance.

[0140] In this embodiment, based on the inventory results, a data synchronization command can be generated to drive the static ledger data of the asset management system to converge with the actual state. This step, through the data linkage mechanism between systems, ensures that the records of the asset management system and the actual situation reflected by the operation and maintenance system remain dynamically consistent, fundamentally solving the problem of discrepancies between records and actual conditions caused by system isolation.

[0141] In this embodiment, after step S320 completes the verification and generates the asset inventory results, the embodiment can go beyond simply reporting and proactively drive data correction. Specifically, the embodiment will parse the discrepancy information in the inventory results (e.g., specific information of "surplus" assets, identification of "shortage" assets, or correct configuration details of "inconsistent information" assets), and automatically generate one or more asset data synchronization instructions based on this verified actual data.

[0142] This asset data synchronization command is used to keep asset ledger data consistent with actual asset data. Therefore, the operations included in this command directly address the elimination of identified discrepancies, for example: For "surplus" assets, the instruction is to add a new asset record to the asset management system.

[0143] For "inventory deficit" assets, the instruction is to mark the corresponding asset record as retired or lost in the asset management system.

[0144] For assets with "information discrepancies", the instruction is to update the configuration, location, and other information of the corresponding asset in the asset management system.

[0145] This implementation transforms the traditional "inventory count - manual verification - manual update" workflow into an intelligent process of "automatic inventory count - automatic / confirmed synchronization." This significantly shortens the time from discovering discrepancies to correcting them and substantially reduces the risk of inconsistencies between accounts and physical assets caused by delays or oversights in manual operations. This ensures the continuous accuracy and real-time performance of the asset management system as a reliable source, thereby improving the efficiency and reliability of asset management.

[0146] The asset inventory method provided in this application can effectively overcome the problems of high cost, low efficiency and easy error in manual inventory in related technologies. Through data linkage and automatic verification, the embodiment can significantly improve the accuracy and real-time performance of asset management.

[0147] Based on the above embodiments, in another embodiment provided in this application, when acquiring the first asset data, step S310 may further include the following steps: In step S311, the original static asset ledger data is obtained from the asset management system.

[0148] This step involves initial data interaction with heterogeneous asset management systems. In this example, unprocessed raw ledger data can be extracted from the asset management system via inter-system interfaces (such as plug-in interfaces). This raw data typically follows the asset management system's own data model and format specifications, may contain extended attributes related to finance and procurement, and there are significant differences in data structure and field definitions between systems from different vendors.

[0149] In step S312, the original static asset ledger data is converted into a standardized asset model with unified field definitions as the second asset data to obtain the first asset data. The standardized asset model includes a unique identifier field to identify the asset, an asset category field to describe the asset type, and a location field to indicate the physical location of the asset.

[0150] In this embodiment, the purpose of this step is to overcome the technical obstacles caused by the heterogeneity of multi-source data. By parsing, cleaning, and reconstructing the acquired raw ledger data, it maps it to a predefined standardized asset model. This standardized asset model and the second asset data use the same field definitions, ensuring that the two types of data from different sources can be effectively compared on the same dimension.

[0151] This standardized asset model can include at least the following core fields: Unique Identifier Field: Used to uniquely identify each asset instance, such as equipment serial number, asset code, etc., serving as a key basis for data association and comparison.

[0152] Asset Category Field: Used to describe the type and classification of assets, such as "server", "switch", "CPU", "memory", etc., and supports filtering and grouping inventory by asset type.

[0153] Location field: Used to indicate the physical location information of assets, such as data center name, server room number, rack location, warehouse shelf number, etc., supporting accurate verification of asset location.

[0154] This embodiment, through the above-described data standardization and conversion process, unifies the original ledger data from different systems and with varying formats into standardized data with a clear structure and semantics. This can fundamentally eliminate the data heterogeneity barrier between systems and provide a data foundation for subsequent asset reconciliation.

[0155] Based on the above embodiments, in another embodiment provided in this application, when acquiring the second asset data, step S310 may further include the following steps: In step S313, real-time asset status information is obtained from the operation and maintenance system. The operation and maintenance system is used to monitor and collect the actual status and circulation information of the assets in real time. This circulation information refers to the status and location change data of the assets during their circulation within the warehouse. In this embodiment, the operations and maintenance system serves as the target data source. Its core function is to monitor assets in real time and collect their actual status and circulation information. This circulation information can include data on changes in status and location of warehouse assets during the processes of warehousing, outbound, requisition, return, and allocation. This allows for the continuous acquisition of the latest and most accurate status of assets within the data center through proactive detection, proxy programs, or receiving sensor data. The real-time status information of assets obtained from the operations and maintenance system forms the "real" data foundation for inventory, contrasting sharply with the "accounts" of the asset management system.

[0156] In step S314, the second asset data is obtained based on the real-time status information.

[0157] In this embodiment, this step illustrates the process of transforming raw monitoring information into standardized asset data. The raw status information obtained directly from the operations and maintenance system may be complex, unstructured, or specifically designed for monitoring purposes. Therefore, a data processing and transformation stage is required. This stage mainly includes: Data extraction and cleaning: Filtering key data points related to asset identity, configuration, and location from massive amounts of real-time information. For example, extracting serial numbers, models, CPU configurations, or memory sizes from server performance data.

[0158] Standardized modeling: The extracted data is mapped and transformed into a predefined standardized asset model consistent with the primary asset data. This transformation ensures the comparability of data from different sources (such as operations and maintenance systems and asset management systems) with vastly different formats.

[0159] The embodiments of this application ensure that the second asset data not only has a high degree of real-time performance, accurately reflecting the instantaneous status of the assets, but also, through standardized processing, enables precise and automated verification with static ledger data within a unified framework. This solves the problems of inefficiency and frequent errors caused by data lag and inconsistent formats in traditional inventory methods.

[0160] In this embodiment, the aforementioned real-time status information may include: information on the complete machines and components of managed equipment obtained through out-of-band management, and / or information on the flow of individual components and complete machines in the warehouse. Here, a complete machine is an independent device deployed in a data center and in operation; a component is an identifiable device installed inside the complete machine; and individual components are independent materials stored in the warehouse but not installed in the complete machine.

[0161] Specifically, this real-time status information mainly covers the following two key sources, ensuring the comprehensiveness of the asset inventory scope and the real-time nature of the data: Information on the complete equipment and components of the managed equipment obtained through out-of-band management: (1) Out-of-band management: This is a management channel independent of the business network. It communicates with the device through a dedicated management port. This method is not affected by the traffic load or failure of the business network, ensuring the stability and reliability of management operations.

[0162] Overall device information: including but not limited to the device's serial number, model, power status, rack location, and other overall attributes.

[0163] Component information: This reflects the detailed inventory capabilities of this application embodiment. It refers to the main identifiable components inside the entire machine, such as the model and quantity of the central processing unit, the capacity and serial number of the memory modules, the serial number and capacity of the hard disk drive, network card information, etc. Obtaining this information through out-of-band management can accurately reflect the real, fine-grained hardware configuration of the online device.

[0164] (2) Obtain information on the flow of loose parts and complete machines in the warehouse: In this embodiment, the transfer information targets assets that are not deployed in the data center, i.e., warehouse assets. It is obtained through the warehouse management module in the operation and maintenance system.

[0165] Components: These refer to independent, usable, or replaceable parts, such as spare CPUs, memory modules, hard drives, power supply modules, etc.

[0166] Complete equipment: In this context, it refers to a complete spare device, such as a spare server or switch.

[0167] The circulation information records the entire lifecycle dynamics of these warehouse assets, including but not limited to changes in the time, operator, quantity, and inventory location (such as warehouse and shelf number) of operations such as receiving, issuing, returning, borrowing, and scrapping. This ensures that the status of offline assets can also be obtained in a timely manner.

[0168] By combining the two types of information mentioned above, this embodiment makes asset inventory no longer one-sided, but a complete view covering the entire lifecycle of assets. It includes both equipment running online and its internal details, as well as spare parts circulation in offline warehouses, truly realizing unified, real-time, and refined management of data center-related assets (from complete machines to components, from online to offline), effectively eliminating management blind spots.

[0169] Based on the above embodiments, in another embodiment provided in this application, when verifying the first asset data and the second asset data to generate the asset inventory result, the above step S320 may further include the following steps: Step S321: Obtain the inventory strategy. This inventory strategy guides the reconciliation process between the first asset data and the second asset data.

[0170] In this embodiment, the inventory strategy can be a set of rules and parameters predefined by the user according to actual business needs. Its function is to guide the automated verification process between the first asset data and the second asset data. Users can customize the specific execution method of the inventory task through the configuration interface provided by the terminal, for different inventory scenarios and objectives.

[0171] Step S322: Based on the inventory strategy, the first asset data and the second asset data are compared to obtain the asset inventory results.

[0172] In this embodiment, after obtaining the inventory strategy, the verification process may not involve a uniform comparison of all asset data. Instead, it may first filter and select the first asset data (ledger) and the second asset data (real-time status) based on the conditions in the strategy. For example, if the strategy limits the inventory scope to "Data Center A" and the asset type to "servers," the embodiment may select only the data that meets these conditions for comparison. Subsequently, the embodiment performs matching (e.g., through serial number association) and difference analysis on the filtered dataset. This strategy-based verification mechanism can greatly improve the targeting and execution efficiency of the inventory operation, avoid unnecessary consumption of computing resources, and generate more business-specific inventory results.

[0173] In the example, users can flexibly formulate the most suitable inventory plan according to the control priorities, resource status or audit requirements, so as to meet the diverse management needs in complex operation and maintenance environments while ensuring the accuracy of the inventory.

[0174] In the embodiments, the above-mentioned inventory strategy includes one or more of the following: inventory scope, inventory object type, and inventory triggering conditions.

[0175] In this embodiment, the scope of the inventory may include the region and location of the assets.

[0176] The types of objects to be inventoried include one or more of the following: complete equipment, loose components, and equipment parts. Complete equipment, loose components, and equipment parts together constitute the hardware assets of the data center. Complete equipment is a complete unit with independent operating functions; equipment parts are components that make up complete equipment; and loose components are spare or replaceable units that exist independently of complete equipment. Complete equipment includes servers, switches, or storage devices. Equipment parts include CPUs, memory, hard drives, or network interface cards (NICs).

[0177] Inventory counts can be triggered by timed events or events; events include asset receipt operations, asset issuance operations, or asset information change operations.

[0178] Specifically, the inventory scope is used to spatially or logically define the boundaries of assets that need to be inventoried. Users can specify scopes of different granularities according to management needs, such as a specific data center, a server room, a group of server racks, a warehouse, or even a specific shelf. By setting the scope, it is possible to flexibly switch from a global survey to a precise local check, significantly improving inventory efficiency.

[0179] The inventory object type defines the specific category and granularity of the assets to be inventoried. It supports inventorying assets of different forms and levels, such as: Complete equipment: such as servers, switches, storage devices, and other complete functional units; Individual spare parts: Independent spare components; Equipment components: Key components already installed inside the complete machine, such as CPUs, memory, hard drives, network cards, etc. This reflects the level of detail in the inventory operation.

[0180] The inventory count trigger condition controls when the inventory count task starts and its execution frequency. Specifically, it can be set as follows: Scheduled triggering: For example, set it to run automatically at midnight on the 1st of each month to achieve periodic routine inventory checks and meet compliance requirements.

[0181] Event-triggered: Associated with specific business events, such as automatically triggering an inventory count after monitoring the completion of asset inbound or outbound operations, or changes in key asset information. This ensures timely verification when asset status changes, improving the real-time nature of asset data.

[0182] Asset entry operation: Triggered when a new asset is registered and entered into the warehouse, ensuring that the new asset is recorded in a timely manner.

[0183] Asset outbound operation: triggered when an asset is issued or outbound, ensuring that the asset flow is accurately recorded.

[0184] Asset information change operation: triggered when key asset information (such as configuration and location) is detected to change, ensuring that the ledger and real-time status are quickly synchronized.

[0185] This implementation breaks down inventory strategies into several independently configurable yet combinable dimensions: scope, object type, and triggering conditions. This allows users to quickly construct highly accurate inventory tasks tailored to specific scenarios. This enhances the flexibility and practicality of the solution, accurately meeting diverse asset management needs, from periodic audits to immediate confirmation after changes, and avoiding the resource waste associated with fixed inventory models.

[0186] Based on the above embodiments, in another embodiment provided in this application, the method may further include the following steps: In step S340, a visualization interface is generated, and the asset inventory results are output through the visualization interface.

[0187] The visual interface is used to display the details of inventory discrepancies and / or provide the function of exporting inventory results.

[0188] In this embodiment, the asset inventory results data generated in step S320, which may be somewhat abstract, can be transformed into an intuitive and easy-to-understand visual interface and presented to the user. This interface serves as the main portal for user interaction with the inventory system, and its core functions can be reflected in one or more of the following aspects: To display detailed inventory discrepancies: the interface doesn't just show a simple percentage of similarity; instead, it clearly lists all discovered discrepancies in a structured manner (such as tables, lists, or charts). Each line of discrepancy details typically includes key information such as asset identifier (serial number), discrepancy type (e.g., "inventory surplus," "inventory shortage," "information discrepancy"), ledger information, physical item information, and the specific details of the discrepancy (e.g., inconsistent location, different configuration models, etc.). This allows users to quickly locate problematic assets and understand the details of the discrepancy.

[0189] The system provides an export function for inventory results: To meet the needs of archiving, distribution, auditing, or further offline analysis, the visualization interface also integrates a report export function. Users can use interface operations (such as clicking the "Export" button) to generate standard format files (such as tables or documents) and save them locally, including summary statistics and complete discrepancy details.

[0190] The example demonstrates how a visual interface transforms complex verification data into easily understandable information, significantly reducing the user's interpretation costs and facilitating rapid decision-making.

[0191] By dividing each function into corresponding modules, this application provides a data center asset inventory device based on an operation and maintenance system. This device can be a server, a terminal, or a chip applied to a server. Figure 4This is a schematic block diagram of the functional modules of a data center asset inventory device based on an operation and maintenance system, provided as an exemplary embodiment of this application. (See diagram for reference.) Figure 4 As shown, the asset inventory device includes: The asset data acquisition module 41 is used to acquire first asset data and second asset data. The first asset data is obtained based on the static asset ledger data provided by the asset management system, which records the baseline information of the data center hardware assets. The second asset data is obtained based on the actual asset data obtained by the operation and maintenance system, which represents the current status of the data center hardware assets. The asset inventory result generation module 42 is used to verify the first asset data and the second asset data and generate the asset inventory result; the asset inventory result is used to represent the difference between the first asset data and the second asset data.

[0192] The data synchronization instruction generation module 43 generates data synchronization instructions based on the asset inventory results. The data synchronization instructions are used to correct the static asset ledger data corresponding to the first asset data according to the second asset data, so as to achieve consistency between the static asset ledger data and the actual asset data.

[0193] In another embodiment provided in this application, the asset data acquisition module 41 described above is specifically used for: Obtain the original static asset ledger data from the asset management system; The original static asset ledger data is converted into a standardized asset model with unified field definitions as the second asset data to obtain the first asset data; The standardized asset model includes a unique identifier field to identify the asset, an asset category field to describe the asset type, and a location field to indicate the physical location of the asset.

[0194] In another embodiment provided in this application, the asset data acquisition module 41 is further used for: The system obtains real-time status information of assets from the operation and maintenance system, which is used to monitor and collect the actual status and circulation information of assets in real time. Among them, circulation information refers to the status and location change data of assets during the circulation process in the warehouse.

[0195] Second asset data is obtained based on real-time status information.

[0196] This solution ensures that the secondary asset data not only has a high degree of real-time accuracy, accurately reflecting the instantaneous status of assets, but also, through standardized processing, enables precise and automated verification with static ledger data within a unified framework. This solves the problems of inefficiency and frequent errors caused by data lag and inconsistent formats in traditional inventory methods.

[0197] In another embodiment provided in this application, the real-time status information includes: information on the complete machine and components of the managed equipment obtained through out-of-band management, and / or information on the flow of loose parts and complete machines in the warehouse. Here, a complete machine is an independent device deployed in a data center and in operation; a component is an identifiable device installed inside the complete machine; and loose parts are independent materials stored in the warehouse but not installed in the complete machine.

[0198] This solution enables unified, real-time, and refined management of data center assets, effectively eliminating management blind spots.

[0199] In another embodiment provided in this application, the asset inventory result generation module 42 is specifically used for: Obtain the inventory strategy, which guides the reconciliation process between primary and secondary asset data. Based on the inventory strategy, the data of the first asset and the data of the second asset are compared to obtain the asset inventory results.

[0200] In another embodiment provided in this application, the inventory strategy includes one or more of the following: inventory scope, inventory object type, and inventory triggering conditions.

[0201] In this solution, users can flexibly formulate the most suitable inventory plan according to the control priorities, resource status or audit requirements, so as to meet the diverse management needs in complex operation and maintenance environments while ensuring the accuracy of the inventory.

[0202] In yet another embodiment provided in this application, the scope of the inventory includes the region and location of the assets; The types of items to be inventoried include one or more of the following: complete equipment, loose materials, and equipment components. Complete equipment, loose materials, and equipment components together constitute the hardware assets of the data center. Complete equipment is a complete unit with independent operating functions, equipment components are the parts that make up the complete equipment, and loose materials are spare or replaceable units that exist independently of complete equipment. Complete equipment includes servers, switches, or storage devices; equipment components include CPUs, memory, hard drives, or network interface cards.

[0203] The inventory count is triggered by either a timed event or an event; events include asset receipt, asset release, or asset information change operations.

[0204] In another embodiment provided in this application, the above-mentioned synchronization instructions may include data addition instructions, data deletion instructions, and / or data modification instructions.

[0205] In another embodiment provided in this application, the device further includes a visualization interface generation module, used for: Generate a visual interface to output the asset inventory results. The visual interface is used to display the details of inventory discrepancies and / or provide the function of exporting inventory results.

[0206] This solution transforms complex verification data into easily understandable information through a visual interface, significantly reducing the user's interpretation costs and facilitating rapid decision-making.

[0207] This application also provides a computing device, such as... Figure 5 As shown, Figure 5 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. The computing device can be the server mentioned above, including a processor 501, a communication interface 502, a memory 503 and a communication bus 504, wherein the processor 501, the communication interface 502 and the memory 503 communicate with each other through the communication bus 504.

[0208] Memory 503 is used to store computer programs; The processor 501, when executing the program stored in the memory 503, implements the method described above in the embodiments of this application.

[0209] The communication bus mentioned in the computing device above can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0210] The communication interface is used for communication between the aforementioned computing device and other devices.

[0211] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0212] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0213] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the methods described above in the embodiments of this application.

[0214] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute the methods described above in the embodiments of this application.

[0215] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0216] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0217] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, computing devices, and computer-readable storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0218] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A method for data center asset inventory based on an operation and maintenance system, characterized in that, The method comprises: obtaining first asset data and second asset data; wherein the first asset data is obtained based on static asset ledger data provided by an asset management system, the static asset ledger data recording reference information of data center hardware assets; the second asset data is obtained based on actual asset data obtained by an operation and maintenance system, the actual asset data representing a current state of the data center hardware assets; checking the first asset data and the second asset data to generate an asset inventory result; the asset inventory result is used to represent differences between the first asset data and the second asset data; based on the asset inventory result, generating a data synchronization instruction; the data synchronization instruction is used to correct the static asset ledger data corresponding to the first asset data according to the second asset data, to realize consistency between the static asset ledger data and the actual asset data.

2. The method of claim 1, wherein, The first asset data is obtained, comprising: obtaining original static asset ledger data from the asset management system; converting the original static asset ledger data into a standardized asset model with unified field definitions as the second asset data, to obtain the first asset data; wherein the standardized asset model includes a unique identifier field for identifying assets, an asset category field for describing asset types, and a positioning field for indicating asset physical locations.

3. The method of claim 1, wherein, The second asset data is obtained, comprising: obtaining real-time state information of assets from the operation and maintenance system, the operation and maintenance system being used to monitor and collect actual states and transfer information of assets in real time; wherein the transfer information represents state and location change data generated during warehouse transfer process of assets; obtaining the second asset data based on the real-time state information.

4. The method of claim 3, wherein, The real-time state information includes whole machine and component information of managed devices obtained through out-of-band management mode, and / or transfer information of spare parts and whole machines in the warehouse; wherein the whole machine is an independent device deployed in the data center and in a running state, the component is an identifiable device installed inside the whole machine, and the spare part is an independent material stored in the warehouse and not installed in the whole machine.

5. The method of claim 1, wherein, The first asset data and the second asset data are checked to generate an asset inventory result, comprising: obtaining an inventory strategy, the inventory strategy being used to guide the checking process between the first asset data and the second asset data; based on the inventory strategy, checking the first asset data and the second asset data to obtain an asset inventory result.

6. The method of claim 5, wherein, The inventory strategy includes one or more of inventory range, inventory object type, and inventory trigger condition.

7. The method of claim 6, wherein, The inventory range includes the region and location to which the asset belongs. The inventory object types include one or more of the following: whole machine equipment, spare part material, and equipment component; wherein the whole machine equipment, the spare part material, and the equipment component together constitute a hardware asset set of the data center, the equipment component is a constituent element of the whole machine equipment, and the spare part material is a spare or replaceable unit independent of the whole machine equipment; the whole machine equipment includes a server, a switch, or a storage device; and the equipment component includes a CPU, a memory, a hard disk, or a network card. The inventory triggering condition is a timing trigger or an event trigger; wherein the event includes an asset warehousing operation, an asset delivery operation, or an asset information change operation.

8. The method of claim 1, wherein, The synchronization instruction includes a data addition instruction, a data deletion instruction, and / or a data modification instruction.

9. The method of claim 1, wherein, The method further includes: generating a visual interface through which the asset inventory result is output; wherein the visual interface is used to display inventory difference details and / or provide an export function of the inventory result.

10. A computing device, comprising: comprise: at least one processor; a memory for storing instructions executable by the at least one processor; wherein the at least one processor is configured to execute the instructions to implement the method of any one of claims 1-9.

Images