CN117614818A - 一种处理客户端问题的方法、装置及电子设备 - Google Patents

Abstract

本申请提供了一种处理客户端问题的方法、装置及电子设备，用以提升处理客户端问题的效率。该方法包括：确定客户端的媒体文件，以及确定服务端的目标日志；其中，所述目标日志与所述媒体文件对应，所述媒体文件包括客户端接收到的处理指令和所述处理指令对应的操作流程信息，所述操作流程信息包括客户端的报错节点；对所述媒体文件和所述目标日志进行结构化处理，得到待分析数据；基于所述待分析数据，定位所述报错节点的问题源，并对所述问题源进行处理。

Description

一种处理客户端问题的方法、装置及电子设备

技术领域

本申请涉及电子信息技术领域，尤其涉及一种处理客户端问题的方法、装置及电子设备。

背景技术

随着WEB应用技术的发展，可实现业务类型、数量随之增涨。相应地，用户使用过程中也会出现不可预期的问题。由于客户端环境多样，且用户角色不同，用户操作流程的不确定等方面因素，关于WEB应用的软件在发布前实际上难以实现预知所有问题，并处理。为此，为用户提供意见反馈渠道/工具成为必要策略。

当前供用户反馈的方法以页面截图标注，并反馈页面报错时的request ID为主。Request ID为客户端对某一具体接口进行单一请求的标识。技术人员通过复制request ID到客户端日志中，在客户端日志中查找对应的数据信息，并对查找到的数据信息进行分析，结合页面截图，对用户遇到问题进行定位。由于日志信息海量，且页面截图为静态，导致技术人员据此定位问题时容易出现错误，且效率低，进而导致处理客户端问题时出现处理效率低的问题。

发明内容

本申请提供了一种处理客户端问题的方法、装置及电子设备，用以提升处理客户端问题的效率。

第一方面、本申请实施例提供一种处理客户端问题的方法，包括：

确定客户端的媒体文件，以及确定服务端的目标日志；其中，所述目标日志与所述媒体文件对应，所述媒体文件包括客户端接收到的处理指令和所述处理指令对应的操作流程信息，所述操作流程信息包括客户端的报错节点；

对所述媒体文件和所述目标日志进行结构化处理，得到待分析数据；

基于所述待分析数据，定位所述报错节点的问题源，并对所述问题源进行处理。

一种可能的实施方式，所述确定服务端的目标日志，包括：

在所述媒体文件中，提取关键信息；其中，所述关键信息包括会话标识符sessionID；

基于所述关键信息，确定所述目标日志。

一种可能的实施方式，所述媒体文件的形式包括对屏幕进行录制得到的视频和/或音频；

则所述关键信息包括录制所述视频和/或音频的时间信息；其中，所述时间信息包括录制的起始时间和结束时间。

一种可能的实施方式，所述对所述媒体文件和所述目标日志进行结构化处理，得到待分析数据，包括：

基于预设目录中类型标签，为所述媒体文件和所述目标日志匹配目标标签，得到所述待分析数据。

一种可能的实施方式，所述对所述媒体文件和所述目标日志进行结构化处理，得到待分析数据，包括：

基于所述预设目录中的关键字，在所述媒体文件和/或所述目标日志中提取对应于所述关键字的目标字段；

将所述关键字与所述目标字段组合，得到标签信息；则所述媒体文件、所述媒体文件的所述标签信息、所述目标日志和所述目标日志的所述标签信息组成所述待分析数据。

一种可能的实施方式，所述确定客户端的媒体文件，包括：

接收客户端的问题文件；

过滤所述问题文件中的目标数据，得到中间文件；

将所述中间文件转为预设格式，得到所述媒体文件。

第二方面、本申请实施例提供一种处理客户端问题的装置，包括：

媒体单元，用于确定客户端的媒体文件，以及确定服务端的目标日志；其中，所述目标日志与所述媒体文件对应，所述媒体文件包括客户端接收到的处理指令和所述处理指令对应的操作流程信息，所述操作流程信息包括客户端的报错节点；

数据单元，用于对所述媒体文件和所述目标日志进行结构化处理，得到待分析数据；

定位单元，用于基于所述待分析数据，定位所述报错节点的问题源，并对所述问题源进行处理。

一种可能的实施方式，所述媒体单元具体用于在所述媒体文件中，提取关键信息；其中，所述关键信息包括会话标识符session ID；基于所述关键信息，确定所述目标日志。

一种可能的实施方式，所述媒体文件的形式包括对屏幕进行录制得到的视频和/或音频；则所述关键信息包括录制所述视频和/或音频的时间信息；其中，所述时间信息包括录制的起始时间和结束时间。

一种可能的实施方式，所述数据单元具体用于基于预设目录中类型标签，为所述媒体文件和所述目标日志匹配目标标签，得到所述待分析数据。

一种可能的实施方式，所述数据单元具体用于基于所述预设目录中的关键字，在所述媒体文件和/或所述目标日志中提取对应于所述关键字的目标字段；将所述关键字与所述目标字段组合，得到标签信息；则所述媒体文件、所述媒体文件的所述标签信息、所述目标日志和所述目标日志的所述标签信息组成所述待分析数据。

一种可能的实施方式，所述媒体单元还用于接收客户端的问题文件；过滤所述问题文件中的目标数据，得到中间文件；将所述中间文件转为预设格式，得到所述媒体文件。

第三方面、本申请实施例提供一种可读存储介质，包括，

存储器，

所述存储器用于存储计算机程序，当所述计算机程序被处理器执行时，使得包括所述可读存储介质的装置完成第一方面及任一种可能的实施方式所述的方法。

第四方面、本申请实施例提供一种电子设备，包括：

存储器，用于存放计算机程序；

处理器，用于执行所述存储器上所存放的计算机程序时，以实现第一方面及任一种可能的实施方式所述的方法。

本发明实施例中所提供的一个或多个技术方案，至少具有以下技术效果：

本申请实施例所提供的处理客户端问题的方法中，通过客户端的媒体文件，和服务端一侧的目标日志，使得客户端遇到的问题：报错节点，以及产生问题的问题源得以复现，从而提升定位问题源的效率以及确定到的问题源的准确度，进而提升处理客户端问题的效率，提升用户体验。

在此基础上，通过视频和/或音频展示媒体文件，避免基于文字排查问题所导致的效率低的问题。尤其是，将待分析数据发送至第三方平台/系统或云端时，其中视频、音频的可视化展示，有助于第三方平台或系统或云端能够更快的反馈，从而更进一步提升处理客户端问题的效率。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例提供的一种处理客户端问题的方法的流程示意图；

图2为本申请实施例提供的一种处理客户端问题的方法的示意图；

图3为本申请实施例提供的一种处理客户端问题的装置的结构示意图；

图4为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

针对现有技术中用户使用客户端过程中遇到问题报错后，难以高效且准确的确定相关问题，所导致的对客户端问题处理不准确、不及时的问题，本申请实施例提供一种处理客户端问题的方法：通过来自服务端的目标日志，结合客户端的媒体文件，对问题源进行定位。由于目标日志包括服务端基于客户端相应请求所进行操作的轨迹信息以及交互信息，所以可结合媒体文件中信息，高效且准确定位客户端所遇问题来源，由此实现高效且准确处理客户端问题的目的。

为了更好的理解上述技术方案，以下对本申请实施例提供的处理客户端的问题的方法所适用场景进行举例说明：

在线上交易中，客户端页面出现报错提醒(节点)，未能展示对应于获取产品详细信息的处理指令的页面。此时客户端日志中包括以下信息：向服务端发送的关于前述产品详细信息的请求；接收到服务端根据请求返回的数据，读取该数据为空：“null”。如果仅仅分析客户端日志，则容易对“null”进行异常判断，从而将问题源确定为服务端响应错误，未能正确处理客户端发起的请求。

而根据本申请实施例所提供的处理客户端问题的方法，可抓取服务端的目标日志，根据服务端日志和媒体文件，定位问题源。当对服务端的目标日志进行分析时，可得到服务端实际上对该请求进行了正确且及时响应，如此可以确定问题源并非在于服务端，而是客户端未能对“null”进行兼容处理，导致出现报错。

下面通过附图以及具体实施例对本申请技术方案做详细的说明，应当理解本申请实施例以及实施例中的具体特征是对本申请技术方案的详细的说明，而不是对本申请的技术方案的限定，在不冲突的情况下，本申请实施例以及实施例中的技术特征可以相互组合。

本申请的说明书和权利要求书及上述附图中的术语“第一”和“第二”是用于区别不同对象，而非用于描述特定顺序。此外，术语“包括”以及它们任何变形，意图在于覆盖不排他的保护。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请中的“多个”可以表示至少两个，例如可以是两个、三个或者更多个，本申请实施例不做限制。

请参考图1，本申请提出一种处理客户端问题的方法，用以提升处理客户端问题的准确度和效率，该方法具体包括以下实现步骤：

步骤101：确定客户端的媒体文件，以及确定服务端的目标日志。

其中，目标日志与媒体文件对应，二者均为前端用户操作客户端时报错的相关信息。

该客户端包括但不限于硬件设备，或者硬件设备上具体的web应用。

该媒体文件包括，客户端接收到的处理指令以及对应于所述处理指令的操作流程信息。例如处理指令为选用某一或多个配置，则操作流程包括客户端根据处理指令调用对应于配置的一个或多个具体接口，确认配置的下单接口、以及报错的详细。

该媒体文件还包括接收到处理指令的时间，以及根据该处理指令进行操作直到报错节点出现的时间。

上述操作流程信息包括客户端的报错节点。该报错节点例如可以为客户端含报错提示的页面。该报错提示例如可以为“系统繁忙”。

上述媒体文件的形式包括但不限于单独的截图、连续的截图(即视频)、和音频中的一种或多种。

相应地，上述媒体文件的格式包括但不限于WebM(Web Media，网络媒体)、Ogg(OGGVobis，Ogg音频压缩)、WAV(Waveform Audio File Format，波形音频文件格式)。

在一些实施例中，前述媒体文件中的视频和/或音频可能够通过直接在客户端、浏览器中调用的MediaRecorder API得到。具体而言，首先，在对应于启动录屏的处理指令下，通过getUserMedia()方法获取音频和视频的媒体流。并创建MediaRecorder实例：使用MediaRecorder构造函数创建一个MediaRecorder对象，并将媒体流作为参数传递给它。

然后，在对应于开始录屏的处理指令下，通过调用MediaRecorder实例的start()方法开始录制。

接着，通过调用MediaRecorder实例的stop()方法，结束录制。

在前述调用MediaRecorder实例的过程中，同步监听MediaRecorder实例的dataavailable事件，以同步获取录制到的音频、视频数据。

可选地，前述启动录屏的处理指令中，可包括预设的配置指标，例如，音频和/或视频的编码器、比特率、帧率等。

客户端所接受到的处理指令一般与客户端的报错提示对应。也即，前述媒体文件实际上是在客户端出现报错提示之后确定的。因此，媒体文件为客户端出现报错信息的复现。

在一些实施例中，前述媒体文件中的截图可通过能直接在客户端、浏览器中使用的html2canvas库实现。在对应于截图的处理指令下，可将客户端当前显示页面渲染为Canvas(画板)，并将其导出为图像，得到相应截图。

可选地，前述对应于截图的处理指令中，可包括预设的配置信息，例如可以为转换精度、忽略预设元素、忽略预设样式，和处理跨域图像。该html2canvas库还可根据处理指令对应进行Promise(对象)和回调函数。

在一些实施例中，上述媒体文件中还可包括客户端的日志文件，与前述图像、视频或音频相对应，该日志文件为前述媒体文件中处理指令和操作流程信息的文字版本，具体可通过日志库或日志框架生成。此处框架例如可以为log4j(Logging for Java，Java日志记录库)、logback(Java日志记录库)、log4net((Logging for Java.net，基于.net开发的Java日志记录库))等。

在一些实施例中，上述媒体文件还可包括问题标签，该问题标签可供步骤102和103中进行结构化处理，以及问题源定位。

该问题标签可根据客户端接收到的处理指令对应选择，也可以从处理指令中直接读取。问题标签例如可以为系统故障问题、优化建议、问题咨询。

在一些实施例中，上述媒体文件还可包括客户端显示页面的基本信息、设备基本信息、客户端日志信息等。

为了保证信息安全，在一些实施例中，客户端的媒体文件通过以下方式确定：

首先，接收客户端的问题文件。该问题文件即对应包括前述屏幕录制视频、音频、截图等。

然后，对该问题文件中的目标数据进行过滤，得到中间文件。此处目标数据的检测识别可结合特征分析实现。该目标数据可以为从黑名单中提取的关键词，于是可通过关键词过滤技术，对不合规的目标数据进行过滤，得到中间文件。该目标数据也可通过预设的API(Application Programming Interface，应用程序编程接口)、SDK(SoftwareDevelopment Kit，软件开发工具包)进行检测过滤。

最后，对中间文件进行二次封装：将该中间文件转为预设格式，得到媒体文件。

进一步地，服务端的目标日志可通过以下方式确定：

首先，在媒体信息中，提取关键信息。该关键信息包括会话标识符session ID。

然后，基于关键信息，在服务端日志中确定目标日志。该服务端日志可以前述客户端多个会话的日志记录，也可以为多个客户端多个会话的日志记录。由于sessionID用于跟踪和管理用户会话，所以每一会话对应同一sessionID，则可通过sessionID在服务端日志中确定目标日志。

在一些实施例中，当媒体文件的形式含前述录制屏幕所得的视频和/或音频时，前述关键信息还可包括录制视频和/或音频的时间信息。其中，时间信息包括录制的起始时间和结束时间。

则基于该时间信息和sessionID确定的目标日志，可以是对应会话的服务端日志，且其中标注(例如，高亮)对应于音频/或视频的日志片段。也可以仅仅为对应于音频/或视频的日志片段。具体可通过具体实施场景以及准确性、效率要求对应选择。

由于前一实施方式，即目标日志为对应会话的服务端日志可进一步追溯录制起点、结尾的上、下文，所以可在某些情况下，例如处理指令时间误差大等，更进一步提升处理客户端问题的准确度。

而后一实施方式，即目标日志中仅包含前述对应于音频/或视频的日志片段。由于日志文件中所含信息大幅精简，显然有助于更进一步提升处理客户端问题的效率。

步骤102：对媒体文件和目标日志进行结构化处理，得到待分析数据。

具体而言，此处结构化处理可以是为媒体文件和目标日志添加类型标签，从不同维度对问题文件和目标日志进行归类。也即，基于预设目录中类型标签，为媒体文件和目标日志匹配出目标标签，得到待分析数据。

上述预设目录中可包括以出现报错节点的业务所述系统进行划分的多个类型标签，以报错页面所对应问题进行划分的多个类型标签，及以设备信息进行划分的多个类型标签。

以上述出现报错节点的业务所述系统进行划分为例。类型标签可为相应的子业务线的站点的子域名，例如可以为官网主站、帮助文档系统、各产品的控制台系统等的子域名。

在一些实施例中，预设目录中的类型标签通过与类型标签对应的关键字保存。则为了得到待分析数据，首先，基于预设目录中的关键字，在媒体文件和/或目标日志中提取对应于前述关键字的目标字段。

也就是说，将预设目录中各类型所含的多个类型标签(即关键字)在依次在媒体文件、目标日志中进行匹配，当关键字匹配成功时，则读取媒体文件、目标日志中关键字所对应的字段作为目标字段。当关键字在媒体文件或目标日志中未匹配成功时，则继续将该关键字在剩余的另一文件(目标日志或媒体文件)中进行匹配，例如，在媒体文件中未匹配成功，而在目标日志中匹配成功，则记录该关键字所对应的目标字段作为目标日志的标签信息。如此遍历预设目录中的关键字。

然后，匹配成功，即提取到目标字段的关键字与目标字段组合，作为标签信息。该标签信息与媒体文件、目标日志分别对应。则媒体文件、媒体文件的标签信息、目标日志和目标日志的标签信息组成待分析数据。

步骤103：基于待分析数据，定位报错节点的问题源，并对所述问题源进行处理。

具体地，对待分析数据中处理，定位报错节点的问题源提供以下三个实施例：

实施例1

若仅有媒体文件中出现错误信息，目标日志中并无接口请求日志。此时可得出，用户在点击按钮发生接口请求前客户端就已报错(在请求前做入参准备时数据处理异常)。定位为客户端有问题，用户点击并未触发接口请求。

实施例2

若目标日志中有接口日志信息，但是出入参均正常，且无错误级别日志。则可确定客户端对返回结果的数据处理过程出现异常。进一步结合媒体文件，如媒体文件中记录，客户端对接收到服务端的返回结果中字段为值为null做取值操作，则可确定问题源在于客户端对null做了取值。

实施例3

若媒体文件与服务端目标日志中均有错误日志信息。且媒体文件中的日志信息为对服务端返回错误的捕获日志，则可认为问题源在于服务端，且由于服务端所遇到异常为实现未能预测的不可控的错误，以至于不能向客户端返回具体错误提示，由此需要对目标日志中服务端的处理逻辑进一步分析，以确定问题源。此时处于服务端的问题源存在多样性。也即，通过分析目标日志，确定的问题源可能有多种，例如业务场景逻辑处理异常(空指针异常、数组下标越界、类转换异常等)、数据库异常(数据库连接失败、SQL语法错误等)、三方服务异常(外部接口失败、第三方服务不可用等)、系统配置异常(配置文件缺失、配置项错误、环境变量设置错误等)。

以上情形出现时，服务端为保障程序的健壮性，会捕获异常，记录于日志中，并向客户端返回内部错误的统一的状态码：数据“null”。则此时媒体文件中包括记录接口请求的返回信息的客户端日志信息，由此得到媒体文件中日志信息中的“对服务端返回错误的捕获日志”。

进一步地，以下对问题源的处理进行说明：

在一些实施例中，通过特征分析，在预设数据库中为待分析数据匹配相似度大于预设相似度阈值的目标问题数据。

该预设数据库中的问题数据包括处理该问题数据的处理方法和/或对应于媒体文件中报错节点的问题源，以及问题数据。也即，该问题数据为已处理完成的历史分析数据。则可对问题源进行处理。

该问题数据与前述待分析数据的格式一致，以便于进行特征匹配。

在一些实施例中，可向云端或第三方系统(例如，工单系统)发送待分析数据，接收问题源，并基于该待分析数据和接收到的问题源更新前述预设数据库。

在确定问题源之后，则可对应进行处理。并在处理完成之后，向客户端发送处理完成的通知消息。

当同时/连续接收到多个客户端的媒体文件，以及确定对应于多个客户端的待分析数据时，为了提升处理效率，在一些实施例中，可根据待分析数据中的标签信息，结合第一自定义算法，为待分析数据的迫切程度排序，则优先处理迫切程度高的客户端的问题。

例如，根据自定义算法选出客户端无法使用的待分析数据作为迫切程度较高的问题，以及客户端使用体验差的待分析数据作为迫切程度较低的问题。

在一些实施例中，在向客户端发送处理完成的通知消息时，可一并发送意见征集表单，以使用户能通过意见征集表单从客户端进行评价、评分。则接收该评价评分，结合第二自定义算法对评价、评分处理，确定是否将客户端所遇见问题(包括媒体文件中的报错节点)纳入常见问题集合。该常见问题集合用于站点对外展示。

本申请实施例所提供的处理客户端问题的方法，可由服务端执行，也可由能够与客户端、服务端进行交互的第三端执行，还可以由服务端和该第三端共同配合完成。

进一步地，以下基于步骤101-103，提供由服务端执行前述处理客户端问题的方法时的实施例，请参考图2。

首先，用户选择、点击相应的处理指令，使客户端唤起反馈工具面板，开始对客户端录屏，直到客户端通过例如为报错窗口或其它形式进行报错。

客户端反馈工具面板被唤起，则根据接收到用户的处理指令，开始录制视频，以及与之后接收到用户其它处理指令，结束或处理录制视频，并制作媒体文件，以便于进行反馈。然后，客户端将制作的媒体文件发送至服务端。

服务端在接收到媒体文件之后，对媒体文件进行数据来源安全检测。当媒体文件的数据来源的安全检测不通过，确定该媒体文件的发送端不可信，则不做处理，并向客户端发送拒绝处理的通知消息。

当媒体文件关于数据来源的安全检测通过之后，对媒体文件中的数据内容进行安全检测并过滤目标数据，得到中间文件。同时，根据对应于客户端与服务端本次会话的sessionID，在服务端的日志中抓取目标日志。该目标日志包括服务端的逻辑处理信息、中间键调用等等信息。

接着，服务端对中间文件和目标日志一并进行格式转化，以便于根据预设目录，对中间文件和目标日志进行不同维度的分类，并将分类结果作为标签信息对应添加至中间文件、目标日志；则得到待分析数据。

接着，根据待分析数据，确定问题源，并调用相应的处理策略对问题源进行处理。具体地，将待分析数据与数据库中已处理完成的历史分析数据进行特征匹配，也即，根据预设的深度学习模型或相似度计算方法，在数据库中为待分析数据匹配相似度高于预设相似度阈值的历史分析数据。

当匹配成功时，查询该历史分析数据的问题源进行处理；或，调用该历史分析数据的处理策略进行处理。

当匹配失败时，则将待分析数据发送至工单系统，待接收到工单系统发送的问题源、对应的处理策略。基于该工单系统发送的处理策略对问题源进行处理，并将该待分析数据、接收到的问题源、处理策略、及三者的对应关系存储于前述数据库中。

最后，向客户端发送处理完成的通知消息。

此后，还可在接收到客户端发送的评价消息之后，根据评价消息中的打分结果以及评价消息中所选中的评价标签，决定是否需要更新处理策略。

基于同一发明构思，本申请实施例中提供一种处理客户端问题的装置，该装置与前述图1所示处理客户端问题的方法对应，该装置的具体实施方式可参见前述方法实施例部分的描述，重复之处不再赘述，参见图3，该装置包括：

媒体单元301，用于确定客户端的媒体文件，以及确定服务端的目标日志.

其中，所述目标日志与所述媒体文件对应，所述媒体文件包括客户端接收到的处理指令和所述处理指令对应的操作流程信息，所述操作流程信息包括客户端的报错节点。

媒体文件的形式包括对屏幕进行录制得到的视频和/或音频；则所述关键信息包括录制所述视频和/或音频的时间信息；其中，所述时间信息包括录制的起始时间和结束时间。

媒体单元301具体用于在所述媒体文件中，提取关键信息；其中，所述关键信息包括会话标识符session ID；基于所述关键信息，确定所述目标日志。

媒体单元301还用于接收客户端的问题文件；过滤所述问题文件中的目标数据，得到中间文件；将所述中间文件转为预设格式，得到所述媒体文件。

数据单元302，用于对所述媒体文件和所述目标日志进行结构化处理，得到待分析数据。

数据单元302具体用于基于预设目录中类型标签，为所述媒体文件和所述目标日志匹配目标标签，得到所述待分析数据。

数据单元302具体用于基于所述预设目录中的关键字，在所述媒体文件和/或所述目标日志中提取对应于所述关键字的目标字段；将所述关键字与所述目标字段组合，得到标签信息；则所述媒体文件、所述媒体文件的所述标签信息、所述目标日志和所述目标日志的所述标签信息组成所述待分析数据。

定位单元303，用于基于所述待分析数据，定位所述报错节点的问题源，并对所述问题源进行处理。

基于同一发明构思，本申请实施例还提供一种可读存储介质，包括：

存储器，

所述存储器用于存储计算机程序，当所述计算机程序被处理器执行时，使得包括所述可读存储介质的装置完成如上所述的处理客户端问题的方法。

基于与上述处理客户端问题的方法相同的发明构思，本申请实施例中还提供了一种电子设备，所述电子设备可以实现前述一种处理客户端问题的方法的功能，请参考图4，所述电子设备包括：

至少一个处理器401，以及与至少一个处理器401连接的存储器402，本申请实施例中不限定处理器401与存储器402之间的具体连接介质，图4中是以处理器401和存储器402之间通过总线400连接为例。总线400在图4中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。总线400可以分为地址总线、数据总线、控制总线等，为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。或者，处理器401也可以称为控制器，对于名称不做限制。

在本申请实施例中，存储器402存储有可被至少一个处理器401执行的指令，至少一个处理器401通过执行存储器402存储的指令，可以执行前文论述处理客户端问题的方法。处理器401可以实现图3所示的装置中各个模块的功能。

其中，处理器401是该装置的控制中心，可以利用各种接口和线路连接整个该控制设备的各个部分，通过运行或执行存储在存储器402内的指令以及调用存储在存储器402内的数据，该装置的各种功能和处理数据，从而对该装置进行整体监控。

在一种可能的设计中，处理器401可包括一个或多个处理单元，处理器401可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器401中。在一些实施例中，处理器401和存储器402可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器401可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的处理客户端问题的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器402作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器402可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等。存储器402是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器402还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

通过对处理器401进行设计编程，可以将前述实施例中介绍的处理客户端问题的方法所对应的代码固化到芯片内，从而使芯片在运行时能够执行图1所示的处理客户端问题的方法的步骤。如何对处理器401进行设计编程为本领域技术人员所公知的技术，这里不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

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

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种处理客户端问题的方法，其特征在于，包括：

确定客户端的媒体文件，以及确定服务端的目标日志；其中，所述目标日志与所述媒体文件对应，所述媒体文件包括客户端接收到的处理指令和所述处理指令对应的操作流程信息，所述操作流程信息包括客户端的报错节点；

对所述媒体文件和所述目标日志进行结构化处理，得到待分析数据；

基于所述待分析数据，定位所述报错节点的问题源，并对所述问题源进行处理。

2.如权利要求1所述的方法，其特征在于，所述确定服务端的目标日志，包括：

在所述媒体文件中，提取关键信息；其中，所述关键信息包括会话标识符sessionID；

基于所述关键信息，确定所述目标日志。

3.如权利要求2所述的方法，其特征在于，所述媒体文件的形式包括对屏幕进行录制得到的视频和/或音频；

则所述关键信息包括录制所述视频和/或音频的时间信息；其中，所述时间信息包括录制的起始时间和结束时间。

4.如权利要求1所述的方法，其特征在于，所述对所述媒体文件和所述目标日志进行结构化处理，得到待分析数据，包括：

基于预设目录中类型标签，为所述媒体文件和所述目标日志匹配目标标签，得到所述待分析数据。

5.如权利要求1-4任一项所述的方法，其特征在于，所述对所述媒体文件和所述目标日志进行结构化处理，得到待分析数据，包括：

基于所述预设目录中的关键字，在所述媒体文件和/或所述目标日志中提取对应于所述关键字的目标字段；

将所述关键字与所述目标字段组合，得到标签信息；则所述媒体文件、所述媒体文件的所述标签信息、所述目标日志和所述目标日志的所述标签信息组成所述待分析数据。

6.如权利要求1-4任一项所述的方法，其特征在于，所述确定客户端的媒体文件，包括：

接收客户端的问题文件；

过滤所述问题文件中的目标数据，得到中间文件；

将所述中间文件转为预设格式，得到所述媒体文件。

7.一种处理客户端问题的装置，其特征在于，包括：

媒体单元，用于确定客户端的媒体文件，以及确定服务端的目标日志；其中，所述目标日志与所述媒体文件对应，所述媒体文件包括客户端接收到的处理指令和所述处理指令对应的操作流程信息，所述操作流程信息包括客户端的报错节点；

数据单元，用于对所述媒体文件和所述目标日志进行结构化处理，得到待分析数据；

定位单元，用于基于所述待分析数据，定位所述报错节点的问题源，并对所述问题源进行处理。

8.如权利要求7所述的装置，其特征在于，所述媒体单元具体用于在所述媒体文件中，提取关键信息；其中，所述关键信息包括会话标识符sessionID；基于所述关键信息，确定所述目标日志。

9.一种可读存储介质，其特征在于，包括，

存储器，

所述存储器用于存储计算机程序，当所述计算机程序被处理器执行时，使得包括所述可读存储介质的装置完成如权利要求1-6中任一项所述的方法。

10.一种电子设备，其特征在于，包括：

存储器，用于存放计算机程序；

处理器，用于执行所述存储器上所存放的计算机程序时，以实现如权利要求1-6中任一项所述的方法。