Change positioning method and device, equipment and storage medium

Abstract

The invention provides a change positioning method and device, equipment and a storage medium, and relates to the technical field of data analysis, in particular to the technical field of knowledge maps, change management and fault positioning. The specific implementation scheme is as follows: acquiring original change data generated by a target system within a preset time period; performing semantic analysis on the original change data to obtain a change entity associated with the original change data and a business index corresponding to the change entity; based on a preset distinction degree screening rule, screening out a target changed entity from the changed entities; constructing a change domain knowledge graph according to the target change entity; and based on the received abnormal time information and abnormal service clues, executing retrieval and matching operations in the change domain knowledge graph to determine a target change event. According to the technical scheme disclosed by the invention, the change event can be accurately retrieved and matched by using the abnormal service clues, and the efficiency and accuracy of fault root cause positioning in a complex system environment are improved.

Description

Technical Field

[0001] This disclosure relates to the field of data analysis technology, and in particular to the fields of knowledge graphs, change management, and fault location technology. Background Technology

[0002] With the rapid development of internet technology, the architecture of large-scale distributed systems (such as commercial advertising retrieval systems and e-commerce transaction systems) is becoming increasingly complex. To meet the needs of rapid business development, these systems typically adopt continuous integration and continuous deployment (CI / CD) models, resulting in extremely high iteration frequencies. In actual production environments, tens of thousands of change events may occur daily, covering various types such as code releases, configuration modifications, data (such as thesaurus) updates, and experimental traffic switching. Summary of the Invention

[0003] This disclosure provides a method, apparatus, device, and storage medium for changing the location.

[0004] According to one aspect of this disclosure, a method for changing location is provided, comprising: Obtain the original change data generated by the target system within a preset time period; Semantic parsing is performed on the original change data to obtain the change entities associated with the original change data and the corresponding business metrics of the change entities; Based on preset discrimination filtering rules, target change entities are filtered out from change entities; A change domain knowledge graph is constructed based on the target change entity, wherein the change domain knowledge graph contains an inverted index pointing from business metrics to the target change entity; Based on the received abnormal time information and abnormal business clues, a retrieval and matching operation is performed in the change domain knowledge graph to identify the target change event.

[0005] According to another aspect of this disclosure, a positioning change device is provided, the device comprising: The acquisition module is used to acquire the original change data generated by the target system within a preset time period. The parsing module is used to perform semantic parsing on the original change data to obtain the change entities associated with the original change data and the corresponding business metrics of the change entities; The filtering module is used to filter out target change entities from change entities based on preset discrimination filtering rules; The construction module is used to build a change domain knowledge graph based on the target change entity. The change domain knowledge graph contains an inverted index pointing from business metrics to the target change entity. The determination module is used to perform retrieval and matching operations in the change domain knowledge graph based on the received abnormal time information and abnormal business clues in order to determine the target change event.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and The memory is communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described in the present disclosure.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of this disclosure.

[0009] The technical solution disclosed herein enables accurate retrieval and matching of change events using abnormal business clues, thereby improving the efficiency and accuracy of fault root cause localization in complex system environments.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating a method for changing a location according to an embodiment of the present disclosure; Figure 2 This is a schematic diagram of the filtering logic according to an embodiment of the present disclosure; Figure 3 This is a schematic diagram of the module change knowledge mining process provided according to an embodiment of the present disclosure; Figure 4 This is an overall architecture diagram of a change positioning method provided according to an embodiment of the present disclosure; Figure 5 This is a schematic diagram of the structure of a positioning device according to an embodiment of the present disclosure; Figure 6 This is a block diagram of an electronic device used to implement the change positioning method of the embodiments of this disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] In related technologies, when an online system malfunctions or monitoring metrics show abnormalities (such as declining revenue or abnormal traffic), quickly locating the root cause change event is crucial for service recovery. Currently, existing change localization technologies mainly rely on time attributes for initial screening. That is, after a failure occurs, operations personnel pull a list of all change events that occurred within the abnormal time window (e.g., a period before the failure) and then manually check them one by one based on experience. However, in environments with high-frequency changes, the candidate change list filtered solely by time windows is often still very long (potentially hundreds of items). Manual investigation is not only time-consuming and labor-intensive, but also prone to errors due to fatigue or lack of experience, severely impacting the time to repair (MTTR).

[0014] To aid in localization, some existing technologies have begun to incorporate knowledge graphs or tagging systems to manage the relationship between changes and their scope of impact. For example, recording which project a change belongs to and which general business metrics it might affect (e.g., "affects revenue," "affects click-through rate"). However, existing knowledge construction methods often lack effective measures for knowledge differentiation. As the volume of knowledge grows, a large number of change entities may be labeled with the same broad tags (e.g., thousands of changes are tagged as "affects revenue"). This lack of specificity in the associated information fails to provide effective filtering in actual troubleshooting, resulting in search results still containing a large amount of noise, making it difficult to accurately pinpoint a few suspicious targets using specific business clues (e.g., specific traffic IDs or channel IDs).

[0015] Furthermore, for data-related changes (such as updates to configuration files or thesaurus files), common change management tools typically only record file-level changes (e.g., recording "a file was modified at a certain time"). Existing technologies often lack the ability to deeply analyze the specific business logic modified within the file. Especially when dealing with binary data structures or complex text formats (such as serialized data based on Proto definitions), general tools struggle to automatically parse out the fine-grained business entities involved in the changes (e.g., which specific ad slot or industry tag had its parameters adjusted). This results in the system being unable to automatically establish a direct mapping between the changed content and specific business alarm indicators when facing failures caused by data changes, still heavily relying on manual reading of code or configuration file differences (Diff) to determine the impact.

[0016] To at least partially address one or more of the aforementioned problems and other potential issues, embodiments of this disclosure provide a change location method. By utilizing the technical solutions of embodiments of this disclosure, change events can be accurately retrieved and matched using abnormal business clues, thereby improving the efficiency and accuracy of fault root cause location in complex system environments.

[0017] This embodiment provides a change location method for quickly identifying change events that cause online problems in large-scale distributed systems or high-frequency iterative environments. This method can be applied to servers, cloud platforms, or electronic devices with computing capabilities. Figure 1 This is a flowchart illustrating a method for changing a location according to an embodiment of this disclosure, as shown below. Figure 1 As shown, the method includes the following steps: S110. Obtain the original change data generated by the target system within a preset time period.

[0018] In this embodiment, the target system can be any software or hardware system, such as a commercial advertising retrieval system, an e-commerce transaction system, or a large-scale microservice architecture. Original change data refers to all modification records generated during system operation, including but not limited to code releases, configuration file modifications, data table (such as a thesaurus) updates, and experimental traffic switching. The preset time period can be a window of time before and after the fault occurs, such as the interval from 2 hours before the fault occurs to the time of the fault.

[0019] In a specific example, the system can connect to CI / CD (Continuous Integration / Continuous Deployment) pipelines, configuration centers, data publishing platforms, etc., and automatically pull all change records generated within a preset time period.

[0020] S120. Perform semantic parsing on the original change data to obtain the change entities associated with the original change data and the business metrics corresponding to the change entities.

[0021] A changed entity can be understood as the physical object that has undergone a change, such as a specific module name, file name, configuration item key, or dictionary file path. A business metric can be understood as a tag or identifier with business meaning, such as a traffic ID (cmatch), ad placement ID (rank), channel ID, or industry tag. Semantic parsing refers to extracting key information with business semantics from unstructured or semi-structured changed content using specific rules or algorithms.

[0022] In a specific example, for a change record of a thesaurus file, the system parses out that the content updated in this file (the changed entity) involves "Traffic ID: 713" and "Industry: Games" (business metrics).

[0023] S130. Based on the preset discrimination filtering rules, select the target change entity from the change entities.

[0024] Discrimination filtering rules can be understood as a logical judgment standard used to measure whether business metrics can accurately pinpoint a few changed entities. Target changed entities refer to those changed entities that can be uniquely identified or locked with a high probability by a small number of business metrics. The purpose of this step is to filter out entities with overly generalized relationships and retain high-discrimination entities with significant screening value.

[0025] In a specific example, the system found that the metric "Traffic ID: 713" only corresponds to the current word list file change and has high distinguishability, so it identified that word list file as the target change entity. Another metric, "Affects Revenue," is associated with thousands of modules and has low distinguishability, so it was not used as an indexing basis.

[0026] S140. Construct a change domain knowledge graph based on the target change entity. The change domain knowledge graph contains an inverted index pointing from business metrics to the target change entity.

[0027] A change domain knowledge graph is a structured knowledge base used to store change entities, business metrics, and the relationships between them. An inverted index is a data structure that allows for quick lookup of "keys" (i.e., change entities) using "values" (i.e., business metrics).

[0028] This step involves persistently storing and structurally organizing the entities selected above and the established index relationships. The changed entity nodes, business indicator nodes, and inverted index relationships generated in S130 are written into a graph database or relational database to form a queryable knowledge base.

[0029] In the specific example, the constructed graph stores an index record: Key="Traffic ID: 713" -> Value="Vocabulary File A_Version V1.2". When querying "713" later, it can directly locate "Vocabulary File A".

[0030] S150. Based on the received abnormal time information and abnormal business clues, perform retrieval and matching operations in the change domain knowledge graph to determine the target change event.

[0031] Anomaly time information refers to the specific point in time when operations and maintenance personnel perceive system alarms, faults, or abnormal operational metrics. Anomaly business clues refer to characteristic information discovered during fault investigation, such as specific IDs or industries appearing in error logs. Target change events are those ultimately determined to be the root cause of the fault or anomaly.

[0032] In a specific example, the user inputs the abnormal time "11:30" and the clue "Traffic ID: 713". The system searches for "Traffic ID: 713" in the graph and directly finds "vocabulary file A". Based on the time consistency, the system identifies the "launch event of vocabulary file A" as the target change event.

[0033] According to the solution of this disclosure, by performing deep semantic analysis on the change data and constructing a knowledge graph based on a high-discrimination index inverted index, it is possible to directly reverse look up and accurately lock a very small number (e.g., less than 10) of suspicious change entities using specific business clues (such as specific IDs). This significantly solves the problems of low efficiency and poor accuracy in change location under high-frequency iteration environment and greatly shortens the fault recovery time.

[0034] In one possible implementation, S130 filters out target change entities from change entities based on preset discrimination filtering rules, and further includes the following steps: S131. Generate a combination of business metrics.

[0035] In this embodiment of the disclosure, the indicator combination can be understood as a query condition formed by arranging and combining one or more business indicators.

[0036] In one example, Figure 2 This demonstrates the mapping from multi-source changes (modules, thesaurus, experiments) to business metrics. For example... Figure 2As shown, the system first aggregates multi-source change data, including module changes, thesaurus changes, and Edison experiment data (which can be understood as an experiment management platform or traffic distribution control system). It then extracts relevant business metrics from this multi-source change data. For example, it extracts Metric-cmd (a business entity metric typically associated with module changes (code / program changes)) from module changes and Metric-pid (a business entity metric typically associated with thesaurus changes (data changes)) from thesaurus changes. Based on this, the system combines these individual metrics to generate candidate key values ​​for subsequent analysis.

[0037] For example, a certain entity undergoing change is associated with the Metric-pid metric (region: Beijing) and the Metric-cmd metric (business: food delivery). The system generates the following metric combinations: [A], [B], and [A+B].

[0038] S132. Count the number of change entities associated with each combination of indicators.

[0039] Coverage refers to the number of entities in the full list of changed entities that simultaneously possess all the features of the given metric combination. The system searches the full physical entity database and calculates how many physical entities each generated metric combination can match. This value reflects the "discrimination" capability of the metric combination. For example, it counts how many thesaurus files the metric combination "cmatch#719" is associated with in the current system.

[0040] In specific examples, statistics show that there are 5 entities that contain only [A]; 100 entities that contain only [B]; and 2 entities that contain [A+B].

[0041] S133. In response to the coverage quantity meeting the preset convergence condition, the change entity associated with the index combination is determined as the target change entity.

[0042] Convergence criteria refer to the threshold standards used to determine whether a combination of indicators has sufficient discriminative power.

[0043] For example, in such Figure 2 The filtering process shown in the diagram for constructing a high-discrimination inverted index for entities using single / dual / three-dimensional indicator analysis employs a funnel-shaped filtering logic: First, the coverage quantity of a single indicator combination is determined. If the convergence condition is met (e.g., number of associated entities ≤ 10), it is directly identified as a high-discrimination entity. If not, the coverage quantity of a dual indicator combination is further determined. If still not met, the three-indicator combination is then evaluated. Only when the coverage quantity ultimately falls within a preset low range (e.g., less than 10) will the entity be confirmed as a high-discrimination physical entity.

[0044] In the specific example, the preset convergence condition is "number of associated entities <= 10". Therefore, combination [A] (5 entities) and combination [A+B] (2 entities) meet the condition, and their corresponding entities are marked as target change entities. Combination [B] (100 entities) does not meet the condition and is considered a low-discrimination index combination.

[0045] S134. Establish an inverted index relationship that points from the combination of indicators to the target change entity.

[0046] For confirmed high-discrimination entities, the system constructs a mapping relationship of "Metric combination -> Changed entity," generating index key-value pairs at the logical level. This establishes the logical path for tracing physical entities back from business leads, preparing the data for subsequent formal inclusion in the knowledge graph. This ensures that in the event of a failure, these specific entities can be quickly retrieved through business leads.

[0047] In a specific example, the following indexes are created: Index_A -> [Entity 1, Entity 2...Entity 5]; Index_AB -> [Entity 1, Entity 2]. This way, when a fault occurs, using index A or A+B can quickly narrow down the scope, allowing for rapid reverse lookup of these specific entities through business leads.

[0048] According to the solution of this disclosure embodiment, by introducing statistics on the number of coverages and judgment of convergence conditions, the system effectively filters out those "inefficient indicators" (such as general configurations associated with thousands of modules) that have business meaning but are too broad in their orientation, ensuring that the final inverted index only contains those highly distinguishable clues with good positioning capabilities, thereby solving the technical problem of difficulty in extracting effective positioning clues from massive change data.

[0049] In one possible implementation, the preset convergence condition is that the number of coverages is less than or equal to a preset discrimination threshold.

[0050] In this embodiment of the disclosure, the discrimination threshold is an empirical value that represents the maximum acceptable range for manual screening.

[0051] In this specific example, the threshold is set to 10. This means that the system only retains indicator combinations that can narrow down the suspects to 10 or fewer. If an indicator combination is associated with more than 11 entities, the system will consider the clue insufficiently discriminative and will either not index it or reduce its weight.

[0052] According to the solution of this disclosure, the convergence condition is specified as a quantity threshold (e.g., 10), which directly aligns with the cognitive load limit of maintenance personnel. This ensures that the result list output by the positioning tool is always within an easily distinguishable range, avoiding the awkward situation where the tool outputs a large number of results, which in turn increases the cost of manual screening.

[0053] In one possible implementation, step S131 generates a combination of business metrics, including the following steps: S1311, Traverse all business metrics corresponding to the changed entity.

[0054] The system scans each physical entity (such as a modified module or vocabulary) to obtain all the original business tags it carries, such as traffic ID, channel ID, and experimental bucket number.

[0055] In a specific example, the system reads a configuration change entity that affects three metrics: {Data Center A, Module B, and Interface C}.

[0056] S1312. Generate candidate indicator combinations containing a single business indicator, two business indicators, and three business indicators, respectively.

[0057] Candidate indicator combinations refer to combinations generated through different dimensions. This step prevents combination explosion by limiting the dimensions of the combinations (1 to 3 dimensions) while covering the most common investigation scenarios (usually 1-3 clues).

[0058] In specific examples, single-indicator combinations {Data Center A}, {Module B}, etc. are generated; dual-indicator combinations {Data Center A + Module B}, etc. are generated; and triple-indicator combinations {Data Center A + Module B + Interface C} are generated.

[0059] like Figure 2 As shown, the system does not generate all combinations at once, but rather generates them according to the hierarchical order of the discrimination analysis: Single-Metric Analysis Phase: Initially, only combinations containing a single business metric are generated. If this combination narrows down the entity range to within a threshold (e.g., 10), generation of that branch stops.

[0060] Dual-Metric Combination Analysis Phase: For cases where a single metric cannot cover all entities (i.e., too many related entities), the system pairs the metrics of the uncovered entities together to generate dual-metric combinations. For example, combining "Traffic ID" with "Channel ID".

[0061] Three-Metric Combination Analysis Stage: For complex entities that cannot be covered by dual metrics, the system further adds dimensions to generate three-metric combinations. Through this cascaded generation method, the system dynamically constructs candidate combinations with different dimensions.

[0062] S1313, Use candidate indicator combinations as indicator combinations.

[0063] The system will take the single-dimensional, two-dimensional, or three-dimensional combinations generated in the above process and verified to be valid (i.e., meeting the discrimination requirements) and finally determine them as the formal index combinations to be used to build the index.

[0064] In the specific example, the seven combinations generated above are all used as input objects for subsequent coverage quantity statistics.

[0065] According to the scheme of this disclosure embodiment, a progressively increasing combination generation strategy is adopted. Simple single indicators are used first for positioning; only when the discrimination of a single indicator is insufficient is the discrimination improved by adding dimensions (two / three indicators). This avoids the waste of computational resources caused by indiscriminate full permutation combinations, while ensuring that effective positioning clues can be generated even for changing entities in complex scenarios (such as general components that require multiple conditions to be uniquely determined), achieving an optimal balance between computational efficiency and positioning accuracy.

[0066] In one possible implementation, S120 performs semantic parsing on the original change data to extract the change entities associated with the original change data and the corresponding business metrics, including the following steps: S121. Identify the change source type of the original change data.

[0067] The change source type refers to the manner in which the change occurred or the technical field to which it belongs. This could be code release, configuration modification, data production, or experimental platform operation, etc. The change source type is used to distinguish the technical attributes of the change; different types of changes require different parsers. like Figure 3 As shown, it can be integrated into the program's order placement process to capture Prod change events within the associated time window. Based on the content of the change, it can identify whether it is a Prod change (module release) or an Edison experiment (Launch configuration) change.

[0068] In a specific example, the system identifies one change as "Data Change" (data / vocabulary) and another as "Code Change" (code) based on information such as file extension and source system identifier.

[0069] S122. Based on the change source type, call the corresponding parsing rule from the preset parsing strategy library.

[0070] The parsing strategy library stores the parsing logic for different types of changes. For example, for Prod changes, the system further distinguishes between "NoDiff Push Full" (undifferentiated release) and "Diff Push Full" (differentiated release). For experimental changes, the "Launch Large Model Semantic Analysis" strategy is invoked.

[0071] In a specific example, for "Data change", the system calls the Proto parser; for "Code change", the system calls the white-box code scanner.

[0072] S123. Use parsing rules to extract the content of the original change data in a structured manner to obtain business indicators.

[0073] For module changes, the offline CI information can be communicated by calling the ff platform API, and the offline CI team can be coordinated to obtain build information.

[0074] For experimental changes, a large model can be used to perform semantic analysis on the Launch configuration to interpret its business meaning.

[0075] Finally, the business impact analysis module maps the above changes to specific observation indicators (such as cmatch, QPS, etc.).

[0076] In one specific example, the Proto parser is used to read the contents of a data file and extract the business meaning corresponding to the modified columns.

[0077] Related technologies typically treat all changes as homogeneous text for simple recording, ignoring the internal structural differences between different types of changes (code, data, configuration). According to the solution of this disclosure, by identifying the source type of the change and invoking appropriate parsing rules, a deeper understanding of the internal logic of different types of changes can be achieved, thereby extracting more accurate and in-depth business metrics. By connecting offline CI information with the online release process and introducing a large model to assist in parsing experimental semantics, the system can comprehensively cover the entire chain of information from code submission to deployment, solving the problem of information gap between the development and production environments in traditional positioning methods.

[0078] In one possible implementation, S123 uses parsing rules to perform structured extraction of the content of the original change data to obtain business metrics, including the following steps: S1231. When the change source type is data change, perform field matching on the differences in the data change based on the metadata description information in the data structure definition file corresponding to the data change.

[0079] Data structure definition files can be understood as metadata files that describe the format and meaning of data, such as Proto (Protocol Buffers) files, schema files, etc. Data changes are usually binary or text files (such as dictionaries), whose meaning is difficult to understand by direct reading.

[0080] In this specific example, the modified file is a word list file named filter_dict.txt. The system loads the filter_dict.proto file associated with this word list during registration. The proto file defines: the first column is ID, and the second column is cmatch (traffic ID). The system compares the txt files before and after the change and finds that the data in the second column has changed.

[0081] S1232. Identify the meaning of fields that have changed in the differences.

[0082] In the specific example, according to the definition in the Proto file, the system recognizes that the change in the second column means that "cmatch" (traffic) has changed.

[0083] S1233. Extract the specific numerical values ​​pointed to by the meaning of the field as business indicators.

[0084] In the specific example, the system extracts the specific values ​​"713" and "710" from the changes in column 2. The final generated business metrics are "cmatch: 713" and "cmatch: 710".

[0085] Related technologies often only record changes to data files such as dictionaries as "file A has changed," without being able to identify which specific business object was affected. According to the solution of this disclosure, by combining a data structure definition file (such as Proto) with deep analysis of the Diff content of data changes, the specific business ID (such as traffic ID) is extracted, achieving a leap from the file level to the content semantic level, greatly improving the granularity of change location.

[0086] In one possible implementation, such as Figure 3 As shown, when the change source type is code change or configuration change (i.e., module change), S123 uses parsing rules to extract the content of the original change data in a structured manner, including the following steps: S1241. When the source of change is code change or configuration change, use white-box parsing rules to scan for changes in code files or configuration files.

[0087] White-box parsing rules can be understood as static analysis rules based on code syntax trees (ASTs) or regular expressions, used to identify specific patterns in code or configuration.

[0088] The system performs in-depth CI content diff analysis on the changed entities. This includes not only differences in lines of code, but also changes in configuration files.

[0089] In a specific example, the system scans the diff of a Java code file or scans the changed parts of a YAML configuration file.

[0090] S1242. Identify and extract key-value pair information contained in the change differences.

[0091] In this step, the system identifies the following key elements from the diff content: Change Entity: Specifically, which files or modules were modified.

[0092] Dynamic / Static Switches: Identify new or modified feature flags in the code.

[0093] Plugin functions: Identify the modified plugin logic or function entry points.

[0094] At the same time, by using switch / plugin matching technology, these technical elements are associated with offline CI information to confirm their corresponding business function points.

[0095] S1243. Map key-value pairs to business metrics.

[0096] The business impact analysis module transforms identified technical details such as switches and plug-ins into specific observation indicators (e.g., "affected the recall rate of the advertising retrieval module").

[0097] According to the solution of this disclosure, by conducting in-depth Diff analysis of CI content and combining it with precise matching of switches / plugins, the system can transform obscure code changes into visualized business impact indicators. This enables operations and maintenance personnel to not only know "the code has changed" but also "which function switch has changed" during fault localization, greatly improving the accuracy and interpretability of root cause localization.

[0098] In one possible implementation, S123 uses parsing rules to perform structured extraction of the content of the original change data to obtain business metrics, including the following steps: S1251. When the change source type is experimental change, query the database of the experimental management system for the selected traffic tags and trigger branch information of the experimental change.

[0099] Experiment management systems (such as the Edison platform) are typically used for small-scale experiments or A / B testing.

[0100] In a specific example, the system detects an experiment publishing operation, then queries the experiment database to obtain the detailed configuration corresponding to the experiment ID.

[0101] S1252. Determine the traffic tags and trigger branch information as business metrics.

[0102] In the specific example, the query results showed that the experiment selected the traffic with "cmatch=545" and triggered "algorithm branch B". The system identified "cmatch: 545" and "trigger: branch B" as the business metrics for this change.

[0103] According to the solution of this disclosure embodiment, experimental changes are included in the positioning range, and the traffic selection logic behind them is analyzed, which solves the problem that traditional positioning tools often ignore "dynamic switches" or "experimental flow switching" and achieves full coverage of all change types.

[0104] In one possible implementation, S150 performs a retrieval and matching operation in the change domain knowledge graph based on the received abnormal time information and abnormal business clues to determine the target change event, including the following steps: S151. Delineate a time window based on abnormal time information and retrieve a set of candidate change events within the time window.

[0105] In a specific example, the user reported that the anomaly occurred at 10:00. The system automatically defines a two-hour window (08:00-12:00) before and after the anomaly and retrieves all 100 change events that occurred within that time period from the database as a candidate set.

[0106] S152. Calculate the time difference between the deployment time and the abnormal time information of each change event in the candidate change event set, and calculate the time matching score based on the time difference.

[0107] The time matching score reflects the correlation between the change time and the failure time. Generally, the closer the change is to the failure time, the more suspicious it is.

[0108] In the specific example, change A occurred at 09:59, one minute before the abnormal time of 10:00. Change B occurred at 08:00, 120 minutes before the abnormal time. The system sets an initial score of 100, deducting 0.1 points for every second of difference. Change A scores higher, while change B scores lower (or even negative).

[0109] S153. Use abnormal business clues to search in the knowledge graph of the change domain. If the change event in the candidate change event set matches the search result, assign a matching weight score to the clue.

[0110] The lead matching weight score is an additional weight applied to change events that match business characteristics.

[0111] In the specific example, the user provided the clue "cmatch: 545". The system searched for this indicator in the graph and found that change A was associated with "cmatch: 545". Therefore, the system awarded change A an additional +5 points (preset weight score). Change B was not matched and no points were awarded.

[0112] S154. Based on the time matching score and the clue matching weight score, sort the candidate change event set and determine the change event with the highest ranking as the target change event.

[0113] In the specific example, after comprehensive calculation, change A ranks first in total score. The system displays change A to the user as the most suspicious target change event.

[0114] According to the scheme of this disclosure embodiment, a hybrid sorting algorithm combining "time attribute" and "knowledge matching" is adopted. The time attribute ensures basic causal logic, while knowledge matching utilizes highly discriminative business clues for precise matching. This combination effectively solves the problems of excessively long lists when relying solely on time filtering and the ease of missing detections when relying solely on keyword search, placing the most likely root causes first.

[0115] In one possible implementation, a normalization process is introduced based on step S154. The method further includes the following steps: S1541. After calculating the time matching score and the clue matching weight score, calculate the sum of the two to obtain the initial total score.

[0116] In the specific example, the time score for changing A is 90 points, the clue score is 5 points, and the initial total score is 95 points.

[0117] S1542, Obtain the highest initial total score in the candidate change event set.

[0118] In the specific example, among all candidate events, change A has the highest score of 95.

[0119] S1543. Based on the sum of the highest initial total score and the preset buffer value, normalize the initial total score of each change event to obtain the final ranking score.

[0120] A preset buffer value (e.g., 5 points) is used to prevent a 100% match rate, so as not to mislead users into thinking that there is absolute certainty.

[0121] In the specific example, the normalized baseline = highest score 95 + buffer value 5 = 100. The final score for change A = 95 / 100 = 95%. The final score for change B could be 10 / 100 = 10%.

[0122] According to the solution of this disclosure, by introducing buffer value normalization processing, the absolute score is converted into a relative confidence percentage, and the display of absolute results such as 100% is artificially avoided. This is more scientific and rigorous in terms of user interaction experience, prompting users that the result is based on a high-probability recommendation of the algorithm rather than absolute facts, guiding users to make final confirmation, and reducing the risk of being misled.

[0123] In one possible implementation, the method further includes the following steps: S161. In response to the completion of the change domain knowledge graph construction, obtain historical abnormal business clues from the historical fault attribution report.

[0124] Historical failure attribution reports are records of failures that actually occurred in the past and their confirmed causes.

[0125] In a specific example, the system reads a fault review report from the past month, which records a fault investigation clue as "Industry: Healthcare".

[0126] S162. Verify whether the historical abnormal business clues can be retrieved in the change domain knowledge graph to find the corresponding historical fault change entity.

[0127] In a specific example, the system attempts to search the graph using "Industry: Healthcare" to see if it can find the changed entity that caused the failure at that time.

[0128] S163. Based on the verification results, calibrate and update the discrimination screening rules.

[0129] In a specific example, if the "Industry: Healthcare" category is found to be associated with too many entities, making it impossible to accurately locate the faulty entity if and only if, it indicates that the discrimination of this indicator is insufficient. The system may adjust the discrimination threshold or mark the "Industry" category as a low-weight indicator to optimize the subsequent graph construction and filtering logic.

[0130] According to the scheme of this disclosure embodiment, a post-evaluation and feedback mechanism based on historical data is established. By continuously using real historical fault data to verify and calibrate the definition and screening rules of "discrimination", the knowledge graph construction strategy can evolve with the development of business, ensuring the positioning accuracy under long-term operation.

[0131] Figure 4 This is an overall architecture diagram of a change location method provided according to an embodiment of this disclosure. The following is a specific embodiment of this technical solution. This embodiment describes in detail the entire process from data extraction and knowledge graph construction in the CI / CD process to the final realization of change location, following a bottom-up logical order (from data mining to final location). As shown in the figure, the method specifically includes the following steps: S401, Perform CICD process integration and multi-dimensional knowledge mining.

[0132] The system first acquires raw data from the very beginning of the software development lifecycle. Specifically, it integrates data from stages such as CR (Code Review), CI (Continuous Integration), and RB (Release Branch), as well as data from requirement documents and data production stages. After acquiring the data, the system performs multi-dimensional knowledge mining: Code and configuration mining: Utilizing white-box analysis techniques, specific module changes (including modifications to binary files (bin) and configuration files (conf)) are identified from the code and configuration files. Simultaneously, by integrating CI / CD information, code changes are linked to specific release pipelines (prodCI).

[0133] Semantic mining of requirements: For requirement documents, leverage the requirement understanding capabilities of large models to analyze the semantics of the requirement text and associate it with subsequent experimental changes (such as experimental launch configuration).

[0134] Data content mining: For the data production stage, specific data changes are identified through production rule proto parsing and data change content mining (including specific diff row parsing). Through the above steps, the system structures the underlying development and maintenance actions into three basic data categories: module changes, experiment changes, and data changes.

[0135] S402, Construct a knowledge graph for the change domain.

[0136] Based on the fundamental data mined by S401, the system constructs a hierarchical domain knowledge graph. This graph defines the propagation path from change to metrics: First, the change events identified in S401 (such as a code release or configuration modification) are mapped to specific physical entities (such as specific servers, files, or database tables).

[0137] At the same time, by combining the configuration library (configuration / RB) and project information, the project to which the change belongs is determined.

[0138] Next, the association between physical entities and business entities is established. For example, a certain configuration file corresponds to the business entity "ad retrieval".

[0139] Finally, the business entities are linked to monitoring metrics (such as QPS and latency) and ultimate alarm metrics (such as revenue decline and abnormal success rate). This step forms a complete knowledge chain of "change event -> physical entity -> business entity -> monitoring metric -> alarm metric".

[0140] S403. Capture alarm events and perform feature analysis.

[0141] When an anomaly occurs in the online system, the change location module first receives the alarm event. The system extracts the alarm time and alarm curve (time series data) of the alarm event and performs in-depth analysis in the following three dimensions: Data center characteristic analysis: Analyze whether the alarms have a regional or data center clustering (e.g., whether only a certain data center reports an error).

[0142] Inflection point analysis: Identify the specific time point (inflection point) when an indicator undergoes a sudden change based on the alarm curve.

[0143] Impact attribution: Preliminary assessment of the scope of business affected by the alarm.

[0144] S404. Extract multidimensional attribute information of change events.

[0145] Upon receiving an alarm, the system, based on the domain knowledge graph built by S402, retrieves change events within the relevant time window and extracts their key attributes for subsequent matching: Time attribute: Obtain the deployment time of changes at each stage, such as canary release and full release, so as to accurately compare with the alarm time.

[0146] Spatial attributes: Determine the platform or environment in which the change occurred (such as a specific data center or a specific cluster).

[0147] Relationship attributes: Based on the knowledge graph, query the business entities associated with the change event to clarify the business scope that the change may affect.

[0148] For word list changes, such as Figure 3 As shown, the system performs proto parsing of the vocabulary to understand the vocabulary structure, and combines vocabulary row and column diff parsing technology to accurately identify the specific data rows and columns that have changed, thereby determining the potential scope of their business impact.

[0149] S405. Perform a weighted sort to locate the root cause.

[0150] The system comprehensively matches the alarm analysis results (data center characteristics, inflection point time, and attribution results) obtained from S403 with the change event attributes (deployment time, change platform, and associated business entities) extracted from S404. The system uses a weighted sorting algorithm to calculate the matching score between each candidate change event and the current alarm event. For example, if the deployment time of the change highly matches the alarm inflection point time, and the associated business entity is consistent with the attribution of the alarm's impact, then the change event will receive a high score. Finally, the system outputs a list of change events according to their scores, with the top-ranked events being the core root cause changes leading to online problems, thus achieving rapid and accurate fault location.

[0151] Figure 5 This is a structural schematic diagram of a positioning device 500 provided according to an embodiment of the present disclosure. Figure 5 As shown, the device includes: The acquisition module 501 is used to acquire the original change data generated by the target system within a preset time period; The parsing module 502 is used to perform semantic parsing on the original change data to obtain the change entities associated with the original change data and the business indicators corresponding to the change entities. The filtering module 503 is used to filter out target change entities from change entities based on preset discrimination filtering rules; Module 504 is used to construct a change domain knowledge graph based on the target change entity, wherein the change domain knowledge graph contains an inverted index pointing from business metrics to the target change entity; The determination module 505 is used to perform retrieval and matching operations in the change domain knowledge graph based on the received abnormal time information and abnormal business clues in order to determine the target change event.

[0152] In one possible implementation, the filtering module 503 is used for: Generate a combination of business metrics; Count the number of changed entities associated with each combination of indicators; In response to the fact that the number of coverages meets the preset convergence conditions, the change entity associated with the combination of indicators is determined as the target change entity; Establish an inverted index relationship that points from a combination of indicators to the entity undergoing the change of the target.

[0153] In one possible implementation, the preset convergence condition is that the number of coverages is less than or equal to a preset discrimination threshold.

[0154] In one possible implementation, the filtering module 503 is used for: Iterate through all business metrics corresponding to the changed entity; Generate candidate indicator combinations containing a single business indicator, two business indicators, and three business indicators, respectively. The candidate indicator combination is used as the indicator combination.

[0155] In one possible implementation, the parsing module 502 is used for: Identify the source type of the original change data; Based on the change source type, the corresponding parsing rule is called from the preset parsing strategy library; By using parsing rules, the content of the original change data is extracted in a structured manner to obtain business metrics.

[0156] In one possible implementation, the parsing module 502 is used for: When the change source type is data change, the difference content of the data change is matched based on the metadata description information in the data structure definition file corresponding to the data change; Identify the meaning of fields that have changed in the differing content; Extract the specific numerical values ​​pointed to by the field meanings into business metrics.

[0157] In one possible implementation, the parsing module 502 is used for: When the source of change is code change or configuration change, white-box parsing rules are used to scan for differences in code files or configuration files. Identify and extract key-value pair information contained in the change differences; Map key-value pairs to business metrics.

[0158] In one possible implementation, the parsing module 502 is used for: When the change source type is experimental change, query the database of the experimental management system for the selected traffic tags and triggering branch information of the experimental change; Traffic tags and trigger branch information are identified as business metrics.

[0159] In one possible implementation, the determining module 505 is used for: Delineate a time window based on abnormal time information, and retrieve a set of candidate change events within the time window; Calculate the time difference between the deployment time and the anomaly time information for each change event in the candidate change event set, and calculate the time matching score based on the time difference; Search the knowledge graph of change domain using abnormal business clues. If a change event in the candidate change event set matches the search results, assign a matching weight score to the clue. Based on time matching score and clue matching weight score, the candidate change event set is sorted, and the change event with the highest ranking is determined as the target change event.

[0160] In one possible implementation, the device further includes a normalization module for: After calculating the time matching score and the clue matching weight score, the sum of the two is calculated to obtain the initial total score; Get the highest initial total score in the candidate change event set; Based on the sum of the highest initial total score and the preset buffer value, the initial total score of each change event is normalized to obtain the final ranking score.

[0161] In one possible implementation, the device further includes a calibration module for: In response to the completion of the domain knowledge graph construction, retrieve historical abnormal business clues from the historical fault attribution report; Verify whether the historical abnormal business leads can be retrieved in the change domain knowledge graph to find the corresponding historical fault change entities; The discrimination screening rules are calibrated and updated based on the validation results.

[0162] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0163] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0164] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0165] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0166] like Figure 6 As shown, device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 602 or a computer program loaded into random access memory (RAM) 603 from storage unit 608. RAM 603 may also store various programs and data required for the operation of device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0167] Multiple components in device 600 are connected to I / O interface 605, including: input unit 606, such as keyboard, mouse, etc.; output unit 607, such as various types of monitors, speakers, etc.; storage unit 608, such as disk, optical disk, etc.; and communication unit 609, such as network card, modem, wireless transceiver, etc. Communication unit 609 allows device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0168] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above, such as the change-of-location method. For example, in some embodiments, the change-of-location method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and / or installed on device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the change-of-location method described above may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured to perform the change-of-location method by any other suitable means (e.g., by means of firmware).

[0169] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0170] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0171] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0172] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0173] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0174] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0175] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0176] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for changing location, comprising: Obtain the original change data generated by the target system within a preset time period; Semantic parsing is performed on the original change data to obtain the change entities associated with the original change data and the business metrics corresponding to the change entities; Based on preset discrimination filtering rules, target change entities are filtered out from the changed entities; A change domain knowledge graph is constructed based on the target change entity; wherein, the change domain knowledge graph contains an inverted index pointing from the business metrics to the target change entity; Based on the received abnormal time information and abnormal business clues, a retrieval and matching operation is performed in the change domain knowledge graph to determine the target change event.

2. The method according to claim 1, wherein, The step of filtering target change entities from the changed entities based on preset discrimination rules includes: Generate the combination of the aforementioned business metrics; Count the number of changed entities associated with each of the aforementioned indicator combinations; In response to the coverage quantity satisfying a preset convergence condition, the change entity associated with the index combination is determined as the target change entity; Establish an inverted index relationship pointing from the combination of indicators to the target changed entity.

3. The method according to claim 2, wherein, The preset convergence condition is that the number of coverages is less than or equal to a preset discrimination threshold.

4. The method according to claim 2, wherein, The combination of metrics used to generate the business metrics includes: Iterate through all business metrics corresponding to the changed entity; Generate candidate indicator combinations containing a single business indicator, two business indicators, and three business indicators, respectively. The candidate index combination is used as the index combination.

5. The method according to claim 1, wherein, The step of semantically parsing the original change data to extract the change entities associated with the original change data and the business metrics corresponding to the change entities includes: Identify the type of change source for the original change data; Based on the change source type, the corresponding parsing rule is called from the preset parsing strategy library; The content of the original change data is extracted in a structured manner using the parsing rules to obtain the business metrics.

6. The method according to claim 5, wherein, The process of extracting the structured content of the original change data using the parsing rules to obtain the business metrics includes: When the change source type is data change, the difference content of the data change is matched based on the metadata description information in the data structure definition file corresponding to the data change. Identify the meaning of the fields that have changed in the differences; The specific numerical values ​​pointed to by the meaning of the fields are extracted as the business metrics.

7. The method according to claim 5, wherein, The process of extracting the structured content of the original change data using the parsing rules to obtain the business metrics includes: When the change source type is code change or configuration change, white-box parsing rules are used to scan for changes in code files or configuration files; Identify and extract the key-value pair information contained in the changes; The key-value pair information is mapped to the business metrics.

8. The method according to claim 5, wherein, The process of extracting the structured content of the original change data using the parsing rules to obtain the business metrics includes: If the change source type is experimental change, query the database of the experimental management system for the selected traffic tags and trigger branch information of the experimental change; The traffic label and the trigger branch information are determined as the business metrics.

9. The method according to claim 1, wherein, Based on the received abnormal time information and abnormal business clues, the step of performing retrieval and matching operations in the change domain knowledge graph to determine the target change event includes: Based on the abnormal time information, a time window is defined, and a set of candidate change events within the time window is retrieved; Calculate the time difference between the deployment time of each change event in the candidate change event set and the abnormal time information, and calculate the time matching score based on the time difference; The abnormal business clues are used to search the knowledge graph of the change domain. If the change event in the candidate change event set matches the search result, the clue is assigned a matching weight score. Based on the time matching score and the clue matching weight score, the candidate change event set is sorted, and the change event with the highest ranking is determined as the target change event.

10. The method of claim 9, further comprising: After calculating the time matching score and the clue matching weight score, the sum of the two is calculated to obtain the initial total score; Obtain the highest initial total score from the set of candidate change events; Based on the sum of the highest initial total score and the preset buffer value, the initial total score of each change event is normalized to obtain the final ranking score.

11. The method according to claim 1, further comprising: In response to the completion of the changed domain knowledge graph construction, historical abnormal business clues from the historical fault attribution report are obtained; Verify whether the historical abnormal business clues can be retrieved in the change domain knowledge graph to find the corresponding historical fault change entity; The discrimination screening rules are calibrated and updated based on the verification results.

12. A positioning change device, comprising: The acquisition module is used to acquire the original change data generated by the target system within a preset time period. The parsing module is used to perform semantic parsing on the original change data to obtain the change entities associated with the original change data and the business indicators corresponding to the change entities; The filtering module is used to filter out target change entities from the change entities based on preset discrimination filtering rules; A construction module is used to construct a change domain knowledge graph based on the target change entity, wherein the change domain knowledge graph contains an inverted index pointing from the business indicator to the target change entity; The determination module is used to perform retrieval and matching operations in the change domain knowledge graph based on the received abnormal time information and abnormal business clues, so as to determine the target change event.

13. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-11.

14. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-11.

15. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-11.

Images