System hidden danger processing method and device and electronic equipment

By identifying and standardizing potential hazards in multi-level systems, generating a list, and optimizing resource allocation, the problem of insufficient identification of cross-level hazards was solved, and operational efficiency and production stability were improved.

CN121836376APending Publication Date: 2026-04-10CHINA TELECOM CORP LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511989080.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-25
Publication Date
2026-04-10

AI Technical Summary

Technical Problem

In existing technologies, the identification of hidden dangers in multi-level systems is limited to a single level and does not connect the assets of each level, resulting in the neglect of cross-level hidden dangers and failure to be detected in a timely manner, leading to production failures; hidden danger assessment lacks a unified and quantitative standard, resource allocation and disposal priorities are unreasonable, and operation and maintenance efficiency is low.

Method used

By acquiring asset data from the target system, potential hazards are identified from multiple dimensions, a standardized hazard list is generated, and hazard events are handled based on the list. This includes the analysis of internal, multi-level, and external monitoring data to achieve dynamic linkage and priority ranking of resources.

Benefits of technology

It enables global correlation analysis of multi-level systems, accurately determines the priority of handling hidden dangers, optimizes resource allocation, improves operation and maintenance efficiency, and avoids the problems of hierarchical fragmentation and rough assessment.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121836376A_ABST
    Figure CN121836376A_ABST
Patent Text Reader

Abstract

The invention discloses a system hidden danger processing method and device and electronic equipment. The method comprises the steps that asset data stored in a configuration management database by a target system is acquired, and the target system is a multi-level system; according to the asset data, hidden danger checking is carried out on the target system from multiple dimensions, a hidden danger checking information set of the target system is obtained, and the multiple dimensions comprise monitoring data inside each hierarchy in multiple hierarchies of the target system, monitoring data between the multiple hierarchies and monitoring data outside the target system; a standardized hidden danger list is generated according to the hidden danger investigation information set, and the standardized hidden danger list is at least used for indicating a hidden danger disposal mode and a resource type needed for solving the hidden danger; and processing hidden danger events existing in the target system according to the standardized hidden danger list. According to the method and the device, the technical problem of difficulty in adapting to the operation and maintenance requirements of a multi-level system due to hierarchy splitting, extensive evaluation and disordered disposal existing in a hidden danger checking processing method in the related technology is solved.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The present application relates to the field of IT operation and maintenance, in particular to a system hidden danger processing method and device and electronic equipment. BACKGROUND

[0002] A multi-level system (for example, an IT system has formed a multi-level collaborative architecture of a hardware facility layer (IaaS), a platform layer (PaaS), and an application layer (SaaS)). Hidden dangers have the characteristics of multi-source, cross-level, and strong conduction, and the hidden danger investigation and disposal of related technologies have many pain points.

[0003] First, the hidden danger identification in the related technology is limited to a single level, and the asset correlation of each level is not connected, and the cross-level hidden danger is easily ignored. Such cross-level conduction hidden danger cannot be discovered in time due to the lack of global correlation analysis, resulting in serious production failure. Second, the hidden danger evaluation excessively depends on the experience of operation and maintenance personnel and lacks unified and quantitative standards. On the one hand, the hidden danger impact difference is not distinguished according to the core degree of the business system, and the hidden dangers of the core business system and the non-core business system are treated equally. On the other hand, the diffusion risk caused by the cross-level conduction of hidden dangers is ignored. Some seemingly minor intra-level hidden dangers may be transmitted to multiple core business links through asset correlation, forming a situation of "small hidden danger causing big failure", which makes the operation and maintenance team unable to accurately determine the disposal priority of the hidden danger, and the resource allocation and disposal priority are unreasonable. Finally, the current hardware resources adopt a "fixed allocation" mode, and the resources are pre-allocated to specific systems or business modules, and do not form a dynamic linkage with the disposal priority of the hidden danger, resulting in that low-level hidden dangers often occupy limited high-quality hardware resources (such as new devices with a service life of ≤3 years), and high-level hidden dangers (such as cluster single-point hidden dangers involving core systems) can only wait for resource release or start a new procurement process, causing disposal delay and seriously affecting business continuity. The hidden danger disposal process relies on manual cooperation and cannot realize one-key dispatching and progress tracking. The link of hidden danger disposal is incomplete, the responsibility is fuzzy, and the operation and maintenance efficiency is low.

[0004] In summary, the traditional mode has problems such as "level fragmentation, extensive evaluation, and disordered disposal" in the aspects of hidden danger identification, evaluation, resource allocation, and disposal process, which has been difficult to adapt to the operation and maintenance needs of a multi-level system.

[0005] At present, no effective solution has been proposed to solve the above problems. SUMMARY

[0006] The embodiments of the present application provide a system hidden danger processing method and device and electronic equipment to at least solve the technical problem that the hidden danger investigation and disposal method of related technologies has level fragmentation, extensive evaluation, and disordered disposal, which makes it difficult to adapt to the operation and maintenance needs of a multi-level system.

[0007] According to an aspect of the embodiments of the present application, a system risk processing method is provided, comprising: obtaining asset data of a target system stored in a configuration management database, wherein the target system is a multi-level system; performing risk investigation on the target system from multiple dimensions according to the asset data, to obtain a risk investigation information set of the target system, wherein the multiple dimensions include internal of each level of the target system, between the multiple levels, and external monitoring data of the target system; generating a standardized risk list according to the risk investigation information set, wherein the standardized risk list is used to at least indicate a disposal method of the risk and a resource type required to solve the risk; and processing a risk event existing in the target system according to the standardized risk list.

[0008] Optionally, performing risk investigation on the target system from multiple dimensions according to the asset data, to obtain a risk investigation information set of the target system, comprises: performing risk investigation on each level of the target system from the inside of the level according to running data and configuration information corresponding to each level of the target system in the asset data, to obtain risk investigation information corresponding to each level; analyzing the correlation between the multiple levels according to correlation data stored in the asset data, to obtain risk investigation information between the multiple levels, wherein the correlation data at least includes a device binding relationship and a dependency relationship between the multiple levels; obtaining external monitoring data corresponding to the multiple levels, and comparing the external monitoring data with target asset data, to obtain risk investigation information corresponding to the external monitoring data, wherein the target asset data is asset data of which an environment label of each level is production, and the environment label is an identifier used to identify a running environment of the asset data; and determining a set of the risk investigation information corresponding to each level, the risk investigation information between the multiple levels, and the risk investigation information corresponding to the external monitoring data as the risk investigation information set of the target system.

[0009] Optionally, generating a standardized risk list according to the risk investigation information set comprises: performing attribute extraction and standardization processing on each piece of risk information in the risk investigation information set according to a target attribute, to obtain standardized risk information, and generating the standardized risk list according to a set of all the standardized risk information, wherein the target attribute includes a risk name, a risk category, a resource type required to solve the risk, and a risk disposal method.

[0010] Optionally, the hidden trouble events existing in the target system are processed according to the standardized hidden trouble list, including: obtaining system state data of the target system, and performing hidden trouble identification on the system state data according to the standardized hidden trouble list to obtain the hidden trouble events existing in the target system, and determining a set of all the hidden trouble events as a hidden trouble event set, wherein each hidden trouble event corresponds to a hidden trouble name in the standardized hidden trouble list; determining a required resource type for solving the hidden trouble corresponding to each hidden trouble event in the hidden trouble event set in the standardized hidden trouble list, wherein the required resource type is divided into a hardware resource required type and a hardware resource free type; dividing the hidden trouble events in the hidden trouble event set into a first set and a second set according to the required resource type for solving the hidden trouble, wherein the first set contains hidden trouble events with the required resource type being the hardware resource free type, and the second set contains hidden trouble events with the required resource type being the hardware resource required type; and processing the hidden trouble events in the first set and the second set by using corresponding processing manners respectively.

[0011] Optionally, the hidden trouble events in the second set are processed by the following processing manner: dividing all the hardware resources required by the hidden trouble events in the second set into a plurality of hardware resource type sets according to the resource type; performing priority sorting on the hidden trouble events in the second set to obtain a priority score corresponding to each hidden trouble event; for each hardware resource type set, the hidden trouble events are assigned hardware resources in descending order of the priority score; and a first target hidden trouble event is processed by executing a hidden trouble handling manner corresponding to the first target hidden trouble event in the standardized hidden trouble list, wherein the first target hidden trouble event is any hidden trouble event in the second set that has been assigned all the required hardware resources.

[0012] Optionally, the hidden trouble events in the second set are processed by the following processing manner: dividing all the hardware resources required by the hidden trouble events in the second set into a plurality of hardware resource type sets according to the resource type; performing priority sorting on the hidden trouble events in the second set to obtain a priority score corresponding to each hidden trouble event; for each hardware resource type set, the hidden trouble events are assigned hardware resources in descending order of the priority score; and a first target hidden trouble event is processed by executing a hidden trouble handling manner corresponding to the first target hidden trouble event in the standardized hidden trouble list, wherein the first target hidden trouble event is any hidden trouble event in the second set that has been assigned all the required hardware resources.

[0013] Optionally, the determining the impact range score corresponding to the second target hidden danger event comprises: determining all businesses affected by the second target hidden danger event and a business system corresponding to each business, wherein different business systems correspond to different level scores; in a case where a sum of the level scores corresponding to all the businesses affected by the second target hidden danger event is less than or equal to a preset maximum impact score threshold, determining the sum of the level scores corresponding to all the businesses affected by the second target hidden danger event as the impact range score corresponding to the target hidden danger event; and in a case where the sum of the level scores corresponding to all the businesses affected by the second target hidden danger event is greater than the preset maximum impact score threshold, determining the preset maximum level score threshold as the impact range score corresponding to the target hidden danger event.

[0014] Optionally, the first set of hidden danger events are processed by: processing the third target hidden danger event by performing a hidden danger handling mode corresponding to the third target hidden danger event in the standardized hidden danger list, wherein the third target hidden danger event is any one of the hidden danger events in the first set.

[0015] Optionally, the method further comprises: in a case where the target system is an IT system, the multiple levels include a hardware facility layer, a platform layer, and an application layer.

[0016] According to another aspect of the embodiments of the present application, a system hidden danger processing apparatus is further provided, comprising: an acquisition module configured to acquire asset data stored in a configuration management database by a target system, wherein the target system is a multi-level system; a hidden danger investigation module configured to perform hidden danger investigation on the target system from multiple dimensions according to the asset data, to obtain a hidden danger investigation information set of the target system, wherein the multiple dimensions include internal of each level of the multiple levels of the target system, between the multiple levels, and external monitoring data of the target system; a generation module configured to generate a standardized hidden danger list according to the hidden danger investigation information set, wherein the standardized hidden danger list is used at least to indicate a hidden danger handling mode and a resource type required to solve the hidden danger; and a processing module configured to process a hidden danger event existing in the target system according to the standardized hidden danger list.

[0017] According to another aspect of the embodiments of the present application, a nonvolatile storage medium is further provided, wherein the nonvolatile storage medium stores a program, and when the program is run, the nonvolatile storage medium controls a device in which the nonvolatile storage medium is located to execute the system hidden danger processing method.

[0018] According to another aspect of the embodiments of the present application, an electronic device is further provided, comprising: a memory and a processor, wherein the processor is configured to run a program stored in the memory, and when the program is run, the processor executes the system hidden danger processing method.

[0019] According to another aspect of the embodiments of the present application, a computer program product is also provided, which comprises computer instructions, and the computer instructions are executed by a processor to implement the above system hidden danger processing method.

[0020] In the embodiments of the present application, asset data stored in a configuration management database by a target system is acquired, wherein the target system is a multi-level system; hidden danger investigation is performed on the target system from multiple dimensions according to the asset data, to obtain a hidden danger investigation information set of the target system, wherein the multiple dimensions include internal of each level of the multiple levels of the target system, between the multiple levels, and external monitoring data of the target system; a standardized hidden danger list is generated according to the hidden danger investigation information set, wherein the standardized hidden danger list is used at least to indicate a disposal mode of the hidden danger and a resource type required to solve the hidden danger; and a hidden danger event existing in the target system is processed in a manner according to the standardized hidden danger list, by acquiring asset data stored in the configuration management database by the target system, and then performing hidden danger investigation from multiple dimensions, to obtain a hidden danger investigation information set of the target system, which avoids level fragmentation and extensive evaluation, and the next step of generating a standardized hidden danger list according to the hidden danger investigation information set and processing a hidden danger event existing in the target system according to the standardized hidden danger list avoids disposal disorder, thereby solving the technical problems of level fragmentation, extensive evaluation, and disposal disorder existing in the hidden danger investigation and processing method of the related art, which leads to difficulty in adapting to operation and maintenance requirements of a multi-level system. BRIEF DESCRIPTION OF DRAWINGS

[0021] The accompanying drawings, which are included to provide a further understanding of the present application, constitute a part of the present application, and the illustrative embodiments of the present application and their description serve to explain the present application, and do not constitute improper limitations on the present application. In the drawings:

[0022] Figure 1 is a hardware structure block diagram of a computer terminal for implementing a system hidden danger processing method according to an embodiment of the present application;

[0023] Figure 2 is a flowchart of a system hidden danger processing method according to an embodiment of the present application;

[0024] Figure 3 is a module interaction schematic diagram of a hidden danger processing system according to an embodiment of the present application;

[0025] Figure 4 is a flowchart of another system hidden danger processing method according to an embodiment of the present application;

[0026] Figure 5 is a structural schematic diagram of a system hidden danger processing apparatus according to an embodiment of the present application. DETAILED DESCRIPTION

[0027] In order to make the person skilled in the art better understand the scheme of the present application, the technical scheme in the embodiments of the present application will be clearly and completely described below in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by the person skilled in the art without creative labor should belong to the scope of protection of the present application.

[0028] The information collected by the embodiments of the present application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant regions, necessary security measures are taken, public order and good customs are not violated, and corresponding operation portals are provided for the user to select authorization or refuse automatic decision results; if the user chooses to refuse, the expert decision process is entered.

[0029] It should be noted that the terms "first", "second" and the like in the specification and claims of the present application and the above-described drawings are used to distinguish similar objects, and do not necessarily have to describe a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device including a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0030] In related technologies, multi-level systems (e.g., IT systems have formed a multi-level collaborative architecture of hardware infrastructure layer (IaaS), platform layer (PaaS), and application layer (SaaS)) exhibit characteristics of multi-source, cross-level, and strong transmission of risks. Risk identification is limited to a single level, failing to connect assets across levels, and cross-level risks are easily overlooked. Due to the lack of global correlation analysis, such cross-level risks cannot be detected in a timely manner, leading to serious production failures. Ignoring the diffusion risk brought about by cross-level risk transmission means that some seemingly minor intra-level risks may propagate to multiple core business processes through asset relationships, creating a situation where "small risks lead to big failures," making it difficult for the operations and maintenance team to accurately determine the priority of risk handling, resulting in unreasonable resource allocation and handling priorities. Risk handling processes rely on manual collaboration, failing to achieve one-click dispatch and progress tracking, resulting in an incomplete risk handling chain, ambiguous responsibility definition, and low operational efficiency. Therefore, the risk investigation and handling methods of related technologies suffer from hierarchical fragmentation, crude assessment, and disordered handling, making them difficult to adapt to the operational and maintenance needs of multi-level systems. To address this issue, relevant solutions are provided in the embodiments of this application, which are described in detail below.

[0031] According to an embodiment of this application, an embodiment of a method for handling system vulnerabilities is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0032] The methods and embodiments provided in this application can be executed on a computer terminal or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing a method to handle system vulnerabilities is shown. Figure 1 As shown, the computer terminal 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0033] It should be noted that the one or more processors 102 and / or other data processing circuitry described above can be generally referred to herein as "data processing circuitry". The data processing circuitry can be embodied in whole or in part as software, hardware, firmware, or any combination thereof. In addition, the data processing circuitry can be a single standalone processing module or incorporated in whole or in part within any of the other elements of the computer terminal 10. As referred to in embodiments of the present application, the data processing circuitry functions as a processor to control, for example, the selection of the variable resistance terminal path connected to the interface.

[0034] The memory 104 can be used to store software programs and modules of application software, such as program instructions / data storage means corresponding to the system vulnerability processing method of embodiments of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, i.e. implements the system vulnerability processing method described above. The memory 104 can include a high-speed random access memory, and can also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 can further include a memory disposed remotely with respect to the processor 102, which can be connected to the computer terminal 10 through a network. Examples of the network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0035] The transmission device 106 is used to receive or send data via a network. Specific examples of the network can include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (Radio Frequency, RF) module, which is used to communicate with the Internet in a wireless manner.

[0036] The display can be, for example, a touch screen type liquid crystal display (LCD), which can enable a user to interact with the user interface of the computer terminal 10.

[0037] Under the above operating environment, embodiments of the present application provide a system vulnerability processing method, as shown in Figure 2 FIG. 1 is a flowchart of a system vulnerability processing method according to embodiments of the present application, which includes the following steps:

[0038] In step S202, asset data stored in a configuration management database by a target system is acquired, wherein the target system is a multi-level system.

[0039] In some embodiments of the present application, in the case of the target system being an IT system, the multiple levels include a hardware facility layer (IaaS), a platform layer (PaaS), and an application layer (SaaS), wherein the IaaS layer provides basic computing, storage, and network resources, and is the physical or virtual infrastructure of the IT system. It includes servers, storage devices, network devices (such as switches and routers), security devices, etc. The IaaS layer is responsible for carrying the hardware support of the upper layer services (PaaS and SaaS), including running virtual machines and containers, providing data storage services, supporting network connections and data transmission, etc. The PaaS layer provides a platform for developing and running applications, including middleware, databases, message queues, and other services, as well as development, testing, and deployment tools, etc.

[0040] In the related art, the hidden danger processing method is limited to a single level, and the correlation of assets in each level is not connected, so that cross-level hidden dangers are easily overlooked, and it is not possible to process such IT systems. For example, the master and slave nodes of a PaaS layer cluster are located on the same host of two virtual machines in the IaaS layer, and if this host fails, the two virtual machines carried by the host will also be down, causing the master and slave nodes of the PaaS cluster to fail, and the cluster service to be interrupted, and further causing the SaaS layer core business system to be paralyzed. This is a typical cross-level cluster affinity hidden danger. Due to the lack of global correlation analysis, such cross-level transmitted hidden dangers cannot be discovered in time, resulting in serious production failures. The hidden danger processing system can be used to execute the system hidden danger processing method of the embodiments of the present application, Figure 3The application provides a hidden danger processing system and a hidden danger processing method. The hidden danger processing system comprises a hidden danger identification module, a hidden danger list management module, a hidden danger evaluation module, a hidden danger disposal module, a hidden danger work order management module and a configuration management database (CMDB). The hidden danger identification module is connected to CMDB asset data, and is used for performing step S202, obtaining asset data of a target system stored in the configuration management database. The asset data of the step is obtained in response to an authorized instruction of an asset data owner. For an IT system, the asset data records detailed information about IT assets (for example, hardware, software, virtual resources, network equipment and the like). The detailed information includes but is not limited to: basic attributes, including a unique identifier (such as an asset ID) of the asset, a name, a type (hardware, software, network equipment and the like), a manufacturer, a model, a version, a purchase date, warranty information, a location (such as a data center, a rack location), a state (such as running, in maintenance, scrapped) and the like; configuration information, which describes configuration settings of the asset in detail, for example, an operating system version, application software configuration, network settings (IP address, subnet mask, gateway), hardware configuration (CPU, memory, hard disk, network interface) and the like. Association relationship, which records not only information of a single asset, but also relationships between the assets, for example, connection of a server and storage equipment, dependence of an application program and a database, association of network equipment and services and the like. Performance data, which is used for performance analysis and troubleshooting, and includes running status, performance indicators (such as CPU usage, memory usage, I / O rate), health status, monitoring data and the like of the asset.

[0041] In step S204, hidden danger investigation information of the target system is obtained by performing hidden danger investigation on the target system from multiple dimensions according to the asset data.

[0042] In the technical scheme provided in step S204, the multiple dimensions include internal monitoring data of each level in multiple levels of the target system, monitoring data between the multiple levels, and external monitoring data of the target system.

[0043] In the technical solution provided in step S204, the target system is respectively inquired for hidden dangers from multiple dimensions according to the asset data, and the implementation manner of obtaining the hidden danger inquiry information set of the target system is various, for example: according to the running data and configuration information corresponding to each level of the target system in the asset data, the hidden danger inquiry within each level is respectively performed to obtain the hidden danger inquiry information corresponding to each level; according to the association data between multiple levels of the target system stored in the asset data, the association between levels is analyzed to obtain the hidden danger inquiry information between multiple levels, wherein the association data at least includes the device binding relationship and the dependency relationship between multiple levels; external monitoring data corresponding to each level is obtained, and the external monitoring data is compared with the target asset data to obtain the hidden danger inquiry information corresponding to the external monitoring data, wherein the target asset data is asset data whose environment label of each level is production in the asset data, wherein the environment label is an identifier used by the asset data to identify the running environment of the asset data; and the set of the hidden danger inquiry information corresponding to each level, the hidden danger inquiry information between multiple levels, and the hidden danger inquiry information corresponding to the external monitoring data is determined as the hidden danger inquiry information set of the target system. The process of inquiring for hidden dangers from multiple dimensions to obtain the hidden danger inquiry information set of the target system is described in detail below.

[0044] In some embodiments of the present application, Figure 3 The hidden danger identification module of the system shown performs hidden danger identification on the target system (for example, an IT system) from three dimensions through "intra-level inquiry-cross-level analysis-external comparison", and comprehensively identifies various potential hidden dangers:

[0045] For intra-layer hidden danger identification (inside each level in multiple levels of the target system), according to the running data and configuration information corresponding to each level of the target system in the asset data, the preset hidden danger standard (predefined for various hidden dangers) is used to perform hidden danger elimination inside each level, and hidden danger elimination information corresponding to each level is obtained: in the case of the target system being an IT system, the multiple levels are divided into IaaS, PaaS, and SaaS layers, and for each layer, the configuration standard (i.e., the above configuration information) and the running data of the corresponding level asset in the CMDB are used to eliminate hidden dangers inside the level one by one, and hidden danger elimination information corresponding to each level is obtained. For example, for the IaaS layer: old equipment hidden danger (information stored in the running data and configuration information of the CMDB in the aaaS layer shows that the server usage time is > 5 years, and the hardware component failure rate is > 15%). Resource allocation imbalance hidden danger (such as virtual machine CPU usage rate > 85% or insufficient memory allocation leading to frequent stalls), device compatibility hidden danger (such as switch and new access network device protocol mismatch), etc. For the PaaS layer: single-point hidden danger (such as Redis cluster without deploying master and standby nodes (Redis is an open source high-performance key value storage database), API gateway without redundancy design), structure hidden danger (such as unreasonable cluster node number leading to cluster master brain split), configuration exception hidden danger (such as inconsistent container image version leading to service startup failure), etc.

[0046] For cross-layer hidden danger identification (between multiple levels), according to the association data (the association data at least includes the device binding relationship and the dependency relationship between multiple levels) between multiple levels of the target system stored in the asset data, the association between levels is analyzed, and hidden danger elimination information between multiple levels is obtained: in the case of the target system being an IT system, the association data between multiple levels of the target system stored in the asset data is the association data of the IaaS layer and the PaaS / SaaS layer assets in the CMDB (such as the binding relationship of the PaaS cluster node and the IaaS server and storage device carrying it, and the dependency link of the SaaS service and the IaaS network resource). When analyzing the association between levels according to the association data, first, the graph database technology is used to convert the association data into nodes, and the relationship between levels is converted into edges, an asset relationship graph is constructed, and an index is created for the key attributes (such as device ID, service name, asset type, etc.) in the asset relationship graph to speed up the graph query speed. Each node contains an asset entity (for example, a server, a database, an application service, etc.) in the association data of a level, and each edge represents the dependency or binding relationship between the corresponding two nodes. The asset relationship graph contains the association data between the levels in the target system.

[0047] Next, the cross-layer hidden trouble identification algorithm capable of traversing the relationship between each level is used to analyze the correlation of the asset relationship graph, identify the potential hidden trouble transmission path, and identify the path and correlation with hidden troubles, thereby obtaining the hidden trouble investigation information between multiple levels: cross-level hidden trouble identification rules are defined according to the operation and maintenance experience of the IT system and industry standards. The cross-level hidden trouble identification rules at least include the identification conditions of cross-level hidden troubles, hidden trouble type definition (providing a clear description and classification for each cross-level hidden trouble type), and threshold setting information (such as resource utilization, failure rate, and delay time) that triggers hidden troubles. The cross-level hidden trouble identification rules include but are not limited to the following identification rules:

[0048] Cluster affinity hidden trouble: defined as a potential hidden trouble when multiple cluster nodes of the PaaS layer are deployed on the same large IaaS resource (such as a shared host). The rule includes checking the binding relationship between the PaaS layer cluster node and the IaaS layer host, as well as the health status and resource occupation of the host, to evaluate the impact on cluster stability. Resource allocation imbalance hidden trouble: the rule is defined as a hidden trouble when the resource allocation method of the IaaS layer causes the performance of the PaaS or SaaS layer service to be limited. The evaluation criteria are that the IaaS layer resources relied on by the key business services of the SaaS layer are in a long-term high-load state (CPU usage is greater than the first threshold value for a first preset time period, for example, greater than 80% for 5 minutes). Fault transmission hidden trouble: when a fault occurs in the IaaS layer, it may affect the upper layer service through the inter-level dependency relationship. The rule needs to identify these transmission paths: the read-write performance of the storage device of the IaaS layer decreases (the read-write performance decreases by a preset ratio within a preset time period, for example, decreases by 50% within 5 minutes), which is identified as affecting the response speed of the PaaS layer database cluster running on it, thereby affecting the access experience of the SaaS layer application. Insufficient redundancy hidden trouble: the rule is defined as a hidden trouble when the inter-level redundancy design is insufficient, which has a single point of failure risk. For example, the key services of the PaaS layer are not redundantly deployed on different IaaS layer resources. Once a fault occurs in a resource, the service will be affected.

[0049] The nodes in the asset relationship graph are traversed by depth-first search (DFS) or breadth-first search (BFS), and in the traversal process, the defined cross-level hidden danger identification rules are used to check whether the asset relationship between each level meets the requirements of the rules. For example, check whether multiple PaaS layer cluster nodes are bound on the same IaaS layer host, forming a cross-layer single point of failure hidden danger. After the asset relationship graph traversal, the hidden danger troubleshooting information between multiple levels is obtained. For example, the obtained hidden danger troubleshooting information between multiple levels includes but is not limited to: it is found that the key business system of the SaaS layer is highly dependent on a single cluster of the PaaS layer, and the cluster runs on an old server of the IaaS layer. The host of the virtual machine where all nodes of the PaaS layer cluster are located is the same, and the host downtime will cause the entire cluster to be paralyzed. The SaaS service is scattered on IaaS servers with large geographical location span, resulting in high network latency affecting service performance, insufficient read-write performance of IaaS layer storage devices causing PaaS layer database cluster response delay, limited IaaS layer network bandwidth causing PaaS layer message queue data backlog, etc.

[0050] For external monitoring data dimensions, in order to identify the external monitoring missing hidden dangers of the target system, first, obtain the external monitoring data corresponding to multiple levels (including but not limited to resource utilization rate (CPU, memory, disk I / O, network bandwidth), failure rate, delay time, health status, etc. Index). Obtain target asset data, target asset data is asset data in which the environment label (environment label is an identifier used by asset data to identify the running environment of asset data) of each level is production asset data. The environment label of the production asset data means that a specific IT asset (including hardware devices, software applications, network resources, etc.) is marked as in the production environment of the enterprise formal business process, rather than in the test, development or standby environment. Next, compare the external monitoring data with the target asset data: check whether there is monitoring data in the external monitoring data corresponding to the data in the target asset data, that is, check the coverage of each production environment asset in the target asset data in the external monitoring data. If the monitoring data is missing some monitoring indicators of the assets in the target asset data, it is recorded as a monitoring missing hidden danger, which means that there is not enough external monitoring information for part or all of the running state of the asset, increasing the risk of not being able to respond to faults or performance problems in a timely manner. All monitoring missing hidden dangers identified after the comparison are determined as hidden danger troubleshooting information corresponding to the external monitoring data.

[0051] Finally, the set of the hidden danger investigation information corresponding to each level, the hidden danger investigation information between the multi-levels, and the hidden danger investigation information corresponding to the external monitoring data is determined as the hidden danger investigation information set of the target system. The hidden danger investigation information set of the target system provides the hidden danger problems that may exist in all dimensions of the target system, and provides a solid foundation for subsequent hidden danger processing.

[0052] In step S206, a standardized hidden danger list is generated according to the hidden danger investigation information set.

[0053] In the technical solution provided in step S206, the standardized hidden danger list is used at least to indicate the disposal mode of the hidden danger and the resource type required to solve the hidden danger.

[0054] The generation of the standardized hidden danger list according to the hidden danger investigation information set can be realized in various ways, for example: Figure 3 The hidden danger list management module of the system extracts attributes and performs standardization processing on each piece of hidden danger information in the hidden danger investigation information set according to target attributes, and generates a standardized hidden danger list according to the set of all standardized hidden danger information. The target attributes include hidden danger name, hidden danger category, resource type required to solve the hidden danger (specifically, hardware resource type), and hidden danger disposal mode. For each piece of hidden danger information in the hidden danger investigation information set, the hidden danger category corresponding to the hidden danger information is identified. According to whether the hidden danger information causes business interruption, the hidden danger information that causes business interruption and data loss is divided into first-level hidden danger, the hidden danger that limits business and reduces performance is divided into second-level hidden danger, and the hidden danger that does not affect business and only affects non-business related functions of the target system is divided into third-level hidden danger. According to the naming format of the level of hidden danger occurrence and the type of hidden danger, the hidden danger name is obtained. Next, the hidden danger disposal mode corresponding to each piece of hidden danger information is obtained from the preset standardized disposal process library (which contains the standardized processing process of all possible hidden dangers of the target system), and the hidden danger information is divided into two categories: hardware resource class and non-hardware resource class. Finally, the standardized hidden danger information is obtained. The core attributes included in the standardized hidden danger list are shown in Table 1:

[0055] Table 1

[0056]

[0057] In step S208, the hidden danger events existing in the target system are processed according to the standardized hidden danger list.

[0058] In the technical solution provided in step S208, there are various implementation manners for processing the hidden trouble events existing in the target system according to the standardized hidden trouble list. For example, system state data of the target system is acquired, hidden trouble identification is performed on the system state data according to the standardized hidden trouble list, hidden trouble events existing in the target system are obtained, and a set of all the hidden trouble events is determined as a hidden trouble event set, wherein each hidden trouble event corresponds to a hidden trouble name in the standardized hidden trouble list; a required resource type for solving each hidden trouble event in the hidden trouble event set in the standardized hidden trouble list is determined, wherein the required resource type is divided into a hardware resource required type and a hardware resource free type; the hidden trouble events in the hidden trouble event set are divided into a first set and a second set according to the required resource type for solving hidden troubles, wherein the first set contains hidden trouble events with the required resource type being the hardware resource free type, and the second set contains hidden trouble events with the required resource type being the hardware resource required type; the hidden trouble events in the first set and the second set are processed by using corresponding processing manners.

[0059] The hidden trouble events in the first set are processed by the following processing manner: a third target hidden trouble event is processed by executing a hidden trouble handling manner corresponding to the third target hidden trouble event in the standardized hidden trouble list, wherein the third target hidden trouble event is any one of the hidden trouble events in the first set.

[0060] The hidden trouble events in the second set are processed by the following processing manner: all hardware resources required by all the hidden trouble events in the second set are divided according to the resource type to obtain a plurality of hardware resource type sets; the hidden trouble events in the second set are prioritized to obtain a priority score corresponding to each hidden trouble event; for each hardware resource type set, the hidden trouble events are assigned hardware resources in descending order of priority score; a first target hidden trouble event is processed by executing a hidden trouble handling manner corresponding to the first target hidden trouble event in the standardized hidden trouble list, wherein the first target hidden trouble event is any one of the hidden trouble events in the second set that has been assigned all required hardware resources.

[0061] In the above step, there are various implementation manners for prioritizing the hidden trouble events in the second set to obtain a priority score corresponding to each hidden trouble event. For example, a second target hidden trouble event is determined to correspond to a target hidden trouble category in the standardized hidden trouble list, wherein the second target hidden trouble event is any one of the hidden trouble events in the second set; a preset category score corresponding to the target hidden trouble category is acquired, wherein different hidden trouble categories in the standardized hidden trouble list correspond to different preset category scores; an influence range score corresponding to the second target hidden trouble event is determined, wherein the influence range score is used to quantify the influence range of the second target hidden trouble event on the target system; and the priority score of the influence range score is determined according to the preset category score corresponding to the target hidden trouble category and the influence range score.

[0062] The impact range score corresponding to the second target hidden danger event can be determined by determining all businesses affected by the second target hidden danger event and the business systems corresponding to each business, wherein different business systems correspond to different level scores; in a case where the sum of the level scores corresponding to all businesses affected by the second target hidden danger event is less than or equal to a preset maximum impact score threshold, the sum of the level scores corresponding to all businesses affected by the second target hidden danger event is determined as the impact range score corresponding to the target hidden danger event; in a case where the sum of the level scores corresponding to all businesses affected by the second target hidden danger event is greater than the preset maximum impact score threshold, the preset maximum level score threshold is determined as the impact range score corresponding to the target hidden danger event. The process of step S208 of processing the hidden danger event is described in detail below.

[0063] Firstly, Figure 3 The hidden danger assessment module of the system shown in the figure investigates the entire network: acquires system state data of a target system (including state data of the target system and all subsystems having business association, the state data including but not limited to resource utilization rate information, performance index information, configuration information, environment and monitoring data, backup and recovery state of each level of the target system and the subsystems), and performs hidden danger identification matching on the system state data according to the standardized hidden danger list, identifies hidden danger events conforming to the description of the hidden danger list from the hidden danger identification matching, ensures that each hidden danger event can be clearly corresponded to a hidden danger name on the list, realizes, obtains hidden danger events existing in the target system, and determines a set of all the hidden danger events as a hidden danger event set.

[0064] After obtaining the hidden danger event set, the hidden danger events in the hidden danger event set are divided into a first set and a second set according to the required resource type for solving the hidden danger, wherein the first set contains hidden danger events whose required resource type is a hardware resource-free type, and the second set contains hidden danger events whose required resource type is a hardware resource-required type.

[0065] For each hidden danger event in the first set, the hidden danger can be directly processed by the corresponding hidden danger disposal mode in the standardized hidden danger list. For example, operations such as "configuring port flow monitoring indicators for a switch" and "adjusting PaaS cluster node load balancing strategy" do not require additional hardware resources, and operation instructions can be issued by the platform through the operation personnel.

[0066] For the risk events in the second set, the risk events that require hardware resource classes, such as the risk events that require resources of types “virtual machine”, “bare metal”, “switch”, “storage device”, etc., first need to divide all hardware resources required by all risk events in the second set according to resource types to obtain a plurality of hardware resource type sets. Then, the risk events in the second set are prioritized to obtain a priority score corresponding to each risk event. For each hardware resource type set, the hardware resources are allocated to the risk events in order of priority score from high to low. High-priority risks are given high-quality resources to handle the risks first. If a low-priority risk does not obtain resources, it needs to wait for resource scheduling or procurement. After obtaining all the required hardware resources, the risks are handled according to the corresponding handling methods in the standardized risk list, and the operation and maintenance personnel can issue operation instructions through the platform.

[0067] Taking any one of the risk events in the second set as an example (a second target risk event), the calculation method of the priority score is as follows: determine the target risk category corresponding to the second target risk event in the standardized risk list, and obtain the preset category score corresponding to the target risk category, wherein different risk categories in the standardized risk list correspond to different preset category scores (1 point, 5 points, 10 points), wherein a first-level risk is 10 points, a second-level risk is 5 points, and a third-level risk is 1 point. Determine the impact range score corresponding to the second target risk event: determine all businesses affected by the second target risk event and the business systems corresponding to each business, and different business systems correspond to different level scores: clearly distinguish different core systems in terms of scores, with 10 points for affecting a core business system (such as customer relationship management (CRM), payment center), 5 points for affecting an important business system (such as report system, office automation system (OA system)), and 1 point for affecting a general business system (such as internal training system).

[0068] Then the cross-level hidden danger transmission matrix is constructed, the asset relationship graph based on the CMDB is traced to all business systems affected by each hidden danger transmission, and the total sum of the scores of the affected business systems (i.e., the total sum of the level scores corresponding to all businesses affected by the second target hidden danger event) is counted. In the case where the total sum of the level scores corresponding to all businesses affected by the second target hidden danger event is less than or equal to a preset maximum impact score threshold (10 points), the total sum of the level scores corresponding to all businesses affected by the second target hidden danger event is determined as the impact range score corresponding to the target hidden danger event; in the case where the total sum of the level scores corresponding to all businesses affected by the second target hidden danger event is greater than the preset maximum impact score threshold, the preset maximum level score threshold is determined as the impact range score corresponding to the target hidden danger event. For example, a certain Redis cluster is a single-point cluster, there is a single-point hidden danger, and the cluster carries two important business systems, i.e., an OA system and a report system. Therefore, the impact range score of the hidden danger event is: 5 points (score of affecting the OA system) + 5 points (score of affecting the report system) = 10 points, and the impact range score is up to 10 points. If the calculation result exceeds 10 points, the result is processed as 10 points.

[0069] Finally, the priority score of the impact range score is determined according to the preset category score corresponding to the target hidden danger category and the impact range score: priority score = impact range score x preset category score. For example: a first-level hidden danger (preset category score 10 points) affects one core system (impact range score 10 points), and the hidden danger event score = 10 x 10 = 100 points; a third-level hidden danger (category score 1 point) affects one important system (impact range score 5 points), and the hidden danger event score = 1 x 5 = 5 points. Each hardware resource type set is assigned a hardware resource for the hidden danger event in the second set in the order of priority score from high to low.

[0070] In some embodiments of the present application, when the hidden danger events existing in the target system are processed according to the standardized hidden danger list, the hidden danger events are processed by Figure 3 The hidden danger work order management module of the system shown in FIG. 8 realizes one-key dispatching, progress synchronization, and data archiving: one-key dispatching: based on the "asset-responsible person" association relationship in the CMDB, the hidden danger disposal person is automatically matched, and the disposal work order is supported to be generated and pushed to the responsible person in one key; real-time progress feedback: the responsible person updates the disposal progress (such as "resource allocation in progress", "disposal in progress", and "completed") through the work order system; traceability and archiving: after the disposal is completed, the hidden danger information, the disposal process, the resource usage, the responsible person, and other data are archived, and effective data support is provided for the disposal mode optimization in the standardized hidden danger list.

[0071] The method in the embodiments of the present application identifies various hidden troubles of a target system (for example, an IT system) through multi-dimensional troubleshooting, constructs a standardized hidden trouble list based on the identification result, and provides accurate basis for subsequent hidden trouble troubleshooting and disposal. Compared with the traditional evaluation method which relies on manual experience and is prone to fuzzy and biased judgment, the method in the embodiments introduces a hidden trouble event priority score mechanism, realizes objective quantification and priority sorting of hidden trouble events, accurately measures the severity of hidden troubles, and comprehensively considers the influence of cross-layer conduction on core business. The traditional static resource allocation mode of "fixed allocation" is abandoned, and dynamic linkage is formed with the disposal priority of hidden troubles, so as to ensure that limited high-quality hardware resources are tilted to the most urgent hidden troubles, and to solve the problem that low-level hidden troubles occupy resources and hinder the disposal of high-level hidden troubles. The "asset-responsible person" system of CMDB is linked, a "dispatch-disposal-feedback" closed-loop management is constructed, one-key dispatch, progress synchronization and data archiving are realized. This mode replaces the traditional manual coordination mode, the responsibility is clearly defined, and effective data support is provided for disposal mode optimization in the standardized hidden trouble list.

[0072] Figure 4 is a flowchart of another system hidden trouble processing method provided according to the embodiments of the present application. First, full-dimensional hidden trouble identification is performed (that is, the above-mentioned hidden trouble troubleshooting of the target system from multiple dimensions according to asset data is performed to obtain a hidden trouble troubleshooting information set of the target system), then a standardized hidden trouble list is customized (that is, the above-mentioned generation of a standardized hidden trouble list according to the hidden trouble troubleshooting information set is performed), full-network hidden trouble troubleshooting (that is, the above-mentioned hidden trouble identification of system state data according to the standardized hidden trouble list to obtain hidden trouble events existing in the target system is performed), in the case where it is determined that hidden troubles exist, hidden trouble event quantification scoring is performed, it is judged whether resources are needed for disposing hidden troubles, if yes, priority sorting is performed, and resource allocation is performed, then hidden trouble disposal is performed (that is, the above-mentioned processing of hidden trouble events in the second set is performed by the following processing mode: all hardware resources required by all hidden trouble events in the second set are divided according to resource types to obtain a plurality of hardware resource type sets; the hidden trouble events in the second set are sorted according to priority to obtain a priority score corresponding to each hidden trouble event; for each hardware resource type set, the hidden trouble events are allocated hardware resources in descending order of priority score; the first target hidden trouble event is processed by executing the hidden trouble disposal mode corresponding to the first target hidden trouble event in the standardized hidden trouble list, wherein the first target hidden trouble event is any hidden trouble event in the second set which has been allocated all required hardware resources). If no, hidden trouble disposal is directly performed (that is, the above-mentioned processing of hidden trouble events in the first set is performed by the following processing mode: the third target hidden trouble event is processed by executing the hidden trouble disposal mode corresponding to the third target hidden trouble event in the standardized hidden trouble list, wherein the third target hidden trouble event is any hidden trouble event in the first set).

[0073] Figure 5 is a structural schematic diagram of a system hidden danger processing apparatus provided by an embodiment of the present application, comprising:

[0074] The acquisition module 502 is configured to acquire asset data of a target system stored in a configuration management database, wherein the target system is a multi-level system.

[0075] The hidden danger investigation module 504 is configured to investigate hidden dangers of the target system from multiple dimensions according to the asset data, to obtain a hidden danger investigation information set of the target system, wherein the multiple dimensions include internal of each level of the multiple levels of the target system, between the multiple levels, and external monitoring data of the target system.

[0076] The generation module 506 is configured to generate a standardized hidden danger list according to the hidden danger investigation information set, wherein the standardized hidden danger list is used at least to indicate a disposal manner of the hidden danger and a resource type required to solve the hidden danger.

[0077] The processing module 508 is configured to process a hidden danger event existing in the target system according to the standardized hidden danger list.

[0078] It should be noted that, Figure 5 The system hidden danger processing apparatus is configured to execute the system hidden danger processing method shown in Figure 2 Therefore, Figure 2 The related explanations and descriptions in the system hidden danger processing method in the system hidden danger processing method are also applicable to the system hidden danger processing apparatus, and will not be described here.

[0079] It should be noted that each module in the system hidden danger processing apparatus described above can be a program module (for example, a program instruction set implementing a certain specific function) or a hardware module, and for the latter, it can be in the following form, but is not limited to this: the form of each module is a processor, or the functions of each module are implemented by a processor.

[0080] The embodiment of the present application further provides a non-volatile storage medium, which comprises a stored program, wherein when the program is running, the non-volatile storage medium controls the device where the non-volatile storage medium is located to execute the system hidden danger processing method of any one of the above embodiments.

[0081] The embodiment of the present application further provides an electronic device, which comprises a processor, and the processor is configured to run a program, wherein when the program is running, the processor executes the system hidden danger processing method of any one of the above embodiments.

[0082] According to another aspect of the embodiment of the present application, a computer program product is also provided, which comprises a computer program, and when the computer program is executed by a processor, the system hidden danger processing method of any one of the above embodiments is implemented.

[0083] In the above-described embodiments of the present application, the description of each embodiment focuses on different aspects, and the parts not described in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0084] In several embodiments provided in the present application, it should be understood that the disclosed technical contents can be implemented by other ways. Among them, the above-described device embodiments are only schematic, for example, the division of the units can be a logical function division, and actual implementation can have another division way, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or modules shown or discussed can be indirect coupling or communication connection through some interfaces, units or modules, which can be electrical or other forms.

[0085] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or they can be distributed to multiple units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment scheme.

[0086] In addition, each functional unit in each embodiment of the present application can be integrated in a processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The above integrated unit can be realized in the form of hardware or in the form of software functional unit.

[0087] The integrated unit, if realized in the form of software functional unit and sold or used as an independent product, can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application or the part that essentially contributes to the related art or the whole or part of the technical solutions can be embodied in the form of software product, which is stored in a storage medium and includes a plurality of instructions for making a computer device (which can be a personal computer, a server or a network device, etc.) execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic or optical disk and various program code storage media.

[0088] The above merely describes the preferred embodiments of the present application, and it should be pointed out that, for those skilled in the art, some improvements and refinements can be made without departing from the principles of the present application, and these improvements and refinements should also be considered as the protection scope of the present application.

Claims

1. A method of handling a system vulnerability, the method comprising: The method comprises the following steps: acquiring asset data of a target system stored in a configuration management database, wherein the target system is a multi-level system; performing hidden danger investigation on the target system from multiple dimensions according to the asset data, to obtain a hidden danger investigation information set of the target system, wherein the multiple dimensions include each level inside the multiple levels of the target system, the multiple levels, and external monitoring data of the target system; generating a standardized hidden danger list according to the hidden danger investigation information set, wherein the standardized hidden danger list is used at least to indicate a hidden danger treatment method and a resource type required to solve the hidden danger; processing a hidden danger event existing in the target system according to the standardized hidden danger list.

2. The method of claim 1, wherein, The step of performing hidden danger investigation on the target system from multiple dimensions according to the asset data comprises the following steps: performing hidden danger investigation inside each level according to running data and configuration information corresponding to each level in the asset data of the target system, to obtain hidden danger investigation information corresponding to each level; analyzing the correlation between the multiple levels according to association data between the multiple levels stored in the asset data, to obtain hidden danger investigation information between the multiple levels, wherein the association data at least includes a device binding relationship and a dependency relationship between the multiple levels; acquiring external monitoring data corresponding to each level, and comparing the external monitoring data with target asset data, to obtain hidden danger investigation information corresponding to the external monitoring data, wherein the target asset data is asset data of each level whose environment label is production, wherein the environment label is an identifier used by the asset data to identify a running environment of the asset data; determining a set of hidden danger investigation information corresponding to each level, hidden danger investigation information between the multiple levels, and hidden danger investigation information corresponding to the external monitoring data as the hidden danger investigation information set of the target system.

3. The method of claim 1, wherein, The step of generating a standardized hidden danger list according to the hidden danger investigation information set comprises the following steps: performing attribute extraction and standardization processing on each piece of hidden danger information in the hidden danger investigation information set according to a target attribute, to obtain standardized hidden danger information, and generating the standardized hidden danger list according to a set of all the standardized hidden danger information, wherein the target attribute includes a hidden danger name, a hidden danger category, a resource type required to solve the hidden danger, and a hidden danger treatment method.

4. The method of claim 1, wherein, The step of processing a hidden danger event existing in the target system according to the standardized hidden danger list comprises the following steps: acquiring system state data of the target system, performing hidden danger identification on the system state data according to the standardized hidden danger list, to obtain a hidden danger event existing in the target system, and determining a set of all the hidden danger events as a hidden danger event set, wherein each hidden danger event corresponds to a hidden danger name in the standardized hidden danger list. determining a required resource type for solving each hidden trouble event in the hidden trouble event set in the standardized hidden trouble list, wherein the required resource type is classified into a hardware resource required type and a hardware resource free type; dividing hidden trouble events in the hidden trouble event set into a first set and a second set according to the required resource type, wherein the first set contains hidden trouble events of the hardware resource free type, and the second set contains hidden trouble events of the hardware resource required type; processing hidden trouble events in the first set and the second set by using corresponding processing manners respectively.

5. The method of claim 4, wherein, processing hidden trouble events in the second set by using the following processing manner: dividing all hardware resources required by hidden trouble events in the second set into a plurality of hardware resource type sets according to resource types; performing priority sorting on hidden trouble events in the second set to obtain a priority score corresponding to each hidden trouble event; allocating hardware resources to hidden trouble events in each hardware resource type set in descending order of the priority score; processing a first target hidden trouble event by executing a hidden trouble handling manner corresponding to the first target hidden trouble event in the standardized hidden trouble list, wherein the first target hidden trouble event is any hidden trouble event in the second set that has been allocated all required hardware resources.

6. The method of claim 5, wherein, The priority sorting on hidden trouble events in the second set to obtain a priority score corresponding to each hidden trouble event includes: determining a target hidden trouble category corresponding to a second target hidden trouble event in the standardized hidden trouble list, wherein the second target hidden trouble event is any hidden trouble event in the second set; obtaining a preset category score corresponding to the target hidden trouble category, wherein different hidden trouble categories in the standardized hidden trouble list correspond to different preset category scores; determining an impact range score corresponding to the second target hidden trouble event, wherein the impact range score is used to quantify an impact range of the second target hidden trouble event on the target system; determining a priority score of the impact range score according to the preset category score corresponding to the target hidden trouble category and the impact range score.

7. The method of claim 6, wherein, The determination of the impact range score corresponding to the second target hidden trouble event includes: determining all businesses affected by the second target hidden trouble event and a business system corresponding to each business, wherein different business systems correspond to different level scores; in a case where a sum of the level scores corresponding to all businesses affected by the second target hidden trouble event is less than or equal to a preset maximum impact score threshold, determining the sum of the level scores corresponding to all businesses affected by the second target hidden trouble event as the impact range score corresponding to the target hidden trouble event; in a case where the sum of the level scores corresponding to all businesses affected by the second target hidden trouble event is greater than the preset maximum impact score threshold, determining the preset maximum level score threshold as the impact range score corresponding to the target hidden trouble event.

8. The method of claim 4, wherein, The hidden danger events in the first set are processed by the following processing manners: The third target hidden danger event is processed by performing a hidden danger disposal manner corresponding to the third target hidden danger event in the standardized hidden danger list, the third target hidden danger event being any one of the hidden danger events in the first set.

9. The method of claim 1, wherein, The method further comprises: in the case that the target system is an IT system, the multiple levels comprising a hardware facility layer, a platform layer and an application layer.

10. A system for handling of a system hazard, characterized by Comprise: An acquisition module, configured to acquire asset data stored in a configuration management database by a target system, wherein the target system is a multi-level system; A hidden danger investigation module, configured to investigate hidden dangers of the target system from multiple dimensions according to the asset data, to obtain a hidden danger investigation information set of the target system, wherein the multiple dimensions comprise inside each level of the multiple levels of the target system, between the multiple levels, and external monitoring data of the target system; A generation module, configured to generate a standardized hidden danger list according to the hidden danger investigation information set, wherein the standardized hidden danger list is used at least to indicate a hidden danger disposal manner and a resource type required to solve the hidden danger; A processing module, configured to process hidden danger events existing in the target system according to the standardized hidden danger list.

11. A non-volatile storage medium, comprising: The non-volatile storage medium stores a program, wherein when the program is running, the device in which the non-volatile storage medium is located executes the system hidden danger processing method of any one of claims 1 to 9.

12. An electronic device, comprising: Comprise: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program is executed when the program is running to execute the system hidden danger processing method of any one of claims 1 to 9.

13. A computer program product comprising computer instructions, characterized in that, The computer instructions are executed by the processor to implement the system hidden danger processing method of any one of claims 1 to 9.