CN114238041A

CN114238041A - Alarm method, alarm device, electronic equipment and storage medium

Info

Publication number: CN114238041A
Application number: CN202111545393.0A
Authority: CN
Inventors: 张侃; 童彤
Original assignee: Shenzhen Tengyin Information Consulting Co ltd
Current assignee: Shenzhen Tengyin Information Consulting Co ltd
Priority date: 2021-12-16
Filing date: 2021-12-16
Publication date: 2022-03-25

Abstract

The invention discloses an alarm method, an alarm device, electronic equipment and a storage medium, wherein the method comprises the following steps: pre-configuring a basic strategy base, wherein the basic strategy base stores limiting strategies for different service scenes; acquiring a current service scene, acquiring a corresponding limiting strategy in a basic strategy library according to the service scene, and generating a service scene limiting strategy; configuring a service scene according to a service scene limiting strategy; when detecting that a user accesses a service scene, acquiring access data of the user; and if the access data of the user is detected to meet the service scene limiting strategy, generating an alarm operation. In the embodiment of the invention, in the development of different projects, only the corresponding basic strategy library is required to be introduced, and through unified api management, the problem of recycling between different systems of developers is solved, a service processing mechanism with limited capability is enhanced, data space is saved, and the timely monitoring and processing of the existing risk service are enhanced.

Description

Alarm method, alarm device, electronic equipment and storage medium

Technical Field

The present invention relates to the field of computer technologies, and in particular, to an alarm method and apparatus, an electronic device, and a storage medium.

Background

The service restriction processing capacity aiming at different scenes cannot achieve unified management, each service function needs to realize different set of restriction schemes, different service systems cannot be used universally and decoupled, the workload of developers is large, and operation with risks cannot be predicted and alarm processing is performed.

In the prior art, if various service scenes need to be subjected to service limitation, a large number of limiting codes need to be written, so that a large amount of repeated work is caused, the workload is large, and warning cannot be timely performed.

Accordingly, the prior art is yet to be improved and developed.

Disclosure of Invention

In view of the defects of the prior art, the invention provides an alarm method, an alarm device, electronic equipment and a storage medium, and aims to solve the problems that in the prior art, if service limitation needs to be performed on various service scenes, a large number of limit codes need to be written, so that a large amount of repeated work is caused, the workload is large, and alarm cannot be performed in time.

The technical scheme of the invention is as follows:

the first embodiment of the invention provides an alarm method, which comprises the following steps:

pre-configuring a basic strategy base, wherein the basic strategy base stores limiting strategies for different service scenes;

acquiring a current service scene, acquiring a corresponding limiting strategy in a basic strategy library according to the service scene, and generating a service scene limiting strategy;

configuring a service scene according to a service scene limiting strategy;

when detecting that a user accesses a service scene, acquiring access data of the user;

and if the access data of the user is detected to meet the service scene limiting strategy, generating an alarm operation.

Further, the pre-configuring the base policy repository includes:

the method comprises the steps of configuring limiting strategies under different service scenes in advance, wherein the service scenes comprise user login error frequency limitation, mobile phone short message sending condition limitation, IP high-frequency access limitation, bank card transaction limit limitation, marketing activity red packet drawing and issuing frequency limitation, account balance use limitation and face recognition verification error frequency verification limitation.

Further, the acquiring the current service scenario and generating a service scenario restriction policy according to the corresponding restriction policy in the service scenario acquisition basic policy library includes:

acquiring a user ID and a current service scene, and binding the user ID and the service scene;

and acquiring a time limiting strategy, a rule detail configuration strategy, a white list configuration strategy and a limiting rule frequency statistical strategy in a basic strategy library according to the user instruction to generate a service scene limiting strategy.

Further, when it is detected that the user accesses the service scenario, acquiring access data of the user includes:

when detecting that a user accesses a service scene, acquiring a user ID, and judging whether the user ID has a corresponding service scene limiting strategy;

if not, judging that the current user passes the non-matching rule;

if the data exists, the data accessed by the user is obtained, and whether the data accessed by the user meets the service scene limiting strategy is judged.

Further, the determining whether the access data of the user meets the service scenario restriction policy includes:

judging whether the user meets the condition of the white list or not;

if the user is a white list, judging that the current white list is matched and passed;

judging whether the current time meets a time limit strategy;

if the time limit strategy is not satisfied, judging that the time limit strategy does not pass through;

judging whether the current frequency meets a frequency statistical strategy of a restriction rule;

if the frequency statistical strategy does not meet the limiting rule frequency statistical strategy, judging that the frequency statistical strategy does not pass through the limiting rule frequency statistical strategy;

determining whether the current rule satisfies a rule detail configuration policy,

and if the rule detail configuration strategy is not satisfied, judging that the rule detail configuration strategy is not satisfied to pass.

Further, if it is detected that the access data of the user satisfies the service scenario restriction policy, generating an alarm operation, including:

and if the fact that the access data of the user meet the service scene limiting strategy is detected, generating alarm information and sending the alarm information to the operation and maintenance personnel terminal.

if the fact that the access data of the user meet the service scene limiting strategy is detected, counting the times of the access behaviors of the user;

and when the number of times of detecting the access behavior of the user meets a preset threshold value, generating alarm information and sending the alarm information to the operation and maintenance personnel terminal.

Another embodiment of the present invention provides an alarm device, including:

the system comprises a first configuration module, a second configuration module and a third configuration module, wherein the first configuration module is used for pre-configuring a basic strategy base which stores limiting strategies for different service scenes;

the strategy generation module is used for acquiring the current service scene, acquiring a corresponding limiting strategy in the basic strategy library according to the service scene and generating a service scene limiting strategy;

the second configuration module is used for configuring the service scene according to the service scene limiting strategy;

the data acquisition module is used for acquiring the access data of the user when detecting that the user accesses the service scene;

and the alarm module is used for generating alarm operation if the fact that the access data of the user meet the service scene limiting strategy is detected.

Another embodiment of the present invention provides an electronic device comprising at least one processor; and the number of the first and second groups,

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the alert method described above.

Yet another embodiment of the present invention provides a non-transitory computer-readable storage medium storing computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform the above-described alerting method.

Has the advantages that: in the embodiment of the invention, in the development of different projects, only the corresponding basic strategy library is required to be introduced, and through unified api management, the problem of recycling between different systems of developers is solved, a service processing mechanism with limited capability is enhanced, data space is saved, and the timely monitoring and processing of the existing risk service are enhanced.

Drawings

The invention will be further described with reference to the accompanying drawings and examples, in which:

FIG. 1 is a flow chart of a preferred embodiment of an alarm method of the present invention;

FIG. 2 is a diagram of a basic architecture of an embodiment of an alarm method according to the present invention;

FIG. 3 is a timing diagram illustrating an exemplary application of an alarm method according to the present invention;

FIG. 4 is a schematic flow chart illustrating the consumption amount at a specific time in a certain consumption scenario in accordance with an embodiment of the present invention;

FIG. 5 is a functional block diagram of an alarm device according to a preferred embodiment of the present invention;

fig. 6 is a schematic diagram of a hardware structure of an electronic device according to a preferred embodiment of the invention.

Detailed Description

In order to make the objects, technical solutions and effects of the present invention clearer and clearer, the present invention is described in further detail below. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

Aiming at different business scene limiting strategies in the prior art, a large number of codes need to be written, uniform api management does not exist, and the management difficulty of follow-up personnel is high. A large amount of garbage data can be recorded in different time by the same service data, and the expandability is not high. The invention provides an alarm method, which supports the limited processing capability of different service scenes, has a basic API, developers can create different strategy rules according to different services, and can solve the limited problem only according to user-defined keys and fields when the services need to be processed.

Embodiments of the present invention will be described below with reference to the accompanying drawings.

Referring to fig. 1, fig. 1 is a flowchart illustrating a preferred embodiment of an alarm method according to the present invention. As shown in fig. 1, it includes the steps of:

step S100, a basic strategy base is configured in advance, and the basic strategy base stores limiting strategies for different service scenes;

s200, acquiring a current service scene, acquiring a corresponding limiting strategy in a basic strategy library according to the service scene, and generating a service scene limiting strategy;

s300, configuring a service scene according to a service scene limiting strategy;

s400, when detecting that a user accesses a service scene, acquiring access data of the user;

and step S500, if the access data of the user is detected to meet the service scene limiting strategy, generating an alarm operation.

In specific implementation, as shown in fig. 2 and fig. 3, when the apparatus is used, a user needs to integrate the function, configure a basic rule according to a basic API parameter, where the basic rule needs to determine a source service system, a basic parameter, a belonging system parameter, configure a custom field (define different service fields according to different scenarios), and configure granularity for time: the method includes the steps that year, month, day, hour, minute, second, designated time period or no time concept limitation exists, for example, the maximum consumption amount (0 is not limited) needs to be configured related to the amount of money, the maximum limiting times need to be configured for frequency and times (if the frequency limit is not set for 0), a white list function strategy needs to be provided for a special user or an IP, a user operation data can be made into a redis cache or a database mysql, and the like, and the strategy configuration needs to be returned to a key called by the user after being completed.

In one embodiment, pre-configuring a base policy repository includes:

In specific implementation, the embodiment of the invention configures the restriction strategies in different service scenes in advance. The service scene comprises user login error frequency limitation, mobile phone short message sending condition limitation, IP high-frequency access limitation, bank card transaction limit limitation, marketing activity red packet drawing and issuing frequency limitation, account balance use limitation and face recognition check error frequency check limitation. Therefore, the method is suitable for different service scenes such as user account login, user activity participation, short message calling frequency, short message verification error frequency setting, IP access limitation, bank card account use limitation, user red packet use limitation, face swiping payment error times, consumption limit and the like.

The embodiment of the invention is applied to various service scenes for use, such as user login error frequency limitation, mobile phone short message bombing limitation, IP high-frequency access, bank card transaction limit, marketing activity red packet receiving and issuing frequency, account balance use limitation, face recognition and verification error frequency verification and the like, and limits and processes illegal and unsafe service data.

Taking the limitation of login scene frequency as an example, the user login error times can only be input for 5 times a day;

the policy is configured to: the check field is the user mobile phone number, and the rule is as follows: the maximum number of input errors is 5 times per day.

And (4) recording the data statistics to a redis cache or mysql database, and processing the data statistics in a counting mode.

The Redis storage mode comprises consumption limit key, a service system, a mobile phone number and time, and the effective duration is 1 day.

If the accumulated times reach a threshold value, the user login times need to be limited and error handling is prompted.

The embodiment of the invention aims at the problems that a plurality of limited scenes exist in the existing system, the vehicle needs to be repeatedly built in the program development, and a maintenance mode of unified management cannot be formed.

And a set of basic rule configuration under different scenes is provided, when the operation behavior meets the configured specified service rule, the specific service can be continuously operated, the processing device simultaneously supports the database and the redis cache limitation under different service scenes, the operation behavior with abnormal safety risk is uniformly monitored and counted, and if necessary, an alarm can be given to related operation and maintenance personnel to perform related risk troubleshooting.

The embodiment of the invention can support the limited processing capability of different service scenes, has a basic API, developers can create different strategy rules according to different services, and can solve the limited problem only according to the user-defined key and the field when the services need to be processed,

the problem of manpower and development cost is solved, a large amount of garbage data can not be generated under the scene of the same strategy at different time periods, and the existing potential risks can be timely alarmed and processed under the key business scene.

In one embodiment, acquiring a current service scenario, and generating a service scenario restriction policy according to a corresponding restriction policy in a service scenario acquisition basic policy library, includes:

In specific implementation, as shown in fig. 3, a user may customize a key, and the user may customize a rule that needs to be restricted, where a specific field is a user ID + service scenario, and obtain a time restriction policy, for example, a set rule time range of the time restriction policy is: 1. year; 2. month; 3. day; 4. week; 5. when the current is over; 6. time period specified, 7, all. The rule specification is configured to: amount, number of times, etc.; the white list configuration strategy is a special case white list; the restriction rule statistical strategy is to perform statistics through database DB processing or through a redis cache processing operation.

In one embodiment, when it is detected that a user accesses a service scenario, acquiring access data of the user includes:

if not, judging that the current user passes the non-matching rule;

In specific implementation, as shown in fig. 3, it is detected that a user accesses a service scenario, a user ID is obtained, and whether a corresponding service scenario restriction policy exists is determined; mainly by judging whether a user-defined key is matched; and returns the matching result and the rule. The user generally accesses the service scene through the mobile phone number or user information such as a user name and a password.

And if no matching result exists, judging that the user passes the no matching rule.

And if the matching result exists, judging whether the user meets the corresponding service scene restriction strategy according to the corresponding matching rule.

Further, determining whether the access data of the user meets the service scenario restriction policy includes:

judging whether the user meets the condition of the white list or not;

judging whether the current time meets a time limit strategy;

In specific implementation, as shown in fig. 3, the policy is configured in detail by sequentially determining whether the user is a white list, whether the user satisfies a time period, and obtaining counted data according to the matching rule, so as to determine the rules such as amount and times;

if the user is a white list, judging that the current white list is matched and passed; if the user is not in the white list, the user access is limited;

if the user is a white list, judging whether the current time meets a time limit strategy;

if the time limit strategy is not satisfied, judging that the time limit strategy does not pass through; if the time limit strategy is met, limiting the user access;

if the user does not satisfy the time limit strategy, judging whether the current frequency satisfies the frequency statistic strategy of the limit rule;

if the frequency statistical strategy does not meet the limiting rule frequency statistical strategy, judging that the frequency statistical strategy does not pass through the limiting rule frequency statistical strategy; if the frequency statistical strategy of the restriction rule is met, restricting the user access;

if the frequency statistical strategy does not meet the limiting rule, whether the current access data meets the rules of money amount, times and the like is judged,

if the amount and the times are on line, the verification is not passed;

if the amount and the times are not on line, the verification is passed.

In one embodiment, if it is detected that the access data of the user satisfies the service scenario restriction policy, generating an alert operation, including:

In specific implementation, when it is detected that the access data of the user meets the service scene restriction policy, it indicates that the current user is restricted in access, and in order to improve the security, alarm information corresponding to the reason that the user is restricted in access is generated and sent to the operation and maintenance personnel terminal.

In specific implementation, in order to reduce the data volume of the alarm information, when it is detected that the access data of the user meets a service scene limiting strategy, the current user access is limited, the times of the behavior of the user with limited access are counted, only when the times of the behavior meet a preset threshold value, the alarm information corresponding to the reason of limited user access is generated, and the alarm information is sent to the operation and maintenance personnel terminal.

In some other embodiments, a specific service restriction scenario is not limited, and if a new service scenario needs to be supported by expansion, only the corresponding service scenario and the basic policy rule configuration need to be added.

As shown in fig. 4, an embodiment of the present invention provides a flowchart of a specific embodiment of a certain consumption scenario specifying time consumption amount, taking zhongxing dining hall as an example, where the zhongxing dining hall has consumption modes in different time periods of morning, noon, evening and night, and needs to process the limit capacity for business consumption in different time periods: 1. it is verified whether consumption within a specified time is satisfied. 2. And verifying whether the specified time consumption stroke number is met. 3. Verifying whether the total consumption amount at the specified time is met. 4. And verifying whether the total consumption amount of the day is met.

The limiting conditions are enterprise users, each enterprise needs to be configured with an independent self-defined limiting key, rule judgment processing conditions comprise consumption self-defined keys, enterprise spids, user ids, date/time, when limitation is added, limiting data of different rules are recorded for the users, consumption limiting statistics (amount and time limitation) are added according to different time periods if limitation is carried out according to time period, consumption times and amount of the users need to be counted if total consumption amount in one day is limited, consumption times and amount need to be rolled back for users who fail to consume or fail to process, whether consumption limit statistics configuration exists in the previous day or not needs to be judged for the first time of the second day, the limiting data exist in the previous day, the limiting statistics data in the previous day are directly updated, consumption statistics at this time are initialized, consumption failure processing is carried out on the users who do not meet consumption limit and times, and prompting the user that the consumption amount or the consumption times are on line. Data space can be saved, and only one piece of data can be generated in different time periods of each user.

According to the method embodiment, the alarm method is provided, only corresponding module packages need to be introduced in different project development, unified api management is achieved, the problem of recycling between different systems of developers is solved, a service processing mechanism with limited capacity is enhanced, data space is saved, and timely monitoring and processing of the risk service are enhanced.

It should be noted that, a certain order does not necessarily exist between the above steps, and those skilled in the art can understand, according to the description of the embodiments of the present invention, that in different embodiments, the above steps may have different execution orders, that is, may be executed in parallel, may also be executed interchangeably, and the like.

Another embodiment of the present invention provides an alarm device, as shown in fig. 5, the device 1 includes:

a first configuration module 11, configured to pre-configure a basic policy repository, where the basic policy repository stores restriction policies for different service scenarios;

the strategy generation module 12 is used for acquiring a current service scene, acquiring a corresponding restriction strategy in the basic strategy library according to the service scene, and generating a service scene restriction strategy;

a second configuration module 13, configured to configure a service scenario according to the service scenario restriction policy;

the data acquisition module 14 is configured to acquire access data of a user when detecting that the user accesses a service scene;

and the warning module 15 is configured to generate a warning operation if it is detected that the access data of the user meets the service scenario restriction policy.

The specific implementation is shown in the method embodiment, and is not described herein again.

Another embodiment of the present invention provides an electronic device, as shown in fig. 6, an electronic device 10 includes:

one or more processors 110 and a memory 120, where one processor 110 is illustrated in fig. 6, the processor 110 and the memory 120 may be connected by a bus or other means, and fig. 6 illustrates a connection by a bus as an example.

The processor 110 is used to implement various control logic for the electronic device 10, which may be a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a single chip, an ARM (Acorn RISC machine) or other programmable logic device, discrete gate or transistor logic, discrete hardware controls, or any combination of these components. Also, the processor 110 may be any conventional processor, microprocessor, or state machine. Processor 110 may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The memory 120, which is a non-volatile computer-readable storage medium, may be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as program instructions corresponding to the alert method in the embodiments of the present invention. The processor 110 executes various functional applications and data processing of the device 10, i.e. implements the alerting method in the above-described method embodiments, by running non-volatile software programs, instructions and units stored in the memory 120.

The memory 120 may include a storage program area and a storage data area, wherein the storage program area may store an application program required for operating the device, at least one function; the storage data area may store data created according to the use of the device 10, and the like. Further, the memory 120 may include high speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, flash memory device, or other non-volatile solid state storage device. In some embodiments, memory 120 optionally includes memory located remotely from processor 110, which may be connected to device 10 via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

One or more units are stored in the memory 120, which when executed by the one or more processors 110, perform the alerting method of any of the above-described method embodiments, e.g. performing the above-described method steps S100 to S500 in fig. 1.

Embodiments of the present invention provide a non-transitory computer-readable storage medium storing computer-executable instructions for execution by one or more processors, for example, to perform method steps S100-S500 of fig. 1 described above.

By way of example, non-volatile storage media can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as Synchronous RAM (SRAM), dynamic RAM, (DRAM), Synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The disclosed memory controls or memories of the operating environments described herein are intended to comprise one or more of these and/or any other suitable types of memory.

Another embodiment of the invention provides a computer program product comprising a computer program stored on a non-volatile computer readable storage medium, the computer program comprising program instructions which, when executed by a processor, cause the processor to perform the alerting method of the above-described method embodiment. For example, the method steps S100 to S500 in fig. 1 described above are performed.

The above-described embodiments are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment.

Through the above description of the embodiments, those skilled in the art will clearly understand that the embodiments may be implemented by software plus a general hardware platform, and may also be implemented by hardware. Based on such understanding, the above technical solutions essentially or contributing to the related art can be embodied in the form of a software product, which can be stored in a computer-readable storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of the various embodiments or some parts of the embodiments.

Conditional language such as "can," "might," or "may" is generally intended to convey that a particular embodiment can include (yet other embodiments do not include) particular features, elements, and/or operations, among others, unless specifically stated otherwise or otherwise understood within the context as used. Thus, such conditional language is also generally intended to imply that features, elements, and/or operations are in any way required for one or more embodiments or that one or more embodiments must include logic for deciding, with or without input or prompting, whether such features, elements, and/or operations are included or are to be performed in any particular embodiment.

What has been described herein in the specification and drawings includes examples that enable the provision of alert methods and apparatus. It will, of course, not be possible to describe every conceivable combination of components and/or methodologies for purposes of describing the various features of the disclosure, but it can be appreciated that many further combinations and permutations of the disclosed features are possible. It is therefore evident that various modifications can be made to the disclosure without departing from the scope or spirit thereof. In addition, or in the alternative, other embodiments of the disclosure may be apparent from consideration of the specification and drawings and from practice of the disclosure as presented herein. It is intended that the examples set forth in this specification and the drawings be considered in all respects as illustrative and not restrictive. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. An alert method, the method comprising:

configuring a service scene according to a service scene limiting strategy;

2. The method of claim 1, wherein pre-configuring the base policy repository comprises:

3. The method of claim 2, wherein the obtaining the current service scenario and generating the service scenario restriction policy according to the corresponding restriction policy in the service scenario acquisition base policy repository comprises:

4. The method according to claim 3, wherein the obtaining access data of the user when detecting that the user accesses the service scenario comprises:

if not, judging that the current user passes the non-matching rule;

5. The method of claim 4, wherein the determining whether the access data of the user satisfies the service scenario restriction policy comprises:

judging whether the user meets the condition of the white list or not;

judging whether the current time meets a time limit strategy;

6. The method of claim 5, wherein generating an alert operation if it is detected that the access data of the user satisfies the traffic scenario restriction policy comprises:

7. The method of claim 5, wherein generating an alert operation if it is detected that the access data of the user satisfies the traffic scenario restriction policy comprises:

8. An alert device, the device comprising:

9. An electronic device, characterized in that the electronic device comprises at least one processor; and the number of the first and second groups,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the alert method of any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform the alert method of any one of claims 1-7.