业务策略的验证方法、装置、电子设备及可读存储介质

技术领域

本公开涉及数据处理技术领域，特别涉及一种业务策略的验证方法、装置、电子设备及可读存储介质。

背景技术

业务策略用于设定业务的执行逻辑以及执行方式。例如，在页面版式展现的业务场景中，通过不同的业务策略能够向不同的用户呈现不同形式的页面版式样式。又如，在用户资源配置的业务场景中，通过不同的业务策略能够向不同的用户配置不同的资源。总之，业务策略用于定义业务执行的方式。随着线上业务的更新，业务策略也可能发生更改。例如，在一些情况下，需要将业务策略从A策略更新为B策略。

为了确保新策略的正常运行，需要在新策略发布之前对其进行验证。在相关技术中，为了实现新旧策略的对比验证，需要将两种策略同时部署到业务生产系统中，并在业务生产系统中分别进行验证。

但是，上述方式至少存在以下缺陷：新旧策略的验证过程均在业务生产系统中实现，而业务生产系统本身还需要与上下游的业务系统进行对接，系统资源的耗费量非常大。在此基础上，容易因受到上下游业务系统的影响而导致业务生产系统本身出现故障，进而导致策略验证结果异常。

发明内容

本公开提供了一种业务策略的验证方法、装置、电子设备及可读存储介质，用于提升策略验证的准确性。

第一方面，本公开提供了一种业务策略的验证方法，包括以下步骤：

获取业务生产模块基于第一业务策略对目标业务事件执行处理后得到的第一执行结果；其中，所述业务生产模块中配置有业务生产环境，所述第一业务策略为对应于灰度版本的业务策略；

获取业务仿真模块基于第二业务策略对所述目标业务事件执行处理后得到的第二执行结果；其中，所述业务仿真模块中配置有业务仿真环境，所述第二业务策略为对应于生产版本的业务策略，且所述第一业务策略和所述第二业务策略对应于同一业务场景；

将所述第一执行结果与所述第二执行结果进行比对，根据比对结果验证所述第一业务策略的有效性。

第二方面，本公开提供了一种业务策略的验证装置，包括：

第一获取模块，适于获取业务生产模块基于第一业务策略对目标业务事件执行处理后得到的第一执行结果；其中，所述业务生产模块中配置有业务生产环境，所述第一业务策略为对应于灰度版本的业务策略；

第二获取模块，适于获取业务仿真模块基于第二业务策略对所述目标业务事件执行处理后得到的第二执行结果；其中，所述业务仿真模块中配置有业务仿真环境，所述第二业务策略为对应于生产版本的业务策略，且所述第一业务策略和所述第二业务策略对应于同一业务场景；

验证模块，适于将所述第一执行结果与所述第二执行结果进行比对，根据比对结果验证所述第一业务策略的有效性。

第三方面，本公开提供了一种电子设备，该电子设备包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的一个或多个计算机程序，一个或多个所述计算机程序被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述方法。

第四方面，本公开提供了一种计算机可读存储介质，其上存储有计算机程序，其中，所述计算机程序在被处理器/处理核执行时实现上述方法。

在本公开所提供的实施例中，首先，获取业务生产模块基于第一业务策略对目标业务事件执行处理后得到的第一执行结果；在业务生产模块中配置有业务生产环境，第一业务策略为对应于灰度版本的业务策略。然后，获取业务仿真模块基于第二业务策略对目标业务事件执行处理后得到的第二执行结果，在业务仿真模块中配置有业务仿真环境，第二业务策略为对应于生产版本的业务策略；最后，将第一执行结果与第二执行结果进行比对，根据比对结果验证第一业务策略的有效性。在本实施例中，在对新策略(即对应于灰度版本的业务策略)进行验证时，需要分别获取同一目标业务事件基于两种策略(即对应于灰度版本的业务策略以及对应于生产版本的业务策略)得到的两种执行结果，从而根据两种执行结果的比对情况来验证新策略是否有效。由于本实施例中，将目标业务事件基于生产版本的业务策略的验证过程转由业务仿真环境实现(而非直接由业务生产环境实现)，由此能够将因业务生产环境本身的异常所带来的影响降至最低，提升策略验证的准确性。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用来提供对本公开的进一步理解，并且构成说明书的一部分，与本公开的实施例一起用于解释本公开，并不构成对本公开的限制。通过参考附图对详细示例实施例进行描述，以上和其他特征和优点对本领域技术人员将变得更加显而易见，在附图中：

图1为本公开一个实施例提供的一种业务策略的验证方法的流程图；

图2示出了本申请的业务策略的验证方法的一个具体示例的流程示意图；

图3示出了图2的具体示例的系统架构图；

图4为本公开实施例提供的一种业务策略的验证装置的框图；

图5为本公开实施例提供的一种电子设备的框图。

具体实施方式

为使本领域的技术人员更好地理解本公开的技术方案，以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

在不冲突的情况下，本公开各实施例及实施例中的各特征可相互组合。

如本文所使用的，术语“和/或”包括一个或多个相关列举条目的任何和所有组合。

本文所使用的术语仅用于描述特定实施例，且不意欲限制本公开。如本文所使用的，单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术语“包括”和/或“由……制成”时，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其它特征、整体、步骤、操作、元件、组件和/或其群组。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。

除非另外限定，否则本文所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。

根据本公开实施例的业务策略的验证方法可以由终端设备或服务器等电子设备执行，终端设备可以为车载设备、用户设备(User Equipment，UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字助理(Personal Digital Assistant，PDA)、手持设备、计算设备、车载设备、可穿戴设备等；所述服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。所述方法具体可以是通过处理器调用存储器中存储的计算机程序的方式来实现。

在相关技术中，为了实现新旧策略的对比验证，需要将两种策略同时部署到业务生产系统中，并在业务生产系统中分别进行验证。但是，上述方式至少存在以下缺陷：新旧策略的验证过程均在业务生产系统中实现，而业务生产系统本身还需要与上下游的业务系统进行对接，系统资源的耗费量非常大。在此基础上，容易因受到上下游业务系统的影响而导致业务生产系统本身出现故障，进而导致策略验证结果异常。为了解决上述问题，本申请提出了一种业务策略的验证方法，通过将目标业务事件基于生产版本的业务策略的验证过程转由业务仿真环境实现(而非直接由业务生产环境实现)，由此能够将因业务生产环境本身的异常所带来的影响降至最低，提升策略验证的准确性。

图1为本公开的一个实施例提供的一种业务策略的验证方法的流程图。参照图1，该方法包括：

步骤S110：获取业务生产模块基于第一业务策略对目标业务事件执行处理后得到的第一执行结果；其中，业务生产模块中配置有业务生产环境，第一业务策略为对应于灰度版本的业务策略。

其中，业务生产模块中部署有业务生产环境。所谓业务生产环境是指面向外部用户的环境，是连接上互联网即可访问的正式环境。相应的，业务生产模块中通常需要部署对应于生产版本的业务策略，用于面向多数用户。另外，为了便于对新的业务策略进行评估测试，在本实施例中，进一步在业务生产模块中部署有对应于灰度版本的第一业务策略。

由于第一业务策略是对应于灰度版本的，因此，通常只针对部分用户开放，或者，只用于处理部分业务功能。相应的，在业务生产模块检测到业务事件的情况下，需要根据与业务事件相对应的用户标识或业务功能标识，判断该业务事件是否需要通过第一业务策略处理，若是，则确定该业务事件为目标业务事件，并基于第一业务策略对目标业务事件执行处理，得到第一执行结果。其中，第一业务策略可通过第一策略模型等方式实现，用于获取目标业务事件的事件参数，并通过第一策略模型得到与事件参数相对应的执行结果。其中，执行结果包括：审批通过、审批未通过、事件异常等各种情况，本申请不限定执行结果的具体种类和内涵。

步骤S120：获取业务仿真模块基于第二业务策略对目标业务事件执行处理后得到的第二执行结果；其中，业务仿真模块中配置有业务仿真环境，第二业务策略为对应于生产版本的业务策略，且第一业务策略和第二业务策略对应于同一业务场景。

其中，业务仿真模块可通过流量复制、事件监控等方式监测目标业务事件。并且，业务仿真模块在监测到目标业务事件的情况下，基于第二业务策略对目标业务事件执行处理，以得到第二执行结果。业务仿真模块中部署有业务仿真环境。所谓业务仿真环境，顾名思义是和真正使用的生产环境相同的环境，因此，业务仿真环境中的所有的配置情况均与业务生产环境相同。在业务仿真模块中配置有对应于生产版本的第二业务策略。由此可见，与对应于灰度版本的第一业务策略不同，第二业务策略是对应于生产版本的。并且，第一业务策略和第二业务策略均对应于同一业务场景。相应的，借助业务仿真模块，能够针对目标业务事件，基于第二业务策略进行处理，并得到第二执行结果。

因此，在本步骤中，针对步骤S110中的目标业务事件，能够通过第二业务策略进行处理。其中，第二业务策略可通过第二策略模型等方式实现，用于获取目标业务事件的事件参数，并通过第二策略模型得到与事件参数相对应的执行结果。由此可见，由于步骤S110和步骤S120中的目标业务事件为同一个业务事件，因此，其对应的事件参数是相同或相似的，步骤S110和步骤S120的主要区别在于：用于处理目标业务事件的业务策略不同。因此，本实施例能够针对同一个业务事件，分别得到两种不同的业务策略所对应的执行结果，以便于通过两种执行结果之间的异同进行验证。

步骤S130：将第一执行结果与第二执行结果进行比对，根据比对结果验证第一业务策略的有效性。

其中，本实施例的执行主体可以为检测模块。该检测模块可以独立于业务生产模块和业务仿真模块；或者，该检测模块也可以集成在业务生产模块或业务仿真模块的内部，本申请对具体实现细节不作限定。

具体的，将第一执行结果与第二执行结果进行比对，以分析第一执行结果与第二执行结果之间的相同点和不同点，从而根据比对结果验证第一业务策略是否有效。例如，若第一执行结果与第二执行结果均为审批通过，则说明第一业务策略有效，可以将对应于灰度版本的第一业务策略正式发布到生产环境中。

由此可见，在本实施例中，在对新策略(即对应于灰度版本的业务策略)进行验证时，需要分别获取同一目标业务事件基于两种策略(即对应于灰度版本的业务策略以及对应于生产版本的业务策略)得到的两种执行结果，从而根据两种执行结果的比对情况来验证新策略是否有效。由于本实施例中，将目标业务事件基于生产版本的业务策略的验证过程转由业务仿真环境实现(而非直接由业务生产环境实现)，由此能够将因业务生产环境本身的异常所带来的影响降至最低，提升策略验证的准确性。

本领域技术人员还可以针对上述实施例进行各种改动和变形，本申请不限定上述实施例的具体实现细节。

在一种可选的实现方式中，可以根据待验证的局部业务功能或局部业务特性，对待验证的目标业务事件的事件属性进行配置，从而仅针对特定类型的目标业务事件进行针对性的策略验证，避免针对全部业务事件进行验证所导致的不必要的系统开销。相应的，目标业务事件包括：事件属性信息与预先配置的待监测事件的目标属性相匹配的业务事件；其中，预先配置的待监测事件的目标属性包括：业务事件的业务渠道属性、和/或业务事件的业务功能属性。由此可见，在该方式中，在获取业务仿真模块基于第二业务策略对目标业务事件执行处理后得到的第二执行结果之前，进一步根据预先配置的待监测事件的目标属性，监测目标业务事件。其中，在监测到目标业务事件的情况下，业务仿真模块基于第二业务策略对目标业务事件执行处理。例如，在本实施例中，可以预先通过配置界面配置待监测事件的目标属性，例如，配置业务渠道属性为指定业务渠道的业务事件作为待监测的目标业务事件；又如，配置业务功能属性为指定业务功能(例如对应于某一新产品的新增业务功能)的业务事件作为待监测的目标业务事件。相应的，业务生产模块需要根据监测到的业务事件的事件属性，筛选特定类型的目标业务事件执行上述处理。在该方式中，无需在业务仿真环境中对业务生产模块基于第一业务策略处理的全部业务事件进行验证处理，只需将特定业务类型的业务事件通过流量复制的方式复制到业务仿真模块处理，从而能够提升仿真验证的针对性。

在又一种可选的实现方式中，在将第一执行结果与第二执行结果进行比对，根据比对结果验证第一业务策略的有效性时，具体通过以下方式实现：首先，获取第一执行结果中包含的第一结果指标。其中，第一结果指标用于表征目标业务事件基于第一业务策略的执行情况。例如，第一结果指标可以包括：基于第一业务策略得到的审批通过率、用户取消率或拒绝率等各类指标。然后，获取第二执行结果中包含的第二结果指标。第二结果指标可以包括：基于第二业务策略得到的审批通过率、用户取消率或拒绝率等各类指标。最后，将第一结果指标与第二结果指标进行比对，根据第一结果指标与第二结果指标之间的差值与预设阈值之间的匹配关系，确定第一业务策略是否有效。例如，将基于第一业务策略得到的审批通过率与基于第二业务策略得到的审批通过率之间的差值与预设的审批通过率阈值进行比较，若差值不大于审批通过率阈值，则说明第一业务策略是有效的(未引起审批通过率的显著波动)。

在又一种可选的实现方式中，在待监测事件中的目标属性为多个的情况下，预设阈值还可以进一步包括多个分别对应于不同目标属性的预设目标阈值。相应的，在将第一结果指标与第二结果指标进行比对，根据第一结果指标与第二结果指标之间的差值与预设阈值之间的匹配关系，确定第一业务策略是否有效时，可以分别针对每个目标属性，从第一结果指标中提取与目标属性相对应的第一目标结果指标，从第二结果指标中提取与目标属性相对应的第二目标结果指标；根据第一目标结果指标与第二目标结果指标之间的差值与预设目标阈值之间的匹配关系，确定第一业务策略中对应于目标属性的策略内容是否有效。由此可见，在目标属性为多个的情况下，在执行业务策略时，分别得到与每个目标属性相对应的目标结果指标，从而分别针对每个目标结果指标进行有效性验证。例如，假设目标属性包括多个对应于不同业务功能的属性，如支付功能属性、预览功能属性等。相应的，针对支付功能属性，根据第一业务策略确定对应于支付功能属性的第一支付结果指标，根据第二业务策略确定对应于支付功能属性的第二支付结果指标，从而根据第一支付结果指标与第二支付结果指标之间的差值与预设支付阈值之间的匹配关系，确定第一业务策略中对应于支付功能属性的策略内容是否有效。

在又一种可选的实现方式中，为了便于实现快速比对的效果，通过图表可视化的方式进行验证。相应的，第一目标结果指标与第二目标结果指标之间的差值与预设目标阈值之间的匹配关系通过以下方式确定：首先，将第一目标结果指标通过可视化图表方式展示在结果展示界面的第一展示区域；其次，将第二目标结果指标通过可视化图表方式展示在结果展示界面的第二展示区域；并且，通过可视化图表方式，确定并展示第一目标结果指标与第二目标结果指标之间的差值与预设目标阈值之间的匹配关系。由于图表可视化的展示方式更加直观，因此，借助图表展示方式能够提升比对的效率和准确性。

在又一种可选的实现方式中，业务仿真模块借助事件监听器监测业务生产模块中的目标业务事件。其中，事件监听器可通过回调函数、挂钩函数等多种方式实现。另外，还可以针对事件监听器中的待监测事件的事件参数进行配置，以使事件监听器仅针对事件参数所表征的事件属性与上文提到的目标属性相匹配的业务事件进行监听，从而便于通过对事件监听器的配置，灵活设置需要通过仿真环境进行验证的业务事件的种类和数量。另外，还可以借助事件消息队列实现业务生产模块与业务仿真模块之间的事件同步。相应的，在业务生产模块中配置有事件监听器，用于在监听到目标业务事件的情况下，将与目标业务事件相对应的事件输入数据写入事件消息队列。其中，事件输入数据包括：事件参数、事件变量和/或事件数据源。事件参数用于表征业务事件的属性或种类。事件变量是指与业务事件相关联的变量，例如，事件变量可以为：近6个月内的用户访问次数、近3个月内的用户登录次数等，由此可见，事件变量的变量值随时间推移而动态改变。事件数据源是指：事件所依据的数据来源，如事件数据源可以为第三方的数据表等。由此可见，事件输入数据是指用于执行策略处理时所需的数据内容。每个业务事件所对应的事件输入数据通过事件消息的形式依次写入事件消息队列。因此，业务仿真模块在基于第二业务策略对目标业务事件执行处理时，具体通过以下方式实现：首先，从预设的事件消息队列中获取与目标业务事件相对应的事件输入数据。然后，调用第二业务策略中包含的策略模型，对事件输入数据进行处理。其中，策略模型是指：用于运行指定业务策略的数据模型，例如，策略模型用于根据输入的事件输入数据，执行预设类型的处理，并得到输出结果。由此可见，在业务处理过程中，涉及多种复杂的数据处理过程，相应的，可以分别针对每种数据处理过程设置对应的策略模型。其中，事件输入数据中包含的数据源可能为多个，且事件输入数据中包含的事件变量也可能为多个，相应的，策略模型需要根据输入的事件输入数据中的多个数据源以及多个事件变量，执行对应的处理，以得到输出结果。另外，在一些情况中，策略模型可能需要执行多次迭代过程，方可得到最终的输出结果。例如，在策略模型针对事件输入数据中的多个数据源以及多个事件变量，执行第i次运算处理后，判断第i次运算处理的结果是否满足预设结束条件，若否，则迭代执行第i+1次运算处理，直至运算处理的结果满足预设结束条件。其中，预设结束条件可以为运算处理的结果小于预设第一阈值或大于预设第二阈值等各类模型收敛条件，具体可根据实际业务情况设置，本发明不限定预设结束条件的具体内涵。

在又一种可选的实现方式中，业务生产模块中进一步配置有第二业务策略，则业务生产模块在接收到业务事件的情况下，根据预设的事件分流策略，确定业务事件通过第一业务策略或第二业务策略处理；其中，事件分流策略包括以下中的至少一种：按比例分流策略、按事件类型分流策略。由此可见，在该方式中，业务生产模块中同时配置有对应于灰度版本的第一业务策略，以及对应于生产版本的第二业务策略，相应的，在检测到业务事件的情况下，按照事件分流策略确定当前业务事件由何种业务策略处理。其中，按比例分流策略可以配置将第一比例(如70％)的业务事件通过第二业务策略处理，将第二比例(如30％)的业务事件通过第一业务策略处理。按事件类型分流策略可以配置将第一功能类型(如支付功能类型)的业务事件通过第二业务策略处理，将第二功能类型(如预览功能类型)的业务事件通过第一业务策略处理。

在又一种可选的实现方式中，在根据比对结果验证第一业务策略的有效性之后，进一步执行以下操作：在确定第一业务策略有效的情况下，在业务生产环境中发布第一业务策略。另外，为了避免在第一业务策略发布后出现异常情况，可以在第一业务策略发布之后，进一步根据预设的指标监测策略，从第一业务策略发布后的业务运行结果中提取与预设指标相对应的指标结果，并在监测到指标结果异常的情况下，关闭第一业务策略。其中，指标监测策略用于在第一业务策略发布后评估运行结果是否正常。通过该方式，能够在监测到指标结果异常的情况下，快速关闭第一业务策略，避免线上出现大量的业务问题。若在预设时段内未监测到指标结果异常的情况，则全量发布第一业务策略。

综上可知，由于本实施例中，将目标业务事件基于生产版本的业务策略的验证过程转由业务仿真环境实现(而非直接由业务生产环境实现)，由此能够将因业务生产环境本身的异常所带来的影响降至最低，提升策略验证的准确性。并且，该方式还能够灵活配置业务生产模块中需要执行第一业务策略的业务事件的事件类型或事件比例，而且，还能够灵活设置需要在业务仿真模块中进行验证的业务事件的业务类型。另外，借助可视化图表的方式，能够提升验证效率和准确性。

为了便于理解，下面以一个具体示例为例，详细介绍本申请中的业务策略的验证方法的具体实现细节。

随着互联网的发展，传统的通过线下方式办理的业务功能逐渐可通过线上方式办理。在用户通过线上方式办理业务时，需要在线上完成用户身份验证、业务申请流程、业务审批流程以及业务处理流程等各个业务流程。线上办理业务能够极大的提升处理效率。但是，在业务审批环节，需要通过预设的业务策略进行审批验证。并且，随着业务功能的迭代更新，业务策略也需要不断地更新，以满足用户需求。例如，在风控场景中，需要根据用户的各项信息，评估用户风险等级，以降低业务风险。在该场景中需要提取用户的多维度数据信息，从综合评估该用户是否为安全用户。为了精确识别用户的安全等级，一套完善的风控审批系统需要设置复杂的风险决策过程(即业务策略)，该风险决策过程包含多个决策轮次，且每个决策轮次通常包含数据准备、变量调用、模型分析等多个环节。相应的，如何针对一套新的业务策略进行有效性验证，成为亟待解决的技术难题。

在相关技术中，主要通过下述两种方式进行策略验证：

在第一种方式中，在生产环境中进行灰度版本的业务策略的发布。相应的，生产环境中同时设置新版本业务策略(即灰度版本)和原版本业务策略(即生产版本)，通过设置灰度比例，将生产环境中的部分流量切到灰度版本进行验证。若灰度版本验证通过，则进行新版本的全量发布。但是，上述方式至少存在以下缺陷：由于新版本策略的验证过程在生产环境中实现，因此，在定位异常问题时存在干扰项：如果新版本策略发布时，审批结果显示异常，无法准确和快速地定位究竟是由新版本策略引起的问题，还是由系统本身资源或上下游系统资源的异常而导致的问题。具体原因在于：在验证新版本策略时，需要将新版本策略的执行结果与老版本策略的执行结果进行对比，根据对比结果判断新版本策略是否正常。然而，老版本策略在运行过程中可能会受到系统本身资源或上下游系统资源的异常的问题，从而导致老版本策略的审批状态异常，进而导致比对结果异常，以致使新版本策略的验证异常。

在第二种方式中，需要额外构建仿真环境，并在仿真环境中进行灰度发布。相应的，生产环境中只部署原版本业务策略，仿真环境中部署新版本业务策略，待仿真环境的测试结果达到预期效果后再将新版本业务策略部署到生产环境中。其中，针对新版本业务策略的验证方式，可采用人工日志、SQL分析等方式实现。但是，该方式至少存在以下缺陷：在新版本业务策略通过验证后，需要将新版本业务策略同步更新至生产环境中，在同步更新的过程中，可能由于误操作等原因导致最终更新至生产环境中的新版本业务策略不同于仿真环境中验证通过的新版本业务策略，进而导致异常问题。例如，在向生产环境中同步更新新版策略包时，由于人工误操作或者网络异常等原因，将导致仿真环境验证通过的灰度版本和生产环境中最终部署的版本不一致。由此可见，若在仿真环境下验证新版本符合预期，此时需自动或手动将新版本策略同步至生产环境，而该同步过程可能出现异常，若异常发现不及时，此时生产环境已全量发布新版本，那么将导致短时间内出现大量的异常审批单，若系统采取了异常补偿或者重试机制，则极端情况下会导致系统上下游压力负载过大，造成业务损失严重。另外，若生产环境中的新版本策略更新失败，则回滚操作也存在失败风险。而且，当回滚后的新版本再次发布到生产环境后需要再次进行审批验证和指标验证，从而增加了发布验证的耗时，提高了风险概率。而且，若仿真环境下验证新版本不符合预期，则需要对新版本在仿真环境下进行数据分析。而实际情况中可能存在新版本策略无误，但是由于人工误操作或者网络异常原因，而导致仿真环境策略包更新失败的问题，从而导致仿真环境中的审批状态异常，由此会增加策略验证的耗时。由此可见，由于该方式中针对新版本的策略验证过程在仿真环境中实现，而仿真环境与生产环境不同，因而需要额外增加从仿真环境向生产环境的同步过程，而该同步过程则可能导致错误，进而导致新版本的策略验证效率较低、事故问题定位较慢等一系列问题。

为了解决上述问题，提高策略发布的验证效率以及快速定位线上的事故问题点，本示例建立了一套用于模拟生产环境(而非用于模拟灰度环境)的仿真环境，用于实现新版本策略的验证。本示例通过构建仿真环境辅助灰度验证的方式，有效地降低了业务策略的发布风险，并提高了验证效率。具体方案为：在新版本策略发布前，生产环境中同时设置原版本(即生产版本)和灰度版本两套策略；仿真环境则运行原版本策略。仿真环境通过流量复制的方式实时获取灰度发布期间生产环境的提单详情，并执行流程审批，通过比对生产版本运行策略和新迭代版本(灰度版本)运行策略的审批结果，快速验证新版本策略的连通性，还可以快速定位新版本策略发布期间的事故问题点，并通过生成的比对报告，对新版本业务需求进行快速验证并提供数据服务的数据质量分析。

本示例至少具备如下优势：

首先，能够规避生产环境异常所带来的干扰。通过构建仿真环境，有效地规避了对生产版本进行验证时，由于系统资源瓶颈或者上下游系统异常导致的对版本验证的干扰。例如，如果不采用仿真环境，在新版本策略发布时，若审批结果显示异常，无法准确和快速地定位是否是新版本策略引起的问题，也有可能是系统本身资源或上下游系统的问题。

其次，针对同一个申请单(即业务事件)，可通过不同策略版本进行校验，从而实现灰度版本与原版本之间的比对验证，从而快速实现新版本策略异常验证和业务需求验证。具体为同一申请单，在生产环境采用灰度版本(新版本)策略审批，在仿真环境采用原有版本策略审批。由此可解决以下问题：一方面，通过规避生产环境的干扰的方式，可实现新版本策略的快速异常验证：同一申请单，通过对比生产环境(灰度版本)的申请单和仿真环境(原版本)的申请单的审批状态，若生产环境(灰度版本)的审批异常，则能够快速针对灰度版本的异常进行响应和处理。另一方面，借助图表可视化方式，可实现新版本业务需求的快速验证：由于一套完善的风控审批系统会经过复杂的风险决策过程，且一个决策轮次可能包含数据准备、变量调用、模型分析等多个环节。同时，完善的风控系统需要针对公司运营策略和技术指标不断迭代升级。一次策略的变更，会涉及到大量的数据服务(复杂审批系统拥有着上千个数据服务)的修改，比如数据服务的出入参修改，策略的出入参修改等操作。而为了验证每个环节的策略变更均有效，往往导致验证时间过长。本示例通过可视化操作以及指标配置操作，可自动导出比对报告，有利于实现策略改动点的快速验证。

再次，还能够规避由于二次同步更新策略所导致的异常风险：通过生产环境直接灰度发布的方式，保证了生产环境灰度验证完毕阶段，生产环境已同步了最新验证过的策略版本，无需执行从仿真环境到生产环境的同步操作。通过生产环境直接灰度发布的方式，异常单风险可控，灰度版本在预发布验证阶段采取了流量控制的方式，尽管灰度版本申请单审批异常，只要及时关闭灰度，无需进行版本回滚操作，有效降低了回滚操作的风险和异常单补偿或者重试机制对审批系统的冲击。

下面详细介绍本示例的具体实现细节：

在本示例中，共涉及到两套应用环境：生产环境和仿真环境。其中，生产环境具有以下特点：新版本策略未发布时，运行的策略包和仿真环境一致，均为老版本策略(即第二业务策略)，以OnlineVersionRegular表示；当新版本策略发布时，以灰度的方式发布，灰度版本策略(即第一业务策略)以GaryVersionRegular表示；此时生产环境运行两套策略，分别为OnlineVersionRegular和GaryVersionRegular。当新版本策略发布验证通过，生产环境运行策略包OnlineVersionRegular下线，灰度版本策略包正式生产运行GaryVersionRegular->OnlineVersionRegular。仿真环境则具有以下特点：和生产的应用系统和风控策略(OnlineVersionRegular)均保持一致；通过流量复制的方式实时获取灰度发布期间生产环境的提单详情，并通过老版本策略执行流程审批。通过比对生产运行策略OnlineVersionRegular和新迭代版本策略GaryVersionRegular的审批结果，不仅可快速验证新版本策略的连通性，还可快速定位新版本策略发布期间的事故问题点。通过生成的比对报告，后续可提供给业务方进行数据服务的数据质量分析。

图2示出了该具体示例提供的业务策略的验证方法的流程示意图。图3示出了该示例的系统架构图，如图3所示，在该示例中，配置有生产环境和仿真环境两套相互独立的环境。其中，生产环境由业务生产模块实现，仿真环境由业务仿真模块实现，并且，该系统还包括验证模块以及发布模块。其中，验证模块用于验证第一业务策略(也叫新业务策略)的有效性，发布模块用于在第一业务策略有效的情况下将第一业务策略正式发布到生产环境中。

如图2所示，该方法具体包括以下步骤：

步骤S201：在生产环境中以灰度方式运行新版本策略。

具体的，在本步骤中，需要开启灰度，并进行灰度配置。具体的，以灰度方式发布新版本的策略流程包，该策略流程包主要是对数据服务(如三方数据源、变量、模型，规则包等)的流程编排，审批系统按照流程包执行审批调用。另外，在灰度发布之前，需要执行灰度配置操作，该灰度配置操作例如可以为设置灰度比例。例如，灰度配置可按照分流比例进行配置，即：配置生产环境中需要实时分流到灰度版本的流程包的比例。并且，还可以进行灰度的开启与关闭的操作。例如，将20％的业务事件通过灰度版本的业务策略(即新版本业务策略)进行处理。

另外，还需要开启流量复制功能，具体可配置将不同维度的业务流量分流到仿真环境进行验证。其中，具体维度可通过业务渠道标识或业务产品标识进行表征。例如，可通过产品、渠道维度进行配置，也可以配置切流比例(如92％)和/或切流数量，从而灵活配置需要通过流量复制方式分流到仿真环境进行验证的业务流量。

步骤S202：在系统中配置监控指标，用于实现灰度发布后的指标验证。

其中，该监控指标主要用于监控决策数据服务的入参。具体的，监控决策数据服务的入参的原因在于：风控策略中最终影响审批结果的是决策输出，而决策输入则直接决定了决策输出，因此，监控决策数据服务的入参能够更加直接的监控异常情况。其中，决策输入是由多维度数据服务组成的，例如，包括：三方数据源、内部变量、用户数据等。所以，通过监控决策输入分析数据服务调用以及编排的方式，能够更直接的确定策略对结果的影响情况。

步骤S203：在生产环境中基于新版本策略对业务事件进行处理，并将业务事件的事件输入数据发送至消息中间件。

在生产环境中基于新版本策略对业务事件进行处理时，需要基于新版本策略对业务事件进行审批、验证等处理。其中，该消息中间件用于存储业务事件的事件输入数据，具体也可以通过事件消息队列的方式实现。其中，事件输入数据可通过提单消息获取。

步骤S204：从消息中间件中获取业务事件的事件输入数据，并在仿真环境中通过老版本策略进行处理。

其中，老版本策略即为上文提到的对应于生产版本的第二业务策略。具体的，在仿真环境中从消息中间件中获取事件输入数据，并基于老版本策略执行审批。

步骤S205：将生产环境中基于新版本策略对业务事件进行处理得到的处理结果与在仿真环境中通过老版本策略进行处理得到处理结果进行比对。

其中，可借助可视化比对工具进行比对，该可视化比对工具会分别从审批结果、审批数据服务调用流程、数据服务出入参等方面进行分析，并生成比对报告。具体的，通过可视化界面，查看新版本策略灰度发布时是否存在异常取消单。其中，异常取消单可通过业务订单的通过率、拒绝率、和/或取消率等指标进行检测。

步骤S206：根据比对结果判断新版本策略是否验证通过。

在该步骤中，可实现以下操作：例如，监控端实时监控生产环境的灰度单审批结果，如果出现大量的取消单，则发送监控告警，以研发人员和业务方进行处理。又如，在新版本业务需求的快速验证过程中，通过分析自动导出的比对报告，有利于对策略改动点的快速验证。具体验证流程可通过以下方式实现：

如果仿真环境的审批单流程正常，生产环境的灰度单流程异常，则及时关闭灰度。

如果仿真环境和生产环境的灰度审批单流程正常，则进一步通过比对报告查看步骤S202中配置的新需求变更指标(即监控指标)的指标数据是否符合预期：如果配置的监控指标的指标数据不符合预期，则暂时关闭灰度；如果配置的监控指标的指标数据符合预期，则在线上实现新版本的全量发布。

具体的，在本示例中，为了提升验证效率，通过可视化图表方式进行比对验证，具体可查看新版本策略(GaryVersionRegular-线上环境)和线上正式运行版本策略(OnlineVersionRegular-仿真环境)的审批结果对比。例如，在可视化界面中，可以分别针对每个待验证的维度，展示审批结果中的审批总数量、一致数、以及一致率等指标，并且，还可以分别展示决策输入中的一致数和一致率，以及决策输出中的一致数和一致率，并且，还可以展示流程轨迹中的总数、一致数和一致率。其中，一致数以及一致率是指：新版本策略的审批结果与老版本策略的审批结果是否相同，若相同，则一致；若不同，则不一致。因此，通过分别展示审批结果、决策输入、决策输出以及流程轨迹等维度的一致数和一致率，能够直观呈现新老版本的对比情况。

总之，通过可视化界面，能够自动导出灰度版本策略(即新版本策略)的决策入参以及线上正式运行的版本策略(即老版本策略)的决策入参之间的比对报告，以便于对新版本的更改点进行验证分析；同时，还会额外生成一份比对报告，用于展示监控变量的数据。其中，在比对报告中，可通过数据表的方式列出日期、审批轮次、变量名、申请单号、产品编号、渠道号、不一致类型、数据服务名、灰度版本值(生产环境)以及生产版本值(仿真环境)等详细描述信息。

综上可知，该示例通过可配置化的策略灰度发布方式，提高了发布的效率，且能够及时关闭新版本策略，以规避生产风险。该示例至少能够实现以下有益效果：

首先，能够实现多维度配置切流验证的效果。在生产环境中需要切流至仿真环境进行验证的业务流量可灵活配置。具体可针对性地分析新策略在不同维度(如产品维度或者渠道维度)的影响；比如新版本策略只是针对特定产品或者特定渠道进行了变更，那么在配置时，可着重配置切流相关维度的申请单进行特定的需求功能点的验证。

其次，可快速实现新版本策略的异常验证。通过审批结果可视化界面，可实时查看生产环境的申请单和仿真环境的申请单审批状态，若生产环境(灰度版本)的审批异常，仿真环境(生产版本)审批正常，则能够及时做出异常响应的判断和处理。

再次，新版本业务需求可快速验证。由于一套完善的风控审批系统会经过复杂的风险决策，一个决策轮次可能包含数据准备、变量调用、模型分析多个环节。同时，完善的风控系统需要针对运营策略和技术指标不断迭代升级。一次策略的变更，会涉及到大量的数据服务的修改，比如数据服务的出入参修改，策略的出入参修改等操作。而为了验证每个环节的策略变更均有效，往往验证时间会比较长。本示例通过可视化操作以及指标配置操作，可自动导出灰度版本策略决策入参和线上正式运行版本策略入参之间的比对报告，有利于对策略改动点的快速验证。

最后，该示例能够规避二次同步更新策略所导致的异常风险。通过生产环境直接灰度发布的方式，保证了生产环境灰度验证完毕阶段，生产环境已同步了最新验证过的策略版本。通过生产环境直接灰度发布的方式，异常单风险可控，灰度版本在预发布验证阶段采取了流量控制的方式，尽管灰度版本申请单审批异常，只要及时关闭灰度，无需进行版本回滚操作，有效降低了回滚操作的风险和异常单补偿或者重试机制对审批系统的冲击。总之，通过该示例，不仅能够进行风险验证，而且还可以进行功能需求(新增的业务功能点)的验证，能够同时实现上述两方面的验证。

图4示出了本公开实施例提供的一种业务策略的验证装置的框图。

参照图4，本公开实施例提供了一种业务策略的验证装置30，该业务策略的验证装置30包括：

第一获取模块31，适于获取业务生产模块基于第一业务策略对目标业务事件执行处理后得到的第一执行结果；其中，所述业务生产模块中配置有业务生产环境，所述第一业务策略为对应于灰度版本的业务策略；

第二获取模块32，适于获取业务仿真模块基于第二业务策略对所述目标业务事件执行处理后得到的第二执行结果；其中，所述业务仿真模块中配置有业务仿真环境，所述第二业务策略为对应于生产版本的业务策略，且所述第一业务策略和所述第二业务策略对应于同一业务场景；

验证模块33，适于将所述第一执行结果与所述第二执行结果进行比对，根据比对结果验证所述第一业务策略的有效性。

在一种可选的实现方式中，所述目标业务事件包括：事件属性与预先配置的待监测事件的目标属性相匹配的业务事件；

其中，所述预先配置的待监测事件的目标属性包括：业务事件的业务渠道属性、和/或业务事件的业务功能属性。

在一种可选的实现方式中，所述验证模块33具体适于：

获取所述第一执行结果中包含的第一结果指标；

获取所述第二执行结果中包含的第二结果指标；

将所述第一结果指标与所述第二结果指标进行比对，根据所述第一结果指标与所述第二结果指标之间的差值与预设阈值之间的匹配关系，确定所述第一业务策略是否有效。

在一种可选的实现方式中，在所述待监测事件中的目标属性为多个的情况下，所述预设阈值包括多个分别对应于不同目标属性的预设目标阈值；

所述验证模块33具体适于：

针对每个目标属性，从所述第一结果指标中提取与所述目标属性相对应的第一目标结果指标，从所述第二结果指标中提取与所述目标属性相对应的第二目标结果指标；

根据所述第一目标结果指标与所述第二目标结果指标之间的差值与预设目标阈值之间的匹配关系，确定所述第一业务策略中对应于所述目标属性的策略内容是否有效。

在一种可选的实现方式中，所述第一目标结果指标与所述第二目标结果指标之间的差值与预设目标阈值之间的匹配关系通过以下方式确定：

将所述第一目标结果指标通过可视化图表方式展示在结果展示界面的第一展示区域；

将所述第二目标结果指标通过可视化图表方式展示在结果展示界面的第二展示区域；

并且，通过可视化图表方式，确定并展示所述第一目标结果指标与所述第二目标结果指标之间的差值与预设目标阈值之间的匹配关系。

在一种可选的实现方式中，所述第二获取模块32具体适于：

从预设的事件消息队列中获取与所述目标业务事件相对应的事件输入数据；

调用所述第二业务策略中包含的策略模型，对所述事件输入数据进行处理；其中，所述事件输入数据包括：事件数据源和/或事件变量；

其中，所述业务生产模块中配置有事件监听器，用于在监听到目标业务事件的情况下，将所述与所述目标业务事件相对应的事件输入数据写入所述事件消息队列。

在一种可选的实现方式中，所述业务生产模块中进一步配置有所述第二业务策略，则所述业务生产模块在接收到业务事件的情况下，根据预设的事件分流策略，确定所述业务事件通过所述第一业务策略或所述第二业务策略处理；

其中，所述事件分流策略包括以下中的至少一种：按比例分流策略、按事件类型分流策略。

在一种可选的实现方式中，所述验证模块33还适于：

在确定所述第一业务策略有效的情况下，在所述业务生产环境中发布所述第一业务策略；

并且，进一步根据预设的指标监测策略，从所述第一业务策略发布后的业务运行结果中提取与预设指标相对应的指标结果，并在监测到所述指标结果异常的情况下，关闭所述第一业务策略。

图5为本公开实施例提供的一种电子设备的框图。

参照图5本公开实施例提供了一种电子设备，该电子设备包括：至少一个处理器501；至少一个存储器502，以及一个或多个I/O接口503，连接在处理器501与存储器502之间；其中，存储器502存储有可被至少一个处理器501执行的一个或多个计算机程序，一个或多个计算机程序被至少一个处理器501执行上述业务策略的验证方法。

本公开实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，其中，所述计算机程序在被处理器/处理核执行时实现上述的业务策略的验证方法。计算机可读存储介质可以是易失性或非易失性计算机可读存储介质。

本公开实施例还提供了一种计算机程序产品，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在电子设备的处理器中运行时，所述电子设备中的处理器执行上述业务策略的验证方法。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读存储介质上，计算机可读存储介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。

如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读程序指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM)、静态随机存取存储器(SRAM)、闪存或其他存储器技术、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读程序指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。

用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本公开的各个方面。

这里所描述的计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software DevelopmentKit，SDK)等等。

这里参照根据本公开实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。

这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。

也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。

附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本文已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和/或元素，或可与其他实施例相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本公开的范围的情况下，可进行各种形式和细节上的改变。