故障预警信息的确定方法、装置、存储介质及电子设备

技术领域

本发明涉及金融科技或其他相关领域，具体而言，涉及一种故障预警信息的确定方法、装置、存储介质及电子设备。

背景技术

随着科技的不断发展，越来越多的用户通过手机、电子手表等设备与商户之间进行交易处理，银行作为收单方，与商户之间的业务交互也随之更加频繁。然而，目前相关技术中缺乏金融机构为商户办理业务时的故障预警方法，无法及时发现故障，从而无法及时为用户提供相关业务服务，影响用户体验。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种故障预警信息的确定方法、装置、存储介质及电子设备，以至少解决相关技术中缺乏金融机构为商户办理业务时的故障预警方法，从而存在无法及时发现故障的技术问题。

根据本发明实施例的一个方面，提供了一种故障预警信息的确定方法，包括：获取金融机构为多个商户办理金融业务时的业务数据，其中，金融业务由与商户进行交互的用户通过商户向金融机构发起；对于每个商户，确定商户匹配的各个业务数据对应的交互渠道，其中，交互渠道是指金融机构与商户之间传输业务数据时使用的渠道；根据商户匹配的业务数据，计算商户在各个交互渠道下匹配的业务办理成功率，并根据商户在各个交互渠道下匹配的业务办理成功率，确定故障预警信息，其中，故障预警信息用于表征金融机构为商户办理金融业务时是否存在故障。

进一步地，故障预警信息的确定方法还包括：对于每个交互渠道，确定交互渠道匹配的各个业务数据所对应的业务场景；对于交互渠道下的每个业务场景，根据商户在各个时间间隔内在交互渠道下的业务场景下匹配的业务数据，计算商户在各个时间间隔内在交互渠道下的业务场景下匹配的业务办理成功率，得到多个目标业务办理成功率；对于每个交互渠道，根据商户在交互渠道下的目标业务办理成功率，确定子预警信息，其中，子预警信息至少用于表征金融机构通过交互渠道为商户办理金融业务时是否存在故障；根据商户在各个交互渠道下匹配的子预警信息，确定故障预警信息。

进一步地，多个目标业务办理成功率为实时确定的，其中，故障预警信息的确定方法还包括：在每得到一个时间间隔匹配的目标业务办理成功率的情况下，比较目标业务办理成功率与预设的目标成功率之间的大小；若目标业务办理成功率小于目标成功率，则对商户在目标业务场景下的异常程度值进行更新操作，得到更新后的异常程度值，其中，异常程度值的初始值为预设值，目标业务场景为交互渠道下目标业务办理成功率匹配的业务场景；在更新后的异常程度值大于或等于预设程度值的情况下，确定子预警信息表征金融机构通过交互渠道为商户办理金融业务时存在故障。

进一步地，故障预警信息的确定方法还包括：在得到更新后的异常程度值之后，确定时间间隔的序位N；在N等于预设数值的情况下，若交互渠道下所有业务场景下的异常程度值均小于预设程度值，则确定子预警信息表征金融机构通过交互渠道为商户办理金融业务时不存在故障，并确定下一个时间间隔的序位N为1，将商户在各个业务场景下的异常程度值更新为预设值，其中，预设数值大于1。

进一步地，故障预警信息的确定方法还包括：若各个子预警信息均表征金融机构通过交互渠道为商户办理金融业务时不存在故障，则确定故障预警信息表征金融机构为商户办理金融业务时不存在故障；若存在表征金融机构通过交互渠道为商户办理金融业务时存在故障的子预警信息，则确定故障预警信息表征金融机构为商户办理金融业务时存在故障。

进一步地，故障预警信息的确定方法还包括：在确定子预警信息之后，在子预警信息表征金融机构通过交互渠道为商户办理金融业务时存在故障的情况下，采用以下方式中的至少之一进行故障诊断：利用预设的故障诊断规则对商户在目标时间间隔内在目标交互渠道下的业务数据进行故障诊断，得到故障诊断结果，其中，目标时间间隔包括使得异常程度值更新至大于或等于预设程度值的时间间隔，目标交互渠道为子预警信息匹配的交互渠道，故障诊断结果包括故障类型；获取金融机构内的业务服务器在目标时间间隔内的运行指标，并在运行指标中存在异常指标值的情况下，根据异常指标值确定故障诊断结果，其中，业务服务器用于办理金融业务；获取业务服务器在目标时间间隔内处理目标交互渠道下的金融业务时的处理状态数据，并在处理状态数据中存在异常数据的情况下，根据异常数据确定故障诊断结果，其中，处理状态数据至少包括业务服务器的业务处理耗时数据。

进一步地，故障预警信息的确定方法还包括：从故障诊断结果中提取故障类型；获取预设的故障类型与故障处理规则的对应关系，并从对应关系中确定提取的故障类型匹配的目标故障处理规则；根据目标故障处理规则对金融机构进行故障处理。

根据本发明实施例的另一方面，还提供了一种故障预警信息的确定装置，包括：第一获取模块，用于获取金融机构为多个商户办理金融业务时的业务数据，其中，金融业务由与商户进行交互的用户通过商户向金融机构发起；第一确定模块，用于对于每个商户，确定商户匹配的各个业务数据对应的交互渠道，其中，交互渠道是指金融机构与商户之间传输业务数据时使用的渠道；计算模块，用于根据商户匹配的业务数据，计算商户在各个交互渠道下匹配的业务办理成功率，并根据商户在各个交互渠道下匹配的业务办理成功率，确定故障预警信息，其中，故障预警信息用于表征金融机构为商户办理金融业务时是否存在故障。

根据本发明实施例的另一方面，还提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行上述的故障预警信息的确定方法。

根据本发明实施例的另一方面，还提供了一种电子设备，电子设备包括一个或多个处理器；存储器，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现用于运行程序，其中，程序被设置为运行时执行上述的故障预警信息的确定方法。

在本发明实施例中，采用根据业务办理成功率确定故障预警信息的方式，通过获取金融机构为多个商户办理金融业务时的业务数据，然后对于每个商户，确定商户匹配的各个业务数据对应的交互渠道，从而根据商户匹配的业务数据，计算商户在各个交互渠道下匹配的业务办理成功率，并根据商户在各个交互渠道下匹配的业务办理成功率，确定故障预警信息。其中，金融业务由与商户进行交互的用户通过商户向金融机构发起，交互渠道是指金融机构与商户之间传输业务数据时使用的渠道，故障预警信息用于表征金融机构为商户办理金融业务时是否存在故障。

容易注意到的是，在上述过程中，通过根据业务办理成功率，确定故障预警信息，实现了根据金融机构对金融业务的办理结果确定金融机构办理业务时是否存在故障，从而实现了对故障预警信息的准确确定，进而能够及时发现故障。进一步地，通过计算商户在各个交互渠道下匹配的业务办理成功率，然后根据商户在各个交互渠道下匹配的业务办理成功率确定故障预警信息，实现了从更细粒度上对金融机构办理业务时是否存在故障进行判断，从而更进一步地提高了确定故障预警信息的准确性。

由此可见，本申请所提供的方案达到了根据业务办理成功率确定故障预警信息的目的，从而实现了及时发现故障的技术效果，进而解决了相关技术中缺乏金融机构为商户办理业务时的故障预警方法，从而存在无法及时发现故障的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的一种可选的故障预警信息的确定方法的示意图；

图2是根据本发明实施例的一种可选的目标预警系统的示意图；

图3是根据本发明实施例的一种可选的获取业务数据的示意图；

图4是根据本发明实施例的一种可选的预警中心的工作示意图；

图5是根据本发明实施例的一种可选的监控中心的示意图；

图6是根据本发明实施例的一种可选的监控中心的工作示意图；

图7是根据本发明实施例的一种可选的故障预警信息的确定装置的示意图；

图8是根据本发明实施例的一种可选的电子设备的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，本公开的故障预警信息的确定方法、装置、存储介质及电子设备可用于金融科技领域，也可用于除金融科技领域之外的任意领域，本公开的故障预警信息的确定方法、装置、存储介质及电子设备的应用领域不做限定。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

实施例1

根据本发明实施例，提供了一种故障预警信息的确定方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本发明实施例的一种可选的故障预警信息的确定方法的示意图，如图1所示，该方法包括如下步骤：

步骤S101，获取金融机构为多个商户办理金融业务时的业务数据，其中，金融业务由与商户进行交互的用户通过商户向金融机构发起。

可选的，可以将电子设备、应用系统、服务器等装置作为本申请的执行主体。在本实施例中，将目标预警系统作为执行主体以获取前述的业务数据。其中，当用户通过设备终端与商户进行交互以办理消费(也即交易)、查询付款进度、退款等金融业务时，商户向金融机构发起相关的业务请求，以请求金融机构处理相关金融业务。金融机构办理金融业务时的业务数据包括但不限于商户发送至金融机构的数据、金融机构在办理金融业务时生成的数据、金融机构发送给商户的数据等。

可选的，在本实施例中，图2是根据本发明实施例的一种可选的目标预警系统的示意图，如图2所示，目标预警系统可以是设置在金融机构中，目标预警系统包括交易集群、监控中心和预警中心，交易集群由多个服务器(即图2中的服务器1-N)组成，分为由若干虚拟服务器组成的交易路由层和由若干业务服务器、数据库服务器组成的业务处理层，业务请求从交易路由层进来，然后路由到下一层业务处理层，业务处理层用于处理金融业务。进一步地，业务处理层可以在处理金融业务时将业务数据通过Kafka实时推送给监控中心，其中，Kafka是一种高吞吐量的分布式发布订阅消息系统，监控中心用于对业务数据进行持久化存储以及可视化展示，预警中心用于采集监控中心存储的业务数据，并根据业务数据确定故障预警信息。

其中，图3是根据本发明实施例的一种可选的获取业务数据的示意图，如图3所示，交易集群通过引入业务监控日志构件，利用拦截器、切面、扩展插件、公共方法等方式对业务处理层中的业务服务器和数据库服务器的多个接口进行监控，以拦截接口接收或发送的报文，并对报文中所需要的数据进行标准化格式改造，从而得到图3中所示出的“服务化被调用日志”、“服务化调用日志”、“其他外部依赖日志”以及“数据库操作日志”，其中，“服务化被调用日志”、“服务化调用日志”、“其他外部依赖日志”以及“数据库操作日志”中的数据共同组成业务数据，业务数据包括但不限于业务请求时间、业务ID、业务耗时、业务返回码、交互渠道、业务场景等。并且，如图3所示，“服务化被调用日志”、“服务化调用日志”、“其他外部依赖日志”以及“数据库操作日志”均可分为开始日志和结束日志，开始日志中的业务数据是根据相关接口接收的报文中的数据确定的，结束日志中的业务数据是根据相关接口发送的报文中的数据确定的。

步骤S102，对于每个商户，确定商户匹配的各个业务数据对应的交互渠道，其中，交互渠道是指金融机构与商户之间传输业务数据时使用的渠道。

可选的，图4是根据本发明实施例的一种可选的预警中心的工作示意图，如图4所示，对于每个商户，目标预警系统中的预警中心可以从监控中心获取该商户的多个业务数据，然后根据每个业务数据中的内容确定该业务数据对应的交互渠道。例如，若用户在某一商户进行消费时，通过某一第三方支付渠道使用用户在金融机构中办理的消费卡，则前述的第三方支付渠道即为交互渠道，商户与金融机构之间通过该第三方支付渠道传输用户消费时的业务数据。

步骤S103，根据商户匹配的业务数据，计算商户在各个交互渠道下匹配的业务办理成功率，并根据商户在各个交互渠道下匹配的业务办理成功率，确定故障预警信息，其中，故障预警信息用于表征金融机构为商户办理金融业务时是否存在故障。

可选的，预警中心可以根据业务数据中的业务返回码确定该业务数据对应的金融业务是否办理成功，其中，业务返回码为金融机构返回给商户的，也即交易集群返回给商户的，业务返回码用于表征业务办理的办理结果，例如，若业务为交易业务，则返回码可以用于表征交易成功、由于余额不足导致交易失败、由于系统故障导致交易失败等。

进一步地，当确定了商户在各个交互渠道下的业务数据匹配的业务办理结果之后，对于每个交互渠道，预警中心可以计算商户在该交互渠道下的业务办理成功率，即将该交互渠道下成功办理的业务数量除以该交互渠道下的总业务数量，得到该交互渠道下的业务办理成功率。从而在商户在各个交互渠道下匹配的业务办理成功率均大于或等于对应的成功率阈值的情况下，确定故障预警信息表征金融机构为商户办理金融业务时不存在故障，反之，在存在某一交互渠道下匹配的业务办理成功率小于对应的成功率阈值的情况下，确定故障预警信息表征金融机构为商户办理金融业务时存在故障，从而实现图4中的故障识别。其中，不同的交互渠道匹配的成功率阈值可以相同也可以不同，且如图4所示，在确定故障预警信息表征金融机构为商户办理金融业务时存在故障的情况下，预警中心可以向运维人员发送报警信息以提供运维人员。

可选的，预警中心还可以在交互渠道的维度上，更进一步地划分业务场景，然后对于每个交互渠道，计算商户在各个业务场景下的业务办理成功率，即将交互渠道的该业务场景下成功办理的业务数量除以交互渠道的该业务场景下的总业务数量，得到交互渠道的该业务场景下的业务办理成功率。从而根据商户在各个交互渠道的各个业务场景下的业务办理成功率，确定故障预警信息。

基于上述步骤S101至步骤S103所限定的方案，可以获知，在本发明实施例中，采用根据业务办理成功率确定故障预警信息的方式，通过获取金融机构为多个商户办理金融业务时的业务数据，然后对于每个商户，确定商户匹配的各个业务数据对应的交互渠道，从而根据商户匹配的业务数据，计算商户在各个交互渠道下匹配的业务办理成功率，并根据商户在各个交互渠道下匹配的业务办理成功率，确定故障预警信息。其中，金融业务由与商户进行交互的用户通过商户向金融机构发起，交互渠道是指金融机构与商户之间传输业务数据时使用的渠道，故障预警信息用于表征金融机构为商户办理金融业务时是否存在故障。

容易注意到的是，在上述过程中，通过根据业务办理成功率，确定故障预警信息，实现了根据金融机构对金融业务的办理结果确定金融机构办理业务时是否存在故障，从而实现了对故障预警信息的准确确定，进而能够及时发现故障。进一步地，通过计算商户在各个交互渠道下匹配的业务办理成功率，然后根据商户在各个交互渠道下匹配的业务办理成功率确定故障预警信息，实现了从更细粒度上对金融机构办理业务时是否存在故障进行判断，从而更进一步地提高了确定故障预警信息的准确性。

由此可见，本申请所提供的方案达到了根据业务办理成功率确定故障预警信息的目的，从而实现了及时发现故障的技术效果，进而解决了相关技术中缺乏金融机构为商户办理业务时的故障预警方法，从而存在无法及时发现故障的技术问题。

在一种可选的实施例中，在根据商户匹配的业务数据，计算商户在各个交互渠道下匹配的业务办理成功率，并根据商户在各个交互渠道下匹配的业务办理成功率，确定故障预警信息的过程中，目标预警系统可以对于每个交互渠道，确定交互渠道匹配的各个业务数据所对应的业务场景，然后对于交互渠道下的每个业务场景，根据商户在各个时间间隔内在交互渠道下的业务场景下匹配的业务数据，计算商户在各个时间间隔内在交互渠道下的业务场景下匹配的业务办理成功率，得到多个目标业务办理成功率，对于每个交互渠道，根据商户在交互渠道下的目标业务办理成功率，确定子预警信息，从而根据商户在各个交互渠道下匹配的子预警信息，确定故障预警信息。其中，子预警信息至少用于表征金融机构通过交互渠道为商户办理金融业务时是否存在故障。

可选的，对于某一交互渠道下的业务数据，目标预警系统可以根据业务数据中的内容确定业务数据对应的业务场景，业务场景包括但不限于消费(也即交易)、查询付款进度、退款等场景。

进一步地，对于某一交互渠道下的某一业务场景，目标预警系统可以计算商户在各个时间间隔内在该交互渠道下的该业务场景下匹配的业务办理成功率。例如，将在某一时间间隔内在该交互渠道下的该业务场景下成功办理的业务数量除以该时间间隔内在该交互渠道下的该业务场景下的总业务数量，得到商户在该时间间隔内在该交互渠道下的该业务场景下匹配的目标业务办理成功率，即对于某一交互渠道下的某一业务场景，存在与多个时间间隔一一对应的目标业务办理成功率。

更进一步地，对于每个交互渠道，目标预警系统可以对交互渠道下的不同业务场景设置不同的成功率阈值，然后分别将各个目标业务办理成功率与对应的成功率阈值进行比较，从而根据各个目标业务办理成功率对应的比较结果确定子预警信息。例如，在小于成功率阈值的目标业务办理成功率的数量大于预设数量时，确定子预警信息表征金融机构通过交互渠道为商户办理金融业务时存在故障，反之，确定子预警信息表征金融机构通过交互渠道为商户办理金融业务时不存在故障。可选的，目标预警系统也采用其它方式根据商户在交互渠道下的目标业务办理成功率，确定子预警信息。

进一步地，目标预警系统可以根据商户在各个交互渠道下匹配的子预警信息，确定故障预警信息。

需要说明的是，通过上述过程，实现了在交互渠道的基础上，从更细粒度对金融机构办理业务时是否存在故障进行判断，从而更进一步地提高了确定故障预警信息的准确性。

在一种可选的实施例中，多个目标业务办理成功率为实时确定的，其中，在根据商户在交互渠道下的目标业务办理成功率，确定子预警信息的过程中，目标预警系统可以在每得到一个时间间隔匹配的目标业务办理成功率的情况下，比较目标业务办理成功率与预设的目标成功率之间的大小，若目标业务办理成功率小于目标成功率，则对商户在目标业务场景下的异常程度值进行更新操作，得到更新后的异常程度值，从而在更新后的异常程度值大于或等于预设程度值的情况下，确定子预警信息表征金融机构通过交互渠道为商户办理金融业务时存在故障。其中，异常程度值的初始值为预设值，目标业务场景为交互渠道下目标业务办理成功率匹配的业务场景。

可选的，在本实施例中，多个目标业务办理成功率为实时确定的，例如，若时间间隔的时间长度为15分钟，则对于某一交互渠道下的某一业务场景，在14:15时，预警中心计算得到商户在14:00-14:15这一时间间隔对应的目标业务办理成功率，然后在14:30时，预警中心计算得到商户在14:15-14:30这一时间间隔对应的目标业务办理成功率。

故而，在每得到一个时间间隔匹配的目标业务办理成功率的情况下，预警中心可以目标业务办理成功率与预设的目标成功率之间的大小。其中，在本实施例中，目标成功率为根据目标业务办理成功率所匹配的交互渠道和业务场景确定的，即不同交互渠道下的相同业务场景对应的目标成功率可以相同也可以不同，同一交互渠道下的不同业务场景对应的目标成功率可以相同也可以不同，其中，若某一商户主要使用的交互渠道为A第三方支付渠道，则可以对该渠道设置较高的目标成功率，反之，可以设置较低的目标成功率。

进一步地，若某一时间间隔匹配的目标业务办理成功率小于其对应的目标成功率，预警中心可以对目标业务场景下的异常程度值进行更新操作，得到更新后的异常程度值，例如，执行+5操作，若异常程度值的初始值为0，则更新后的异常程度值可以为5。其中，当预警中心确定当前交互渠道的该目标业务场景在下一个时间间隔内匹配的目标业务办理成功率仍小于其对应的目标成功率时，预警中心继续对商户在目标业务场景下的异常程度值进行更新操作，得到更新后的异常程度值，例如，将前述的5更新为10。

可选的，在更新后的异常程度值大于或等于预设程度值的情况下，确定子预警信息表征金融机构通过交互渠道为商户办理金融业务时存在故障。其中，预设程度值可以为15，在此情况下，相当于当当前交互渠道的目标业务场景下有三个时间间隔的目标业务办理成功率小于目标成功率时，该确定金融机构通过该交互渠道为商户办理金融业务时存在故障，其中，更具体地，子预警信息还可以表征金融机构通过交互渠道为商户办理目标业务场景下的金融业务时存在故障。可选的，预设程度值可以是根据目标业务办理成功率所匹配的交互渠道和业务场景确定的。

例如，某一商户在不同交互渠道、不同业务场景下的目标成功率以及预设程度值可以如表1所示：

表1

需要说明的是，通过上述过程，实现了对子预警信息的准确确定。

在一种可选的实施例中，在得到更新后的异常程度值之后，目标预警系统可以确定时间间隔的序位N，从而在N等于预设数值的情况下，若交互渠道下所有业务场景下的异常程度值均小于预设程度值，则确定子预警信息表征金融机构通过交互渠道为商户办理金融业务时不存在故障，并确定下一个时间间隔的序位N为1，将商户在各个业务场景下的异常程度值更新为预设值，其中，预设数值大于1。

可选的，时间间隔的序位N为根据时间间隔的时间顺序确定的，例如，若14:00-14:15这一时间间隔的序位为1，则14:15-14:30这一时间间隔的序位为2。

进一步地，当N等于预设数值时，若当前交互渠道下所有业务场景下最新(也即当前)的异常程度值均小于预设程度值，则确定子预警信息表征金融机构通过交互渠道为商户办理金融业务时不存在故障，也即子预警信息表征金融机构通过当前交互渠道为商户办理所有业务场景下的金融业务时均不存在故障。

更进一步地，当N等于预设数值时，无论交互渠道下所有业务场景下的异常程度值是否均小于预设程度值，均确定下一个时间间隔的序位N为1，并将商户在当前交互渠道的各个业务场景下的异常程度值更新为预设值。例如，若N为4，则相当于一小时重置一次交互渠道下业务场景的异常程度值。

需要说明的是，通过上述过程，实现了对子预警信息更有效的确定。

在一种可选的实施例中，在根据商户在各个交互渠道下匹配的子预警信息，确定故障预警信息的过程中，若各个子预警信息均表征金融机构通过交互渠道为商户办理金融业务时不存在故障，则确定故障预警信息表征金融机构为商户办理金融业务时不存在故障，若存在表征金融机构通过交互渠道为商户办理金融业务时存在故障的子预警信息，则确定故障预警信息表征金融机构为商户办理金融业务时存在故障。

具体地，在故障预警信息表征金融机构为商户办理金融业务时存在故障的情况下，还可以在故障预警信息中添加识别出存在故障的交互渠道和业务场景的信息。

需要说明的是，通过上述过程，实现了对故障预警信息的准确确定。

在一种可选的实施例中，图5是根据本发明实施例的一种可选的监控中心的工作示意图，如图5所示，监控中心分为前端和后台两部分。在后台部分，监控中心获取到交易集群推送的业务数据之后，将其持久化存储在本地服务器中，并对业务数据进行加工分析，得到可视化数据，运维人员则可以在前端通过桌面端或者应用程序端查看相关可视化数据。

具体地，图6是根据本发明实施例的一种可选的监控中心的工作示意图，如图6所示，当监控中心获取到业务数据之后，监控中心可以从业务数据中确定业务数据的业务ID，并将其作为业务数据的唯一标识，然后对业务ID进行哈希计算，根据得到的哈希值确定业务数据匹配的聚合服务节点，从而将业务数据分发至对应的聚合服务节点。进一步地，如图6所示，聚合服务节点在获取到业务数据之后，根据业务数据的内容构建业务数据对应的拓扑关系，生成对应的拓扑关系图，其中，拓扑关系是指处理业务数据对应的金融业务时所执行的工作节点以及执行顺序，例如，一种可选的拓扑关系可以是“检查数据合法性-调用第一接口检查余额-根据余额判断是否支付”等。

进一步地，如图6所示，聚合服务节点将得到的拓扑关系图存储至图数据库，以实现对拓扑关系的存储。图数据库提供图元计算，图数据库可以为拓扑关系图标记业务场景，同时在通过代码显示拓扑关系图对应的业务ID，运维人员可按照业务ID或业务场景从图数据库中实时查询业务数据的拓扑关系图，然后由监控中心的前端通过全息监控界面进行可视化展示。

需要说明的是，通过上述过程，实现了对业务数据的可视化展示，从而便于工作人员及时了解各金融业务的办理情况。

在一种可选的实施例中，在确定子预警信息之后，目标预警系统可以在子预警信息表征金融机构通过交互渠道为商户办理金融业务时存在故障的情况下，采用以下方式中的至少之一进行故障诊断：利用预设的故障诊断规则对商户在目标时间间隔内在目标交互渠道下的业务数据进行故障诊断，得到故障诊断结果，其中，目标时间间隔包括使得异常程度值更新至大于或等于预设程度值的时间间隔，目标交互渠道为子预警信息匹配的交互渠道，故障诊断结果包括故障类型；获取金融机构内的业务服务器在目标时间间隔内的运行指标，并在运行指标中存在异常指标值的情况下，根据异常指标值确定故障诊断结果，其中，业务服务器用于办理金融业务；获取业务服务器在目标时间间隔内处理目标交互渠道下的金融业务时的处理状态数据，并在处理状态数据中存在异常数据的情况下，根据异常数据确定故障诊断结果，其中，处理状态数据至少包括业务服务器的业务处理耗时数据。

如图4所示，预警中心还可以进行故障诊断，具体地，预警中心可以根据子预警信息，确定商户在目标时间间隔内在目标交互渠道下的业务数据。例如，若子预警信息为在得到某一交互渠道在14:30-14:45这一时间间隔匹配的目标业务办理成功率之后所确定的，则目标时间间隔即为前述的14:30-14:45这一时间间隔。可选的，目标时间间隔还可以包括前述的14:30-14:45这一时间间隔之前所相邻的时间间隔。且更具体的，预警中心可以获取商户在目标时间间隔内在目标交互渠道的第一业务场景下的业务数据，第一业务场景即为子预警信息匹配的异常程度值所对应的业务场景。

之后，预警中心可以利用预设的故障诊断规则对所获取的业务数据进行故障诊断，得到故障诊断结果，故障类型可以是业务繁忙、订单号错误等。

可选的，预警中心可以监控上述的业务处理层中的业务服务器在目标时间间隔内的运行指标，其中，业务服务器用于办理金融业务。然后将运行指标中的指标值与预设的标准指标值进行比较，以判断是否存在异常指标值，从而在存在异常指标值的情况下，利用预设的第一诊断规则，根据异常指标值确定故障诊断结果。其中，运行指标可以是CPU、内存等，故障类型可以是CPU占用过高等。

可选的，预警中心还可以获取业务服务器在目标时间间隔内处理目标交互渠道下的金融业务时的处理状态数据，其中，处理状态数据包括但不限于业务服务器的业务处理耗时数据、处理成功率等。之后，预警中心可以将处理状态数据中的业务处理耗时数据、处理成功率等与预设的标准阈值比较，以确定处理状态数据中是否存在异常数据，从而在存在异常数据的情况下，利用预设的第二诊断规则，根据异常数据确定故障诊断结果，其中，故障诊断结果可以是某一工作节点出现故障等。

需要说明的是，通过上述过程，实现了对故障的有效诊断，从而降低了人工成本，并便于提高故障处理效率。

在一种可选的实施例中，目标预警系统可以从故障诊断结果中提取故障类型，然后获取预设的故障类型与故障处理规则的对应关系，并从对应关系中确定提取的故障类型匹配的目标故障处理规则，从而根据目标故障处理规则对金融机构进行故障处理。

可选的，当确定了故障诊断结果之后，如图4所示，目标预警系统还可以进行故障恢复。具体地，目标预警系统可以从故障诊断结果中提取故障类型，然后依据预设的对应关系匹配与故障诊断结果中的故障类型对应的目标故障处理规则，从而根据目标故障处理规则对金融机构进行故障处理。例如，目标故障处理规则可以是增加容器数量、通知对应的工作人员等。

需要说明的是，通过上述过程，实现了对故障的自动处理，从而能够提高故障处理效率，避免对业务的处理产生影响。

由此可见，本申请所提供的方案达到了根据业务办理成功率确定故障预警信息的目的，从而实现了及时发现故障的技术效果，进而解决了相关技术中缺乏金融机构为商户办理业务时的故障预警方法，从而存在无法及时发现故障的技术问题。

实施例2

根据本发明实施例，提供了一种故障预警信息的确定装置的实施例，其中，图7是根据本发明实施例的一种可选的故障预警信息的确定装置的示意图，如图7所示，该装置包括：

第一获取模块701，用于获取金融机构为多个商户办理金融业务时的业务数据，其中，金融业务由与商户进行交互的用户通过商户向金融机构发起；

第一确定模块702，用于对于每个商户，确定商户匹配的各个业务数据对应的交互渠道，其中，交互渠道是指金融机构与商户之间传输业务数据时使用的渠道；

计算模块703，用于根据商户匹配的业务数据，计算商户在各个交互渠道下匹配的业务办理成功率，并根据商户在各个交互渠道下匹配的业务办理成功率，确定故障预警信息，其中，故障预警信息用于表征金融机构为商户办理金融业务时是否存在故障。

需要说明的是，上述第一获取模块701、第一确定模块702以及计算模块703对应于上述实施例中的步骤S101至步骤S103，三个模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。

可选的，计算模块703还包括：第一确定子模块，用于对于每个交互渠道，确定交互渠道匹配的各个业务数据所对应的业务场景；计算子模块，用于对于交互渠道下的每个业务场景，根据商户在各个时间间隔内在交互渠道下的业务场景下匹配的业务数据，计算商户在各个时间间隔内在交互渠道下的业务场景下匹配的业务办理成功率，得到多个目标业务办理成功率；第二确定子模块，用于对于每个交互渠道，根据商户在交互渠道下的目标业务办理成功率，确定子预警信息，其中，子预警信息至少用于表征金融机构通过交互渠道为商户办理金融业务时是否存在故障；第三确定子模块，用于根据商户在各个交互渠道下匹配的子预警信息，确定故障预警信息。

可选的，第二确定子模块还包括：比较单元，用于在每得到一个时间间隔匹配的目标业务办理成功率的情况下，比较目标业务办理成功率与预设的目标成功率之间的大小；更新单元，用于若目标业务办理成功率小于目标成功率，则对商户在目标业务场景下的异常程度值进行更新操作，得到更新后的异常程度值，其中，异常程度值的初始值为预设值，目标业务场景为交互渠道下目标业务办理成功率匹配的业务场景；第一确定单元，用于在更新后的异常程度值大于或等于预设程度值的情况下，确定子预警信息表征金融机构通过交互渠道为商户办理金融业务时存在故障。

可选的，故障预警信息的确定装置还包括：第二确定模块，用于确定时间间隔的序位N；第三确定模块，用于在N等于预设数值的情况下，若交互渠道下所有业务场景下的异常程度值均小于预设程度值，则确定子预警信息表征金融机构通过交互渠道为商户办理金融业务时不存在故障，并确定下一个时间间隔的序位N为1，将商户在各个业务场景下的异常程度值更新为预设值，其中，预设数值大于1。

可选的，第三确定子模块还包括：第二确定单元，用于若各个子预警信息均表征金融机构通过交互渠道为商户办理金融业务时不存在故障，则确定故障预警信息表征金融机构为商户办理金融业务时不存在故障；第三确定单元，用于若存在表征金融机构通过交互渠道为商户办理金融业务时存在故障的子预警信息，则确定故障预警信息表征金融机构为商户办理金融业务时存在故障。

可选的，故障预警信息的确定装置还包括：故障诊断模块，用于在子预警信息表征金融机构通过交互渠道为商户办理金融业务时存在故障的情况下，采用以下方式中的至少之一进行故障诊断：利用预设的故障诊断规则对商户在目标时间间隔内在目标交互渠道下的业务数据进行故障诊断，得到故障诊断结果，其中，目标时间间隔包括使得异常程度值更新至大于或等于预设程度值的时间间隔，目标交互渠道为子预警信息匹配的交互渠道，故障诊断结果包括故障类型；获取金融机构内的业务服务器在目标时间间隔内的运行指标，并在运行指标中存在异常指标值的情况下，根据异常指标值确定故障诊断结果，其中，业务服务器用于办理金融业务；获取业务服务器在目标时间间隔内处理目标交互渠道下的金融业务时的处理状态数据，并在处理状态数据中存在异常数据的情况下，根据异常数据确定故障诊断结果，其中，处理状态数据至少包括业务服务器的业务处理耗时数据。

可选的，故障预警信息的确定装置还包括：提取模块，用于从故障诊断结果中提取故障类型；第二获取模块，用于获取预设的故障类型与故障处理规则的对应关系，并从对应关系中确定提取的故障类型匹配的目标故障处理规则；处理模块，用于根据目标故障处理规则对金融机构进行故障处理。

实施例3

根据本发明实施例的另一方面，还提供了计算机可读存储介质，计算机可读存储介质中存储有计算机程序，其中，计算机程序被设置为运行时执行上述的故障预警信息的确定方法。

实施例4

根据本发明实施例的另一方面，还提供了一种电子设备，其中，图8是根据本发明实施例的一种可选的电子设备的示意图，如图8所示，电子设备包括一个或多个处理器；存储器，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现用于运行程序，其中，程序被设置为运行时执行上述的故障预警信息的确定方法。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。