本发明涉及网络技术,尤指一种反馈处理服务器、网络系统以及反馈处理方法。
背景技术:
用户对网络进行访问时经常会有反馈信息生成,用于向网络侧反馈自身在网络访问中遇到的情况。目前,对于反馈信息的处理通常是由人工进行的。但是,从如今网络使用的频度来看,反馈信息的数量日益增大,完全通过人工跟进分析很难保证处理效率。
技术实现要素:
本发明实施例提供了一种反馈处理服务器、网络系统以及反馈处理方法,旨在提高反馈信息的处理效率。
在一个示例中,一种反馈处理服务器包括:反馈接口,用于接收反馈信息;业务服务器接口,用于从业务服务器获取与所述反馈信息对应的数据记录;以及控制单元,用于控制所述数据记录的访问验证,得到验证结果。
在一个示例中,一种网络系统包括:反馈处理服务器,用于接收反馈信息,获得与所述反馈信息对应的数据记录提供给验证终端;以及所述验证终端,用于对该数据记录进行访问,并将访问情况提供给所述反馈处理服务器作为该反馈信息的验证结果。
在一个示例中,一种反馈处理方法包括:接收针对网络访问的反馈信息;从业务服务器获取与所述反馈信息对应的数据记录;以及对该数据记录进行访问验证得到验证结果。
附图说明
图1为本发明实施例中反馈处理服务器100的结构示意图。
图2为本发明实施例中反馈处理服务器200的结构示意图。
图3为本发明实施例中网络系统300的结构示意图。
图4为本发明实施例中网络系统400的结构示意图。
图5为本发明实施例中反馈处理方法500的流程示意图。
图6为本发明实施例中反馈处理方法600的流程示意图。
图7为本发明实施例中媒体播放时反馈处理方法700的流程示意图。
图8为本发明实施例中内容下载时反馈处理方法800的流程示意图。
图9为本发明实施例中浏览器内核故障时反馈处理方法900的流程示意图。
图10为本发明实施例中反馈处理服务器1000的结构示意图。
具体实施方式
为使本发明的目的、技术方案及优点更加清楚明白,以下参照附图并举实施例,对本发明进一步详细说明。
本发明实施例提出一种采用机器处理反馈信息的方案,设置反馈处理服务器用于接收反馈信息,并从业务服务器获得与反馈信息关联的数据记录进行访问验证,以得到可能对改善网络访问有帮助的验证结果。
图1为本发明实施例中反馈处理服务器100的结构示意图。在一个示例中,该反馈处理服务器100包括:反馈接口101、业务服务器接口102、以及控制单元103。
在一个示例中,反馈接口101用于接收反馈信息,所述反馈信息是指对网络访问的情况进行反馈的信息。在一个示例中,网络访问是通过浏览器实现的,或者说浏览器是互联网的入口。通常情况下,浏览器是指可以显示网络服务器或者文件系统的文件,并让用户与这些文件交互的一种应用,支持诸如超文本标记语言(hypertextmarkuplanguage,html)。
在一个示例中,所述反馈信息为用户反馈信息。比如,某个用户打开浏览器点击网页上的链接想要访问某个媒体文件,但是该媒体文件没有成功打开,则所述用户可以通过与该浏览器相关的论坛反馈这一问题。在一个示例中,所述反馈信息为异常上报信息。在一个示例中,该异常上报信息可以是用户点击预设的反馈按钮发出的,或者是用户终端自动发出的。比如,通过浏览器打开某个网页失败时,如果发现是内核异常,该浏览器可以自动上报这一问题,不需要用户另行通过网络论坛等途径反馈。
在一个示例中,业务服务器接口102用于从业务服务器获取与所述反馈信息对应的数据记录。需要指出,所述业务服务器用于支持所述浏览器提供的业务,比如媒体访问、下载访问、网页访问等。在一个示例中,所述业务服务器为媒体播放服务器,用于提供视频、音频、动图、多媒体等不同类型的媒体内容。在一个示例中,所述业务服务器为内容下载服务器,用于提供内容(比如某个应用或媒体等)的下载等。在一个示例中,所述业务服务器为网页维护服务器,用于维护、更新网站或网页内容。
业务服务器被访问时,与用户访问内容相关的信息(比如该内容的网络地址等)将作为所述数据记录存储在该业务服务器(比如该业务服务器管理的数据库)中。在一个示例中,所述数据记录以日志的形式加以存储。
在一个示例中,控制单元103用于控制所述数据记录的验证,得到验证结果。通常情况下,在用户使用浏览器对网络中的信息进行访问出现异常、故障等情况时,反馈处理服务器100将收到反馈信息。为此,反馈处理服务器100中设置了所述控制单元103,用于对与所述反馈信息关联的数据记录进行验证,以确定是否存在异常、故障等。
图2为本发明实施例中反馈处理服务器200的结构示意图。该反馈处理服务器200包括:反馈接口101、业务服务器接口102、以及控制单元103。在一个示例中,所述反馈接口101、业务服务器接口102、以及控制单元103的功能如图1所述,此处不再赘述。
在一个示例中,所述控制单元103包括:第一验证模块2031,用于将所述数据记录发送给验证终端进行验证,并接收所述验证终端提供的验证结果。也即,接收到所述反馈信息后,所述反馈处理服务器200通过所述业务服务器接口102获得所述数据记录,再将所述数据记录提供给所述验证终端进行真机验证,从而还原出提供所述反馈信息的用户之前访问该数据记录的场景,以便进行问题定位,得到与所述反馈信息对应的第一验证结果。在一个示例中,所述验证终端为计算机、手机、平板电脑、智能可穿戴设备,或者其他类型的电子终端。也即,验证终端采用的是真实的硬件设备。在一个示例中,所述验证终端通过通用串行总线(universalserialbus,usb)接口或者wifi等无线接口与所述反馈处理服务器200连接,从而进行信息交互。
在一个示例中,所述控制单元103包括:第二验证模块2032,用于向所述业务服务器发出验证请求,并接收所述业务服务器的反馈。在一个示例中,所述第二验证模块2032的验证请求为统一资源定位器(uniformresourcelocator,url)访问请求。如果针对该url的访问失败,所述业务服务器将反馈相应的错误码,使得所述反馈处理服务器200得到与所述反馈信息对应的第二验证结果。
在一个示例中,所述控制单元103可以包括所述第一验证模块2031和所述第二验证模块2032。在一个示例中,所述控制单元103用于:从所述数据记录中查找错误码,按照错误码的类型对所述数据记录分类,并从每一类数据记录中选出至少一部分数据记录进行访问验证。在一个示例中,所述控制单元103可以从每一类数据记录中选择一条进行验证,也可以全部验证。
在一个示例中,所述反馈处理服务器200进一步包括:展示单元204,用于展示所述验证结果。比如,所述反馈处理服务器200在一段时间内可接收到一定数量的反馈信息,将上述反馈信息的验证结果按照错误类型进行统计分类后,以图形化的形式呈现给该反馈处理服务器200的管理员。
在一个示例中,所述反馈处理服务器200进一步包括:第一数据库205,用于存储所述反馈信息、所述数据记录和/或所述验证结果。其中,所述数据 记录与所述反馈信息关联,是所述反馈处理服务器200从所述业务服务器拉取到的。在一个示例中,第一数据库205也可以是独立于反馈处理服务器200的一个设备,反馈处理服务器200可以对该第一数据库205进行数据的存取操作。
图3为本发明实施例中网络系统300的结构示意图。该网络系统300包括:反馈处理服务器301、验证终端302。
在一个示例中,该反馈处理服务器301用于接收反馈信息,获得与所述反馈信息对应的数据记录提供给验证终端。该反馈信息是由进行过网络访问的用户终端发出的,业务服务器上存储有该网络访问的日志。
在一个示例中,该验证终端302用于对该数据记录进行访问,并将访问情况提供给所述反馈处理服务器301作为该反馈信息的验证结果。需要指出,该验证终端302不同于发出反馈信息的所述用户终端,而是该网络系统300中设置的用于对网络访问进行再次验证的终端设备。当然,验证终端302可以采用常规的智能手机、平板电脑等,在其上加载可实现上述验证功能的可执行文件(比如验证脚本等)即可。在一个示例中,验证终端302接收到所述数据记录后,从中获得网络访问特征信息(比如网络地址等)。随后,该验证终端302向该网络地址发出访问请求,并记录相应的访问结果提供给所述反馈处理服务器301。在一个示例中,该访问结果与反馈信息是一致的(比如都是访问失败等),或者该访问结果与反馈信息不一致。
图4为本发明实施例中网络系统400的结构示意图。该网络系统400包括:反馈处理服务器301、验证终端302、网络403、用户终端404、第一数据库405、业务服务器406、第二数据库407。
其中,反馈处理服务器301和验证终端302的功能可参考图1-3中的描述,此处不再赘述。在一个示例中,反馈处理服务器301是用于进行反馈处理的该网络系统400的核心设备。
在一个示例中,反馈处理服务器301可根据用户终端404提供的反馈信息中携带的用户标识到与业务服务器406关联的第二数据库407拉取对应用户的数据记录。在一个示例中,所述用户标识为全局唯一标识符(globaluniqueidentifier,guid),用于指示对应的用户。在一个示例中,该数据记录可以是第二数据库407存储的日志信息,该日志信息记录有网络访问成功或失败等信息,以及失败情况下的具体错误类型等。在一个示例中,日志信息中的一个关键字是错误码(errorcode),当该错误码为0时表示访问成功,不为0是访问异常。需要指出,错误码的取值对应的含义可根据实际需要进行设置,比如也可以规定当错误码为0时表示访问异常,这点在本发明实施例中并不加以限定。
在一个示例中,反馈处理服务器301将拉取到的数据记录按照错误码进行分类,把具有相同错误码的数据记录归为一类进行真机验证,从而批量解决对应的反馈信息。在一个示例中,反馈处理服务器301针对每类错误码选出一条数据记录,将其网络地址发送给验证终端302,由验证终端302对该网络地址进行访问,得到验证结果。在一个示例中,验证终端302也可对每类错误码对应的多条数据记录全部验证。
比如,反馈处理服务器收到10条反馈信息,通过业务服务器406从第二数据库407拉取每条反馈信息对应的数据记录,获得10条数据记录。之后,反馈处理服务器301对所述10条数据记录进行分类,发现3种类型的错误码。为此,反馈处理服务器301针对每种错误码,要求验证终端302进行一次真机验证。
在一个示例中,用户终端404在其用户使用浏览器访问网络403出现问题时,向反馈处理服务器301发出反馈信息。在一个示例中,用户终端404和反馈处理服务器301之间也通过网络403相互连接、通信。
在一个示例中,反馈处理服务器301会将拉取到的每条数据记录都存入第一数据库405以备后用。此外,第一数据库405还可存储反馈信息、分类信息、验证结果等。在一个示例中,该验证结果可以是通过真机验证得到的 第一验证结果,也可以是与业务服务器406交互得到的第二验证结果。在一个示例中,该分类信息包括:用户所访问网站的分类信息、错误码的分类信息等。
在一个示例中,业务服务器406用于向所述反馈处理服务器301提供所述数据记录。在一个示例中,业务服务器406可根据反馈信息中的用户标识从第二数据库407中查找到一条或多条该用户的数据记录。在一个示例中,业务服务器406需要根据用户标识和反馈日期进行上述数据记录的查找。
进一步地,所述反馈处理服务器301在获得数据记录后,可进一步向所述业务服务器406发出针对该数据记录的访问请求,并根据该业务服务器406的响应生成反馈信息的第二验证结果。比如,反馈处理服务器301可获得该数据记录的网络地址,并直接向业务服务器406发出访问该网络地址的请求,业务服务器406将对这一访问请求给出响应,指示访问成功或失败。需要指出,这种类型的验证能够定位出简单的网络问题。
在通过所述网络系统400得到第一验证结果和/或第二验证结果后,反馈处理服务器301将对上述验证结果进行汇总分类,输出测试报告等。在一个示例中,所述测试报告包括:访问成功网站的数量、访问失败网站的数量、第一次访问成功/失败的网站数量、第二次访问成功/失败的网站数量、访问总数等。在一个示例中,真机验证可以执行多次。比如,对某条数据记录采用真机第一次进行访问验证的结果是成功,则计入第一次访问成功的网站数量。对于第一次访问验证失败的数据记录,还可以进行第二次访问验证,如果成功则计入第二次访问成功的网站数量。在一个示例中,网络站点可根据规模、内容、影响力等因素划分出不同类型:访问大站、访问小站、成人站点等。对验证结果进行汇总分类可以是计算出访问大站成功的数量/占比、访问小站成功的数量/占比、成人站点成功的数量/占比等。测试报告、汇总分类等可通过图2所示的展示单元204呈现给反馈处理服务器301的管理员。
图5为本发明实施例中反馈处理方法500的流程示意图。在一个示例中, 该方法500由计算机实现,包括以下操作。
在步骤501,接收针对网络访问的反馈信息。在一个示例中,该反馈信息可以是针对媒体播放发出的,也可以是针对内容下载发出的,或者是针对浏览器内核故障发出的。在一个示例中,该反馈信息是用户终端通过网络发送给反馈处理服务器的。
在步骤502,从业务服务器获取与所述反馈信息对应的数据记录。
需要指出,网络访问可基于浏览器进行,而浏览器一般可提供多种网络访问业务,因此需要确定该反馈信息所针对的业务类型,从而到相应的业务服务器获得所需的数据记录。在一个示例中,该步骤502是由反馈处理服务器自动执行的,也即反馈处理服务器接收到反馈信息后,对其进行解析,再根据解析结果获知需要到哪个业务服务器拉取数据记录。
在步骤503,对该数据记录进行访问验证得到验证结果。在一个示例中,所述验证是指通过再次访问定位出反馈信息所指示的网络访问是否存在问题,以及存在什么问题等。在一个示例中,所述再次访问是采用真机验证实现的。在一个示例中,所述再次访问是通过反馈处理服务器301与业务服务器406之间的简单交互实现的。
图6为本发明实施例中反馈处理方法600的流程示意图。该反馈处理方法600包括以下操作。
在步骤601,接收针对网络访问的反馈信息。该步骤601可参考步骤501。在一个示例中,所述反馈信息包括:用户标识和反馈内容。其中,反馈内容可以是“网络无法访问”等文字信息。
在步骤602,从所述反馈内容判断是否为访问异常,如果是就执行步骤603,如果否就结束本流程。
在步骤603,根据所述用户标识从业务服务器获得相应的数据记录。
在步骤604,从所述数据记录获取网络访问特征信息,发送给验证终端。
具体地,该网络访问特征信息用于描述与网络访问相关的特征。在一个 示例中,该网络访问特征信息为网络地址。比如,该网络地址是媒体的播放/下载地址,应用的下载地址,或者网页的url地址等。在一个示例中,还可以从数据记录中获取网络接入方式(比如采用3g还是wifi接入)、用户终端404的具体机型、操作系统的版本信息等其他网络访问特征信息,提供给验证终端302,使得验证终端302根据上述信息进行真机调度测试,更准确地再现用户终端404的网络访问场景,从而定位出问题。比如,验证终端302采用与用户终端404相同的网络接入方式、操作系统版本等向该网络地址发出网络访问请求。
在步骤605,接收所述验证终端根据该网络访问特征信息进行的网络访问的验证结果。在一个示例中,该访问结果可采用错误码的形式呈现。
媒体播放(比如视频播放等)是浏览器的主要功能之一,用户量较大,针对媒体播放的反馈信息相应也较多。图7示出本发明实施例中媒体播放时反馈处理方法700的流程示意图。其中,所述媒体可以是视频、音频、动图、多媒体等。在一个示例中,所述动图是指由多张静态图片帧组合而成的图片,各帧按一定的速度播放而形成动态的图片效果,比如3d动画等。
在步骤701,导入针对媒体播放的反馈条目。在一个示例中,反馈信息可包括一条或多条反馈条目,反馈处理服务器可逐条加以处理。在一个示例中,一条反馈条目记录有用户标识,用于指示该反馈条目是由哪个用户生成的。在一个示例中,该用户标识可以是guid,作为标识该用户的唯一识别码,将该反馈条目和业务服务器保存的数据记录(比如媒体播放日志等)关联起来。后续步骤702-708将详细说明对每条反馈条目的处理过程。
在步骤702,根据该反馈条目中携带的反馈内容判断该反馈条目是否为媒体播放异常,如果是就执行步骤703,如果否就执行步骤709。
在一个示例中,所述反馈内容可以是解析异常时的错误提示。比如,在媒体播放失败时,浏览器上将出现错误提示,向用户告知一些常见的异常情况。相应地,用户向反馈处理服务器上报反馈信息时,可以将上述错误提示 作为反馈内容告知该反馈处理服务器。在一个示例中,可将带有用户标识和反馈内容的该反馈条目保存到第一数据库中。
在步骤703,从媒体播放服务器获取与该反馈条目对应的媒体播放记录。
在一个示例中,该步骤703是根据该反馈条目中的用户标识查询相应的媒体播放记录。在一个示例中,反馈处理服务器从媒体播放服务器的第二数据库407找到该用户标识所指示的所有媒体播放记录。在一个示例中,只根据用户标识进行检索将查找到大量的、与该用户相关的媒体播放记录,此时,该反馈条目可进一步包括反馈日期,以便根据该反馈日期从第二数据库查询到该反馈条目所确切对应的媒体播放记录。也即,可进一步根据反馈日期从第二数据库407中筛选媒体播放记录。在一个示例中,可以从该用户标识对应的所有媒体播放记录中找出落在该反馈日期这一天的失败记录,作为媒体播放记录提供给反馈处理服务器。
在步骤704,判断该媒体播放记录中是否有错误码,如果是就执行步骤705,如果否就执行步骤708。
在一个示例中,错误码指示的类别包括:用户网络问题(比如无网络),网站内容问题(比如色情网站不可访问),播放器问题等。
在步骤705,将该媒体播放记录标记为异常。
在步骤706,判断该媒体播放为本地播放或者在线播放。如果是本地播放则执行步骤708。如果是在线播放则执行步骤707。在一个示例中,所述本地播放是指将媒体下载到用户终端本地(比如手机存储卡等)后进行播放。
在步骤707,从该媒体播放记录中获取播放媒体时的网络访问特征信息(比如网络地址等),发送给验证终端进行播放验证,并接收所述验证终端对该网络地址的访问结果,再执行步骤709。
在一个示例中,所播放媒体的网络地址为某个网页内播放该媒体的网址。在一个示例中,验证终端所进行的播放验证主要包括:验证网站问题,验证播放器问题等。比如,由于网站改版带来播放失败的问题,或者媒体播放请求中没有携带指定参数导致播放失败等。
在步骤708,启动人工分析,再执行步骤709。
在一个示例中,人工分析是指人工联系提供反馈条目的用户获取媒体播放记录,再基于所述媒体播放记录人工进行验证,确认该反馈条目的播放失败问题。
在步骤709,判断反馈处理是否结束,如果否就返回执行步骤701,如果是则结束本流程。
在一个示例中,步骤709判断的是所有反馈条目是否都已执行过步骤702-708的分析流程。比如,在步骤701中导入3条反馈条目,则需要逐条进行步骤702-708的分析。
从图7的流程看出,本发明实施例在反馈处理时引入计算机自动验证进行问题定位。进一步地,对于通过计算机无法处理的反馈信息,再启动人工分析。也即,在机器处理的基础上叠加人工处理的环节。和单纯人工分析的手段相比,本发明实施例提高了反馈处理的效率。在一个数据统计中,图7所示的流程能验证80%的媒体播放失败类反馈信息,并且90%的工作可以实现计算机自动化处理,与以往单纯的人工分析方式相比,可将反馈跟进率从20%提升到80%,并能缩减处理反馈信息的0.5人力。
图8为本发明实施例中内容下载时反馈处理方法800的流程示意图。在一个示例中,所述内容下载可以是媒体下载、应用(app)下载等。在一个示例中,该反馈处理方法800由反馈处理服务器100实现。
在步骤801,导入针对内容下载的反馈条目。在步骤802,根据该反馈条目中携带的反馈内容判断该反馈条目是否为内容下载异常,如果是就执行步骤803,如果否就执行步骤807。在步骤803,从内容下载服务器获取与该反馈条目对应的内容下载记录。在步骤804,判断该内容下载记录中是否有错误码,如果是就执行步骤805,如果否就执行步骤806。在步骤805,从该内容下载记录中获取下载内容时的网络访问特征信息(比如网络地址等),发送给验证终端进行下载验证,并接收所述验证终端对该网络地址的访问结果, 再执行步骤807。在步骤806,启动人工分析,再执行步骤807。在步骤807,判断反馈处理是否结束,如果否就返回执行步骤801,如果是则结束本流程。
在一个示例中,用户终端的下载失败页面设置有反馈按钮。用户通过点击该反馈按钮可以发出反馈信息,将下载失败提示中出现的故障原因作为反馈内容发送给反馈处理服务器。在一个示例中,可以在不同的网页上分别设置反馈按钮,比如下载视频的页面上设置有第一反馈按钮、位于页面的下方,下载应用的页面上设置有第二反馈按钮、位于页面的上角等。在一个示例中,也可以在一个网站的主菜单上设置一个统一的反馈入口。在一个示例中,用户可以在内容下载失败后登录特定的反馈论坛,向反馈处理服务器发出该反馈信息。需要指出,用户在内容下载时和登录反馈论坛时使用的是同一个用户标识,以便将反馈信息和内容下载服务器中的内容下载记录正确地关联起来。
图9为本发明实施例中浏览器内核故障时反馈处理方法900的流程示意图。在一个示例中,该反馈处理方法900由反馈处理服务器100实现。在一个示例中,浏览器内核用于对网页语法进行解释并显示网页。在一个示例中,浏览器的内核故障是指某个网页无法访问。
在步骤901,导入针对内核故障的反馈条目。在步骤902,根据该反馈条目中携带的反馈内容判断该反馈条目是否为浏览器异常,如果是就执行步骤903,如果否就执行步骤907。在步骤903,从网页维护服务器获取与该反馈条目对应的网页访问记录。在步骤904,判断该网页访问记录中是否有错误码,如果是就执行步骤905,如果否就执行步骤906。在步骤905,从该网页访问记录中获取访问网页时的网络访问特征信息(比如网络地址等),发送给验证终端进行访问验证,并接收所述验证终端对该网络地址的访问结果,再执行步骤907。在步骤906,启动人工分析,再执行步骤907。在步骤907,判断反馈处理是否结束,如果否就返回执行步骤901,如果是就结束本流程。
图10为本发明实施例中反馈处理服务器1000的结构示意图。该反馈处理服务器1000包括:处理器1001,以及存储器1002。在一个示例中,该存储器1002为非易失性机器可读存储介质。
在一个示例中,存储在该存储器1002中、由该处理器1001执行的程序模块1003包括:控制模块1013和接口模块1023。
接口模块1023用于接收反馈信息,并从业务服务器获取与所述反馈信息对应的数据记录。控制模块1013用于控制所述数据记录的访问验证,得到验证结果。
在一个示例中,该程序模块1003进一步包括:数据库交互模块1033,用于将所述反馈信息、所述数据记录和/或所述验证结果发送给第一数据库205进行存储。
在一个示例中,该程序模块1003进一步包括:展示模块1043,用于将所述验证结果以图形界面的形式展示在该反馈处理服务器1000的显示屏上。
在一个示例中,该反馈处理服务器1000的具体实现可参考图1-9所示。
可以看出,本发明实施例通过设置反馈处理服务器进行反馈信息的分析和验证,对反馈信息的内容尽可能采用机器自动解析和关联,比如从反馈信息中获取用户标识用于数据记录的提取,将失败的数据记录对应的网络访问特征信息(比如网络地址等)提供给验证终端进行真机验证等,从而提高了处理效率,减少了人工成本的开销。进一步地,对问题的及时分析和定位也在一定程度上降低了网络访问的失败率。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。