Risk management and control method and device
By constructing service link topology relationships and conducting differentiated risk analysis, the problem of low efficiency in manual risk screening in e-commerce activities has been solved, achieving efficient and accurate risk control and ensuring system stability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-01
- Publication Date
- 2026-03-10
AI Technical Summary
In large-scale promotional activities in the e-commerce sector, existing manual risk screening methods are inefficient, unable to fully cover potential risk points, and rely on the experience and judgment of technical personnel, which cannot guarantee system stability and service continuity.
Construct the service link topology of the service scenario, use preset screening indicators to determine the core service nodes, track the changes through a unified change platform, and configure risk control tags for differentiated risk analysis to achieve penetrating analysis from single-point changes to full-link risks.
This improved the efficiency and accuracy of risk analysis, reduced the false positive rate, ensured the smooth operation of e-commerce activities, and prevented the spread of potential risks.
Smart Images

Figure CN121636313A_ABST
Abstract
Description
Technical Field
[0001] This specification relates to one or more embodiments in the field of computer network technology, and in particular to a risk information management method and apparatus. Background Technology
[0002] In the e-commerce sector, large-scale promotional events (such as annual shopping festivals and themed promotional days) have become a core means for platforms to increase transaction volume and enhance user stickiness. Such events often involve massive user access and high-concurrency order processing, placing extremely high demands on system stability and service continuity.
[0003] To ensure system stability and service continuity, the platform's technical team invests significant manpower during the preparation period for each e-commerce campaign to comprehensively review technical changes and assess the potential risks introduced by each change. This manual risk assessment method involves a huge amount of repetitive work, and the manual assessment process relies heavily on the experience and judgment of technical personnel, making it difficult to cover all potential risks. Therefore, there is an urgent need for a more efficient and reliable risk management solution. Summary of the Invention
[0004] This specification provides one or more embodiments of a risk management method and apparatus for more efficient and reliable risk management.
[0005] Firstly, one or more embodiments of this specification provide a risk management method, the method comprising: constructing at least one service scenario and a service link topology corresponding to each service scenario, wherein the service link topology includes at least one service link, and each service link includes at least one service node; determining core service nodes in the service link topology according to preset screening indicators; sending instruction information to a unified change platform, the instruction information being used to instruct the core service nodes to be tracked for changes; receiving change data sent by the unified change platform, the change data including the change content and change type corresponding to the changed service node; configuring risk control tags corresponding to each change content according to the change type; generating change information corresponding to the change risk query request in response to receiving a change risk query request input by a user; and performing risk analysis on each change content in the change information using the risk analysis method corresponding to the risk control tag configured for each change, generating risk information corresponding to the change information.
[0006] In one possible implementation, a service scenario includes at least one sub-service scenario, and the service link includes a core service link and a branch service link; the service link topology corresponding to a sub-service scenario includes a core service link and at least one branch service link.
[0007] In one possible implementation, the preset screening criteria include at least one of the following: the amount of code corresponding to the service node, the frequency of changes, the unit traffic, and whether funds are involved.
[0008] In one possible implementation, determining the core service node in the service link topology based on preset screening indicators includes: determining the first core service node in the service link topology based on the value of the preset screening indicators in a first time period; and updating the first core service node in the service link topology to the second core service node based on the value of the preset screening indicators in a second time period; wherein the second time period is the time period after the first time period.
[0009] In one possible implementation, the change types include code changes, configuration changes, and storage changes. Based on the change type, risk control tags are configured for each change, including: when the change is a code change and / or a configuration change, the risk control tags corresponding to the change include service scenarios and service functions; when the change is a code change and / or a storage change, the risk control tags corresponding to the change include service performance; and when the change is a code change, the risk control tags corresponding to the change include link call relationships and service links.
[0010] In one possible implementation, when the risk control label includes a service scenario, the risk analysis method includes: determining whether the changed content involves a change in the service scenario. If the changed content involves a change in the service scenario, the risk level of the changed content is determined to be high risk; if the changed content does not involve a change in the service scenario, the risk level of the changed content is determined to be low risk. And / or, when the risk control label includes a service function, the risk analysis method includes: determining whether the changed content involves a change in marketing parameters. If the changed content involves a change in marketing parameters, the risk level of the changed content is determined to be high risk; if the changed content does not involve a change in marketing parameters, the risk level of the changed content is determined to be low risk. And / or, when the risk control label includes service performance, the risk analysis method includes: determining whether the changed content involves an interface whose timeout exceeds the average value, and whether this interface is a strongly dependent call. If the changed content involves an interface with a timeout exceeding the average value, and that interface is a strongly dependent call, the risk level of the changed content is determined to be high risk; if the changed content does not involve an interface with a timeout exceeding the average value, and that interface is not a strongly dependent call, the risk level of the changed content is determined to be low risk; and / or, if the risk control label includes link call relationships, the risk analysis method includes: determining whether the changed content involves a newly added link call relationship. If the changed content involves a newly added link call relationship, the risk level of the changed content is determined to be high risk; if the changed content does not involve a newly added link call relationship, the risk level of the changed content is determined to be low risk; and / or, if the risk control label includes service links, the risk analysis method includes: determining whether the changed content involves a newly added service link. If the changed content involves a newly added service link, the risk level of the changed content is determined to be high risk; if the changed content does not involve a newly added service link, the risk level of the changed content is determined to be low risk.
[0011] In one possible implementation, the change risk query request includes the query service scenario, the query service node, and the query time range, and the change information includes the change service node corresponding to the change risk query request, the change content corresponding to the change service node, and the change type.
[0012] Secondly, one or more embodiments of this specification also provide a risk management device, the device comprising: a construction module, configured to construct at least one service scenario and a service link topology corresponding to each service scenario, wherein the service link topology includes at least one service link, and each service link includes at least one service node; a determination module, configured to determine the core service node in the service link topology according to preset screening indicators; a sending module, configured to send instruction information to a unified change platform, the instruction information being used to instruct the core service node to undergo change tracking; a receiving module, configured to receive change data sent by the unified change platform, the change data including the change content and change type corresponding to the changed service node; a configuration module, configured to configure risk control tags corresponding to each change content according to the change type; a first generation module, configured to generate change information corresponding to the change risk query request in response to receiving a change risk query request input by a user; and a second generation module, configured to perform risk analysis on each change content in the change information using the risk analysis method corresponding to each configured risk control tag, and generate risk information corresponding to the change information.
[0013] In one possible implementation, a service scenario includes at least one sub-service scenario, and the service link includes a core service link and a branch service link; the service link topology corresponding to a sub-service scenario includes a core service link and at least one branch service link.
[0014] In one possible implementation, the preset screening criteria include at least one of the following: the amount of code corresponding to the service node, the frequency of changes, the unit traffic, and whether funds are involved.
[0015] In one possible implementation, the determining module is specifically used to: determine the first core service node in the service link topology based on the value of the preset screening index in the first time period; and update the first core service node in the service link topology to the second core service node based on the value of the preset screening index in the second time period; wherein the second time period is the time period after the first time period.
[0016] In one possible implementation, the change types include code changes, configuration changes, and storage changes; the configuration module is specifically used for: when the change content is a code change and / or a configuration change, configuring the risk control tags corresponding to the change content to include service scenarios and service functions; when the change content is a code change and / or a storage change, configuring the risk control tags corresponding to the change content to include service performance; when the change content is a code change, configuring the risk control tags corresponding to the change content to include link call relationships and service links.
[0017] In one possible implementation, when the risk control label includes a service scenario, the risk analysis method includes: determining whether the change involves a change in the service scenario. If the change involves a change in the service scenario, the risk level of the change is determined to be high risk; if the change does not involve a change in the service scenario, the risk level of the change is determined to be low risk; and / or, When the risk control label includes service functions, the risk analysis method includes: determining whether the change involves changes to marketing parameters. If the change involves changes to marketing parameters, the risk level of the change is determined to be high risk; if the change does not involve changes to marketing parameters, the risk level of the change is determined to be low risk; and / or, When service performance is included in the risk control tags, the risk analysis method includes: determining whether the changed content involves interfaces with timeouts exceeding the average value, and whether these interfaces are strongly dependent calls. If the changed content involves interfaces with timeouts exceeding the average value, and these interfaces are strongly dependent calls, the risk level of the changed content is determined to be high risk; if the changed content does not involve interfaces with timeouts exceeding the average value, and these interfaces are not strongly dependent calls, the risk level of the changed content is determined to be low risk; and / or, When risk control tags include link call relationships, the risk analysis method includes: determining whether the changed content constitutes a new link call relationship. If the changed content constitutes a new link call relationship, the risk level of the changed content is determined to be high risk; if the changed content does not constitute a new link call relationship, the risk level of the changed content is determined to be low risk; and / or, When the risk control label includes service links, the risk analysis method includes: determining whether the changed content belongs to a new service link. If the changed content belongs to a new service link, the risk level of the changed content is determined to be high risk; if the changed content does not belong to a new service link, the risk level of the changed content is determined to be low risk.
[0018] In one possible implementation, the change risk query request includes the query service scenario, the query service node, and the query time range, and the change information includes the change service node corresponding to the change risk query request, the change content corresponding to the change service node, and the change type.
[0019] Thirdly, one or more embodiments of this specification also provide an electronic device, which includes a memory and a processor; the memory is used to store a computer program product; the processor is used to execute the computer program product stored in the memory, and when the computer program product is executed, it implements the method of the first aspect described above.
[0020] Fourthly, one or more embodiments of this specification also provide a computer-readable storage medium storing computer program instructions that, when executed, implement the method described in the first aspect.
[0021] In summary, the risk management method provided in one or more embodiments of this specification, based on the service link topology, enables risk analysis to link upstream and downstream nodes, achieving a penetrating analysis from "single-point change to full-link risk," fully covering the cascading risks caused by changes. It identifies core service nodes based on preset screening indicators, avoiding the omission of key nodes due to subjective human judgment and improving the core change tracking coverage. By tracking core node changes through a unified change platform and combining risk control tags with corresponding analysis methods, risks can be quickly identified, allowing potential problems to be discovered before or in the early stages of change implementation, preventing risks from spreading to the production environment. Dedicated risk control tags are configured according to change type, with different risk control tags corresponding to differentiated risk analysis methods, avoiding a "one-size-fits-all" approach to assessment, improving the accuracy of risk analysis, and reducing the risk misjudgment rate. Attached Figure Description
[0022] To more clearly illustrate the technical solutions of one or more embodiments of this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of one or more embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0023] Figure 1 A flowchart illustrating a risk management method provided in one or more embodiments of this specification; Figure 2 A flowchart illustrating another risk management method provided in one or more embodiments of this specification; Figure 3 A structural block diagram of a risk management device provided for one or more embodiments of this specification; Figure 4 This is a structural block diagram of an electronic device provided for one or more embodiments of this specification. Detailed Implementation
[0024] The present specification describes one or more embodiments in further detail below with reference to the accompanying drawings and examples. Through these descriptions, the features and advantages of one or more embodiments of the present specification will become clearer and more apparent.
[0025] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments. Although various aspects of embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated otherwise.
[0026] Furthermore, the technical features described below in one or more embodiments of this specification may be combined with each other as long as they do not conflict with each other.
[0027] To facilitate understanding, the application scenarios of the technical solutions provided in one or more embodiments of this specification will be described below.
[0028] In the e-commerce sector, large-scale promotional events (such as annual shopping festivals and themed promotional days) have become core means for platforms to increase transaction volume and enhance user stickiness. These events often involve massive user access, high-concurrency order processing, and complex service chain coordination, placing extremely high demands on system stability and continuity. The inventors discovered that most technical risks during e-commerce events (such as service interruptions, data anomalies, and functional failures) are related to technical changes in the service chain during the event preparation phase. For example, version updates of service nodes, interface adjustments, and modifications to configuration parameters. If such changes introduce potential defects and are not identified in a timely manner, they can easily trigger systemic failures during peak event periods, causing significant economic losses and damage to brand reputation. To mitigate the aforementioned risks, during the preparation period for each e-commerce campaign, the platform's technical team must invest significant manpower to conduct a comprehensive review of service chain technical changes for a specified timeframe (e.g., 1-2 months prior to the campaign). Specifically, technical personnel must meticulously review the change records for each service node in the service chain, including the content, timing, and scope of the changes, and assess the potential risks introduced by each change in light of the service scenario characteristics. However, on the one hand, service chains typically involve multi-level and multi-type service nodes with complex dependencies between them. Manual review requires cross-team collaboration among technical personnel to obtain change data, resulting in a massive amount of repetitive work and high labor costs. On the other hand, the manual assessment process heavily relies on the experience and judgment of technical personnel, making it difficult to cover all potential risks. In conclusion, the current technical change risk analysis work during the e-commerce campaign preparation phase can no longer meet the e-commerce platform's requirements for efficient and reliable risk management.
[0029] To address the aforementioned technical issues, one or more embodiments of this specification provide a risk management method. This method can automatically identify technical changes, accurately generate risk analysis results, significantly improve risk analysis efficiency, reduce the probability of technical risks, and ensure the smooth operation of e-commerce activities.
[0030] The following describes embodiments of the risk management method provided in one or more embodiments of this specification.
[0031] See Figure 1 and Figure 2 , Figure 1 This is a flowchart illustrating a risk management method provided in one or more embodiments of this specification. Figure 2 This is a flowchart illustrating another risk management method provided in one or more embodiments of this specification. This method can be applied to a risk control management platform, which can be configured on a server or terminal device. The following description uses the application of this method to a risk control management platform as an example to illustrate the content of the embodiment. Figure 1 and Figure 2 As shown, the method may include the following steps: Step S102: Construct at least one service scenario and the service link topology relationship corresponding to each service scenario.
[0032] This specification does not limit the service scenarios in one or more embodiments. For example, service scenarios may include order services, payment services, inventory services, user authentication services, and other service scenarios.
[0033] Each service scenario can correspond to a service link topology. The service link topology can include at least one service link, and each service link can include at least one service node.
[0034] like Figure 2 As shown, each service scenario may include at least one sub-service scenario (e.g., sub-service scenario 01, sub-service scenario 02, sub-service scenario 03, and sub-service scenario 04), and the service link may include a core service link and branch service links. Thus, the core service link and different branch service links can form the service link topology corresponding to different sub-service scenarios. For example, the core service link corresponds to sub-service scenario 02; the core service link and branch service link 1 form the service link topology corresponding to sub-service scenario 02; the core service link and branch service link 2 form the service link topology corresponding to sub-service scenario 03; and the core service link and branch service link 3 form the service link topology corresponding to sub-service scenario 04.
[0035] In one or more embodiments of this specification, the server performs a series of response operations in response to the client's operation, wherein each response operation performed by the server can be referred to as a service node.
[0036] Taking the order service scenario as an example, when a user completes product selection in an e-commerce app (client) and clicks the "Submit Order" button (client operation), the e-commerce platform's server will immediately trigger a series of response operations. Each independent response operation can be regarded as a "service node," as follows: Order Parameter Validation Service Node: The server first receives order data (including product ID, quantity, shipping address ID, payment method, etc.) from the client. This node is specifically responsible for performing parameter validity checks. For example, it checks whether the product ID exists in the platform database, whether the quantity exceeds the current product inventory limit, and whether the shipping address ID is associated with a valid address under the username. If any parameter validation fails, it will directly return a "parameter error" message to the client and terminate subsequent operations.
[0037] Inventory Lock Service Node: If the parameter verification passes, the server will call the inventory management module to trigger this service node. Based on the product ID and quantity in the order, it will query the real-time inventory of the corresponding product and perform an "inventory lock" operation (for example, if a product has 100 units in stock and a user buys 10 units, then 10 units will be locked, and the remaining inventory will be updated to 90 units) to prevent other users from buying at the same time and causing overselling. If the inventory is insufficient, this node will return an "insufficient inventory" prompt to the client.
[0038] Order generation and storage service node: After the inventory is successfully locked, the server enters the order generation stage. This node is responsible for: generating a unique order number, storing the order data in a structured manner in the order database, and establishing an association index between the order and the user and the product to ensure that the order details can be quickly queried later.
[0039] Order Amount Calculation Service Node: After the order data is stored, the server triggers the amount calculation node. Combining the original price of the product, current coupons, platform discount rules, shipping fee rules, etc., the server automatically calculates the actual payment amount of the order and updates the "Actual Payment Amount" field in the order database with the calculation result. At the same time, the server synchronously feeds back the result to the client and displays the final amount on the order confirmation page.
[0040] Payment Link Generation Service Node: After the amount calculation is completed, the server calls the payment integration module. This node sends a request to the corresponding payment platform based on the payment method selected by the user to obtain a unique payment link / payment QR code. It then binds the payment link to the current order number and returns the payment link to the client, guiding the user to click and enter the payment page.
[0041] The five service nodes mentioned above work together to complete the server-side response to the "user submits an order" client operation. Each node focuses on a single response task, and the next node will only be triggered after the previous node is successfully executed. If a node fails to execute (such as insufficient inventory), the server will terminate the process and return the corresponding result to the client, which reflects the independence of the service nodes and the process correlation.
[0042] In one or more embodiments of this specification, the specific implementation method for constructing at least one service scenario and the service link topology relationship corresponding to each service scenario is not limited.
[0043] For example, a server-side user can register an account on the risk control management platform. After logging in, the server-side user can input at least one service scenario and the corresponding service link topology for each service scenario into the risk control management platform. Then, based on the information input by the server-side user, the risk control management platform can construct the corresponding service scenarios and the corresponding service link topology for each service scenario.
[0044] Optionally, the risk control management platform can provide a visual service scenario construction function. For example, the platform can offer service scenario options and service node options. Server-side users can select service scenarios and service nodes from the provided options and configure the relationships between the selected service nodes. Alternatively, server-side users can define new service scenarios, select or define service nodes for them, and configure the relationships between the selected nodes. The risk control management platform then responds to these user actions by constructing the service link topology corresponding to the selected service scenario based on the relationships between the service nodes.
[0045] Optionally, the service scenarios provided by the risk control management platform can be pre-associated with one or more service link topology templates. Server-side users can select one of these templates as the service link topology for the chosen service scenario. Alternatively, server-side users can modify a pre-associated service link topology template for the selected service scenario, and the risk control management platform will respond to this change by generating a new service link topology. The newly generated template can also be added to the service link topology template library corresponding to the selected service scenario.
[0046] In this way, the risk control management platform can build a standardized and reusable service link topology template library in advance for common service scenarios in various industries. After logging in, users do not need to start from scratch. They only need to select the corresponding template according to their own needs, or make minor adjustments based on the template, to quickly complete the construction of service scenarios and link topology relationships, which greatly reduces user operation costs and improves construction efficiency.
[0047] As another example, the risk control management platform can pre-build fixed service scenarios and the corresponding service link topology for each service scenario. This approach can reduce the likelihood of invalid links caused by server-side users' misunderstanding of services or operational negligence during manual input.
[0048] Thus, one or more embodiments of this specification support the custom construction of service scenarios and service link topologies in different fields such as e-commerce, finance, and logistics, which can flexibly adapt to the service characteristics of different industries without the need for repeated development for a single scenario.
[0049] Step S104: Determine the core service nodes in the service link topology based on the preset screening criteria.
[0050] This specification does not limit the preset screening criteria in one or more embodiments. For example, preset screening criteria may include at least one of the following: the amount of code corresponding to the service node, the frequency of change, the unit traffic, and whether it involves funds.
[0051] For example, a service node whose code size exceeds a certain threshold for lines of code can be identified as a core service node. Alternatively, a service node whose change frequency exceeds a certain threshold for change frequency can be identified as a core service node. Alternatively, a service node whose unit traffic exceeds a certain threshold for unit traffic can be identified as a core service node. Alternatively, a service node involving funds can be identified as a core service node. Alternatively, a service node that meets any of the above conditions can be identified as a core service node.
[0052] In one or more embodiments of this specification, when the preset screening indicators include dynamically changing screening indicators, the core service nodes can be updated according to the dynamic changes of the screening indicators.
[0053] For example, based on the value of the preset filtering index in a first time period, a first core service node in the service link topology is determined; based on the value of the preset filtering index in a second time period, the first core service node in the service link topology is updated to a second core service node; wherein, the second time period is the time period following the first time period. The values of the preset filtering index in the first time period and the second time period may be different, and the first core service node and the second core service node may be different.
[0054] In one or more embodiments of this specification, the preset filtering indicators can be dynamically adjusted. For example, filtering indicators can be added or removed from the preset filtering indicators. Then, the core service nodes can be updated based on the adjusted filtering indicators.
[0055] Step S106: Send instruction information to the unified change platform. The instruction information is used to instruct the core service node to track changes.
[0056] like Figure 2 As shown, after determining the core service node (e.g., service node A), the risk control management platform can send instruction information to the unified change platform to instruct the unified change platform to track changes to the core service node.
[0057] The unified change management platform can be a standardized platform for centralized management of technical changes across all service nodes. It enables unified control and data aggregation of changes at each service node, providing accurate and real-time change data support for the risk management platform.
[0058] In this way, identifying core service nodes based on preset screening criteria can avoid missing key nodes due to subjective human judgment, thereby improving the coverage of core change tracking. By tracking changes to core nodes through a unified change platform, comprehensive change data can be collected.
[0059] Step S108: Receive change data sent by the unified change platform.
[0060] The unified change platform can periodically or in real-time feed back the tracked change data to the risk control management platform. The change data received by the risk control management platform can include the change content and type corresponding to the change service node.
[0061] This specification does not limit the type of modification in one or more embodiments. For example, such as Figure 2 As shown, change types can include code changes, configuration changes, storage changes, etc.
[0062] The changes can include the content of the service node before and after the change. Alternatively, the changes can include a description of the changes to the service node. For example, the description of the changes could be adding / deleting / modifying a parameter, interface, or processing logic.
[0063] Step S110: Configure the risk control tags corresponding to each change according to the change type.
[0064] The inventors discovered that different types of changes correspond to different risk impacts. For example, code changes and / or configuration changes have a certain impact on service scenarios and service functions; code changes and / or storage changes have a certain impact on service performance; and code changes have a certain impact on link call relationships and service links.
[0065] Based on this, corresponding risk control tags can be configured for the change type to which the changed content belongs. Different risk control tags can correspond to different risk analysis methods. In this way, subsequent risk analysis of the changed content can be conducted based on the risk control tags and the corresponding risk analysis methods.
[0066] For example, when the change involves code changes and / or configuration changes, the risk control tags corresponding to the change include service scenarios and service functions; when the change involves code changes and / or storage changes, the risk control tags corresponding to the change include service performance; and when the change involves code changes, the risk control tags corresponding to the change include link call relationships and service links.
[0067] For example, the risk analysis method corresponding to the risk control label and service scenario may include: determining whether the change involves a change in the service scenario. If it does, the risk level is high; if it does not, the risk level is low.
[0068] For example, the risk analysis method corresponding to the risk control label-service function may include: determining whether the changed content involves changes to marketing parameters. If it does, the risk level is high; if it does not, the risk level is low.
[0069] For example, the risk analysis method corresponding to the risk control tag and service performance may include: determining whether the changed content involves an interface whose timeout exceeds the average value and whether that interface is a strongly dependent call. If it does, the risk level is high; if it does not, the risk level is low.
[0070] For example, the risk analysis method corresponding to the risk control label-link call relationship may include: determining whether the changed content belongs to a new link call relationship. If it does, then further determining whether the new link call relationship belongs to a strong dependency call. If it does, the risk level is high risk; if it does not, the risk level is low risk.
[0071] For example, the risk analysis method corresponding to the risk control label-service link may include: determining whether the changed content belongs to a newly added service link. If it does, the risk level is high risk; if it does not, the risk level is low risk.
[0072] It should be noted that one or more embodiments in this specification are merely illustrative examples of the change types, risk control labels, and risk analysis methods listed above, and do not imply any limitation on the change types, risk control labels, and risk analysis methods. For example, more or fewer change types, risk control labels, and risk analysis methods may be included.
[0073] In this way, by configuring exclusive risk control labels according to the type of change, and by using different risk control labels to correspond to differentiated risk analysis methods, we can avoid the "one-size-fits-all" approach to rough assessment, improve the accuracy of risk analysis, and reduce the risk misjudgment rate.
[0074] It should also be noted that when the change involves adding a new service link, the new service link will be updated to the service link topology relationship constructed in step S102, thereby achieving dynamic maintenance of the service link topology relationship.
[0075] Step S112: In response to receiving the change risk query request input by the user, generate the change information corresponding to the change risk query request.
[0076] By combining steps S102 to S110 above, the risk control management platform can collect comprehensive and complete change-related data. This change-related data may include the change time, change content, change type, risk control tag, risk analysis method, etc., associated with the change service node.
[0077] In this way, the risk control management platform can support the query of change risks based on the collected change-related data.
[0078] One or more embodiments of this specification can receive a change risk query request and, in response to the received change risk query request, generate change information corresponding to the change risk query request.
[0079] For example, a user can input a query service scenario, query service node, and query time range into the user interface of the risk control management platform. Based on the user-input query service scenario, query service node, and query time range, the risk control management platform generates a corresponding change risk query request. Afterwards, the risk control management platform can retrieve the change information corresponding to the query service scenario, query service node, and query time range from the stored change-related data.
[0080] The change information may include the change service node corresponding to the change risk query request, the change content corresponding to the change service node, and the change type.
[0081] Optionally, the change information can be displayed to the user in the form of a change list.
[0082] Step S114: For each change in the change information, perform risk analysis using the risk analysis method corresponding to the respective configured risk control tag, and generate risk information corresponding to the change information.
[0083] The risk analysis methods corresponding to each risk control label can be found in the description of step S110, and will not be repeated here.
[0084] For example, taking a change in content as a new interface call as an example, its corresponding risk control tag is the link call relationship. In this way, the risk analysis method corresponding to the link call relationship can be used to determine the risk level of the changed content. For instance, if the changed content is a new interface call and belongs to a link-dependent call, the risk level corresponding to the changed content is determined to be high risk; if the changed content is a new interface call and does not belong to a link-dependent call, the risk level corresponding to the changed content is determined to be low risk.
[0085] For example, taking a change to a payment interface as an example, the corresponding risk control tag is "service function." Thus, the risk analysis methods corresponding to the service function can be used to determine the risk level of the changed content. For instance, if the changed content pertains to a marketing parameter change, the risk level is determined to be high risk; if the changed content does not pertain to a marketing parameter change, the risk level is determined to be low risk.
[0086] For example, taking the change as the addition of a new service link as an example, its corresponding risk control tag is "service link". In this way, the risk analysis method corresponding to the service link can be used to determine the risk level of the changed content. For example, if the changed content belongs to a new service link, the risk level corresponding to the changed content is determined to be high risk; if the changed content does not belong to a new service link, the risk level corresponding to the changed content is determined to be low risk.
[0087] After conducting a risk analysis on each change in the change information, the risk level corresponding to each change can be obtained.
[0088] Optionally, after obtaining the risk level corresponding to each change, risk information corresponding to the change information can be generated, which may include high-risk information.
[0089] Optionally, after obtaining the risk level corresponding to each change, risk information corresponding to the change information can be generated, which may include low-risk and high-risk information.
[0090] Ultimately, risk information can be presented to users in the form of a risk list, allowing users to take further action against high-risk service nodes based on the displayed risk list.
[0091] In this way, by combining the analysis methods corresponding to risk control tags, risks can be quickly identified, and potential problems can be discovered before or in the early stages of change implementation, thus preventing risks from spreading to the production environment.
[0092] The risk management method provided in one or more embodiments of this specification, based on service link topology, enables risk analysis to link upstream and downstream nodes, achieving penetrating analysis from "single-point change to full-link risk," and fully covering the cascading risks caused by changes. It identifies core service nodes based on preset screening indicators, avoiding the omission of key nodes due to subjective human judgment and improving the core change tracking coverage. By tracking core node changes through a unified change platform and combining risk control tags with corresponding analysis methods, risks can be quickly identified, allowing potential problems to be discovered before or in the early stages of change implementation, preventing risks from spreading to the production environment. Dedicated risk control tags are configured according to change type, with different risk control tags corresponding to differentiated risk analysis methods, avoiding a "one-size-fits-all" approach to assessment, improving the accuracy of risk analysis, and reducing the risk misjudgment rate.
[0093] It is understood that the above embodiments are merely examples, and modifications can be made to the above embodiments in actual implementation. Those skilled in the art will understand that any modifications to the above embodiments that do not require creative effort fall within the protection scope of one or more embodiments of this specification, and will not be described again in the embodiments.
[0094] Based on the same inventive concept, one or more embodiments of this specification also provide a risk management device. Since the principle of the risk management device in solving the problem is similar to that of the aforementioned risk management method, the implementation of the risk management device can refer to the implementation of the aforementioned risk management method, and the repeated parts will not be described again.
[0095] See Figure 3 , Figure 3 This is a structural block diagram of a risk management device provided for one or more embodiments of this specification. Figure 3 As shown, the risk management device 300 may include: a construction module 301, a determination module 302, a sending module 303, a receiving module 304, a configuration module 305, a first generation module 306, and a second generation module 307. Among them, The construction module 301 is used to construct at least one service scenario and the service link topology relationship corresponding to each service scenario, wherein the service link topology relationship includes at least one service link and the service link includes at least one service node; The determination module 302 is used to determine the core service nodes in the service link topology based on preset screening indicators; Sending module 303 is used to send instruction information to the unified change platform, the instruction information being used to instruct the core service node to perform change tracking; The receiving module 304 is used to receive change data sent by the unified change platform, the change data including the change content and change type corresponding to the change service node; Configuration module 305 is used to configure risk control tags corresponding to each of the change contents according to the change type; The first generation module 306 is used to generate change information corresponding to the change risk query request in response to receiving a change risk query request input by a user. The second generation module 307 is used to perform risk analysis on each change in the change information using the risk analysis method corresponding to the respective configured risk control tag, and generate risk information corresponding to the change information.
[0096] In one possible implementation, a service scenario includes at least one sub-service scenario, and the service link includes a core service link and branch service links; the service link topology corresponding to a sub-service scenario includes a core service link and at least one branch service link.
[0097] In one possible implementation, the preset screening criteria include at least one of the following: the amount of code corresponding to the service node, the frequency of changes, the unit traffic, and whether funds are involved.
[0098] In one possible implementation, the determining module 302 is specifically used to: determine the first core service node in the service link topology based on the value of the preset filtering index in the first time period; and update the first core service node in the service link topology to the second core service node based on the value of the preset filtering index in the second time period; wherein the second time period is the time period after the first time period.
[0099] In one possible implementation, the change type includes code change, configuration change, and storage change; the configuration module 305 is specifically used to: when the change content is a code change and / or configuration change, configure the risk control tags corresponding to the change content to include service scenarios and service functions; when the change content is a code change and / or storage change, configure the risk control tags corresponding to the change content to include service performance; when the change content is a code change, configure the risk control tags corresponding to the change content to include link call relationships and service links.
[0100] In one possible implementation, when the risk control label includes a service scenario, the risk analysis method includes: determining whether the change involves a change in the service scenario. If the change involves a change in the service scenario, the risk level of the change is determined to be high risk; if the change does not involve a change in the service scenario, the risk level of the change is determined to be low risk; and / or, When the risk control label includes service functions, the risk analysis method includes: determining whether the changed content involves changes to marketing parameters. If the changed content involves changes to marketing parameters, the risk level of the changed content is determined to be high risk; if the changed content does not involve changes to marketing parameters, the risk level of the changed content is determined to be low risk; and / or, When the risk control label includes service performance, the risk analysis method includes: determining whether the changed content involves an interface whose timeout exceeds the average value and which is a strongly dependent call. If the changed content involves an interface whose timeout exceeds the average value and which is a strongly dependent call, the risk level of the changed content is determined to be high risk; if the changed content does not involve an interface whose timeout exceeds the average value and which is not a strongly dependent call, the risk level of the changed content is determined to be low risk; and / or, When the risk control label includes a link call relationship, the risk analysis method includes: determining whether the changed content belongs to a new link call relationship. If the changed content belongs to a new link call relationship, the risk level of the changed content is determined to be high risk; if the changed content does not belong to a new link call relationship, the risk level of the changed content is determined to be low risk; and / or, When the risk control label includes a service link, the risk analysis method includes: determining whether the changed content belongs to a new service link. If the changed content belongs to a new service link, the risk level of the changed content is determined to be high risk; if the changed content does not belong to a new service link, the risk level of the changed content is determined to be low risk.
[0101] In one possible implementation, the change risk query request includes a query service scenario, a query service node, and a query time range, and the change information includes the change service node corresponding to the change risk query request, the change content corresponding to the change service node, and the change type.
[0102] See Figure 4 , Figure 4 This is a structural block diagram of an electronic device provided for one or more embodiments of this specification. Figure 4As shown, the electronic device 400 may include a processor 401 and a memory 402; the memory 402 may be coupled to the processor 401. It is worth noting that... Figure 4 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.
[0103] In one possible implementation, the functions of the risk management device 300 can be integrated into the processor 401. The processor 401 can be configured to perform the following operations: Construct at least one service scenario and the service link topology relationship corresponding to each service scenario, wherein the service link topology relationship includes at least one service link and the service link includes at least one service node; Based on preset screening criteria, the core service nodes in the service link topology are determined; Send instruction information to the unified change platform, the instruction information being used to instruct the core service node to track changes; Receive change data sent by the unified change platform, the change data including the change content and change type corresponding to the change service node; Configure risk control tags corresponding to each of the aforementioned change types; In response to receiving a change risk query request input by a user, change information corresponding to the change risk query request is generated; For each change in the change information, risk analysis is performed using the risk analysis method corresponding to the respective configured risk control tag, and risk information corresponding to the change information is generated.
[0104] In another possible implementation, the risk management device 300 can be configured separately from the processor 401. For example, the risk management device 300 can be configured as a chip connected to the processor 401, and risk management can be achieved through the control of the processor 401.
[0105] Furthermore, in some alternative implementations, the electronic device 400 may also include: a communication module, an input unit, an audio processor, a display, a power supply, etc. It is worth noting that the electronic device 400 is not necessarily required to include these components. Figure 4 All components shown; in addition, the electronic device 400 may also include Figure 4 For components not shown, please refer to existing technologies.
[0106] In some alternative implementations, processor 401, sometimes also referred to as controller or operation control, may include a microprocessor or other processor device and / or logic device, which receives input and controls the operation of various components of electronic device 400.
[0107] The memory 402 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned information related to the risk management device 300, and may also store programs for executing that information. The processor 401 may execute the program stored in the memory 402 to perform information storage or processing, etc.
[0108] An input unit can provide input to the processor 401. This input unit may be, for example, a button or touch input device. A power supply can be used to provide power to the electronic device 400. A display can be used to display images and text, etc. This display may be, for example, an LCD display, but is not limited to this.
[0109] Memory 402 can be a solid-state memory, such as read-only memory (ROM), random access memory (RAM), SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROM, etc. Memory 402 can also be some other type of device. Memory 402 includes buffer memory (sometimes referred to as a buffer). Memory 402 may include an application / function storage unit for storing application programs and function programs or processes for executing the operation of electronic device 400 via processor 401.
[0110] The memory 402 may also include a data storage unit for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit of the memory 402 may include various drivers for the computer device for communication functions and / or for performing other functions of the computer device (such as messaging applications, address book applications, etc.).
[0111] The communication module is a transmitter / receiver that sends and receives signals via an antenna. The communication module (transmitter / receiver) is coupled to the processor 401 to provide input signals and receive output signals, which can be the same as in a conventional mobile communication terminal.
[0112] Based on different communication technologies, multiple communication modules can be configured in the same computer device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module (transmitter / receiver) is also coupled to a speaker and microphone via an audio processor to provide audio output through the speaker and receive audio input from the microphone, thereby enabling typical telecommunications functions. The audio processor may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor is coupled to processor 401, enabling on-device recording via the microphone and on-device playback of stored sound via the speakers.
[0113] One or more embodiments of this specification also provide a computer-readable storage medium capable of implementing all steps of the risk management method in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the risk management method in the above embodiments. For example, when the processor executes the computer program, it implements the following steps: Construct at least one service scenario and the service link topology relationship corresponding to each service scenario, wherein the service link topology relationship includes at least one service link and the service link includes at least one service node; Based on preset screening criteria, the core service nodes in the service link topology are determined; Send instruction information to the unified change platform, the instruction information being used to instruct the core service node to track changes; Receive change data sent by the unified change platform, the change data including the change content and change type corresponding to the change service node; Configure risk control tags corresponding to each of the aforementioned change types; In response to receiving a change risk query request input by a user, change information corresponding to the change risk query request is generated; For each change in the change information, risk analysis is performed using the risk analysis method corresponding to the respective configured risk control tag, and risk information corresponding to the change information is generated.
[0114] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive labor. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual device or client product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).
[0115] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, apparatus (systems), or computer program products. Therefore, the embodiments of this specification can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, one or more embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0116] This specification describes one or more embodiments of a method, apparatus (system), and computer program product according to one or more embodiments of this specification with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0117] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0118] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0119] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and system embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0120] In this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, without necessarily requiring or implying any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Those skilled in the art will understand the specific meaning of the above terms in one or more embodiments of this specification, depending on the specific circumstances.
[0121] It should be noted that, unless otherwise specified, one or more embodiments and features thereof in this specification can be combined with each other. This specification is not limited to any single aspect, nor to any single embodiment, nor to any combination and / or substitution of such aspects and / or embodiments. Furthermore, each aspect and / or embodiment of one or more embodiments of this specification can be used alone or in combination with one or more other aspects and / or embodiments thereof.
[0122] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of one or more embodiments of this specification, and are not intended to limit them. Although one or more embodiments of this specification have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of one or more embodiments of this specification, and they should all be covered within the scope of the claims and the specification of one or more embodiments of this specification.
[0123] The foregoing description of one or more embodiments of this specification has been provided in conjunction with optional implementation methods. However, these embodiments are merely exemplary and serve only an illustrative purpose. Based on this, various substitutions and modifications can be made to one or more embodiments of this specification, all of which fall within the protection scope of one or more embodiments of this specification.
Claims
1. A risk management method, characterized in that, The method comprises: constructing at least one service scene and the service link topology relationship corresponding to each of the service scenes respectively, wherein the service link topology relationship comprises at least one service link, and the service link comprises at least one service node; determining a core service node in the service link topology relationship according to a preset screening index; sending indication information to a unified change platform, wherein the indication information is used to indicate change tracking of the core service node; receiving change data sent by the unified change platform, wherein the change data comprises change content and a change type corresponding to a changed service node; configuring a risk control label corresponding to each of the change contents according to the change type; generating change information corresponding to a change risk query request in response to receiving the change risk query request input by a user; performing risk analysis on each change content in the change information by using a risk analysis method corresponding to the risk control label configured for the change content, and generating risk information corresponding to the change information.
2. The method of claim 1, wherein, One of the service scenes comprises at least one sub-service scene, and the service link comprises a core service link and a branch service link. The service link topology relationship corresponding to one of the sub-service scenes comprises one core service link and at least one branch service link.
3. The method of claim 1, wherein, The preset screening index comprises at least one of the following: code amount, change frequency, unit flow, and whether it involves funds corresponding to the service node.
4. The method of claim 3, wherein, The determination of the core service node in the service link topology relationship according to the preset screening index comprises: determining a first core service node in the service link topology relationship according to the value of the preset screening index in a first time period; updating the first core service node in the service link topology relationship to a second core service node according to the value of the preset screening index in a second time period; wherein the second time period is a time period after the first time period.
5. The method of claim 1, wherein, The change type comprises code change, configuration change and storage change; and the configuration of the risk control label corresponding to each of the change contents according to the change type comprises: in the case that the change content belongs to code change and / or configuration change, the risk control label corresponding to the change content comprises service scene and service function; in the case that the change content belongs to code change and / or storage change, the risk control label corresponding to the change content comprises service performance; in the case that the change content belongs to code change, the risk control label corresponding to the change content comprises link calling relationship and service link.
6. The method of claim 5, wherein, in the case that the risk control label comprises service scene, the risk analysis method comprises: judging whether the change content involves service scene change, in the case that the change content involves service scene change, determining that the risk level of the change content belongs to high risk; in the case that the change content does not involve service scene change, determining that the risk level of the change content belongs to low risk; and / or, In a case where the risk control label comprises a service function, the risk analysis method comprises: judging whether the change content involves a marketing parameter change, in a case where the change content involves a marketing parameter change, determining that the risk level of the change content belongs to a high risk; in a case where the change content does not involve a marketing parameter change, determining that the risk level of the change content belongs to a low risk; and / or, In a case where the risk control label comprises a service performance, the risk analysis method comprises: judging whether the change content involves an interface with a timeout time exceeding an average value and the interface belongs to a strong dependent call, in a case where the change content involves an interface with a timeout time exceeding an average value and the interface belongs to a strong dependent call, determining that the risk level of the change content belongs to a high risk; in a case where the change content does not involve an interface with a timeout time exceeding an average value and the interface does not belong to a strong dependent call, determining that the risk level of the change content belongs to a low risk; and / or, In a case where the risk control label comprises a link call relationship, the risk analysis method comprises: judging whether the change content belongs to a newly added link call relationship, in a case where the change content belongs to a newly added link call relationship, determining that the risk level of the change content belongs to a high risk; in a case where the change content does not belong to a newly added link call relationship, determining that the risk level of the change content belongs to a low risk; and / or, In a case where the risk control label comprises a service link, the risk analysis method comprises: judging whether the change content belongs to a newly added service link, in a case where the change content belongs to a newly added service link, determining that the risk level of the change content belongs to a high risk; in a case where the change content does not belong to a newly added service link, determining that the risk level of the change content belongs to a low risk.
7. The method of claim 1, wherein, The change risk query request comprises a query service scene, a query service node, and a query time range, and the change information comprises a change service node corresponding to the change risk query request, change content corresponding to the change service node, and a change type.
8. A risk management device, characterized by, The device comprises: a construction module configured to construct at least one service scene and a service link topology relationship corresponding to each of the service scenes, wherein the service link topology relationship comprises at least one service link, and the service link comprises at least one service node; a determination module configured to determine a core service node in the service link topology relationship according to a preset screening index; a sending module configured to send indication information to a unified change platform, the indication information being used to indicate that the core service node is tracked for change; a receiving module configured to receive change data sent by the unified change platform, the change data comprising change content corresponding to a change service node and a change type; a configuration module configured to configure a risk control label corresponding to each of the change contents according to the change type; a first generation module configured to generate change information corresponding to the change risk query request in response to receiving a change risk query request input by a user. The second generation module is configured to perform risk analysis on each change content in the change information by using a risk analysis method corresponding to a risk control label configured for the change content, and generate risk information corresponding to the change information.
9. The apparatus of claim 8, wherein, One of the service scenarios includes at least one sub-service scenario, and the service link includes a core service link and a branch service link. The service link topology relationship corresponding to one of the sub-service scenarios includes one core service link and at least one branch service link.
10. The apparatus of claim 8, wherein, The preset screening index includes at least one of the following: code amount, change frequency, unit traffic, and whether it involves funds.
11. The apparatus of claim 10, wherein, The determination module is specifically configured to: According to the value of the preset screening index in the first time period, determine a first core service node in the service link topology relationship; and according to the value of the preset screening index in the second time period, update the first core service node in the service link topology relationship to a second core service node; wherein the second time period is a time period after the first time period.
12. The apparatus of claim 10, wherein, The change type includes code change, configuration change, and storage change; and the configuration module is specifically configured to: In the case that the change content is code change and / or configuration change, the risk control label corresponding to the change content includes service scenarios and service functions; in the case that the change content is code change and / or storage change, the risk control label corresponding to the change content includes service performance; and in the case that the change content is code change, the risk control label corresponding to the change content includes link calling relationship and service link.
13. The apparatus of claim 12, wherein, In the case that the risk control label includes service scenarios, the risk analysis method includes: judging whether the change content involves service scenario change; in the case that the change content involves service scenario change, determining that the risk level of the change content belongs to high risk; and in the case that the change content does not involve service scenario change, determining that the risk level of the change content belongs to low risk; and / or, In the case that the risk control label includes service functions, the risk analysis method includes: judging whether the change content involves marketing parameter change; in the case that the change content involves marketing parameter change, determining that the risk level of the change content belongs to high risk; and in the case that the change content does not involve marketing parameter change, determining that the risk level of the change content belongs to low risk; and / or, In the case that the risk control label includes service performance, the risk analysis method includes: judging whether the change content involves an interface with timeout time exceeding the average value and the interface belongs to strong dependent calling; in the case that the change content involves an interface with timeout time exceeding the average value and the interface belongs to strong dependent calling, determining that the risk level of the change content belongs to high risk; and in the case that the change content does not involve an interface with timeout time exceeding the average value and the interface does not belong to strong dependent calling, determining that the risk level of the change content belongs to low risk; and / or, In a case where the risk control label comprises a link calling relationship, the risk analysis method comprises: judging whether the change content belongs to a newly added link calling relationship, in a case where the change content belongs to the newly added link calling relationship, determining that the risk level of the change content belongs to high risk; in a case where the change content does not belong to the newly added link calling relationship, determining that the risk level of the change content belongs to low risk; and / or, In a case where the risk control label comprises a service link, the risk analysis method comprises: judging whether the change content belongs to a newly added service link, in a case where the change content belongs to the newly added service link, determining that the risk level of the change content belongs to high risk; in a case where the change content does not belong to the newly added service link, determining that the risk level of the change content belongs to low risk.
14. The apparatus of claim 12, wherein, The change risk query request comprises a query service scenario, a query service node and a query time range, and the change information comprises a change service node corresponding to the change risk query request, change content corresponding to the change service node and a change type.
15. An electronic device, comprising: The electronic device comprises: a memory for storing a computer program product; a processor for executing the computer program product stored in the memory, and when the computer program product is executed, the method in any one of claims 1-7 is implemented.
16. A computer-readable storage medium, characterized in that, The computer program instructions stored on the computer readable storage medium are executed to implement the method in any one of claims 1-7.