Enterprise management-oriented enterprise operation supervision method based on micro-service architecture

Abstract

The invention relates to the technical field of enterprise management, in particular to an enterprise management-oriented enterprise operation supervision method based on a micro-service architecture, and the method comprises the steps: collecting observability data from a plurality of micro-services deployed in the micro-service architecture, carrying out the standardization processing of the observability data, and injecting a unified label set; calculating a real-time supervision index value through a supervision algorithm model by using the observability data after standardization processing, and generating corresponding interpretability information; and obtaining a real-time supervision index value, calculating to obtain a supervision index risk score at the current moment, comparing the supervision index risk score with a dynamic threshold value, generating alarm events when a preset alarm triggering condition is met, and aggregating the alarm events.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of enterprise management, in particular to an enterprise operation supervision method for enterprise management based on a micro-service architecture. BACKGROUND

[0002] The micro-service architecture splits a large application into multiple independently deployable small services, each focusing on a specific business capability. This architecture brings advantages such as agile development, independent scaling, and technology diversity.

[0003] Traditional enterprise operation supervision methods are usually based on monolithic architecture, discovering problems through centralized log systems or simple metric monitoring. However, under the micro-service architecture, a complete business request may span dozens of services, and traditional monitoring methods are difficult to achieve end-to-end tracking and correlation. There are the following defects: log, metric, and tracking data are stored in scattered storage, lack of unified correlation, resulting in low efficiency in operation problem troubleshooting. Many anomaly detection models use black box algorithms such as deep learning, and the output results are difficult for business personnel to understand and trust, and cannot provide decision basis. Fixed thresholds cannot adapt to periodic changes and sudden traffic, resulting in high false positive rate or missed reports. After the alarm, there is a lack of collection and utilization of processing results, which cannot continuously optimize the supervision model.

[0004] Therefore, there is an urgent need for an enterprise operation supervision method that can fully utilize the characteristics of the micro-service architecture, provide interpretable supervision indicators, and have dynamic threshold and self-optimization capabilities. SUMMARY

[0005] The present application realizes interpretable and adaptive supervision of enterprise operation status under the micro-service architecture by setting dynamic thresholds and implementing intelligent alarms through a supervision algorithm model.

[0006] The technical solution of the present application is: an enterprise operation supervision method for enterprise management based on a micro-service architecture, the method comprising:

[0007] Collecting observability data from multiple micro-services deployed in the micro-service architecture, standardizing the observability data, and injecting a unified label set; the unified label set includes service identification, business domain identification, and tracking identification;

[0008] Using the standardized observability data, calculating real-time supervision indicator values through a supervision algorithm model, and generating corresponding interpretability information; the observability data includes micro-service output logs, monitoring indicators, and tracking data; the interpretability information includes key features contributing to the supervision indicator values and their contribution degrees;

[0009] Obtaining real-time supervision index values, calculating supervision index risk scores at the current time, comparing the supervision index risk scores with dynamic thresholds, generating an alarm event when a preset alarm triggering condition is met, and aggregating the alarm event.

[0010] Preferably, further comprising: obtaining a dynamic threshold based on a time series of monitoring indicators and combining supervision algorithm model output;

[0011] The monitoring indicators include the number of unauthorized access to sensitive data, service error rate, and audit log coverage.

[0012] Preferably, further comprising: obtaining feedback data for alarm event processing, and adjusting the dynamic threshold and updating the supervision algorithm model based on the feedback data;

[0013] The supervision algorithm model includes one of a rule model, a linear model, a statistical-based anomaly detection model, or a fusion model thereof.

[0014] Preferably, the observable data is collected from a plurality of microservices deployed in a microservice architecture, including:

[0015] Header sampling is performed at the entrance of each microservice according to a preset frequency, and it is dynamically determined whether to retain tracking data according to request processing results, including whether the request is incorrect and whether the processing delay exceeds a threshold;

[0016] The structured microservice output log includes a timestamp, a service name, a tracking identifier, a business event type, and a key business field.

[0017] Business event logs are generated for key business operation points, and audit event logs are generated for sensitive operation points.

[0018] The standardized processing of the observable data and the injection of a uniform label set include automatically injecting and transmitting service identifiers and business domain identifiers during inter-microservice communication, the business domain identifiers including at least user identifiers, order identifiers, and transaction identifiers.

[0019] Preferably, the real-time supervision index values are calculated by the supervision algorithm model, and corresponding explainability information is generated, including:

[0020] A rule model is used as the supervision algorithm model, and the rule model stores a plurality of supervision rules, each supervision rule being expressed as: if (condition combination) then (conclusion);

[0021] The condition combination is constructed based on observable data features, and the conclusion includes an abnormality level, a risk score, and a recommended action.

[0022] When real-time data meets the conditions of the corresponding regulatory rules, the corresponding conclusion is output, and the observable data characteristics of the triggered regulatory rules are recorded as interpretability information.

[0023] Preferably, the step of calculating real-time regulatory indicator values ​​through a regulatory algorithm model and generating corresponding interpretability information further includes:

[0024] A linear model is used as the regulatory algorithm model, and the output of the linear model is represented as a weighted linear combination of the input features:

[0025] ;

[0026] in For the first Each input feature is an observable data feature. These are the weighting coefficients for observable data features; Indicates the number of input features; Indicates the model output, This indicates the bias term.

[0027] Preferably, the step of calculating real-time regulatory indicator values ​​through a regulatory algorithm model and generating corresponding interpretability information further includes:

[0028] A statistical anomaly detection model is adopted as the regulatory algorithm model. This anomaly detection model uses the exponentially weighted moving average (EWMA) algorithm to dynamically calculate the baseline and fluctuation range.

[0029] ; ;

[0030] The abnormality determination condition is ;in, These are the observed values ​​of regulatory indicators for the current time window. For a moment The EWMA smoothing value is the baseline value. As a smoothing factor, For a moment The EWMA standard deviation, The threshold coefficient is; the fluctuation range is ;

[0031] The current observations, baseline values, standard deviations, and anomaly detection results are used as interpretability information.

[0032] Preferably, the step of calculating real-time regulatory indicator values ​​through a regulatory algorithm model and generating corresponding interpretability information further includes:

[0033] A fusion model is used as the regulatory algorithm model, which combines the outputs of two base models. The combination methods include voting, weighted averaging, stacking, or cascading. The base models include a linear model and an anomaly detection model.

[0034] The interpretability information includes the output results and fusion weights of each base model, or it includes local interpretation information generated by a post-interpretation algorithm.

[0035] Preferably, the dynamic threshold obtained by combining the time series of monitoring indicators with the output of the regulatory algorithm model includes:

[0036] Calculate the dynamic threshold for the current moment based on the time series of historical regulatory indicator values; including:

[0037] set up ; ;in, Assess the risk score for the current regulatory indicator value. For a moment EWMA mean;

[0038] Original threshold The original threshold is adjusted based on the model confidence score output by the regulatory algorithm model to obtain a dynamic threshold. ,in, For model confidence, This is the adjustment coefficient.

[0039] Preferably, the aggregation of alarm events includes:

[0040] The generated alarm events are suppressed and aggregated according to alarm rules, which include alarm level and alarm duration conditions;

[0041] Multiple alarm events are merged into a single alarm notification based on alarm similarity.

[0042] The alarm notification includes one or more of the following: alarm level, current regulatory indicator value risk score, dynamic threshold, business context characteristics, and suggested actions;

[0043] Acquiring feedback data on the processing of alarm events, and adjusting dynamic thresholds and updating the monitoring algorithm model based on the feedback data, including:

[0044] Obtain alarm handling results, including whether it was a false alarm and whether it has been resolved;

[0045] Obtain the alarm accuracy rate; adjust the parameters in the dynamic threshold setting step, including the smoothing factor and threshold coefficient, based on the alarm accuracy rate.

[0046] The beneficial effects of this invention are:

[0047] 1. This invention injects a unified tag set, enabling all observation data to carry service identifiers, business domain identifiers, and tracking identifiers. This binds business and technical data, avoiding data silos. It also establishes business flow associations between multiple microservices. Furthermore, it employs a combined head and tail sampling strategy, sampling with low probability at the microservice entry point and fully collecting data for errors that have occurred at the microservice output point, thereby controlling storage costs while ensuring data integrity.

[0048] 2. This invention obtains regulatory indicator values ​​through different regulatory algorithm models and generates corresponding interpretable information, which is easy for regulatory personnel to understand and take corresponding measures to improve the efficiency of human-machine collaboration.

[0049] 3. This invention improves alarm accuracy by setting dynamic thresholds to adapt to different business scenarios and triggering corresponding alarm notifications based on these dynamic thresholds. Furthermore, when the alarm accuracy falls below the set threshold, the monitoring algorithm model parameters are adjusted to further enhance alarm accuracy. Attached Figure Description

[0050] Figure 1 This is a flowchart of the enterprise operation supervision method based on microservice architecture for enterprise management according to the present invention. Detailed Implementation

[0051] The following description is intended to disclose the present invention and enable those skilled in the art to implement it. The preferred embodiments described below are merely examples, and other obvious modifications will occur to those skilled in the art. The basic principles of the invention defined in the following description can be applied to other embodiments, modifications, improvements, equivalents, and other technical solutions that do not depart from the spirit and scope of the invention.

[0052] It is understood that the term "a" should be understood as "at least one" or "one or more," that is, in one embodiment, the number of an element can be one, while in another embodiment, the number of the element can be multiple, and the term "a" should not be understood as a limitation on the number.

[0053] Example 1: Reference Figure 1 The technical solution provided by this invention is: an enterprise operation supervision method based on microservice architecture for enterprise management, the method comprising:

[0054] Step 1: Collect observability data from multiple microservices deployed in the microservice architecture, standardize the observability data, inject a unified tag set, and store it in layers, including the original layer, the cleaning layer, the aggregation layer, and the application layer.

[0055] In this embodiment, the unified tag set includes service identifiers, business domain identifiers, and tracing identifiers. The interpretability information includes key features that contribute to regulatory metric values ​​and their degree of contribution; the observable data includes microservice output logs, monitoring metrics, and tracing data. The monitoring metrics include the number of unauthorized accesses to sensitive data, service error rate, and audit log coverage.

[0056] Step 1 specifically includes the following steps:

[0057] Step 1.1: Perform header sampling at the entry point of each microservice according to a preset frequency, and dynamically decide whether to retain tracking data based on the request processing result. The request processing result includes whether the request is erroneous and whether the processing delay exceeds a threshold.

[0058] Specifically, this involves integrating the observability framework OpenTelemetrySDK into each microservice to enable the automatic collection of logs, metrics, and tracking data.

[0059] Sampling is performed at a preset frequency at the microservice entry point. At the end, if the request returns an HTTP status code greater than 500, indicating an error, or if the processing delay exceeds a threshold (e.g., 2 seconds), the global trace ID field is forcibly retained, and the rest are sampled at 10%.

[0060] Step 1.2: Structure the microservice output logs to include timestamps, service names, tracing identifiers, business event types, and key business fields. Specifically, the output of each microservice is forced to use a lightweight data exchange format (JSON), including an event occurrence time field (timestamp), a service name field (service name), a global tracing ID field (tracing identifier), a business event type field (business type), and key business fields (command ID, user ID, etc.).

[0061] Step 1.3: Generate business event logs for key business operation tracking points and generate audit event logs for sensitive operation tracking points; specifically:

[0062] In microservice code, probes can be implanted before and after critical business operations using aspect-oriented programming (AOP) or decorator pattern to capture business parameters, trace identifiers and user IDs, and generate business event logs in JSON format: {event name, command ID, operation success status, username, global trace ID, user ID}, which are then sent asynchronously to local logs or log collectors.

[0063] Probes are implanted before and after sensitive operations (such as querying private data) to obtain query results, operation time, sensitive operation target ID, and operation user ID, generating an audit log in JSON format: {Query results, operation time, sensitive operation target ID, operation user ID, interception feedback identifier}. The process for determining the interception feedback identifier is as follows: verify the operation user ID's permissions. If the permission conditions are met, the feedback identifier is 0, meaning no interception; if the permission conditions are not met, the feedback identifier is 1, indicating interception.

[0064] Traditional metric monitoring can only reflect system problems, but cannot pinpoint the exact cause. Business event logs, on the other hand, can track which operations caused the problem, allowing monitoring not only for microservice anomalies but also for the more granular business actions that triggered them.

[0065] Audit logs provide definitive evidence, namely, evidence proving whether microservices or operations are compliant in the event of data leaks or management conflicts.

[0066] Step 1.4: Automatically inject and transmit service identifiers and business domain identifiers during inter-microservice communication. The business domain identifiers include at least user identifiers, order identifiers, and transaction identifiers. Specifically, during microservice communication, context (tracing identifiers) and key business fields are automatically transmitted via HTTP headers or message queue attributes to ensure end-to-end request traceability.

[0067] Step 2: Using the standardized observable data, calculate the real-time regulatory indicator values ​​through the regulatory algorithm model and generate corresponding interpretable information.

[0068] In this embodiment, a rule model is used as the regulatory algorithm model. The rule model stores multiple regulatory rules, and each regulatory rule is represented as: if (combination of conditions) then (conclusion).

[0069] The combination of conditions is constructed based on observable data features, and the conclusions include anomaly level, risk score, and recommended actions.

[0070] When real-time data meets the conditions of the corresponding regulatory rules, the corresponding conclusion is output, and the observable data characteristics of the triggered regulatory rules are recorded as interpretability information. For example:

[0071] if( Then (the efficiency level is abnormally high);

[0072] Among them, the amount of tasks completed and task completion rate This can be obtained from the microservice output logs. Specifically, extract the business type (task allocation and task reconciliation, etc.) from the microservice output logs, and calculate the number of allocated tasks and the number of tasks completed. The ratio of the two is the task completion rate.

[0073] In this embodiment, the amount of tasks assigned, the amount of tasks completed, and the task completion rate are recorded as interpretability information.

[0074] Example 2: This example also includes step 3: obtaining real-time regulatory indicator values, calculating the regulatory indicator risk score at the current moment, comparing the regulatory indicator risk score with a dynamic threshold, generating an alarm event when the preset alarm triggering conditions are met, and aggregating the alarm events. Specifically, this includes the following steps:

[0075] Step 3.1: Use a linear model as the monitoring algorithm model. The output of the linear model is represented as a weighted linear combination of the input features:

[0076] ;

[0077] in For the first Each input feature is an observable data feature. These are the weighting coefficients for observable data features; Indicates the number of input features; This indicates the predicted value of the regulatory indicator. Indicates the bias term;

[0078] Step 3.2: A statistical anomaly detection model is adopted as the regulatory algorithm model. The anomaly detection model uses the exponentially weighted moving average (EWMA) algorithm to dynamically calculate the baseline and fluctuation range.

[0079] ; ;

[0080] The abnormality determination condition is ;if If the abnormality criteria are met, the regulatory indicator is judged to be abnormal.

[0081] in, These are the observed values ​​of regulatory indicators for the current time window. For a moment The EWMA smoothing value is the baseline value. As a smoothing factor, For a moment The EWMA standard deviation, The threshold coefficient is; the fluctuation range is The current observations, baseline values, standard deviations, and anomaly detection results serve as interpretable information.

[0082] Step 3.3: Employ a fusion model as the monitoring algorithm model. The fusion model combines the outputs of two base models, and the combination methods include voting, weighted averaging, stacking, or cascading. The base models include a linear model and an anomaly detection model. In this embodiment, [the model will be used]. and Risk scores for monitoring indicators are obtained by merging them using a weighted average method. . , For weight fusion.

[0083] The interpretability information includes the output results and fusion weights of each base model, or it includes local interpretation information generated by a post-explanation algorithm, such as LIME or SHAP.

[0084] For example, in this embodiment, for each Values ​​record the top 3 features that contribute the most to the linear model and their weights. (value), then call SHAP to calculate each feature. The SHAP value is used as interpretable information, taking the three features, their weights, and the SHAP value of the features.

[0085] Step 3.4: Based on the time series of monitoring indicators and combined with the output of the regulatory algorithm model, obtain dynamic thresholds, including:

[0086] set up ; ;in, Assess the risk score for the current regulatory indicator value. For a moment EWMA mean;

[0087] Obtain the original threshold The original threshold is adjusted based on the model confidence score output by the regulatory algorithm model to obtain the dynamic threshold. .

[0088] in, The original threshold, For model confidence, For adjustment coefficients, This is a dynamic threshold. In this embodiment, the model confidence level of the linear model is... variance The confidence level of the anomaly detection model is ; ;in, , This represents the confidence level fusion coefficient.

[0089] Alternatively, dynamic thresholds can be obtained by dynamically adjusting the corresponding original thresholds based on business context characteristics, including business line, service importance, time period, and traffic level; specifically, the threshold coefficients are adjusted based on business line, service importance, time period, and traffic level. For example, if the business line processed by the microservice is core business, the threshold coefficient is increased (e.g., adjusted to 3.0) to reduce false alarms; non-core business retains the original value (e.g., 2.5). If the microservice processes business at night, due to low traffic, the threshold coefficient is decreased (e.g., adjusted to 2.0) to improve sensitivity.

[0090] Step 3.4: Set alarm rules to suppress and aggregate generated alarm events according to the alarm rules. The alarm rules include alarm level and alarm duration conditions. Specifically:

[0091] if If the alarm level is 1, and the alarm duration exceeds 3 minutes, then a Class I alarm event will be generated.

[0092] if If the alarm level is 2, and the alarm duration exceeds 2 minutes, a Class II alarm event will be generated.

[0093] if If the alarm level is three and the alarm duration is one minute, then three types of alarm events will be generated. Among them, , Thresholds are set for alarm levels.

[0094] Aggregate alarm events, including:

[0095] Multiple alarm events are merged into a single alarm notification based on alarm similarity. Specifically:

[0096] If the same microservice generates multiple similar alarm events within a preset time period (e.g., 5 minutes), they are merged into a single aggregated alarm notification. The alarm notification includes one or more of the following: alarm level, current regulatory indicator value risk score, dynamic threshold, business context characteristics, and suggested actions.

[0097] Example 3: This example also includes step 5, obtaining feedback data on the processing of alarm events, and adjusting the dynamic threshold and updating the monitoring algorithm model based on the feedback data, including the following steps:

[0098] Obtain alarm handling results, including whether it was a false alarm and whether it has been resolved. Specifically: after receiving the alarm notification, the handling personnel mark the result in the system. If it is confirmed to be a normal business fluctuation, it is marked as a false alarm; if corresponding measures are taken, it is marked as resolved.

[0099] The accuracy rate of alerts is calculated weekly to obtain alert accuracy data.

[0100] Adjust the parameters in the dynamic threshold setting step based on the alarm accuracy, including the smoothing factor and threshold coefficient.

[0101] Specifically, if the alarm accuracy rate is below 95%, the regulatory algorithm model will be retrained. This includes: acquiring false alarm samples; based on the false alarm samples, determining whether the false alarms are caused by short-term business fluctuations; if so, increasing EWMA. Adjust the value to increase the dynamic threshold; otherwise, adjust... This is to avoid false alarms caused by low confidence levels.

[0102] The processes described above with reference to the flowcharts in the embodiments disclosed in this invention can be implemented as computer software programs. The embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit (CPU), it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wire segments, 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 thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless segments, wire segments, optical fibers, RF, etc., or any suitable combination thereof.

[0103] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0104] Those skilled in the art should understand that the embodiments of the present invention described above and shown in the accompanying drawings are merely examples and do not limit the present invention. The purpose of the present invention has been fully and effectively achieved. The functions and structural principles of the present invention have been shown and explained in the embodiments. Without departing from the principles described, the implementation of the present invention may have any changes or modifications.

Claims

1. A microservice architecture-based enterprise operation monitoring method for enterprise management, characterized in that, The method includes: Observability data is collected from multiple microservices deployed in a microservice architecture, the observable data is standardized, and a unified tag set is injected; the unified tag set includes service identifiers, business domain identifiers, and tracing identifiers. Using standardized observable data, real-time regulatory indicator values ​​are calculated through a regulatory algorithm model, and corresponding interpretable information is generated. The observable data includes microservice output logs, monitoring indicators, and tracing data. The interpretable information includes key features that contribute to the regulatory indicator values ​​and their degree of contribution. The system acquires real-time regulatory indicator values, calculates the regulatory indicator risk score for the current moment, compares the regulatory indicator risk score with dynamic thresholds, generates an alarm event when the preset alarm triggering conditions are met, and aggregates the alarm events.

2. The enterprise operation supervision method based on microservice architecture for enterprise management according to claim 1, characterized in that, Also includes: Dynamic thresholds are obtained by combining the time series of monitoring indicators with the output of the regulatory algorithm model. The monitoring metrics include the number of unauthorized accesses to sensitive data, service error rate, and audit log coverage; the regulatory algorithm model includes one or a combination of rule-based models, linear models, and statistical anomaly detection models.

3. The enterprise operation supervision method based on microservice architecture for enterprise management according to claim 2, characterized in that, Also includes: Obtain feedback data on alarm event handling, and adjust dynamic thresholds and update the monitoring algorithm model based on the feedback data, including: Obtain alarm handling results, including whether it was a false alarm and whether it has been resolved; Obtain the alarm accuracy rate; adjust the parameters in the dynamic threshold setting step, including the smoothing factor and threshold coefficient, based on the alarm accuracy rate.

4. The enterprise operation supervision method based on microservice architecture for enterprise management according to claim 3, characterized in that, The collection of observability data from multiple microservices deployed in a microservice architecture includes: Header sampling is performed at the entry point of each microservice according to a preset frequency. Whether to retain tracking data is dynamically determined based on the request processing result. The request processing result includes whether the request is erroneous and whether the processing delay exceeds a threshold. Structured microservice output logs include timestamps, service names, tracing identifiers, business event types, and key business fields. For key business operations, data points are embedded to generate business event logs; for sensitive operations, data points are embedded to generate audit event logs. The standardization of the observable data and the injection of a unified tag set include: automatically injecting and transmitting service identifiers and business domain identifiers during inter-microservice communication, wherein the business domain identifiers include at least user identifiers, order identifiers, and transaction identifiers.

5. The enterprise operation supervision method based on microservice architecture for enterprise management according to claim 4, characterized in that, The process of calculating real-time regulatory indicator values ​​through a regulatory algorithm model and generating corresponding interpretable information includes: A rule model is adopted as the regulatory algorithm model. The rule model stores multiple regulatory rules, and each regulatory rule is expressed as: if (condition combination) then (conclusion); The combination of conditions is constructed based on observable data features, and the conclusions include anomaly level, risk score, and recommended actions; When real-time data meets the conditions of the corresponding regulatory rules, the corresponding conclusion is output, and the observable data characteristics of the triggered regulatory rules are recorded as interpretability information.

6. The enterprise operation supervision method based on microservice architecture for enterprise management according to claim 5, characterized in that, The process of calculating real-time regulatory indicator values ​​through a regulatory algorithm model and generating corresponding interpretable information also includes: A linear model is used as the regulatory algorithm model, and the output of the linear model is represented as a weighted linear combination of the input features: ； in For the first Each input feature is an observable data feature. These are the weighting coefficients for observable data features; Indicates the number of input features; Indicates the model output, This indicates the bias term.

7. The enterprise operation supervision method based on microservice architecture for enterprise management according to claim 6, characterized in that, The process of calculating real-time regulatory indicator values ​​through a regulatory algorithm model and generating corresponding interpretable information also includes: A statistical anomaly detection model is adopted as the regulatory algorithm model. This anomaly detection model uses the exponentially weighted moving average (EWMA) algorithm to dynamically calculate the baseline and fluctuation range. ； ； The abnormality determination condition is ;in, These are the observed values ​​of regulatory indicators for the current time window. For a moment The EWMA smoothing value is the baseline value. As a smoothing factor, For a moment EWMA standard deviation, The threshold coefficient is; the fluctuation range is ; The current observations, baseline values, standard deviations, and anomaly detection results are used as interpretability information.

8. The enterprise operation supervision method based on microservice architecture for enterprise management according to claim 7, characterized in that, The process of calculating real-time regulatory indicator values ​​through a regulatory algorithm model and generating corresponding interpretable information also includes: A fusion model is used as the regulatory algorithm model, which combines the outputs of two base models. The combination methods include voting, weighted averaging, stacking, or cascading. The base models include a linear model and an anomaly detection model. The interpretability information includes the output results and fusion weights of each base model, or it includes local interpretation information generated by a post-interpretation algorithm.

9. The enterprise operation supervision method based on microservice architecture for enterprise management according to claim 8, characterized in that, The dynamic threshold obtained by combining the time series data based on monitoring indicators with the output of the regulatory algorithm model includes: Calculate the dynamic threshold for the current moment based on the time series of historical regulatory indicator values; including: set up ; ;in, Assess the risk score for the current regulatory indicator value. For a moment EWMA mean; Original threshold The original threshold is adjusted based on the model confidence score output by the regulatory algorithm model to obtain a dynamic threshold. ,in, For model confidence, This is the adjustment coefficient.

10. The enterprise operation supervision method based on microservice architecture for enterprise management according to claim 9, characterized in that, The aggregation of alarm events includes: The generated alarm events are suppressed and aggregated according to alarm rules, which include alarm level and alarm duration conditions; Multiple alarm events are merged into a single alarm notification based on alarm similarity. The alarm notification includes one or more of the following: alarm level, current regulatory indicator value risk score, dynamic threshold, business context characteristics, and suggested actions.

Images