CN109241113A - 风险检查方法及系统 - Google Patents

Abstract

本说明书实施例提供一种风险检查方法和系统，本说明书实施例通过构建包括规则管理模块、规则引擎模块、规则查询模块以及变更检查模块的风险检测系统，能够自动查询到变更操作所对应的风险规则，并执行所查询到的风险规则，以判断该变更操作是否存在风险，同时，通过规则管理模块、规则引擎模块、规则查询模块、变更检查模块解耦合，各个模块之间相互没有强依赖，可以独立进行维护，具有较强的扩展性和维护性。

Description

风险检查方法及系统

技术领域

本说明书涉及安全检查技术领域，尤其涉及风险检查方法及系统。

背景技术

变更，可以是针对系统、业务的变更操作，比如，修改数据库、系统发布、对硬件的操作、网络配置参数调整等。针对某些变更操作，在变更操作执行后，可能出现不符合预期的系统\业务运行情况变化，导致异常\故障发生。例如，如果在10分钟内存在应用扩容的情况下，仍启动系统压测中的压力测试，则可能会导致异常\故障发生。因此，在变更操作执行前，对变更的参数、环境等进行分析，以判断是否存在变更风险显得尤为重要。

发明内容

为克服相关技术中存在的问题，本说明书提供了风险检查方法及系统。

根据本说明书实施例的第一方面，提供一种风险检查系统，所述系统包括：规则管理模块、规则引擎模块、规则查询模块、变更检查模块，各模块之间通过独立的接口进行交互；规则管理模块用于提供交互界面以配置风险规则，所述风险规则是用于判断变更操作是否存在风险的规则；规则查询模块用于提供交互界面以配置变更操作的相关数据与规则标识的映射关系；

变更检查模块用于获得在变更源执行变更操作前生成的变更检查请求，并向规则查询模块发送所述变更检查请求，变更检查请求包括所述变更操作的相关数据；

规则查询模块从预存的相关数据与规则标识的映射关系中，查询与变更检查请求中相关数据对应的规则标识，并将查询获得的规则标识反馈至变更检查模块，变更检查模块向规则引擎模块发送携带有规则标识和相关数据的规则执行请求；

规则引擎模块利用规则标识对应的风险规则，并结合所述相关数据判断变更操作是否存在风险，并将判断结果通过变更检查模块反馈至变更源。

在一个实施例中，规则管理模块将配置的风险规则、以及变更操作的相关数据与规则标识的映射关系存储在数据库中；

规则查询模块定时从数据库中查询映射关系，并将映射关系组装为内存对象存储在内存的映射关系集合中。

在一个实施例中，所述相关数据包括：变更操作所属平台、变更操作所属变更类型、变更操作的名称、执行变更操作的应用中一种或多种相关数据，每项相关数据以键名和键值构成的键值对进行存储。

在一个实施例中，所述从预存的相关数据与规则标识的映射关系中，查询与变更检查请求中相关数据对应的规则标识，包括：

从预存的相关数据与规则标识的映射关系中，确定与变更检查请求中相关数据匹配的映射关系，并从所确定的映射关系获取规则标识；

其中，针对当前映射关系，判断当前项相关数据的键值对中键值是否为用于表示包含所有情况的字符串，若是，则对当前映射关系中的下一项相关数据的键值对进行判断；若否，则查询变更检查请求中是否存在当前项相关数据的键值对；若变更检查请求中存在当前项相关数据的键值对、且当前映射关系中存在未匹配的相关数据，则将未匹配的相关数据更新为当前项相关数据，以对当前映射关系中的下一项相关数据的键值对进行判断；若变更查询请求中不存在当前项相关数据的键值对，判定当前映射关系中的相关数据与请求中相关数据不匹配。

在一个实施例中，风险规则至少包括一条风险检查策略，规则引擎模块包括规则执行子模块和策略执行子模块，策略执行子模块将不同风险检查策略采用统一接口进行封装，以供规则执行子模块调用。

根据本说明书实施例的第二方面，提供一种风险检查方法，应用于上述任一项所述风险检查系统，所述方法包括：

变更检查模块获得在变更源执行变更操作前生成的变更检查请求，并向规则查询模块发送所述变更检查请求，变更检查请求包括所述变更操作的相关数据；

规则查询模块从预存的相关数据与规则标识的映射关系中，查询与变更检查请求中相关数据对应的规则标识，并将查询获得的规则标识反馈至变更检查模块，变更检查模块向规则引擎模块发送携带有规则标识和相关数据的规则执行请求；

规则引擎模块利用规则标识对应的风险规则，并结合所述相关数据判断变更操作是否存在风险，并将判断结果通过变更检查模块反馈至变更源。

在一个实施例中，所述相关数据包括：变更操作所属平台、变更操作所属变更类型、变更操作的名称、执行变更操作的应用中一种或多种相关数据，每项相关数据以键名和键值构成的键值对进行存储。

在一个实施例中，所述从预存的相关数据与规则标识的映射关系中，查询与变更检查请求中相关数据对应的规则标识，包括：

从预存的相关数据与规则标识的映射关系中，确定与变更检查请求中相关数据匹配的映射关系，并从所确定的映射关系获取规则标识；

其中，针对当前映射关系，判断当前项相关数据的键值对中键值是否为用于表示包含所有情况的字符串，若是，则对当前映射关系中的下一项相关数据的键值对进行判断；若否，则查询变更检查请求中是否存在当前项相关数据的键值对；若变更检查请求中存在当前项相关数据的键值对、且当前映射关系中存在未匹配的相关数据，则将未匹配的相关数据更新为当前项相关数据，以对当前映射关系中的下一项相关数据的键值对进行判断；若变更查询请求中不存在当前项相关数据的键值对，判定当前映射关系中的相关数据与请求中相关数据不匹配。

本说明书的实施例提供的技术方案可以包括以下有益效果：

本说明书实施例通过构建包括规则管理模块、规则引擎模块、规则查询模块以及变更检查模块的风险检测系统，能够自动查询到变更操作所对应的风险规则，并执行所查询到的风险规则，以判断该变更操作是否存在风险，同时，通过规则管理模块、规则引擎模块、规则查询模块、变更检查模块解耦合，各个模块之间相互没有强依赖，可以独立进行维护，具有较强的扩展性和维护性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本说明书的实施例，并与说明书一起用于解释本说明书的原理。

图1是本说明书根据一示例性实施例示出的一种风险检查系统的结构示意图。

图2是本说明书根据一示例性实施例示出的一种风险检查方法的流程图。

图3A是本说明书根据一示例性实施例示出的一种规则配置部分界面示意图。

图3B是本说明书根据一示例性实施例示出的一种策略配置部分界面示意图。

图3C是本说明书根据一示例性实施例示出的一种规则处理流程示意图。

图3D是本说明书根据一示例性实施例示出的一种类结构示意图。

图3E是本说明书根据一示例性实施例示出的一种触发模型配置界面示意图。

图3F是本说明书根据一示例性实施例示出的一种规则查询示意图。

图4A是本说明书根据一示例性实施例示出的另一种风险检测方法流程图。

图4B是本说明书根据一示例性实施例示出的一种数据设计模型示意图。

图5是本说明书根据一示例性实施例示出的一种风险检查系统所在计算机设备的一种硬件结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。

在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

首先对本说明书涉及的技术用语进行解释。

变更，可以是一次针对某个系统、业务的操作，比如修改数据库数据，发布系统，硬件操作，网络配置调整等。

变更类型，每次变更都属于某一类的变更，比如db变更，发布变更，网络变更都是不同的变更类型。每种变更类型可以设有类型ID。

风险，当执行变更操作后，可能出现不符合预期的系统\业务运行情况变化，导致异常\故障发生，可以称为变更的风险。

风险检查，在变更执行前，系统自动对变更操作所涉及的参数、环境等进行分析，判断是否存在风险的处理过程。

规则触发模型，一个变更对应一个或多个风险规则，变更与风险规则的对应关系可以称为规则触发模型。

业务部门日常会进行各类变更操作，而某些变更操作可能存在各种风险，会对线上业务带来稳定性隐患，因此可以在执行变更操作前，先经过风险检查，通过风险检查的变更操作才被允许执行，而未通过风险检查的变更操作不允许执行。然而实际应用中，变更操作的数量较大，若通过人工介入进行变更风险检查，人工成本高、耗时很长、且很容易疏漏。

鉴于此，本说明书提供一种风险检测系统，通过系统能够自动查询到变更操作所对应的风险规则，并执行所查询到的风险规则，以判断该变更操作是否存在风险，相比传统的人工进行风险把控，在效率、准确性和可靠性上都有着本质的提升。同时，通过规则管理模块、规则引擎模块、规则查询模块、变更检查模块解耦合，各个模块之间相互没有强依赖，可以独立进行维护，具有较强的扩展性和维护性。以下结合附图对本说明书实施例进行示例说明。

如图1所示，是本说明书根据一示例性实施例示出的一种风险检查系统的结构示意图，所述系统包括：规则管理模块120、规则引擎模块140、规则查询模块160、变更检查模块180，各模块之间通过独立的接口进行交互。变更检查模块可以向外部变更源提供检查服务，可以接收检查请求，并调用规则查询模块、规则引擎模块完成具体的检查逻辑处理，得到结果后返回给变更源。可以理解的是，本说明书风险检查系统中各模块可以布局在同一设备中，也可以布局在不同设备中。规则管理模块120用于提供交互界面以配置风险规则，所述风险规则是用于判断变更操作是否存在风险的规则。规则查询模块160用于提供交互界面以配置变更操作的相关数据与规则标识的映射关系。变更检查模块180获得在变更源执行变更操作前生成的变更检查请求，并向规则查询模块160发送所述变更检查请求，变更检查请求包括所述变更操作的相关数据。规则查询模块160从预存的相关数据与规则标识的映射关系中，查询与变更检查请求中相关数据对应的规则标识，并将查询获得的规则标识反馈至变更检查模块180，变更检查模块180向规则引擎模块140发送携带有规则标识和相关数据的规则执行请求。规则引擎模块140利用规则标识对应的风险规则，并结合所述相关数据判断变更操作是否存在风险，并将判断结果通过变更检查模块反馈至变更源。

相应的，本说明书还提供一种依赖于本说明书风险检查系统而实现的风险检查方法。如图2所示，是本说明书根据一示例性实施例示出的一种风险检查方法的流程图。所述方法包括：

变更检查模块获得在变更源执行变更操作前生成的变更检查请求(步骤200)，并向规则查询模块发送所述变更检查请求(步骤202)，变更检查请求包括所述变更操作的相关数据。

规则查询模块从预存的相关数据与规则标识的映射关系中，查询与变更检查请求中相关数据对应的规则标识(步骤204)，并将查询获得的规则标识反馈至变更检查模块(步骤206)，变更检查模块向规则引擎模块发送携带有规则标识和相关数据的规则执行请求(步骤208)。

规则引擎模块利用规则标识对应的风险规则，并结合所述相关数据判断变更操作是否存在风险(步骤210)，并将判断结果通过变更检查模块反馈至变更源(步骤212和214)，以便变更源根据判断结果判定是否继续执行变更操作。

接下来对各模块进行示例说明。

规则管理模块可以用于提供交互界面以配置风险规则、以及变更操作的相关数据与规则标识的映射关系。其中，风险规则是用于判断变更操作是否存在风险的规则，可以是系统能够理解的完整数据模型，描述风险检查中固定的检查内容。风险规则至少包括一条风险检查策略，而风险检查策略可以是系统能够理解的数据模型，描述风险检查中一条检查逻辑。变更操作的相关数据，可以是用于判断变更操作是否具有风险时所需的、与变更操作相关的数据。可见，变更操作的相关数据基于风险规则中的判断逻辑所需数据而定。在一个例子中，所述相关数据可以包括：变更操作所属平台、变更操作所属变更类型、变更操作的名称、执行变更操作的应用中一种或多种相关数据。相关数据也可以称为变更操作的基本数据，或者变更数据。规则标识可以是唯一标识风险规则的标识，例如，可以是规则ID。

在一个实施例中，规则管理模块可以包括规则模型和策略模型。规则模型用于通过UI界面维护规则的基本信息。如图3A所示，是本说明书根据一示例性实施例示出的一种规则配置部分界面示意图。可以理解的是，该附图仅进行部分示意，操作人员可以在该界面配置规则的名称，如“压测变更检查规则”，故障等级、规则状态等。然后可以进入下一界面配置规则所包括的策略。在规则模型提交后，可以将规则的详情信息存储在数据库规则模型表中，表结构可以定义如下：

本条风险规则描述需对压测变更进行风险检查。

相应的，策略模型也可以采用UI界面维护与规则关联的策略信息。如图3B所示，是本说明书根据一示例性实施例示出的一种策略配置部分界面示意图。可以理解的是，该附图仅进行部分示意，操作人员可以在该界面配置规则的策略信息。例如，策略ID、策略类型、策略摘要、策略间关系等等。策略信息提交后，可以将其存储在数据库规则策略表中，表结构可定义如下：

该条策略用于描述要判断10分钟内是否存在应用扩容，如果有应用扩容，则不允许压测。

规则引擎模块用于执行规则内容，并将执行结果反馈至调用方。在一个实施例中，规则引擎模块可以包含规则执行子模块(又可以称为规则执行器)和策略执行子模块(又可以称为策略执行器)。规则执行器可以负责串联整个规则处理过程，以及读取规则和策略配置。如图3C所示，是本说明书根据一示例性实施例示出的一种规则处理流程示意图。在该实施例中，可以根据规则标识读取风险规则，遍历该风险规则中的策略，并调用策略对应的策略处理器执行策略，在所有策略执行完成后，组装结果，并将结果反馈至调用方。

在一个实施例中，为了实现动态扩展，策略执行子模块可以将不同风险检查策略采用统一接口进行封装，以供规则执行子模块调用。不同的策略，可以由不同的策略处理器完成处理。在一个例子中，每个策略处理器可以采用StrategyProcessor接口，并实现process方法，具体的业务逻辑方法在process里实现。如图3D所示，是本说明书根据一示例性实施例示出的一种类结构示意图。策略处理器可以包括数据查询、逻辑判断等处理逻辑。通过灵活的类结构设计，可以动态扩展不同的策略处理逻辑。图3D中的3个策略处理器可以是固定逻辑。针对复杂、容易变化的逻辑，还可以通过groovy脚本实现StrategyProcessor或者继承AbstractStrategyProcessor，则能够被规则引擎识别并进行处理。

关于规则查询模块，规则查询模块可以在用于配置变更操作的相关数据与规则标识的映射关系。在接收到变更检查请求时，可以从预存的相关数据与规则标识的映射关系中，查询与变更检查请求中相关数据对应的规则标识。规则查询模块可以将变更操作的相关数据与规则标识的映射关系存储在数据库中。在一个例子中，在规则查询模块需要查询规则时，可以从数据库中查询。在另一个例子中，为了提高查询效率，规则查询模块可以定时从数据库中查询映射关系，并将映射关系组装为内存对象存储在内存的映射关系集合中，以便后续查询时直接从内存中查询，提高查询效率。

在一个实施例中，规则查询模块可以包括触发模型配置子模块、触发模型缓存子模块以及规则查询触发子模块(又可以称为规则查询器)。在该实施例中，一个变更可能对应一个或多个风险规则，将变更与风险规则的对应关系可以称为触发模型。触发模型中包括变更操作的相关数据与规则标识的映射关系。触发模型配置子模块可以提供交互界面以配置触发模型。例如，如图3E所示，是本说明书根据一示例性实施例示出的一种触发模型配置界面示意图。在该实施例中，通过UI界面维护触发模型的基本信息，在接收到提交指令时，可以将触发模型(变更与风险规则的对应关系)存储在数据库表中，表结构定义如下：

本条触发模型用于描述：如果是压测平台的系统压测中的压测启动操作，并且是针对abc系统的，则匹配到ID是20的规则。

变更操作的相关数据与规则标识的映射关系可以从触发模型中获取。例如，可以将上述触发配置项的数据作为变更操作的相关数据。

在触发模型缓存子模块中，触发模型刷新器(Rule Rigger Refresher)可以定时从数据库中查询出触发模型，组装为内存对象，并存储在集合对象Rule Rigger Cache中。

规则查询器可以根据变更检查请求中的参数，到触发模型缓存子模块中，查找到匹配的触发模型，然后根据触发模型中的规则ID，找到对应的规则模型。

在一个实施例中，每项相关数据以键名(key)和键值(value)构成的键值对进行存储。所述从预存的相关数据与规则标识的映射关系中，查询与变更检查请求中相关数据对应的规则标识，可以包括：

从预存的相关数据与规则标识的映射关系中，确定与变更检查请求中相关数据匹配的映射关系，并从所确定的映射关系获取规则标识；

其中，针对当前映射关系，判断当前项相关数据的键值对中键值是否为用于表示包含所有情况的字符串，若是，则对当前映射关系中的下一项相关数据的键值对进行判断；若否，则查询变更检查请求中是否存在当前项相关数据的键值对；若变更检查请求中存在当前项相关数据的键值对、且当前映射关系中存在未匹配的相关数据，则将未匹配的相关数据更新为当前项相关数据，以对当前映射关系中的下一项相关数据的键值对进行判断；若变更查询请求中不存在当前项相关数据的键值对，判定当前映射关系中的相关数据与请求中相关数据不匹配。

为了方便理解，结合图3F进行示例说明。图3F是本说明书根据一示例性实施例示出的一种规则查询示意图。在该实施例中，利用all表示包含所有情况的字符串，即表示该项相关数据的键值不受限制，可以为任意值。在接收到变更检查请求后，可以获取缓存内所有触发模型，获得触发模型列表。针对每个触发模型，可以从触发模型中提取变更操作的相关数据的键值对，获得键值对列表。可见，每个触发模型对应一个键值对列表。针对当前键值对，判断键名所对应键值是否为all，如果是，则继续下一项键值对判断。如果否，则判断变更检查请求中是否存在当前键值对的键名，如果不存在，则继续下一个触发模型的判断，即进行下一个键值对列表的判断。如果存在，则继续判断变更检查请求中该键名对应的键值是否与当前键值对的键值匹配，如果键值匹配，则判断触发模型中的所有键值对是否匹配完成，如果匹配完成，则将该触发模型作为与变更检查请求匹配的触发模型。如果键值不匹配，则判定该触发模型不匹配，继续下一个触发模型的判断。

规则触发模型中相关信息(如触发配置中的信息)和当前变更检查请求中的相关信息完全匹配时，则认为触发模型匹配当前变更检查请求，触发模型中的规则ID为当前变更检查请求需要执行的规则的ID。

关于变更检查模块，可以向外部变更源提供检查服务，主要完成接收检查请求，并调用规则查询模块、规则引擎模块完成具体检查逻辑处理，并将得到的结果反馈至变更源。

其中，变更源是否执行变更操作，可以由变更源通知变更检查模块，也可以由变更检查模块检测确定。变更检查请求可以由变更源发送给变更检查模块，也可以由变更检查模块根据变更源待执行的变更操作而生成。变更检查模块可以将变更检查请求以以下方式进行存储，例如：

该请求描述了变更的详细信息，变更检查模块可以按照请求中的字段匹配到合适的触发模型，从而获得规则标识，进而调用规则引擎检测变更操作是否有风险。规则引擎可以将检查结果反馈至变更检查模块，以便变更检查模块将结果反馈至变更源。

例如，检查结果可以为下表：

该结果描述了风险检查结果，该压测操作无风险，变更源可以继续执行变更操作。

由上述实施例可见，通过风险规则模型配置、触发模型配置、触发模型缓存、触发模型匹配、获取规则、执行规则、结果组装，实现变更风险检查的目的。

以上实施方式中的各种技术特征可以任意进行组合，只要特征之间的组合不存在冲突或矛盾，但是限于篇幅，未进行一一描述，因此上述实施方式中的各种技术特征的任意进行组合也属于本说明书公开的范围。

以下以其中一种组合进行示例说明。

如图4A所示，是本说明书根据一示例性实施例示出的另一种风险检测方法流程图。在该实施例中，操作员可以基于规则管理模块提供的交互界面配置风险检查规则模型，基于触发模型配置子模块对规则模型配置触发模型。在检查系统启动时，规则查询模块定时从数据库中查询映射关系，并将映射关系组装为内存对象存储在内存的映射关系集合中。例如，在检查系统启动时，通过查询触发模型列表，以判断是否有新的触发模型，若存在新的触发模型，将触发模型组装为内存对象，更新到缓存中。判断刷新器是否启动，若刷新器未启动，则启动刷新器以刷新缓存。

在应用阶段，变更源发起变更后，变更源请求调用变更检查API，并将变更数据传递至检查服务。变更检查API可以将接收到的请求转换为本系统所能识别的格式数据，可以将其称为变更检查请求，或者请求模型。检查服务根据所接收数据调用规则查询器，从缓存中查询与请求匹配的触发模型，并从触发模型中获取规则模型，调用规则引擎执行风险规则。例如，检查服务可以根据请求中的相关数据，调用规则查询器查找与请求匹配的触发模型，进而从匹配的触发模型中获得本请求所对应的规则标识。调用规则引擎执行规则标识对应的风险规则。规则引擎执行规则模型，将得到的执行结果返回至调用方(检测服务)。检查服务将执行结果通过检查API反馈至变更源。检查API可以将执行结果转换为变更源可识别的格式数据，并反馈至变更源。变更源得到检查结果，按照结果确定继续执行变更或者终止变更。图4B所示，是本说明书根据一示例性实施例示出的一种数据设计模型示意图。通过数据设计建模的实现，并结合系统处理流程，实现变更检查的规则化、自动化和系统化。

与前述风险检查方法的实施例相对应，本说明书还提供了系统所应用的电子设备的实施例。

本说明书风险检查系统的实施例可以应用在计算机设备。系统实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的系统，是通过其所在计算机设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图5所示，为本说明书风险检查系统所在计算机设备的一种硬件结构图，除了图5所示的处理器510、网络接口520、内存530、以及非易失性存储器540之外，实施例中风险检查系统531所在的计算机设备通常根据该设备的实际功能，还可以包括其他硬件，对此不再赘述。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书实施例可采用在一个或多个其中包含有程序代码的存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。计算机可用存储介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括但不限于：相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。

应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (8)

1.一种风险检查系统，所述系统包括：规则管理模块、规则引擎模块、规则查询模块、变更检查模块，各模块之间通过独立的接口进行交互；规则管理模块用于提供交互界面以配置风险规则，所述风险规则是用于判断变更操作是否存在风险的规则；规则查询模块用于提供交互界面以配置变更操作的相关数据与规则标识的映射关系；

变更检查模块用于获得在变更源执行变更操作前生成的变更检查请求，并向规则查询模块发送所述变更检查请求，变更检查请求包括所述变更操作的相关数据；

规则查询模块从预存的相关数据与规则标识的映射关系中，查询与变更检查请求中相关数据对应的规则标识，并将查询获得的规则标识反馈至变更检查模块，变更检查模块向规则引擎模块发送携带有规则标识和相关数据的规则执行请求；

规则引擎模块利用规则标识对应的风险规则，并结合所述相关数据判断变更操作是否存在风险，并将判断结果通过变更检查模块反馈至变更源。

2.根据权利要求1所述的系统，规则管理模块将配置的风险规则、以及变更操作的相关数据与规则标识的映射关系存储在数据库中；

规则查询模块定时从数据库中查询映射关系，并将映射关系组装为内存对象存储在内存的映射关系集合中。

3.根据权利要求1所述的系统，所述相关数据包括：变更操作所属平台、变更操作所属变更类型、变更操作的名称、执行变更操作的应用中一种或多种相关数据，每项相关数据以键名和键值构成的键值对进行存储。

4.根据权利要求3所述的系统，所述从预存的相关数据与规则标识的映射关系中，查询与变更检查请求中相关数据对应的规则标识，包括：

从预存的相关数据与规则标识的映射关系中，确定与变更检查请求中相关数据匹配的映射关系，并从所确定的映射关系获取规则标识；

其中，针对当前映射关系，判断当前项相关数据的键值对中键值是否为用于表示包含所有情况的字符串，若是，则对当前映射关系中的下一项相关数据的键值对进行判断；若否，则查询变更检查请求中是否存在当前项相关数据的键值对；若变更检查请求中存在当前项相关数据的键值对、且当前映射关系中存在未匹配的相关数据，则将未匹配的相关数据更新为当前项相关数据，以对当前映射关系中的下一项相关数据的键值对进行判断；若变更查询请求中不存在当前项相关数据的键值对，判定当前映射关系中的相关数据与请求中相关数据不匹配。

5.根据权利要求1至4任一项所述的系统，风险规则至少包括一条风险检查策略，规则引擎模块包括规则执行子模块和策略执行子模块，策略执行子模块将不同风险检查策略采用统一接口进行封装，以供规则执行子模块调用。

6.一种风险检查方法，应用于权利要求1至5任一项所述风险检查系统，所述方法包括：

变更检查模块获得在变更源执行变更操作前生成的变更检查请求，并向规则查询模块发送所述变更检查请求，变更检查请求包括所述变更操作的相关数据；

规则查询模块从预存的相关数据与规则标识的映射关系中，查询与变更检查请求中相关数据对应的规则标识，并将查询获得的规则标识反馈至变更检查模块，变更检查模块向规则引擎模块发送携带有规则标识和相关数据的规则执行请求；

规则引擎模块利用规则标识对应的风险规则，并结合所述相关数据判断变更操作是否存在风险，并将判断结果通过变更检查模块反馈至变更源。

7.根据权利要求6所述的方法，所述相关数据包括：变更操作所属平台、变更操作所属变更类型、变更操作的名称、执行变更操作的应用中一种或多种相关数据，每项相关数据以键名和键值构成的键值对进行存储。

8.根据权利要求7所述的方法，所述从预存的相关数据与规则标识的映射关系中，查询与变更检查请求中相关数据对应的规则标识，包括：

从预存的相关数据与规则标识的映射关系中，确定与变更检查请求中相关数据匹配的映射关系，并从所确定的映射关系获取规则标识；

其中，针对当前映射关系，判断当前项相关数据的键值对中键值是否为用于表示包含所有情况的字符串，若是，则对当前映射关系中的下一项相关数据的键值对进行判断；若否，则查询变更检查请求中是否存在当前项相关数据的键值对；若变更检查请求中存在当前项相关数据的键值对、且当前映射关系中存在未匹配的相关数据，则将未匹配的相关数据更新为当前项相关数据，以对当前映射关系中的下一项相关数据的键值对进行判断；若变更查询请求中不存在当前项相关数据的键值对，判定当前映射关系中的相关数据与请求中相关数据不匹配。