业务异常的处理方法及装置与流程

本申请涉及数据处理技术领域，特别涉及一种业务异常的处理方法。本申请同时涉及一种业务异常的处理装置，一种计算设备，以及一种计算机可读存储介质。

背景技术：

随着智能终端的发展，现有的终端可以安装有各类app(application，应用程序)，这类应用程序可以通过终端与服务器进行交互，从而为用户提供各种各样的功能，满足用户的使用需求。为了了解用户对应用程序的使用情况，以便于在应用程序出现异常时能够及时发现，可以收集应用程序在使用过程中产生的数据。

现有技术中，可以通过埋点的方式采集应用程序使用过程中产生的数据。具体的，可以预先在应用程序中进行埋点，在使用应用程序时则可以触发埋点收集数据，再根据收集到的数据判断应用程序是否出现异常，并在应用程序出现异常的情况下，将收集到的数据上报给服务器。

然而，上述方法中，终端在收集到数据后需要对数据进行异常判断，增加了终端的处理操作，并且在确定应用程序出现异常的情况下才向服务器上报，使得应用程序异常监测比较被动。另外，应用程序可以提供多种业务，对于不同的业务可能会有不同的异常出现，上述方法仅能确定应用程序出现异常但无法定位至具体业务，导致应用程序异常的修复难度增加。

技术实现要素：

有鉴于此，本申请实施例提供了一种业务异常的处理方法。本申请同时涉及一种业务异常的处理装置，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的终端操作繁琐，应用程序异常监测比较被动，以及应用程序异常的修复难度增加的问题。

根据本申请实施例的第一方面，提供了一种业务异常的处理方法，应用于终端，包括：

在监测到针对目标业务预先设置的业务异常点被触发的情况下，获取所述目标业务的异常数据，所述业务异常点是执行所述目标业务的过程中出现业务逻辑冲突的节点；

将所述异常数据上报至服务器；

接收所述服务器发送的业务异常结果，其中，所述业务异常结果是所述服务器对所述异常数据处理得到。

根据本申请实施例的第二方面，提供了一种业务异常的处理方法，应用于服务器，包括：

接收目标业务的异常数据，其中，所述异常数据是通过终端在所述目标业务中预先设置业务异常点采集得到；

对所述异常数据进行数据处理，得到所述目标业务的业务异常；

若所述业务异常结果是从不同维度处理所述异常数据得到，根据所述业务异常结果对应的维度，展示所述业务异常结果。

根据本申请实施例的第三方面，提供了一种业务异常的处理装置，应用于终端，包括：

获取模块，被配置为在监测到针对目标业务预先设置的业务异常点被触发的情况下，获取所述目标业务的异常数据，所述业务异常点是执行所述目标业务的过程中出现业务逻辑冲突的节点；

数据上报模块，被配置为将所述异常数据上报至服务器；

第一接收模块，被配置为接收所述服务器发送的业务异常结果，其中，所述业务异常结果是所述服务器对所述异常数据处理得到。

根据本申请实施例的第四方面，提供了一种业务异常的处理装置，应用于服务器，包括：

第二接收模块，被配置为接收目标业务的异常数据，其中，所述异常数据是通过终端在所述目标业务中预先设置业务异常点采集得到；

数据处理模块，被配置为对所述异常数据进行数据处理，得到所述目标业务的业务异常结果；

展示模块，被配置为若所述业务异常结果是从不同维度处理所述异常数据得到，根据所述业务异常结果对应的维度，展示所述业务异常结果。

根据本申请实施例的第五方面，提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述业务异常的处理方法的步骤。

根据本申请实施例的第六方面，提供了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现所述业务异常的处理方法的步骤。

本申请提供的业务异常的处理方法，在监测到针对目标业务预先设置的业务异常点被触发的情况下，获取所述目标业务的异常数据，所述业务异常点是执行所述目标业务的过程中出现业务逻辑冲突的节点；将所述异常数据上报至服务器；接收服务器发送的业务异常结果，该业务异常结果是服务器对异常数据处理得到。本申请在目标业务的业务逻辑冲突的节点处设置业务异常点，在按照目标业务的内部逻辑执行目标业务的过程中，该业务异常点被触发则可以认为业务出现异常，可以获取异常数据，能够实现对业务异常的主动监测，且不需要终端执行额外操作，可以将异常数据上报给服务器。另外，本申请在目标业务中设置业务异常点，获得的异常数据则是与目标业务对应的异常数据，可以清楚地定位具体出现异常的业务，便于对业务异常进行修复。

本申请提供的业务异常的处理方法，接收目标业务的异常数据，其中，所述异常数据是通过终端在所述目标业务中预先设置业务异常点采集得到；对所述异常数据进行数据处理，得到所述目标业务的业务异常结果；若所述业务异常结果是从不同维度处理所述异常数据得到，根据所述业务异常结果对应的维度，展示所述业务异常结果。本申请在接收到目标业务的异常数据后，可以对异常数据进行数据处理，得到业务异常结果，且可以从不同维度对业务异常结果进行展示，则技术人员可以清楚地从不同维度了解到业务出现异常的情况，该业务异常结果比异常数据更便于技术人员进行分析，从而便于技术人员对出现异常的业务进行修复，提高了异常业务的处理效率。

附图说明

图1是本申请一实施例提供的一种业务异常的处理方法的流程图；

图2是本申请一实施例提供的一种业务执行逻辑的流程示意图；

图3是本申请一实施例提供的另一种业务异常的处理方法的流程图；

图4是本申请一实施例提供的一种应用于皮肤模块的业务异常的处理方法的处理流程图；

图5是本申请一实施例提供的一种展示业务异常结果的示意图；

图6是本申请一实施例提供的一种业务异常的处理装置的结构示意图；

图7是本申请一实施例提供的另一种业务异常的处理装置的结构示意图；

图8是本申请一实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

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

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

首先，对本申请一个或多个实施例涉及的名词术语进行解释。

业务异常：在业务执行的过程中某些功能无法正常使用，则可以认为业务异常。例如，弹幕无法发送，直播间弹幕服务器无法连接看不到其他人弹幕等。

目标业务：本申请的目标业务可以是指应用程序中需要关注的业务或者可能出现异常的业务等。

业务异常点：在目标业务中预埋的异常点。

业务标识：用于唯一指示一个业务。

场景标识：用于唯一指示业务的一个应用场景。

md5摘要：message-digestalgorithm5(信息-摘要算法)，属于摘要算法，可以将很大的数据经过算法运算后生成固定长度的数据。在本申请中，md5摘要可以根据异常数据中的关键数据进行运算得到。

在本申请中，提供了一种业务异常的处理方法，本申请同时涉及一种业务异常的处理装置，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本申请一实施例提供的一种业务异常的处理方法的流程图，该方法应用于终端，具体可以包括以下步骤：

步骤102：在监测到针对目标业务预先设置的业务异常点被触发的情况下，获取所述目标业务的异常数据，所述业务异常点是执行所述目标业务的过程中出现业务逻辑冲突的节点。

本申请可以对应用程序中的目标业务是否出现异常进行监测。通常情况下，终端可以在应用程序出现异常时采集crash(崩溃)数据，或者可以采集应用程序性能数据，但很少收集功能异常的数据。并且，数据收集、展示、告警功能只能根据异常名称分类，而不能根据具体业务进行分类。具体的，可以通过埋点的方式收集应用程序运行过程中产生的数据，并根据收集的数据对应用程序是否出现异常进行监测，在监测到应用程序出现异常的情况下将收集到的数据上报给服务器。但应用程序中可以包括多种业务，在应用程序出现异常时，无法确定具体是哪个业务出现了异常，在这种情况下，技术人员需要根据异常数据进行分析，从而确定出现异常的业务，再对出现异常的业务进行修复更新，这样会浪费很多时间，从而降低应用程序修复的效率。另外，收集到数据后需要终端进行监测，从而判断应用程序是否异常，增加了终端的操作，且在出现异常之后才上报数据，而不是主动监测异常自动上报，使得应用程序异常监测比较被动。

因而，为了减少终端的操作，提高应用程序异常监测的主动性，以及提高应用程序修复的效率，本申请提供了一种业务异常的处理方法，可以在监测到针对目标业务预先设置的业务异常点被触发的情况下，获取所述目标业务的异常数据并上报至服务器，且该业务异常点是执行所述目标业务的过程中出现业务逻辑冲突的节点。如此在目标业务的业务逻辑冲突的节点处设置业务异常点，在按照目标业务的内部逻辑执行目标业务的过程中，该业务异常点被触发则可以认为业务出现异常，可以获取异常数据，能够实现对业务异常的主动监测，且不需要终端执行额外操作，可以将异常数据上报给服务器。另外，本申请在目标业务中设置业务异常点，获得的异常数据则是与目标业务对应的异常数据，可以清楚地定位具体出现异常的业务，便于对业务异常进行修复。

具体的，目标业务可以是需要关注的业务，或者是根据技术人员的经验确定的可能出现异常的业务。例如，目标业务可以是皮肤模块的业务、弹幕模块的业务、播放器模块的业务、排行榜模块的业务等等。业务异常点可以是目标业务在执行过程中业务逻辑可能出现冲突或异常的节点。例如，针对皮肤模块的业务，若某个直播间需要更换皮肤，但本地缓存的皮肤失效，业务逻辑却要求必须使用本地缓存的皮肤，此时业务逻辑的本身是有冲突异常的，这个节点就是可以预先设置业务异常点的节点。

具体实现时，预先设置的业务异常点是在执行目标业务的过程中可能会出现业务逻辑冲突或者出现业务异常的节点，若监测到针对目标业务预先设置的业务异常点被触发，可以认为该目标业务在执行过程中出现了业务逻辑冲突的情况，即目标业务出现了异常，如此可以在执行目标业务的过程中根据目标业务的逻辑确定目标业务出现异常，而不是在目标业务出现异常之后被动触发，可以提高业务异常监测的主动性。并且，在确定目标业务出现异常之后，可以获取目标业务的异常数据，以便于技术人员确定目标业务的问题并解决。

本实施例一个可选的实施方式中，所述目标业务包括至少一个应用场景，在监测到针对目标业务预先设置的业务异常点被触发的情况下，获取所述目标业务的异常数据之前，还包括：基于所述目标业务的业务逻辑，确定所述目标业务在目标应用场景下出现业务逻辑冲突的节点，其中，所述目标应用场景是所述至少一个应用场景之一；在所述业务逻辑冲突的节点处设置所述业务异常点；存储所述业务异常点与业务标识和场景标识的对应关系，其中，所述业务标识用于指示一个目标业务，所述场景标识用于指示一个目标业务的一个应用场景。

具体的，应用场景可以是目标业务的使用场景。例如，若目标业务是皮肤模块的业务，则应用场景可以是皮肤资源下载场景、皮肤图片裁剪场景，皮肤图片上传场景等；若目标业务是弹幕模块的业务，则应用场景可以是弹幕发送场景、弹幕播放场景、弹幕缓存场景等；若目标业务是播放器模块的业务，则应用场景可以是视频播放场景、视频上传场景、视频下载场景等等；若目标业务是排行榜模块的业务，则应用场景可以是排名显示场景、排名更新场景等等。业务标识可以用于唯一指示一个目标业务，且业务标识可以是业务模块名称、业务模块编号等，本申请实施例对此不作限定。例如，业务标识可以是“皮肤”。场景标识可以用于唯一标识一个业务的一个应用场景，且场景标识可以是场景名称、场景编号等，本申请实施例对此不作限定。例如，场景标识可以是“皮肤资源下载”。

具体实现时，目标业务可以包括至少一个应用场景，且在不同的应用场景下目标业务出现的异常可能是不同的，因此，可以先根据目标业务的业务逻辑确定目标业务在目标应用场景下可能出现业务逻辑冲突的节点，预先在该业务逻辑冲突的节点处设置业务异常点。并且，为了后续确定业务异常点与应用场景和目标业务的对应关系，可以存储业务异常点与业务标识以及场景标识的对应关系。

示例性地，假设目标业务是皮肤模块的业务，若想要更换当前皮肤，根据本地缓存中是否包括待更换皮肤，可以采取不同的措施，则皮肤模块的业务的应用场景可以是“皮肤缓存”场景。若想要更换当前皮肤，根据目标业务的执行逻辑，参见图2，可以先判断本地缓存中是否有待更换皮肤，若本地缓存中有待更换皮肤，可以获取本地缓存的待更换皮肤用于更换当前皮肤；若本地缓存中没有待更换皮肤，可以判断目标业务的执行逻辑是否配置为必须获取本地缓存的待更换皮肤，若不是，则可以下载待更换皮肤；若目标业务的执行逻辑被配置为必须获取本地缓存的待更换皮肤，但本地缓存中不存在待更换皮肤，说明目标业务该条分支的内部逻辑是有冲突的，则可以在该有冲突的节点处设置业务异常点。并且，可以存储业务异常点与“皮肤”、“皮肤缓存”的对应关系。

通过上述方式，将业务异常点设置在目标业务在目标场景下可能出现逻辑冲突的节点处，如此，不需要在出现异常时采集异常数据，可以在业务自身逻辑出现问题时主动采集异常数据，实现对业务异常的主动监控。

本实施例一个可选的实施方式中，在监测到针对目标业务预先设置的业务异常点被触发的情况下，获取所述目标业务的异常数据的具体实现可以包括：在执行所述目标业务的过程中，若执行至所述业务逻辑冲突的节点，确定所述目标业务出现异常，则触发所述业务异常点；获取与此次异常相关的数据作为所述目标业务的异常数据。

具体实现中，在执行目标业务的过程中，若执行至业务逻辑冲突的节点，可以认为目标业务出现了异常，则可以触发业务异常点，为了获取此次异常的详细信息，可以获取与此次异常相关的数据，将获取的数据作为目标业务在该目标应用场景下的异常数据。

示例性地，在目标业务是皮肤模块的业务的情况下，若想要下载皮肤资源，则在执行目标业务的过程中，可以判断终端是否连接网络，若终端连接网络，则判断终端是否连接无线网络，若终端没有连接无线网络，且在目标业务的业务逻辑中，终端必须采用无线网络下载皮肤资源，则说明业务内部逻辑出现了冲突，当目标业务执行至此，可以认为目标业务出现异常，可以触发业务异常点，并且获取与此次异常相关的数据，将获取的数据作为“皮肤”业务在“皮肤资源下载”场景下的异常数据。

通过上述方式确定的异常数据与具体业务对应，且与具体业务的具体场景对应，即异常数据的收集可以按照具体业务进行分类，提供如此精确的异常数据，可以便于服务器进行数据分析，得到业务异常结果。

本实施例一个可选的实施方式中，获取与此次异常相关的数据作为所述目标业务的异常数据的具体实现可以包括：从所述对应关系中获取此次异常对应的业务标识和场景标识，并以所述业务标识和所述场景标识为所述目标业务的异常数据。

具体实现中，可以从预先存储的对应关系中获取触发此次异常的业务异常点对应的业务标识和场景标识，并将业务标识和场景标识作为目标业务的异常数据。

示例性地，假设预先存储的对应关系是业务异常点a与业务标识“弹幕”对应，且业务异常点a与场景标识“弹幕下载”对应，若触发此次异常的是业务异常点a，则可以确定异常数据包括“皮肤”和“弹幕下载”。

本申请实施例中，可以预先根据目标业务的业务逻辑，确定出目标业务在目标场景下可能出现业务逻辑冲突的节点，并在该节点处设置业务异常数据，在目标业务执行至该节点处时，可以认为目标业务出现了异常，则可以触发业务异常点，并获取与此次异常相关的数据作为目标业务的异常数据。如此，根据业务内部的业务逻辑触发业务异常点，能够实现对业务异常的主动监测，且获取异常数据后不需要终端进行额外的操作，可以减少对终端资源的消耗。

步骤104：将所述异常数据上报至服务器。

具体的，终端获取到异常数据后，可以将异常数据发送至服务器，以便服务器对异常数据进行处理，使得处理后的异常数据更便于技术人员对业务进行修复更新。

具体实现中，终端和服务器之间可以预先通过http(超文本传输协议，hypertexttransferprotocol)接口建立连接进行数据传输，因此，终端可以通过http接口将异常数据上报至服务器。

本实施例一个可选的实施方式中，将所述异常数据上报至服务器之前，还包括：按照预设格式对所述异常数据进行格式转换，得到格式转换后的异常数据；对所述格式转换后的异常数据进行编码，得到异常数据包；

相应地，将所述异常数据上报至服务器，包括：将所述异常数据包上报至所述服务器。

具体的，预设格式可以是json(javascriptobjectnotation，js对象简谱)格式，采用完全独立于编程语言的文本格式来存储和表示数据。json格式的数据的层次结构清晰且简介，不仅便于用户阅读和编写，同时也便于终端生成以及服务器解析，且可以有效地提升网络传输效率。

具体实现中，可以按照json格式对异常数据进行组装，得到格式转换后的异常数据，并且可以对格式转换后的异常数据进行base64编码，得到异常数据包，将异常数据包上报至服务器。

作为一种示例，base64编码是从二进制到字符的过程，可用于在http环境下传递较长的标识信息。采用base64编码具有不可读性，需要解码后才能阅读。因此，在本申请实施例中，对异常数据进行base64编码后得到异常数据包，将异常数据包上报至服务器，则可以对异常数据进行加密，提高了异常数据传输的安全性。

在一些实施例中，异常数据可以包括业务标识、场景标识、md5摘要、终端通用参数和具体异常的数据等。作为一种示例，md5摘要可以根据异常数据中的关键数据聚合得到。其中，关键数据可以包括业务标识、场景标识、具体异常的数据和终端通用参数中的至少两项。即md5摘要可以根据业务标识、场景标识、终端通用参数和具体异常的数据中的至少两项聚合后得到。

示例性地，异常数据中各个字段的定义如下表1所述。

表1异常数据中各个字段的定义

作为一种示例，业务标识还可以称为异常业务模块名称，场景标识还可以称为异常业务内部细分场景。

示例性地，若目标业务是皮肤模块的业务，且目标场景是皮肤缓存场景，则组装得到的json格式的异常数据如下所示：

modulename：skin(皮肤)

scene：cache(缓存)

md5：ffb61c75886ad66fd145d36fea252c46

data：{app_version(app版本)：622222，os_version(操作系统版本)：8，model(厂商)：oneplus，network(网络)：wifi}

error：{error_message(事件名称)：使用皮肤缓存冲突}

步骤106：接收所述服务器发送的业务异常结果，其中，所述业务异常结果是所述服务器对所述异常数据处理得到。

具体实现中，将异常数据上报至服务器后，服务器可以对该异常数据进行处理，得到业务异常结果，并将该业务异常结果发送至终端，则终端可以得到业务异常结果。

进一步地，接收所述服务器发送的业务异常结果之后，还包括：展示所述业务异常结果。

具体实现中，业务异常结果可以是业务出现异常的次数。并且业务异常结果可以是按照业务标识确定的每个业务出现异常的次数，或者，业务异常结果可以是按照业务标识和场景标识确定的每个业务在每个场景下出现异常的次数，或者，业务异常结果可以是按照md5摘要确定的每个业务在每个场景下出现相同异常的次数等等。终端接收到业务异常结果后，可以通过显示器展示该业务异常结果。

如此，将业务异常结果展示出来，技术人员则可以直观地获取到业务异常的详细情况，为后续业务异常处理提供便利。

本实施例一个可选的实施方式中，展示所述业务异常结果之后，还包括：接收告警指令，并基于所述告警指令生成业务异常通知。

具体实现中，业务异常结果可以是在一段时间内业务出现异常的情况，服务器可以将该情况进行统计并在确定异常情况比较严重时，可以向终端发送告警指令，则终端可以接收到告警指令，该告警指令中可以包括目标业务的业务标识，则终端可以基于业务标识生成业务异常通知，以便于通知用户该业务出现了异常。

本申请实施例中，终端在展示业务异常结果后，还可以接收到告警指令，说明目标业务出现的异常情况比较严重，则可以根据该告警指令生成业务异常通知，并将该业务异常通知发送至应用程序负责人的通信工具中，以告知用户业务出现了异常。

本申请提供的业务异常的处理方法，在监测到针对目标业务预先设置的业务异常点被触发的情况下，获取所述目标业务的异常数据，所述业务异常点是执行所述目标业务的过程中出现业务逻辑冲突的节点；将所述异常数据上报至服务器；接收所述服务器发送的业务异常结果，其中，所述业务异常结果是所述服务器对所述异常数据处理得到。本申请在目标业务的业务逻辑冲突的节点处设置业务异常点，在按照目标业务的内部逻辑执行目标业务的过程中，该业务异常点被触发则可以认为业务出现异常，可以获取异常数据，能够实现对业务异常的主动监测，且不需要终端执行额外操作，可以将异常数据上报给服务器。另外，本申请在目标业务中设置业务异常点，获得的异常数据则是与目标业务对应的异常数据，可以清楚地定位具体出现异常的业务，便于对业务异常进行修复。

图3示出了根据本申请一实施例提供的一种业务异常的处理方法的流程图，该方法应用于服务器，具体可以包括以下步骤：

步骤302：接收目标业务的异常数据，其中，所述异常数据是通过终端在所述目标业务中预先设置业务异常点采集得到。

具体实现中，终端可以通过上述实施例提供的业务异常的处理方法获取目标业务的异常数据，且可以将获取的异常数据发送至服务器，则服务器可以接收到目标业务的异常数据。如此接收到的异常数据是与具体的业务相关的，便于服务器按照具体业务对异常数据进行收集并进行后续处理。

本实施例一个可选的实施方式中，接收目标业务的异常数据的具体实现可以包括：接收所述目标业务的异常数据包，其中，所述异常数据包是对所述异常数据进行格式转换和编码处理后得到；

相应地，对所述异常数据进行数据处理，得到所述目标业务的业务异常结果的具体实现可以包括：对所述异常数据包进行数据处理，得到所述目标业务的业务异常结果。

具体的，终端获取到异常数据后，可以根据上述实施例的方式对异常数据进行格式转换和编码处理，则可以得到异常数据包，并将异常数据包发送至服务器，则服务器可以获取到目标业务的异常数据包。在该种情况下，对异常数据进行数据处理则是对异常数据包进行数据处理，得到目标业务的业务异常结果。

具体实现中，终端可以将异常数据按照json格式进行组装，得到格式转换后的异常数据，并且可以对格式转换后的异常数据进行base64编码，得到异常数据包，将异常数据包上报至服务器，则服务器可以获取到异常数据包。

本申请实施例中，终端将异常数据转换成json格式的异常数据发送至服务器，则服务器可以接收到来自终端的异常数据包，如此可以提高数据传输效率。

步骤304：对所述异常数据进行数据处理，得到所述目标业务的业务异常结果。

在本申请实施例一种可能的实施方式中，对所述异常数据包进行数据处理，得到所述目标业务的业务异常结果的具体实现可以包括：对所述异常数据包进行解码，得到明文数据；对所述明文数据进行解析得到异常数据，并以所述异常数据为所述目标业务的业务异常结果。

由于采用base64编码具有不可读性，需要解码后才能阅读。因此，在本申请实施例中，异常数据包需要进行解码后才能阅读。

具体实现中，在异常数据包中可以按照key-value的形式表示异常数据。则可以对异常数据包进行base64解码，得到明文数据，然后对明文数据进行解析，可以根据对应的key获取value，得到异常数据，并将该异常数据作为业务异常结果。例如，modulename字段可以获取到skin。

本实施例一个可选的实施方式中，以所述异常数据为所述目标业务的业务异常结果之后，还包括：将所述目标业务的业务异常结果存储至数据库。

具体实现中，获取到目标业务的业务异常结果后，可以将业务异常结果存储至数据库，以便于用户查询。

在上述实施方式中，对异常数据包进行解码和解析后可以得到异常数据，将异常数据作为业务异常结果存储至数据库中，可以便于用户后续查询业务异常情况。

在本申请实施例另一种可能的实施方式中，若所述目标业务的数量是至少两个，且所述目标业务包括至少两个应用场景，则所述异常数据包的数量是多个，对所述异常数据包进行数据处理，得到所述目标业务的业务异常结果的具体实现可以包括：对所述多个异常数据包进行解码，得到多个明文数据；对所述多个明文数据进行解析，得到多个异常数据；按照聚类规则对所述多个异常数据进行聚类，得到所述目标业务的业务异常结果。

具体实现中，若目标业务的数量是至少两个，且每个目标业务包括至少两个应用场景，则异常数据包的数量是至少四个，可以理解为多个。在该种情况下，可以对每个异常数据包进行base64解码，得到多个明文数据，然后对每个明文数据进行解析，可以得到多个异常数据，并且，可以按照预先设置的聚类规则对多个异常数据进行聚类，则可以得到每个目标业务的业务异常结果。

通过上述方式可以异常数据进行聚类，进而确定出每个目标业务的业务异常结果，以便于对每个目标业务的异常情况进行判断，有针对性地对业务进行更新或修复。

本实施例一个可选的实施方式中，所述异常数据至少包括业务标识，按照聚类规则对所述多个异常数据进行聚类，得到所述目标业务的业务异常结果的具体实现可以包括：以业务标识相同的异常数据为同一类，将所述多个异常数据划分为至少两种类别，其中，每种类别对应一个目标业务；以每种类别中异常数据的数量作为所述类别对应的目标业务发生异常的次数；将每个目标业务发生异常的次数作为每个目标业务的业务异常结果。

作为一种示例，第一种聚类规则可以是根据业务标识做一级异常数据区分聚类，确定每个目标业务发生异常的次数。

具体实现中，可以将业务标识相同的异常数据聚合为一类，由于目标业务的数量是至少两个，则可以将多个异常数据划分为至少两种类别，并且以每种类别中异常数据的数量作为该类别对应的目标业务中发生异常的次数，且将次数作为每个目标业务的业务异常结果。

示例性地，假设异常数据的数量是8个，且该8个异常数据分别由a、b、c、d、e、f、g和h标识，且a、b、e、g和h对应的业务标识是“皮肤”，c、d和f对应的业务标识是“弹幕”，则可以将a、b、e、g和h划分为一类，将c、d和f划分为一类，可以确定皮肤模块的业务发生异常的次数是5，即皮肤模块的业务的业务异常结果是5，弹幕模块的业务发生异常的次数是3，即弹幕模块的业务的业务异常结果是3。

本实施例一个可选的实施方式中，所述异常数据至少包括业务标识和场景标识，按照聚类规则对所述多个异常数据进行聚类，得到所述目标业务的业务异常结果的具体实现可以包括：以业务标识相同且场景标识相同的异常数据为同一类，将所述多个异常数据划分为多种类别，其中，每种类别对应一个目标业务和一个场景；以每种类别中异常数据的数量作为所述类别对应的目标业务在对应的场景下发生异常的次数；将每个目标业务在每个场景中发生异常的次数作为每个目标业务在每个场景下的业务异常结果。

作为一种示例，第一种聚类规则可以是根据业务标识和场景标识做二级异常数据区分聚类，确定每个目标业务在目标场景下发生异常的次数。

具体实现中，可以将业务标识相同且场景标识相同的异常数据聚合为一类，由于目标业务的数量是至少两个，每个目标业务的目标场景的数量是至少两个，则可以将多个异常数据划分为至少四种类别，并且以每种类别中异常数据的数量作为该类别对应的目标业务在对应的目标场景下发生异常的次数，且将次数作为每个目标业务在每个场景下的业务异常结果。

示例性地，假设异常数据的数量是8个，且该8个异常数据分别由a、b、c、d、e、f、g和h标识，且a、b、e、g和h对应的业务标识是“皮肤”，c、d和f对应的业务标识是“弹幕”，并且a、b、e对应的场景标识是“皮肤资源下载”，g和h对应的场景标识是“皮肤图片裁剪”，c、d对应的场景标识是“弹幕发送”，f对应的场景标识是“弹幕显示”。则可以将a、b和e划分为一类，将g和h划分为一类，将c和d划分为一类，将f单独作为一类。进而可以确定皮肤模块的业务在皮肤资源下载场景下发生异常的次数是3，在皮肤图片裁剪场景下发生异常的次数是2，以及可以确定弹幕模块的业务在弹幕发送场景下发生异常的次数是2，在弹幕显示场景下发生异常的次数是1。

本实施例一个可选的实施方式中，所述异常数据至少包括业务标识、场景标识和节点标识，所述节点标识用于表征所述目标业务中业务逻辑冲突的节点对应的事件，按照聚类规则对所述多个异常数据进行聚类，得到所述目标业务的业务异常结果的具体实现可以包括：根据所述业务标识、场景标识和节点标识确定信息摘要；根据信息摘要对所述多个异常数据进行聚类，确定每个目标业务在每个场景下发生相同异常的次数作为每个目标业务在每个场景下的业务异常结果。

具体的，信息摘要可以是md5摘要，可以根据异常数据中的关键数据聚合得到，可以用于表征该异常数据。并且，在本申请实施例中，md5摘要相同的异常数据可以认为是相同的异常。

具体实现中，业务标识、场景标识和节点标识是比较重要的异常数据，则可以根据业务标识、场景标识和节点标识聚合得到md5摘要，根据md5摘要对多个异常数据进行三级数据区分聚类，确定每个目标业务在每个场景下发生相同异常的次数，并将确定的次数作为每个目标业务在每个场景下的业务异常结果。

本实施例一个可选的实施方式中，根据信息摘要对所述多个异常数据进行聚类，确定每个目标业务在每个场景下发生相同异常的次数作为每个目标业务在每个场景下的业务异常结果的具体实现可以包括：以信息摘要相同的异常数据为同一类，将所述多个异常数据划分为多种类别；以每种类别中异常数据的数量作为所述类别对应的目标业务在对应的场景下发生相同异常的次数；将每个目标业务在每个场景中发生相同异常的次数作为每个目标业务在每个场景下的业务异常结果。

作为一种示例，第三种聚类规则可以是根据信息摘要做三级异常数据区分聚类，确定每个目标业务在每个场景下发生相同异常的次数。

具体实现中，可以将md5摘要相同的异常数据聚合为一类，由于异常数据的数量是多个，每个异常数据的节点标识可能不同，则可以将多个异常数据划分为多种类别，并且以每种类别中异常数据的数量作为该类别对应的目标业务在对应的场景下发生相同异常的次数，且将次数作为每个目标业务在每个场景下的业务异常结果。

示例性地，假设异常数据的数量是8个，且该8个异常数据分别由a、b、c、d、e、f、g和h标识，且a、b、e、g和h对应的业务标识是“皮肤”，c、d和f对应的业务标识是“弹幕”，并且a、b、e对应的场景标识是“皮肤资源下载”，g和h对应的场景标识是“皮肤图片裁剪”，c、d对应的场景标识是“弹幕发送”，f对应的场景标识是“弹幕显示”。并且a和b的md5摘要均是aaa，g和h的md5摘要均是bbb，c、d的md5摘要均是ccc，e的md5摘要是eee，f的md5摘要均是fff。则a和b对应相同的异常，可以将a和b划分为一类，将g和h对应相同的异常，g和h划分为一类，c和d对应相同的异常，将c和d划分为一类，e对应的异常与其他不同，将e单独作为一类，f对应的异常与其他不同，将f单独作为一类。进而可以确定皮肤模块的业务在皮肤资源下载场景下发生aaa异常的次数是2，皮肤模块的业务在皮肤资源下载场景下发生eee异常的次数是1，皮肤模块的业务在皮肤图片裁剪场景下发生bbb异常的次数是2，以及可以确定弹幕模块的业务在弹幕发送场景下发生异常ccc的次数是2，在弹幕显示场景下发生异常fff的次数是1。

需要说明的是，在本申请实施例中，可以通过上述三种聚合规则中的一种实现异常数据聚合，确定业务异常结果，或者，也可以结合上述三种聚合规则中的至少两种实现异常数据聚合，确定业务异常结果，本申请实施例对此不作限定。

本申请实施例中，服务器对异常数据包进行处理可以包括两种实现方式，一种是对异常数据包进行解码和解析，得到异常数据存储至数据库中，以便于后续查询。另一种格式对异常数据包括进行解码和解析，得到异常数据后对异常数据按照聚合规则进行聚合处理，得到业务异常结果，可以实现对异常数据的分析，为技术人员提供方便。

需要说明的是，在一种实施方式中，服务器可以在接收到一段时间内的异常数据包之后对该段时间内的异常数据包进行数据处理，得到业务异常结果。

步骤306：若所述业务异常结果是从不同维度处理所述异常数据得到，根据所述业务异常结果对应的维度，展示所述业务异常结果。

具体的，若业务异常结果是按照不同的聚类规则对异常数据进行聚类得到，由于不同的聚类规则与异常数据中不同的字段相关，这些字段可以认为是异常数据在不同维度的参数，则可以认为该业务异常结果是从不同维度处理异常数据得到的。

具体实现中，业务异常结果可以是在一段时间内至少两个目标业务发生异常的情况，且服务器可以是连接有显示器的设备，则服务器可以展示业务异常结果，便于技术人员查看。

如此，服务器对异常数据进行处理后，将得到的异常结果进行展示，技术人员通常都在后台进行监控，即在服务器侧进行监控，则可以看到业务异常结果，通过该业务异常结果可以查看业务异常的具体情况，并对问题进行修复。

本实施例一个可选的实施方式中，若所述业务异常结果是从不同维度处理所述异常数据得到，根据所述业务异常结果对应的维度，展示所述业务异常结果的具体实现可以包括：若所述业务异常结果与业务维度对应，展示每个业务发生异常的次数；或者，若所述业务异常结果与业务维度对应，且与场景维度对应，展示每个业务在每个场景下发生异常的次数；或者，若所述业务异常结果与信息摘要维度对应，展示每个目标业务在每个场景中发生相同异常的次数。

具体的，业务异常结果可以是业务出现异常的次数。并且业务异常结果可以是按照业务标识确定的每个业务出现异常的次数，或者，业务异常结果可以是按照业务标识和场景标识确定的每个业务在每个场景下出现异常的次数，或者，业务异常结果可以是按照md5摘要确定的每个业务在每个场景下出现相同异常的次数等等。

具体实现中，若业务异常结果与业务维度对应，说明业务异常结果是从业务维度来处理异常数据，即统计同一个业务出现异常的次数，可以认为业务异常结果是每个业务出现异常的次数，则服务器可以按照业务不同，展示每个业务出现异常的次数。若业务异常结果与业务和场景两个维度均对应，说明业务异常结果是结合业务和场景两个维度来处理异常数据，即统计同一个业务在同一个场景下出现异常的次数，可以认为业务异常结果是每个业务在每个场景下发生异常的次数，则服务器可以按照业务和场景的不同，展示每个业务在每个场景下出现异常的次数。若业务异常结果与信息摘要维度对应，说明业务异常结果是从信息摘要维度来处理异常数据，即统计信息摘要相同的异常出现的次数，可以认为业务异常结果是每个业务在每个场景下发生相同异常的次数，则服务器可以按照信息摘要不同，展示每个业务在每个场景下出现相同异常的次数。

如此，可以通过业务模块、业务场景、md5摘要三种维度对发生异常的次数进行展示，并且，对于技术人员来说，可以从这三种维度对展示的数据进行筛选查看，且可以查看同一个异常(相同md5)的详细数据。

本实施例一个可选的实施方式中，对所述异常数据进行数据处理，得到所述目标业务的业务异常结果之后，还可以将所述目标业务的业务异常结果发送至终端。

具体的，业务异常结果可以是在一段时间内至少两个目标业务发生异常的情况，服务器进行分析确定业务异常结果后可以发送至终端，则用户可以看到一段时间内业务出现异常的具体情况。

本实施例一个可选的实施方式中，对所述异常数据进行数据处理，得到所述目标业务的业务异常结果之后，还包括：将所述目标业务的业务异常结果与次数阈值进行比对，若所述业务异常结果大于所述次数阈值，则触发异常告警，并向所述终端发送告警指令，其中，所述告警指令至少包括业务标识。

需要说明的是，次数阈值可以由用户根据实际需求进行设置，也可以由服务器默认设置，本申请实施例对此不作限定。

具体实现中，可以将目标业务的业务异常结果与次数阈值进行比对，若业务异常结果大于次数阈值，说明目标业务发生异常的次数太多，可能会影响目标业务的正常运行，进而影响用户体验，因此，可以触发异常告警，并生成告警指令发送至终端，以便终端为用户示警。

需要说明的是，业务异常结果表示的含义不同，则触发异常告警的条件可能不同。示例性地，可以从业务模块、业务场景和md5摘要三种维度分别确定触发异常告警的条件。例如，若24小时内皮肤模块发生异常高于10万次，可以认为皮肤模块的业务可能存在比较大的问题，则可以触发异常告警。

本申请实施例中，服务器可以根据业务异常结果确定是否要触发异常告警，可以起到对业务异常的进一步筛选的作用，且将告警指令发送至终端，可以用于警示用户，以便技术人员对目标业务进行更新或修复。

本实施例一个可选的实施方式中，触发异常告警之后，服务器可以生成告警指令，并通过通讯软件将该告警指令发送至技术人员。例如，触发异常告警后，可以发送邮件或信息到对应负责人。如此，可以及时通知技术人员业务出现异常，则技术人员可以尽快对该异常进行处理，能够提高处理业务异常的效率。

本申请提供的业务异常的处理方法，接收目标业务的异常数据，其中，所述异常数据是通过终端在所述目标业务中预先设置业务异常点采集得到；对所述异常数据进行数据处理，得到所述目标业务的业务异常结果；若所述业务异常结果是从不同维度处理所述异常数据得到，根据所述业务异常结果对应的维度，展示所述业务异常结果。本申请在接收到目标业务的异常数据后，可以对异常数据进行数据处理，得到业务异常结果，且可以从不同维度对业务异常结果进行展示，则技术人员可以清楚地从不同维度了解到业务出现异常的情况，该业务异常结果比异常数据更便于技术人员进行分析，从而便于技术人员及时发现业务异常并进行修复，提高了异常业务的处理效率。

下述结合附图4，以本申请提供的业务异常的处理方法在皮肤模块的应用为例，对所述业务异常的处理方法进行进一步说明。其中，图4示出了本申请一实施例提供的一种应用于皮肤模块的业务异常的处理方法的处理流程图，具体可以包括以下步骤：

步骤402：基于皮肤模块的业务的业务逻辑，确定皮肤模块的业务在皮肤缓存场景下出现业务逻辑冲突的节点。

其中，皮肤模块的业务包括至少一个应用场景，皮肤缓存场景是所述至少一个应用场景之一。

步骤404：在业务逻辑冲突的节点处设置所述第一业务异常点。

例如，业务逻辑冲突的节点是本地缓存中不存在待更换皮肤，但业务逻辑配置中要求必须使用本地缓存的待更换皮肤，这就是本实施例中设置第一业务异常点的节点。

步骤406：存储业务异常点与“皮肤”和“皮肤缓存”的对应关系。

步骤408：基于皮肤模块的业务的业务逻辑，确定皮肤模块在皮肤资源下载场景下出现业务逻辑冲突的节点。

需要说明的是，步骤408与步骤402没有严格的先后执行顺序。

步骤410：在业务逻辑冲突的节点处设置第二业务异常点。

例如，业务逻辑冲突的节点是终端没有连接无线网络，但在业务逻辑中终端必须采用无线网络下载皮肤资源，这就是本实施例中设置第二业务异常点的节点。

步骤412：存储业务异常点与“皮肤”和“皮肤资源下载”的对应关系。

步骤414：在皮肤缓存场景下执行皮肤模块的业务的过程中，若执行至业务逻辑冲突的节点，确定皮肤模块的业务出现异常，则触发业务异常点。

步骤416：从对应关系中获取此次异常对应的业务标识和场景标识，并以“皮肤”和“皮肤缓存”为皮肤模块的业务在皮肤缓存场景下的异常数据。

步骤418：在皮肤资源下载场景下执行皮肤模块的业务的过程中，若执行至业务逻辑冲突的节点，确定皮肤模块的业务出现异常，则触发业务异常点。

需要说明的是，步骤418与步骤414没有严格的先后执行顺序。

步骤420：从对应关系中获取此次异常对应的业务标识和场景标识，并以“皮肤”和“皮肤资源下载”为皮肤模块的业务在皮肤资源下载场景下的异常数据。

步骤422：按照预设格式对异常数据进行格式转换，得到格式转换后的异常数据，并对格式转换后的异常数据进行编码，得到异常数据包。

步骤424：将异常数据包上报至服务器。

需要说明的是，步骤402-步骤424是对步骤102-步骤104的下位实现，其实现过程可以参见上述应用于终端的业务异常的处理方法的实施例的相关描述，本实施例在此不再赘述。

步骤426：服务器接收该皮肤模块的业务的异常数据包。

步骤428：若该皮肤模块的业务的异常数据包的数量是多个，可以对多个异常数据包进行解码，得到多个明文数据。

步骤430：对多个明文数据进行解析，得到多个异常数据。

步骤432：以业务标识相同且场景标识相同的异常数据为同一类，将多个异常数据划分为多种类别。

例如，假设多个异常数据中包括场景标识是“皮肤资源下载”和“皮肤缓存”的两种异常数据，将业务标识为“皮肤”且场景标识是“皮肤资源下载”的划分为一类，将业务标识为“皮肤”且场景标识是“皮肤缓存”的划分为一类。

步骤434：以每种类别中异常数据的数量作为该类别对应的皮肤模块的业务在每个场景下发生异常的次数。

步骤436：将每个皮肤模块的业务在每个场景下发生异常的次数作为每个皮肤模块的业务在每个场景下的业务异常结果。

需要说明的是，步骤426-步骤436是对步骤304的下位实现，其实现过程可以参见步骤304的相关描述，本实施例在此不再赘述。

步骤438：服务器展示皮肤模块的业务的业务异常结果。

参见图5，图5是一种业务异常结果的展示示意图。左侧边框是对业务模块进行筛选的区域，可以包括皮肤模块、弹幕模块、播放器模块、排行榜模块等，还可以包括“高级搜索”选项，可以用于进行更加精细的业务异常结果搜索，包括“添加业务”选项，可以用于添加新的业务，即对新的业务的运行情况进行统计。在皮肤模块所有场景出现业务异常的次数总计是238132次。图5中包括一个曲线图，横轴是时间，纵轴是业务异常结果，两条曲线分别表示皮肤模块下皮肤缓存场景和皮肤资源下载场景下的业务异常结果。例如，12-11皮肤资源下载场景的业务异常结果是8000，12-16皮肤缓存场景的业务异常结果是2000。并且，md5摘要相同且为xxxxxxx的业务异常的次数有5次，md5摘要相同且为yyyyyyy的业务异常的次数有3次。

步骤440：服务器将所述皮肤模块的业务的业务异常结果与次数阈值进行比对，若所述业务异常结果大于所述次数阈值，则触发异常告警，并向所述终端发送告警指令，其中，所述告警指令至少包括业务标识。

需要说明的是，步骤444与步骤438没有严格的先后执行数据。

步骤442：终端接收告警指令，并基于所述告警指令生成皮肤模块的业务异常通知。

本申请提供的业务异常的处理方法，在目标业务的业务逻辑冲突的节点处设置业务异常点，在按照目标业务的内部逻辑执行目标业务的过程中，该业务异常点被触发则可以认为业务出现异常，可以获取异常数据，能够实现对业务异常的主动监测，且不需要终端执行额外操作，可以将异常数据上报给服务器。另外，本申请在目标业务中设置业务异常点，获得的异常数据则是与目标业务对应的异常数据，可以清楚地定位具体出现异常的业务，便于对业务异常进行修复。并且，服务器在接收到目标业务的异常数据后，可以对异常数据进行数据处理，并对处理得到的业务异常结果从不同维度进行展示，则技术人员可以清楚地从不同维度了解到业务出现异常的情况，该业务异常结果比异常数据更便于技术人员进行分析，从而便于技术人员对出现异常的业务进行修复，提高了异常业务的处理效率。

与上述方法实施例相对应，本申请还提供了一种业务异常的处理装置实施例，应用于终端，图6示出了本申请一实施例提供的一种业务异常的处理装置的结构示意图。如图6所示，该装置包括：

获取模块602，被配置为在监测到针对目标业务预先设置的业务异常点被触发的情况下，获取所述目标业务的异常数据，所述业务异常点是执行所述目标业务的过程中出现业务逻辑冲突的节点；

数据上报模块604，被配置为将所述异常数据上报至服务器；

第一接收模块606，被配置为接收所述服务器发送的业务异常结果，其中，所述业务异常结果是所述服务器对所述异常数据处理得到。

可选地，所述获取模块602还被配置为：

所述目标业务包括至少一个应用场景，基于所述目标业务的业务逻辑，确定所述目标业务在目标应用场景下出现业务逻辑冲突的节点，其中，所述目标应用场景是所述至少一个应用场景之一；

在所述业务逻辑冲突的节点处设置所述业务异常点；

存储所述业务异常点与业务标识和场景标识的对应关系，其中，所述业务标识用于指示一个目标业务，所述场景标识用于指示一个目标业务的一个应用场景。

可选地，所述获取模块602，被配置为：

在执行所述目标业务的过程中，若执行至所述业务逻辑冲突的节点，确定所述目标业务出现异常，则触发所述业务异常点；

获取与此次异常相关的数据作为所述目标业务的异常数据。

可选地，所述获取模块602，被配置为：

从所述对应关系中获取此次异常对应的业务标识和场景标识，并以所述业务标识和所述场景标识为所述目标业务的异常数据。

可选地，数据上报模块604还被配置为：

按照预设格式对所述异常数据进行格式转换，得到格式转换后的异常数据；

对所述格式转换后的异常数据进行编码，得到异常数据包；

将所述异常数据包上报至所述服务器。

可选地，第一接收模块606还被配置为：

展示所述业务异常结果。

可选地，第一接收模块606还被配置为：

接收告警指令，并基于所述告警指令生成业务异常通知。

本申请提供的业务异常的处理方法，在监测到针对目标业务预先设置的业务异常点被触发的情况下，获取所述目标业务的异常数据，所述业务异常点是执行所述目标业务的过程中出现业务逻辑冲突的节点；将所述异常数据上报至服务器；接收服务器发送的业务异常结果，该业务异常结果是服务器对异常数据处理得到。本申请在目标业务的业务逻辑冲突的节点处设置业务异常点，在按照目标业务的内部逻辑执行目标业务的过程中，该业务异常点被触发则可以认为业务出现异常，可以获取异常数据，能够实现对业务异常的主动监测，且不需要终端执行额外操作，可以将异常数据上报给服务器。另外，本申请在目标业务中设置业务异常点，获得的异常数据则是与目标业务对应的异常数据，可以清楚地定位具体出现异常的业务，便于对业务异常进行修复。

上述为本实施例的一种业务异常的处理装置的示意性方案。需要说明的是，该业务异常的处理装置的技术方案与上述应用于终端的业务异常的处理方法的技术方案属于同一构思，业务异常的处理装置的技术方案未详细描述的细节内容，均可以参见上述业务异常的处理方法的技术方案的描述。

与上述方法实施例相对应，本申请还提供了业务异常的处理装置实施例，应用于服务器，图7示出了本申请一实施例提供的一种业务异常的处理装置的结构示意图。如图7所示，该装置包括：

第二接收模块702，被配置为接收目标业务的异常数据，其中，所述异常数据是通过终端在所述目标业务中预先设置业务异常点采集得到；

数据处理模块704，被配置为对所述异常数据进行数据处理，得到所述目标业务的业务异常结果；

展示模块706，被配置为若所述业务异常结果是从不同维度处理所述异常数据得到，根据所述业务异常结果对应的维度，展示所述业务异常结果。

可选地，第二接收模块702，被配置为：

接收所述目标业务的异常数据包，其中，所述异常数据包是对所述异常数据进行格式转换和编码处理后得到；

相应地，所述数据处理模块704，被配置为：

对所述异常数据包进行数据处理，得到所述目标业务的业务异常结果。

可选地，所述数据处理模块704，被配置为：

对所述异常数据包进行解码，得到明文数据；

对所述明文数据进行解析得到异常数据，并以所述异常数据为所述目标业务的业务异常结果。

可选地，所述数据处理模块704还被配置为：

将所述目标业务的业务异常结果存储至数据库。

可选地，所述数据处理模块704，被配置为：

若所述目标业务的数量是至少两个，且所述目标业务包括至少两个应用场景，则所述异常数据包的数量是多个，对所述多个异常数据包进行解码，得到多个明文数据；

对所述多个明文数据进行解析，得到多个异常数据；

按照聚类规则对所述多个异常数据进行聚类，得到所述目标业务的业务异常结果。

可选地，所述数据处理模块704，被配置为：

所述异常数据至少包括业务标识，以业务标识相同的异常数据为同一类，将所述多个异常数据划分为至少两种类别，其中，每种类别对应一个目标业务；

以每种类别中异常数据的数量作为所述类别对应的目标业务发生异常的次数；

将每个目标业务发生异常的次数作为每个目标业务的业务异常结果。

可选地，所述数据处理模块704，被配置为：

所述异常数据至少包括业务标识和场景标识，以业务标识相同且场景标识相同的异常数据为同一类，将所述多个异常数据划分为多种类别，其中，每种类别对应一个目标业务和一个场景；

以每种类别中异常数据的数量作为所述类别对应的目标业务在对应的场景下发生异常的次数；

将每个目标业务在每个场景中发生异常的次数作为每个目标业务在每个场景下的业务异常结果。

可选地，所述数据处理模块704，被配置为：

所述异常数据至少包括业务标识、场景标识和节点标识，所述节点标识用于表征所述目标业务中业务逻辑冲突的节点对应的事件，根据所述业务标识、场景标识和节点标识确定信息摘要；

根据信息摘要对所述多个异常数据进行聚类，确定每个目标业务在每个场景下发生相同异常的次数作为每个目标业务在每个场景下的业务异常结果。

可选地，所述数据处理模块704，被配置为：

以信息摘要相同的异常数据为同一类，将所述多个异常数据划分为多种类别；

以每种类别中异常数据的数量作为所述类别对应的目标业务在对应的场景下发生相同异常的次数；

将每个目标业务在每个场景中发生相同异常的次数作为每个目标业务在每个场景下的业务异常结果。

可选地，所述数据处理模块704还被配置为：

展示所述业务异常结果。

可选地，所述展示模块706被配置为：

若所述业务异常结果与业务维度对应，展示每个业务发生异常的次数；或者，

若所述业务异常结果与业务维度对应，且与场景维度对应，展示每个业务在每个场景下发生异常的次数；或者，

若所述业务异常结果与信息摘要维度对应，展示每个目标业务在每个场景中发生相同异常的次数。

可选地，所述数据处理模块704还被配置为：

将所述目标业务的业务异常结果与次数阈值进行比对，若所述业务异常结果大于所述次数阈值，则触发异常告警，并向所述终端发送告警指令，其中，所述告警指令至少包括业务标识。

可选地，所述数据处理模块704还被配置为：

将所述目标业务的业务异常结果发送至终端。

本申请提供的业务异常的处理方法，接收目标业务的异常数据，其中，所述异常数据是通过终端在所述目标业务中预先设置业务异常点采集得到；对所述异常数据进行数据处理，得到所述目标业务的业务异常结果；若所述业务异常结果是从不同维度处理所述异常数据得到，根据所述业务异常结果对应的维度，展示所述业务异常结果。本申请在接收到目标业务的异常数据后，可以对异常数据进行数据处理，得到业务异常结果，且可以从不同维度对业务异常结果进行展示，则技术人员可以清楚地从不同维度了解到业务出现异常的情况，该业务异常结果比异常数据更便于技术人员进行分析，从而便于对出现异常的业务进行修复，提高了异常业务的处理效率。

上述为本实施例的一种业务异常的处理装置的示意性方案。需要说明的是，该业务异常的处理装置的技术方案与上述的业务异常的处理方法的技术方案属于同一构思，业务异常的处理装置的技术方案未详细描述的细节内容，均可以参见上述业务异常的处理方法的技术方案的描述。

图8示出了根据本申请一实施例提供的一种计算设备800的结构框图。该计算设备800的部件包括但不限于存储器810和处理器820。处理器820与存储器810通过总线830相连接，数据库850用于保存数据。

计算设备800还包括接入设备840，接入设备840使得计算设备800能够经由一个或多个网络860通信。这些网络的示例包括公用交换电话网(pstn)、局域网(lan)、广域网(wan)、个域网(pan)或诸如因特网的通信网络的组合。接入设备840可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(nic))中的一个或多个，诸如ieee802.11无线局域网(wlan)无线接口、全球微波互联接入(wi-max)接口、以太网接口、通用串行总线(usb)接口、蜂窝网络接口、蓝牙接口、近场通信(nfc)接口，等等。

在本申请的一个实施例中，计算设备800的上述部件以及图8中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图8所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备800可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或pc的静止计算设备。计算设备800还可以是移动式或静止式的服务器。

其中，处理器820执行所述指令时实现上述所述的业务异常的处理方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的业务异常的处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述业务异常的处理方法的技术方案的描述。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现上述所述业务异常的处理方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的业务异常的处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述业务异常的处理方法的技术方案的描述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

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

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。