Server component tracking method and system

Abstract

The application discloses a kind of server component tracking method and system, it is related to information technology field, the server component tracking method and system disclosed, by obtaining the original component data of each component of server, standard component data are obtained by preprocessing, generate component digital identity certificate data, store to blockchain network, real-time verification and exception handling, the problem of low efficiency, poor security of traditional method is solved, efficient server component tracking is realized, can improve the efficiency and accuracy of server component tracking, enhance data security and real-time exception response capability, improve historical traceability reliability.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to server component tracking methods and systems. Background Technology

[0002] Throughout the entire process of server manufacturing, deployment, and maintenance, core components such as central processing units (CPUs), memory modules, hard disk drives (HDDs), motherboards, and power supplies are critical assets. Accurate tracking of their quantity, specifications, physical location, and operational status is crucial for ensuring system stability and security. However, current industry practices primarily rely on manual registration or partially automated systems for component information management. Manual operations are not only lengthy and inefficient, but also prone to data errors, omissions, and even information distortion due to operator fatigue or negligence, resulting in a severe disconnect between component records and their actual status. While partially automated solutions can collect specific parameters of some components, they are often limited by technical architecture and only adapt to a single type of component, failing to comprehensively cover the diverse needs of heterogeneous components in servers, leading to information fragmentation. More importantly, existing mechanisms lack reliable data integrity protection. When faced with unauthorized component replacement or malicious information tampering, the system cannot proactively identify anomalies and respond in real time, causing a break in the component history record chain and making it difficult to trace and assign responsibility for lost materials or fraudulent activities. The aforementioned static recording mode, coupled with the lack of real-time verification capabilities, creates vulnerabilities in server component management regarding dynamic security protection and end-to-end traceability, leading to the continuous accumulation of security risks and severely limited traceability efficiency.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a server component tracing method and system, which aims to improve the efficiency and accuracy of server component tracing.

[0005] To achieve the above objectives, this application proposes a server component tracing method, the method comprising: Obtain the raw component data of each component of the server, and preprocess the raw component data to obtain standard component data; Component digital identity certificate data is generated based on the standard component data. The component digital identity certificate data includes component unique identifier data, component type data, and digital signature data. The digital identity certificate data of the component is stored in a blockchain network to obtain blockchain storage record data; Based on the component's digital identity certificate data and preset verification strategy data, the current server component is verified in real time to obtain component verification result data; When the component verification result data indicates verification failure, an exception handling instruction data is generated based on the blockchain stored record data and the component verification result data. Execute the exception handling instruction data and update the component tracking status data.

[0006] In one embodiment, the step of performing real-time verification of the current server component based on the component's digital identity certificate data and preset verification strategy data to obtain component verification result data includes: Based on the digital identity certificate data of the aforementioned component, perform first-level digital certificate verification on the current server component to obtain certificate verification result data; When the certificate verification result data indicates an anomaly in the first-level verification, the physical feature data of the current server component is collected, and the second-level physical feature verification is performed based on the physical feature data to obtain the physical feature verification result data. Based on the certificate verification result data and the physical feature verification result data, and combined with the preset risk level model data, a comprehensive evaluation is performed to obtain the component verification result data.

[0007] In one embodiment, when the certificate verification result data indicates a first-layer verification anomaly, the steps of collecting physical feature data of the current server component, performing second-layer physical feature verification based on the physical feature data, and obtaining physical feature verification result data include: Extract the runtime parameter data of the current server component from the original component data. The runtime parameter data includes power consumption parameter data, temperature parameter data, and response time parameter data. Obtain the baseline feature data of the corresponding component from the historical feature database; The runtime parameter data is compared with the baseline feature data to calculate the feature difference data. Based on the comparison results between the feature difference data and the preset difference threshold data, and combined with the certificate verification result data, the physical feature verification result data is generated.

[0008] In one embodiment, the step of obtaining the component verification result data by comprehensively evaluating the certificate verification result data and the physical feature verification result data in conjunction with preset risk level model data includes: Based on the component type data and historical anomaly record data of the current server component, the basic risk level data is calculated; Based on the current system environmental parameter data and safety status data, the environmental risk coefficient is calculated; Based on the basic risk level data and the environmental risk coefficient, combined with the certificate verification result data and the physical characteristic verification result data, a comprehensive risk score data is calculated using a weighted scoring algorithm. The comprehensive risk score data is compared and processed with preset risk threshold data to generate the component verification result data; wherein, the component verification result data includes verification pass status data, verification doubt status data, and verification failure status data.

[0009] In one embodiment, when the component verification result data indicates verification failure, the step of generating exception handling instruction data based on the blockchain storage record data and the component verification result data includes: The current verification status is determined based on the component verification result data; When the component verification result data indicates a verification failure status, the complete change history data of the current server component is obtained based on the blockchain storage record data. Based on the complete change history data, abnormal operation node location processing is performed, and isolation processing instruction data is generated by combining the component verification result data; wherein, the isolation processing instruction data includes the abnormal processing instruction data.

[0010] In one embodiment, the steps of locating abnormal operation nodes based on the complete change history data and generating isolation processing instruction data in conjunction with the component verification result data include: Extract the most recent preset number of change records from the complete change history data; The change record data is validated based on the blockchain consensus mechanism to identify suspicious change operation data. Based on the time series of the suspicious change operation data, operation chain data is constructed, and abnormal pattern analysis processing is performed on the operation chain data to obtain abnormal pattern analysis result data. Based on the abnormal pattern analysis results, abnormal operation node data is determined, and isolation processing instruction data containing the location information of the abnormal operation node data is generated.

[0011] In one embodiment, the method further includes: Each verification operation generates verification transaction data, and the verification transaction data is associated with the component digital identity certificate data to obtain associated verification data; The associated verification data is packaged into block data based on a distributed consensus mechanism; The block data is linked to the blockchain network to form a verification chain data; When it is necessary to trace the historical status of a component, relevant verification record data is extracted from the verification chain data.

[0012] In one embodiment, the step of packaging the associated verification data into block data based on a distributed consensus mechanism includes: When it is necessary to record a verification transaction, the verification request data is broadcast to multiple verification nodes in the blockchain network; Each verification node performs validity verification on the component's digital identity certificate data based on locally stored blockchain copy data, and obtains node verification result data; Once a preset number of verification nodes confirm the validity of the verification, consensus result data is generated. New block data is generated based on the consensus result data, and the new block data includes hash reference data of the verification transaction data and the component digital identity certificate data; The new block data is added to the blockchain, updating the blockchain replica data of all validator nodes.

[0013] In one embodiment, the method further includes: Smart contract code data is generated based on preset compliance rule data, and the smart contract code data is deployed to the blockchain network to obtain deployed smart contract data; When component change operation data is detected, the smart contract data after deployment is automatically triggered to perform a verification operation; The deployed smart contract data performs legality verification processing on the component change operation data based on the preset compliance rule data to obtain legality verification result data; When the legality verification result data indicates that the verification fails, the violation processing operation is automatically executed based on the preset violation processing logic data.

[0014] Furthermore, to achieve the above objectives, this application also proposes a server component tracing system, which includes: a memory, a processor, and a server component tracing program stored in the memory and executable on the processor, wherein the server component tracing program is configured to implement the steps of the server component tracing method.

[0015] The server component tracking method and system proposed in this application solves the problems of low efficiency and poor security of traditional methods by acquiring the original component data of each server component, preprocessing to obtain standard component data, generating component digital identity certificate data, storing it in the blockchain network, and performing real-time verification and anomaly handling. It achieves efficient server component tracking, improves the efficiency and accuracy of server component tracking, enhances data security and real-time anomaly response capabilities, and improves the reliability of historical traceability. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating an embodiment of the server component tracing method of this application; Figure 2 This is a schematic diagram of a server component tracking system according to an embodiment of this application.

[0019] Explanation of icon numbers: 10. Memory; 20. Processor.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] The technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of this application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0022] It should be understood that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, the terms "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0023] In existing technologies, server component management typically employs manual registration or semi-automated systems to record component information. Manual registration is inefficient and prone to errors due to human negligence, leading to inaccurate or missed entries. While semi-automated systems can automatically collect some information, they usually only cover specific types of components and cannot cover all server components. Furthermore, existing solutions lack effective anti-tampering mechanisms and real-time verification capabilities. When unauthorized component replacement or information tampering occurs, the system cannot detect and issue timely warnings, disrupting the component traceability chain and making it difficult to fundamentally solve the problem of lost materials. This results in serious security risks and traceability difficulties in server component management.

[0024] Based on this, embodiments of this application provide a server component tracing method, referring to... Figure 1 The server component tracing method includes steps S100 to S600, wherein: Step S100: Obtain the original component data of each component of the server, and preprocess the original component data to obtain standard component data; Step S200: Generate component digital identity certificate data based on the standard component data. The component digital identity certificate data includes component unique identifier data, component type data, and digital signature data. Step S300: Store the component's digital identity certificate data in a blockchain network to obtain blockchain storage record data; Step S400: Based on the component digital identity certificate data and preset verification strategy data, perform real-time verification on the current server component to obtain component verification result data; Step S500: When the component verification result data indicates verification failure, an exception handling instruction data is generated based on the blockchain storage record data and the component verification result data. Step S600: Execute the exception handling instruction data and update the component tracking status data.

[0025] In this embodiment, raw component data refers to unprocessed initial information directly collected or read from various server components, such as component serial numbers, models, production batches, manufacturer information, firmware versions, etc. This data may contain inconsistent formats, redundancy, or missing information. Standard component data refers to preprocessed raw component data, whose format has been standardized and unified, and may have been cleaned and deduplicated to facilitate subsequent digital identity certificate generation and system processing. Component digital identity certificate data is an electronic credential created for server components, used to uniquely identify and verify the component's identity. This certificate data carries key component information and has tamper-proof characteristics. Component unique identifier data is a string or code used to uniquely identify a specific server component throughout the tracking system, such as a globally unique serial number or hash value. Component type data describes the category of server components, such as CPU, memory, hard drive, motherboard, power supply, etc., helping the system to classify, manage, and verify different types of components. Digital signature data is data generated by signing the component digital identity certificate data using cryptographic techniques, used to verify the integrity of the certificate and the authenticity of its source, preventing data tampering.

[0026] In this embodiment, the blockchain network is a decentralized distributed ledger system characterized by data being stored in a chain-like manner in the form of blocks, and using cryptographic technology to ensure the immutability and traceability of the data. Blockchain storage record data refers to the immutable transaction records or data entries formed on the blockchain after the component's digital identity certificate data is successfully stored on the blockchain network. Pre-defined verification strategy data consists of a series of rules and logics predefined by the system to guide the real-time verification process of server components, such as verifying the validity of certificates and the compliance of component status. Component verification result data is the conclusion drawn after verifying the current server component according to the pre-defined verification strategy, indicating whether the component has passed verification, such as verification passed, verification suspicious, or verification failed. Anomaly handling instruction data is a sequence of commands or operations generated by the system according to pre-defined logic when the component verification result indicates verification failure, guiding subsequent anomaly handling, such as isolation, alarm, or rollback operations. Component tracking status data reflects the current status of the server component throughout its entire lifecycle, such as in stock, in use, under maintenance, scrapped, or abnormal, and this status data is updated as the component changes and verification results change.

[0027] In this embodiment, the server component tracking method first acquires the raw component data of each server component and preprocesses this raw component data to obtain standard component data. Specifically, the raw component data can be acquired in various ways. For example, it can be acquired manually by an operator who manually enters information such as the component's serial number, model number, and production date; this information may be directly read from the component label. Alternatively, the raw component data can be acquired by scanning the barcode or QR code on the component; the scanning device reads the component information encoded in the barcode / QR code and transmits it to the system. Furthermore, for components with electronic identification or programmable interfaces, the raw component data can be acquired by calling the API interface provided by the component manufacturer or by directly reading it from the component firmware using specific diagnostic tools. The acquired raw component data is then preprocessed, such as by standardizing the format, cleaning, and deduplicating, to form standard component data for subsequent processing.

[0028] Furthermore, component digital identity certificate data is generated based on this standard component data. This component digital identity certificate data includes component unique identifier data, component type data, and digital signature data. For example, the standard component data can be sent to a central server responsible for generating a digital identity certificate for each component. The certificate may contain the component's unique identifier, type, and a digital signature signed with the central server's private key. Alternatively, upon initial installation or registration of the component, a digital identity certificate can be generated by a local device or a dedicated registration terminal based on the standard component data and signed using a pre-configured private key. Furthermore, the standard component data can also be submitted to a trusted third-party Certificate Authority (CA), which will issue a digital identity certificate for the component, verifying the authenticity of the component information and signing the certificate using its private key.

[0029] In this embodiment, the component's digital identity certificate data is stored in a blockchain network to obtain blockchain storage record data. Specifically, the component's digital identity certificate data can be directly submitted to the blockchain network as part of transaction data, with each certificate data being packaged into a transaction and broadcast to nodes in the network. Alternatively, only the hash value of the component's digital identity certificate data can be stored in the blockchain network, while the original certificate data is stored in an off-chain database or distributed file system, with the hash value on the blockchain serving as its immutable index. As a preferred implementation, a smart contract can be deployed to the blockchain network, defining the logic for storing and managing the component's digital identity certificate data. The certificate data or its hash value is stored by calling specific functions of the smart contract.

[0030] Based on this, the system performs real-time verification of the current server component using its digital identity certificate data and preset verification strategy data, obtaining the component verification result data. For example, during real-time verification, the system obtains the digital identity certificate data of the current server component and performs a simple comparison with the certificate data stored on the blockchain. The preset verification strategy may only include checking whether the certificate's hash value is consistent and whether the certificate has expired. Alternatively, the verification process may include checking the validity of the current component's digital identity certificate, such as verifying whether its digital signature was issued by a trusted authority and whether the certificate is within its validity period. The preset verification strategy may also include checking whether the certificate has been revoked. In addition, the preset verification strategy data may contain a series of hard-coded rules, such as "the CPU model must be consistent with the one used during registration" and "the memory capacity must not be lower than a certain threshold." The system obtains the real-time information of the current component and makes judgments based on these rules.

[0031] In this embodiment, when the component verification result data indicates verification failure, exception handling instruction data is generated based on the blockchain storage record data and the component verification result data. Specifically, when the component verification result data indicates verification failure, the system can generate exception handling instruction data according to preset fixed logic. For example, regardless of the reason for failure, the system uniformly generates instructions to "send an alarm email" and "record an exception log". As another implementation, when verification fails, the system returns a specific error code, and the exception handling instruction data is generated based on this error code. For example, error code 101 indicates "invalid certificate signature", so the system generates an instruction to "isolate the component". In addition, the exception handling instruction data can be a predefined script or program call, which is triggered to execute when verification fails. The script contains logic for handling exceptions, such as shutting down related services, sending notifications, or starting diagnostic programs.

[0032] In this embodiment, the exception handling instruction data is executed to update the component tracking status data. For example, after the exception handling instruction data is generated, the system displays it to the administrator, who then manually performs the corresponding operations, such as physically isolating the component or replacing it. The component tracking status data is also manually updated by the administrator. Alternatively, the exception handling instruction data is sent to a specific execution module, which can automatically execute some instructions, such as sending alarm notifications or disabling network ports. After the instructions are executed, the system automatically updates the component tracking status data to "Exception" or "Pending Processing." As a preferred implementation, the component tracking status data is stored in a centralized database. When the exception handling instruction data is executed, the system updates the component's tracking status by calling the database interface, for example, updating the status from "Normal" to "Isolated" or "Pending Disposal."

[0033] In this embodiment, tamper-proof storage and real-time verification of server component information are achieved through component digital identity certificates and blockchain technology. This method effectively solves the problems of inefficiency, error-proneness, limited coverage, and lack of anti-tampering mechanisms in traditional manual registration and semi-automated systems for component information recording. Through real-time verification and the generation and execution of anomaly handling instructions, this application can promptly detect illegal component replacement or information tampering, thereby effectively maintaining the integrity of the component traceability chain, reducing the risk of material loss, and improving the security and traceability of server component management.

[0034] In one feasible implementation, the step of performing real-time verification of the current server component based on the component digital identity certificate data and preset verification strategy data to obtain component verification result data includes: performing a first-layer digital certificate verification on the current server component based on the component digital identity certificate data to obtain certificate verification result data; when the certificate verification result data indicates an anomaly in the first-layer verification, collecting the physical feature data of the current server component, performing a second-layer physical feature verification based on the physical feature data to obtain physical feature verification result data; and performing a comprehensive evaluation based on the certificate verification result data and the physical feature verification result data, combined with preset risk level model data, to obtain the component verification result data.

[0035] In this embodiment, the first-layer digital certificate verification aims to confirm the authenticity and integrity of the digital identity of the current server component. Specifically, this verification process may include decrypting and comparing the digital signature data in the component's digital identity certificate data to verify whether the certificate was issued by a trusted authority and has not been tampered with. Simultaneously, the certificate's validity period, revocation status, and consistency with the component's unique identifier data can also be checked. Through cryptographic algorithms and a trust chain mechanism, it is ensured that the component's digital identity is legitimate and has not been forged.

[0036] In this embodiment, when an anomaly occurs in the first-layer digital certificate verification, it is necessary to collect physical characteristic data of the current server component in order to more deeply evaluate the true state of the component. This physical characteristic data may include, but is not limited to, the component's runtime parameters (such as power consumption parameters, temperature parameters, response time parameters, I / O throughput, etc.), hardware configuration information, firmware version, and real-time operating metrics obtained through sensors. The data can be collected through the server's hardware management interface (such as BMC), operating system logs, performance monitoring tools, or a dedicated sensor network.

[0037] In this embodiment, the second-layer physical feature verification is based on the collected physical feature data and aims to assess whether the actual operating state of the component meets expectations. This verification process typically involves comparing and analyzing the currently collected physical feature data with preset benchmark feature data or historical normal operating data. For example, a machine learning model can be used to model the normal behavior pattern of the component, and then detect whether there are deviations or abnormal patterns in the current physical feature data. In this way, even if the digital certificate is valid, abnormal behavior at the physical level of the component can be detected.

[0038] In this embodiment, preset risk level model data is used to comprehensively evaluate the first-layer digital certificate verification result data and the second-layer physical feature verification result data to generate the final component verification result data. This model can be a rule-based expert system, a weighted scoring system, or a machine learning classifier. It defines the contribution of different verification results (such as certificate anomalies or physical feature anomalies) to the overall risk and quantifies the risk by combining other contextual information (such as component type data, historical anomaly record data, and current system environment parameter data).

[0039] In this embodiment, the comprehensive evaluation involves inputting the first-layer digital certificate verification result data and the second-layer physical feature verification result data into a preset risk level model data. Through model calculation and logical judgment, a unified component verification result data is obtained. This process considers both the legitimacy of the digital identity and the health of physical operation, avoiding the limitations of a single verification method. For example, if the certificate verification passes but the physical features are abnormal, the model may evaluate it as "verification suspicious status data"; if both are abnormal, it may be evaluated as "verification failed status data".

[0040] In this embodiment, the component verification result data is the final judgment derived after comprehensive evaluation, indicating the current trust status of the server component. This data can include multiple states, such as "verification passed," "verification suspicious," and "verification failed." "Verification passed" indicates that the component's digital identity and physical operation are normal; "verification suspicious" indicates that there are some anomalies but not enough to immediately determine failure, requiring further observation or manual intervention; "verification failed" indicates that the component has serious problems and requires immediate action.

[0041] In this embodiment, through the above technical solution, this application further introduces a multi-layered, multi-dimensional verification mechanism based on real-time verification using component digital identity certificate data. First, through the first-layer digital certificate verification, the authenticity and integrity of the component's digital identity can be quickly and effectively confirmed, preventing forged or tampered components from entering the system. When an anomaly occurs in the digital certificate verification, the system does not simply determine failure but further triggers the second-layer physical feature verification, collecting and analyzing the component's physical operating data. This mechanism can compensate for the shortcomings of single digital certificate verification; even if the digital certificate itself has not been tampered with, potential problems can be discovered by detecting abnormal physical behavior of the component (such as performance degradation, abnormal power consumption, etc.). Finally, by combining the results of the two layers of verification with preset risk level model data, a more comprehensive and accurate judgment of the component's true state and potential risks can be made, thereby generating more refined component verification result data. This layered, progressive, and comprehensive evaluation verification method improves the robustness and accuracy of server component tracking, effectively identifying physical anomalies that are difficult to detect solely based on digital identity, providing a more reliable basis for subsequent anomaly handling, thereby ensuring the stable operation and security of the server system.

[0042] In one feasible implementation, when the certificate verification result data indicates a first-level verification anomaly, the steps of collecting physical feature data of the current server component and performing second-level physical feature verification based on the physical feature data to obtain physical feature verification result data include: extracting runtime parameter data of the current server component from the original component data, the runtime parameter data including power consumption parameter data, temperature parameter data, and response time parameter data; obtaining baseline feature data of the corresponding component from the historical feature database; performing feature comparison processing between the runtime parameter data and the baseline feature data to calculate feature difference data; and generating the physical feature verification result data based on the comparison result of the feature difference data and the preset difference threshold data, combined with the certificate verification result data.

[0043] In this embodiment, runtime parameter data refers to real-time indicators reflecting the dynamic performance and health status of server components during actual operation. Power consumption parameter data can be obtained through the server's power management unit, dedicated power consumption sensors, or by monitoring power rail voltage and current. Abnormal fluctuations in power consumption parameter data may indicate component failure, overload, or unauthorized replacement. Temperature parameter data typically originates from thermistors integrated within the components or ambient temperature sensors near the components. Abnormal temperature values ​​are often a direct reflection of component overheating, cooling system failure, or abnormal workload. Response time parameter data is obtained by sending requests to components and recording their response times. Examples include read / write latency of storage devices, packet latency of network interfaces, or the completion time of processors executing specific tasks. Increases in response time parameter data may indicate performance degradation, impending failure, or malicious interference. The extraction of these parameters typically relies on the server's hardware monitoring system, operating system logs, hardware management interfaces, or customized diagnostic tools.

[0044] In this embodiment, to perform effective comparison, it is necessary to obtain the baseline characteristic data of the corresponding component from the historical characteristic database. The baseline characteristic data is a set of verified operational behavior patterns or performance indicators established under known normal operating conditions for a specific type or instance of server component. This historical characteristic database can be collected and established during the component's initial installation, factory testing, or long-term stable operation. It typically contains typical ranges, average values, statistical distributions, or normal behavior patterns built based on machine learning models for the corresponding component model, firmware version, and even specific serial number under different load conditions, including power consumption parameters, temperature parameters, and response time parameters. This baseline data provides a reliable reference for subsequent real-time runtime parameter comparisons.

[0045] In this embodiment, the runtime parameter data and the baseline feature data are subjected to feature comparison processing to calculate feature difference data. Feature comparison processing refers to the process of quantitatively comparing the currently collected runtime parameter data with the baseline feature data stored in the historical feature database to assess the degree of deviation between the two. This comparison can be implemented in various ways, such as calculating the absolute difference, percentage deviation, standard deviation from the mean, or using statistical distance metrics to measure the differences of multidimensional parameters. In addition, anomaly detection algorithms can also be used to score the runtime parameter data to quantify its degree of anomalousness. The calculated feature difference data can be a comprehensive numerical value, a vector containing the differences of each parameter, or a score indicating the probability of anomalies.

[0046] In this embodiment, the physical feature verification result data is generated based on the comparison result between the feature difference data and the preset difference threshold data, combined with the certificate verification result data. The preset difference threshold data is a pre-set numerical limit or a set of limits used to determine whether the feature difference data exceeds the normal range. These thresholds are usually determined through experience testing, domain expert knowledge, or statistical analysis of historical data. During the comparison, if the feature difference data exceeds the preset difference threshold data, it indicates that there is a physical anomaly. Simultaneously, this comparison result is combined with the certificate verification result data. If the certificate verification result data already indicates a first-level verification anomaly, then the difference in physical features will further strengthen the judgment that the component has a problem, thereby generating physical feature verification result data indicating "physical anomaly" or "physical verification failure". Even if the difference in physical features is small, combined with the certificate anomaly, it may still suggest the need for further investigation to form more comprehensive and accurate physical feature verification result data.

[0047] In this embodiment, through the above technical solution, when digital certificate verification fails, this application can perform an in-depth physical state assessment of server components using multi-dimensional, real-time physical characteristic data (such as power consumption parameter data, temperature parameter data, and response time parameter data). By accurately comparing these runtime parameter data with benchmark characteristic data in a historical feature database and combining them with preset difference threshold data for judgment, abnormal operating states or potential tampering behaviors of components can be effectively identified, overcoming the limitations of relying solely on digital certificate verification. This mechanism of comprehensive judgment based on certificate verification results improves the accuracy and reliability of the second-layer physical characteristic verification, avoids misjudgments or omissions that may be caused by a single verification method, thereby ensuring the authenticity and security of server components and providing a solid data foundation for subsequent risk assessment and anomaly handling.

[0048] In one feasible implementation, the step of obtaining the component verification result data by comprehensively evaluating the certificate verification result data and the physical feature verification result data in conjunction with preset risk level model data includes: calculating basic risk level data based on the component type data and historical anomaly record data of the current server component; calculating environmental risk coefficient based on current system environment parameter data and security status data; calculating comprehensive risk score data by weighted scoring algorithm based on the basic risk level data and the environmental risk coefficient, combined with the certificate verification result data and the physical feature verification result data; and comparing the comprehensive risk score data with preset risk threshold data to generate the component verification result data; wherein, the component verification result data includes verification passed status data, verification suspicious status data, and verification failed status data.

[0049] In this embodiment, when calculating the basic risk level data, component type data refers to the classification information of server components, such as central processing units (CPUs), memory modules, hard disk drives, network interface cards, etc. Different types of components may face different risks during design, manufacturing, and use. For example, the failure of certain critical components (such as the CPU) may lead to the paralysis of the entire system, and their inherent risk level is high. Historical anomaly record data refers to records of past failures, performance degradation, unauthorized modifications, security vulnerabilities, or any other abnormal events related to a specific component or similar components. These records can be obtained from maintenance logs, monitoring systems, or supply chain traceability data. By analyzing this historical data, the reliability and security exhibited by the component in the past can be assessed, thereby providing a basis for calculating its basic risk level. The calculation process can employ a predefined risk matrix, expert system rules, or statistical models. For example, initial risk scores can be assigned to different component types, and these scores can be adjusted based on the severity, frequency, and relevance of historical anomaly records.

[0050] In this embodiment, when calculating the environmental risk coefficient, the current system environment parameter data refers to the real-time or near-real-time status information of the operating environment of the server components, including but not limited to server load rate, CPU utilization, memory usage, network bandwidth usage, internal chassis temperature, and power supply voltage stability. These parameters directly reflect the component's workload and external conditions. Security status data refers to the security threats currently faced by the system and the effectiveness of protective measures, such as operating system patch update status, firewall configuration, intrusion detection system alarms, malware scan results, and access control policy enforcement status. A system environment with unpatched vulnerabilities or under attack increases the risk of components being tampered with or exploited. The environmental risk coefficient can be calculated based on a comparison of the real-time monitoring values ​​of these parameters with a preset security baseline or threshold. For example, when the server load remains excessively high, the temperature rises abnormally, or a network attack is detected, the environmental risk coefficient will increase accordingly. This can be achieved through weighted averaging, fuzzy logic, or machine learning models to quantify the impact of the environment on component risk.

[0051] In this embodiment, to obtain comprehensive risk score data, this application employs a weighted scoring algorithm, a method for quantitatively integrating risk assessment results from multiple different sources (such as basic risk level data, environmental risk coefficients, certificate verification results, and physical feature verification results). This algorithm assigns a weight to each input item to reflect its importance in the overall risk assessment. For example, a failed digital certificate verification might be given the highest weight, as it typically signifies a serious identity or integrity issue; while minor physical feature deviations or high environmental risk coefficients might be assigned lower but still impactful weights. The comprehensive risk score data is the output of the weighted scoring algorithm, typically represented as a numerical value that comprehensively reflects the overall risk level of the current server component. The higher the score, the greater the risk of the component.

[0052] In this embodiment, the comprehensive risk score data is compared with preset risk threshold data to generate the component verification result data. The preset risk threshold data refers to one or more pre-defined numerical limits used to classify the comprehensive risk score data into different risk levels. For example, a "low-risk threshold" and a "high-risk threshold" can be set. Based on the comparison result, component verification result data in one of three states is generated: when the comprehensive risk score data is below the low-risk threshold, verification passed status data is generated, indicating that the component is operating normally and the risk is controllable; when the comprehensive risk score data is between the low-risk threshold and the high-risk threshold, verification suspicious status data is generated, indicating that the component has certain risks or anomalies, requiring further attention or manual intervention; when the comprehensive risk score data is above the high-risk threshold, verification failed status data is generated, indicating that the component has serious risks or has malfunctioned, requiring immediate action.

[0053] In this embodiment, by incorporating considerations of component type data, historical anomaly record data, current system environment parameter data, and security status data, and combining them with certificate verification result data and physical feature verification result data, a weighted scoring algorithm is used to calculate a comprehensive risk score. This multi-dimensional and comprehensive evaluation method makes component risk assessment more comprehensive and accurate, avoiding misjudgments or omissions caused by a single anomaly or environmental factor. The final generated component verification result data is no longer a simple binary judgment, but is subdivided into verification pass status data, verification suspicious status data, and verification failure status data, providing a more refined and guiding basis for subsequent anomaly handling and component management. For example, for components in a suspicious state, the system can trigger an alert instead of immediately shutting down, thereby ensuring system security while avoiding unnecessary business interruptions and improving the intelligence and robustness of the server component tracking method.

[0054] In one feasible implementation, when the component verification result data indicates verification failure, the step of generating exception handling instruction data based on the blockchain storage record data and the component verification result data includes: determining the current verification status based on the component verification result data; when the component verification result data indicates verification failure, obtaining the complete change history data of the current server component based on the blockchain storage record data; performing abnormal operation node location processing based on the complete change history data, and generating isolation handling instruction data in conjunction with the component verification result data; wherein, the isolation handling instruction data includes the exception handling instruction data.

[0055] In this embodiment, the current verification status is determined based on the component verification result data. This step aims to clarify whether the current server component verification result is a clear "verification failure" state, thus serving as a trigger condition for subsequent refined exception handling. For example, after receiving the component verification result data, the system will determine the state indicated by the data through preset logic. If the component verification result data indicates a non-failure state such as "verification passed" or "verification suspicious," then there is no need to execute the subsequent exception handling process, thereby avoiding unnecessary resource consumption.

[0056] In this embodiment, when the component verification result data explicitly indicates a verification failure, the system will obtain the complete change history data of the current server component based on the blockchain storage record data. Due to the immutability and traceability of the blockchain, the blockchain storage record data contains all records of changes, maintenance, upgrades, and other operations of the server component since the generation of its component digital identity certificate data. By querying the blockchain network and utilizing information such as the component's unique identifier data, the system can retrieve and aggregate all historical transaction or event records related to the component, thereby forming a detailed and complete change history data. This data provides comprehensive contextual information for subsequent anomaly analysis.

[0057] Based on this, the system will perform abnormal operation node location processing based on the complete change history data, and generate isolation processing instruction data in conjunction with the component verification result data. Abnormal operation node location processing refers to in-depth analysis of the acquired complete change history data to identify the specific operation, event, or participant that caused the current component verification failure. For example, the system can analyze the time series of historical data to find abnormal operations that occurred before the verification failure, such as unauthorized firmware updates, configuration tampering, or maintenance operations performed by suspicious identities. This may involve pattern recognition algorithms, rule engines, or security policy comparisons. Once a suspicious abnormal operation node is located, the system can combine it with the current component verification result data to generate highly targeted isolation processing instruction data. This isolation processing instruction data is a special type of abnormal processing instruction data; it not only indicates the need for abnormal processing but also specifies concrete isolation measures, such as instructing the system to immediately disconnect the component's network connection, disable its specific functions, mark it for physical removal, or conduct further forensic analysis.

[0058] In this embodiment, through the above technical solution, when a component verification failure is detected, this application can accurately determine the current state based on the component verification result data, and further utilize blockchain storage record data to obtain the complete change history data of the current server component. This enables the system to perform in-depth analysis of historical operations, thereby performing abnormal operation node location processing and identifying the specific operation or entity that caused the verification failure. Combined with the component verification result data, the system can generate targeted isolation processing instruction data, rather than generalized abnormal processing instructions. This refined processing method effectively avoids blind processing, improves the accuracy and efficiency of abnormal processing, and can quickly and effectively isolate problematic components, prevent the spread of potential risks, thereby improving the security and reliability of the server component tracking method.

[0059] In one feasible implementation, the steps of locating abnormal operation nodes based on the complete change history data and generating isolation processing instruction data in conjunction with the component verification result data include: Extract the most recent preset number of change record data from the complete change history data; perform validity verification processing on the change record data based on the blockchain consensus mechanism to identify suspicious change operation data; construct operation chain data based on the time series of the suspicious change operation data, perform abnormal pattern analysis processing on the operation chain data to obtain abnormal pattern analysis result data; determine abnormal operation node data based on the abnormal pattern analysis result data, and generate isolation processing instruction data containing the location information of the abnormal operation node data.

[0060] In this embodiment, a preset number of recent change records are extracted from the complete change history data. This aims to focus the analysis on the most recent operations most relevant to the current anomaly. The preset number can be configured according to actual needs; for example, it can be set to the most recent N records, or all change records within a specific time window (such as the past 24 hours or 7 days). These change records typically contain key information such as operation type (e.g., installation, uninstallation, upgrade, configuration change), operation time, operator identity (if recorded on-chain), and component state hashes before and after the change. This approach effectively reduces the amount of data that needs to be processed and improves the efficiency of subsequent analysis.

[0061] In this embodiment, the validity verification of change record data based on the blockchain consensus mechanism is used to identify suspicious change operation data to ensure the authenticity and integrity of the extracted change records. Even if a record has been extracted from the blockchain, its validity on the chain still needs to be confirmed again to prevent data tampering during transmission or processing. The system can broadcast verification requests to multiple consensus nodes in the blockchain network. Each node independently verifies the digital signature, transaction structure, and existence and order of the record on the blockchain. Only when a preset number of consensus nodes confirm its validity is the record considered trustworthy. Based on this, by comparing the operator's identity with the authorization list, the operation time with the normal maintenance window, and the change content with the expected configuration, "suspicious" change operations can be initially screened. For example, a component replacement operation performed by an unauthorized user, even if it is recorded on the chain and valid, should be marked as suspicious.

[0062] In this embodiment, operation chain data is constructed based on the time series of suspicious change operation data. Anomaly pattern analysis is then performed on the operation chain data to obtain anomaly pattern analysis result data. This aims to discover deeper abnormal behavior patterns from a series of suspicious operations. A single suspicious operation may not be sufficient to indicate a serious problem, but when they occur in a specific order or combination, they may reveal malicious attacks, system failures, or misoperations. The identified suspicious change operation data is sorted according to its timestamp to form a time series, thus constructing the operation chain data. Subsequently, various anomaly pattern analysis techniques can be applied. For example, a preset rule engine can be used to identify patterns such as "multiple consecutive modifications to the configuration of key components within a short period"; or a machine learning model can be used to learn normal operation patterns to identify operation sequences that deviate from normal behavior; or statistical analysis methods can be used to identify abnormal fluctuations in parameters (such as operation intervals and operator distribution) in the operation chain. The anomaly pattern analysis result data may include the anomaly type, the probability score of the anomaly occurrence, and the specific operation sequences involved.

[0063] In this embodiment, the ultimate goal of the entire anomaly localization process is to determine the abnormal operation node data based on the anomaly pattern analysis results and generate isolation processing instruction data containing the location information of the abnormal operation node data. Abnormal operation node data refers to the specific entity that caused the anomaly, such as a user account, an automated script, a physical device, or a logical module. Based on the anomaly pattern analysis results, the system can trace the source of the abnormal operation. For example, if the analysis results indicate that a user account made multiple unauthorized component configuration changes within a short period, then that user account is the abnormal operation node data. The location information may include the operator ID, the operation terminal IP address, the operation timestamp, the serial number of the involved component, and the specific changes made. The isolation processing instruction data will contain this precise location information. For example, the instruction may instruct the system administrator to disable access permissions for a specific user account, isolate or take down the affected server component, roll back the component configuration before the abnormal operation occurred, or send an alarm with a detailed anomaly report to the system administrator.

[0064] In this embodiment, through the above technical solution, when server component verification fails, the system no longer simply obtains complete change history data, but intelligently extracts a preset number of recent change records from this data and uses a blockchain consensus mechanism to verify their validity, thereby identifying suspicious change operations. Based on this, by constructing a time series of suspicious operations and performing anomaly pattern analysis, it can deeply explore potential chains of abnormal behavior, rather than viewing individual operations in isolation. Finally, based on the anomaly pattern analysis results, the abnormal operation node causing the verification failure can be accurately identified, and isolation processing instruction data containing detailed location information can be generated. This greatly improves the accuracy and efficiency of anomaly location, enabling anomaly processing instructions to target the source of the problem, avoiding blind or excessive isolation, thereby effectively ensuring the operational security of server components and the stability of the system.

[0065] In one feasible implementation, the method further includes: generating verification transaction data for each verification operation, and associating the verification transaction data with the component's digital identity certificate data to obtain associated verification data; packaging the associated verification data into block data based on a distributed consensus mechanism; linking the block data to a blockchain network to form verification chain data; and extracting relevant verification record data from the verification chain data when it is necessary to trace the historical state of the component.

[0066] In this embodiment, the system generates "verification transaction data" each time a server component is verified in real time. This verification transaction data is a structured record of the verification action and its result, and may include, but is not limited to, a verification initiation timestamp, the unique identifier data of the verified component, the entity identifier performing the verification, the version of the verification strategy used, the verification result (e.g., verification passed status data, verification suspicious status data, or verification failed status data), and any related error codes or exception information. Generating this verification transaction data aims to abstract each independent verification action into a recordable and traceable event. Subsequently, the verification transaction data is associated with the component's digital identity certificate data to obtain "associated verification data." This association can be achieved by including the hash value of the component's digital identity certificate data, the component's unique identifier data, or directly referencing its storage location in the blockchain network within the verification transaction data, thereby ensuring that each verification transaction explicitly points to the specific component it verifies.

[0067] Based on this, the associated verification data will be packaged into block data using a distributed consensus mechanism. Specifically, after the associated verification data is generated, it can be submitted to multiple verification nodes in the blockchain network. These nodes verify the validity and integrity of the associated verification data by executing preset consensus algorithms, such as Proof-of-Work (PoW), Proof-of-Stake (PoS), or Practical Byzantine Fault Tolerance (PBFT), and ultimately reach a consensus to confirm that the data can be recorded. Once consensus is reached, this associated verification data, along with other transaction data to be confirmed, will be packaged into a block structure. This block also includes metadata such as a timestamp and the hash value of the previous block. Subsequently, the block data will be linked to the blockchain network to form "verification chain data." The linking process refers to connecting the newly generated block data with the previous block through cryptographic hash values ​​to form an immutable chain structure. Each new block contains the hash value of the previous block, thereby ensuring the integrity and immutability of the data. In this way, all the block data related to component verification are linked together in chronological order to form a blockchain specifically used to record the history of all verification operations of server components.

[0068] In this embodiment, the above technical solution generates verification transaction data for each server component verification operation and associates it with the component's digital identity certificate data. Then, based on a distributed consensus mechanism, these associated verification data are packaged and linked to a blockchain network, forming a dedicated verification chain data. This ensures that detailed information for each verification operation, regardless of success or failure, is recorded immutably. When it is necessary to trace the component's historical status, such as for auditing, fault analysis, or compliance checks, all relevant verification records can be extracted from the verification chain data based on query conditions such as the component's unique identifier data and time range, thus providing a complete, transparent, and auditable component verification history. This greatly enhances the reliability and credibility of the server component tracking system, not only clearly displaying the component's verification trajectory but also providing a detailed chain of evidence when problems occur, facilitating fault location and accountability, and effectively compensating for the information gaps caused by only recording the component's digital identity certificate and the final abnormal result.

[0069] In one feasible implementation, the step of packaging the associated verification data into block data based on a distributed consensus mechanism includes: when a verification transaction needs to be recorded, broadcasting verification request data to multiple verification nodes in the blockchain network; each verification node performing validity verification processing on the component digital identity certificate data based on locally stored blockchain copy data to obtain node verification result data; when a preset number of verification nodes confirm the verification is valid, consensus result data is formed; generating new block data based on the consensus result data, the new block data containing the verification transaction data and the hash reference data of the component digital identity certificate data; adding the new block data to the blockchain and updating the blockchain copy data of all verification nodes.

[0070] In this embodiment, when the system needs to record a verification transaction, such as the installation, replacement, repair, or status check of a component, it generates corresponding verification request data. This verification request data typically includes the digital identity certificate data of the component to be verified, the specific content of this verification operation (i.e., verification transaction data), and other necessary contextual information. To ensure the transparency and decentralization of the verification process, this request data is sent to multiple verification nodes in the blockchain network. This broadcast mechanism ensures that all participating nodes receive the same verification task, laying the foundation for subsequent distributed verification.

[0071] In this embodiment, upon receiving the verification request data, each verification node in the blockchain network independently performs a verification operation. Specifically, each verification node uses its locally stored blockchain copy data to verify the validity of the component digital identity certificate data included in the request. This verification process may include, but is not limited to: checking whether the digital signature of the certificate is valid, whether the certificate has been revoked, whether the component unique identifier data and component type data recorded in the certificate match the actual information of the current component, and whether the certificate has a legitimate historical record on the blockchain. Through this independent verification, each node generates node verification result data, indicating its judgment on this verification transaction.

[0072] In this embodiment, to ensure the reliability and consistency of the verification results, the system waits for and collects node verification result data from different verification nodes. When the number of verification nodes confirming valid verification reaches a preset threshold, it is considered that the verification transaction has gained majority approval from the network, thus forming a consensus result data. This preset number can be configured according to the distributed consensus algorithm used (such as Proof-of-Work, Proof-of-Stake, Byzantine Fault Tolerance, etc.) to prevent manipulation by a single or a few malicious nodes and ensure the robustness of the consensus.

[0073] In this embodiment, once consensus result data is formed, the system generates a new block based on this consensus result. This new block data will not only contain the data of this verification transaction, but also the hash reference data of the component's digital identity certificate data. Using hash references instead of directly storing the complete certificate data can effectively reduce the storage space of the block, while ensuring the integrity and traceability of the data through the irreversibility of hash values. The new block will also contain the hash value, timestamp, and other information of the previous block to ensure its correct link in the blockchain.

[0074] In this embodiment, the newly generated block data is then broadcast to the entire blockchain network. Upon receiving the new block, all validator nodes in the network verify it (e.g., checking its hash value, signature, transaction validity, etc.). Once confirmed, they add it to their respective locally stored blockchain replica data. In this way, the blockchain replica data of all validator nodes is synchronously updated, ensuring the consistency and up-to-dateness of the component tracking state data throughout the network, thereby maintaining the integrity and authority of the verification chain data.

[0075] In this embodiment, a detailed distributed consensus mechanism is introduced during the process of packaging associated verification data into block data using the above technical solution. Specifically, by broadcasting verification request data to multiple verification nodes and having each node independently verify the validity, the decentralization and multi-party participation of the verification process are ensured. When a preset number of verification nodes confirm the validity of the verification, consensus result data is formed, effectively avoiding single points of failure or malicious nodes tampering with the verification results. Based on this, a new block containing verification transaction data and component digital identity certificate data hash reference data is generated based on the consensus result data and added to the blockchain, updating the blockchain copy data of all verification nodes, thereby ensuring the immutability, transparency, and high reliability of the verification chain data. This enhances the integrity and credibility of the verification chain data in the server component tracking method, making the tracing of component historical states more accurate and secure, and effectively solving the reliability issues that may exist in traditional distributed consensus mechanisms.

[0076] In one feasible implementation, the method further includes: generating smart contract code data based on preset compliance rule data, and deploying the smart contract code data to a blockchain network to obtain deployed smart contract data; automatically triggering a verification operation on the deployed smart contract data when component change operation data is detected; performing legality verification processing on the component change operation data based on the preset compliance rule data to obtain legality verification result data; and automatically executing a violation processing operation based on preset violation processing logic data when the legality verification result data indicates that the verification fails.

[0077] In this embodiment, smart contract code data is generated based on preset compliance rule data. This preset compliance rule data may include, but is not limited to, component compatibility rules, security policies, supplier certification requirements, maintenance operation specifications, lifecycle management regulations, and relevant regulatory compliance requirements. These rules can be defined in the form of structured data (such as JSON or XML) or domain-specific languages ​​(DSLs). The smart contract code data is program code written according to these rules and can be automatically executed on the blockchain. It can be generated manually, using automated code generation tools, or configured through a low-code / no-code platform. Subsequently, the generated smart contract code data is deployed to the blockchain network, becoming the deployed smart contract data. The deployment process typically involves submitting the smart contract's bytecode to the blockchain and obtaining a unique contract address for subsequent calls and interactions.

[0078] In this embodiment, when the system detects any component change operation data, such as component installation, removal, upgrade, configuration modification, or repair, the deployed smart contract data will be automatically triggered to perform a verification operation. Component change operation data detection can be achieved in various ways, such as through server hardware management interfaces (e.g., BMC), operating system logs, sensor data, API calls, or manually entered and submitted transactions to the blockchain. Once a change is detected, the event listener or oracle mechanism in the blockchain network can automatically invoke the corresponding smart contract function. The triggered deployed smart contract data will perform legality verification processing on the component change operation data based on preset compliance rules. This verification process involves the smart contract's internal logic judging the matching of the component change operation data with preset rules, for example, checking whether the new component model is in the allowed list, whether the operator has the corresponding permissions, whether the change time is within the specified window period, and whether the change meets the security baseline. After processing, legality verification result data will be obtained, which can indicate whether the verification passed or failed, and may include a detailed verification report or error code.

[0079] In this embodiment, when the legitimacy verification result indicates that the verification fails, the system will automatically execute violation handling operations based on preset violation handling logic data. The preset violation handling logic data defines automated measures to be taken for different types of violations, such as: sending alerts to administrators, recording violation events on the blockchain for auditing, isolating or disabling components involved in the violation, preventing server startup, rolling back non-compliant configuration changes, or triggering higher-level security response processes. These processing operations are executed directly by smart contracts or through interaction with external systems (e.g., calling external APIs via oracles), thereby ensuring that violations are responded to and handled promptly and accurately.

[0080] In this embodiment, through the above technical solution, this application can achieve automated, mandatory compliance verification and violation handling of server component change operations. This improves the automation level and security of the server component tracking method, ensuring that all component changes strictly follow preset rules, thereby effectively avoiding compliance risks and security vulnerabilities caused by human negligence or malicious operation. Simultaneously, since the verification and processing logic is embedded in smart contracts on the blockchain, its execution process has high transparency, immutability, and auditability, further enhancing the system's trustworthiness. When non-compliant component changes occur, the system can immediately detect and automatically execute preset violation handling operations, thereby significantly shortening response time, reducing potential negative impacts, and improving the overall stability and security of the server infrastructure.

[0081] In the embodiments of this application, the server component tracking method solves the problems of low efficiency and poor security of traditional methods by acquiring the original component data of each component of the server, preprocessing to obtain standard component data, generating component digital identity certificate data, storing it in the blockchain network, and performing real-time verification and anomaly handling. It achieves efficient server component tracking, improves the efficiency and accuracy of server component tracking, enhances data security and real-time anomaly response capabilities, and improves the reliability of historical traceability.

[0082] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the server component tracing method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0083] This application also provides a server component tracking system, referenced... Figure 2 The server component tracking system includes: a memory 10, a processor 20, and a server component tracking program stored on the memory 10 and executable on the processor 20, the server component tracking program being configured to implement the steps of the server component tracking method.

[0084] The server component tracking system provided in this application, employing the server component tracking method in the above embodiments, can improve the efficiency and accuracy of server component tracking. Compared with the prior art, the beneficial effects of the server component tracking system provided in this application are the same as those of the server component tracking method provided in the above embodiments, and other technical features of the server component tracking system are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0085] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0086] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. All equivalent structural transformations made under the technical concept of this application using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included within the scope of patent protection of this application.

Claims

1. A server component tracing method, characterized in that, The method includes: Obtain the raw component data of each component of the server, and preprocess the raw component data to obtain standard component data; Component digital identity certificate data is generated based on the standard component data. The component digital identity certificate data includes component unique identifier data, component type data, and digital signature data. The digital identity certificate data of the component is stored in a blockchain network to obtain blockchain storage record data; Based on the component's digital identity certificate data and preset verification strategy data, the current server component is verified in real time to obtain component verification result data; When the component verification result data indicates verification failure, an exception handling instruction data is generated based on the blockchain stored record data and the component verification result data. Execute the exception handling instruction data and update the component tracking status data.

2. The server component tracing method as described in claim 1, characterized in that, The steps for performing real-time verification of the current server component based on the component's digital identity certificate data and preset verification strategy data to obtain component verification result data include: Based on the digital identity certificate data of the aforementioned component, perform first-level digital certificate verification on the current server component to obtain certificate verification result data; When the certificate verification result data indicates an anomaly in the first-level verification, the physical feature data of the current server component is collected, and the second-level physical feature verification is performed based on the physical feature data to obtain the physical feature verification result data. Based on the certificate verification result data and the physical feature verification result data, and combined with the preset risk level model data, a comprehensive evaluation is performed to obtain the component verification result data.

3. The server component tracing method as described in claim 2, characterized in that, When the certificate verification result data indicates a first-level verification anomaly, the steps of collecting physical feature data of the current server component, performing second-level physical feature verification based on the physical feature data, and obtaining physical feature verification result data include: Extract the runtime parameter data of the current server component from the original component data. The runtime parameter data includes power consumption parameter data, temperature parameter data, and response time parameter data. Obtain the baseline feature data of the corresponding component from the historical feature database; The runtime parameter data is compared with the baseline feature data to calculate the feature difference data. Based on the comparison results between the feature difference data and the preset difference threshold data, and combined with the certificate verification result data, the physical feature verification result data is generated.

4. The server component tracing method as described in claim 2, characterized in that, The steps for obtaining the component verification result data based on the certificate verification result data and the physical feature verification result data, combined with the preset risk level model data, include: Based on the component type data and historical anomaly record data of the current server component, the basic risk level data is calculated; Based on the current system environmental parameter data and safety status data, the environmental risk coefficient is calculated; Based on the basic risk level data and the environmental risk coefficient, combined with the certificate verification result data and the physical characteristic verification result data, a comprehensive risk score data is calculated using a weighted scoring algorithm. The comprehensive risk score data is compared and processed with preset risk threshold data to generate the component verification result data; wherein, the component verification result data includes verification pass status data, verification doubt status data, and verification failure status data.

5. The server component tracing method as described in claim 1, characterized in that, When the component verification result data indicates verification failure, the step of generating exception handling instruction data based on the blockchain stored record data and the component verification result data includes: The current verification status is determined based on the component verification result data; When the component verification result data indicates a verification failure status, the complete change history data of the current server component is obtained based on the blockchain storage record data. Based on the complete change history data, abnormal operation node location processing is performed, and isolation processing instruction data is generated by combining the component verification result data; wherein, the isolation processing instruction data includes the abnormal processing instruction data.

6. The server component tracing method as described in claim 5, characterized in that, The steps of locating abnormal operation nodes based on the complete change history data and generating isolation processing instruction data in conjunction with the component verification result data include: Extract the most recent preset number of change records from the complete change history data; The change record data is validated based on the blockchain consensus mechanism to identify suspicious change operation data. Based on the time series of the suspicious change operation data, operation chain data is constructed, and abnormal pattern analysis processing is performed on the operation chain data to obtain abnormal pattern analysis result data. Based on the abnormal pattern analysis results, abnormal operation node data is determined, and isolation processing instruction data containing the location information of the abnormal operation node data is generated.

7. The server component tracing method as described in claim 1, characterized in that, The method further includes: Each verification operation generates verification transaction data, and the verification transaction data is associated with the component digital identity certificate data to obtain associated verification data; The associated verification data is packaged into block data based on a distributed consensus mechanism; The block data is linked to the blockchain network to form a verification chain data; When it is necessary to trace the historical status of a component, relevant verification record data is extracted from the verification chain data.

8. The server component tracing method as described in claim 7, characterized in that, The steps for packaging the associated verification data into block data based on the distributed consensus mechanism include: When it is necessary to record a verification transaction, the verification request data is broadcast to multiple verification nodes in the blockchain network; Each verification node performs validity verification on the component's digital identity certificate data based on locally stored blockchain copy data, and obtains node verification result data; Once a preset number of verification nodes confirm the validity of the verification, consensus result data is generated. New block data is generated based on the consensus result data, and the new block data includes hash reference data of the verification transaction data and the component digital identity certificate data; The new block data is added to the blockchain, updating the blockchain replica data of all validator nodes.

9. The server component tracing method as described in claim 1, characterized in that, The method further includes: Smart contract code data is generated based on preset compliance rule data, and the smart contract code data is deployed to the blockchain network to obtain deployed smart contract data; When component change operation data is detected, the smart contract data after deployment is automatically triggered to perform a verification operation; The deployed smart contract data performs legality verification processing on the component change operation data based on the preset compliance rule data to obtain legality verification result data; When the legality verification result data indicates that the verification fails, the violation processing operation is automatically executed based on the preset violation processing logic data.

10. A server component tracking system, characterized in that, The server component tracing system includes: a memory, a processor, and a server component tracing program stored in the memory and executable on the processor, the server component tracing program being configured to implement the steps of the server component tracing method as described in any one of claims 1 to 9.

Images