CN112306860A - 一种产品灰度包准入评估方法及系统 - Google Patents

Abstract

本发明涉及一种产品灰度包准入评估方法及系统，其中所述方法包括：根据数据监控类型，将收集到的应用灰度包的监控数据分为多个类别的监控数据；按照相应类别的分析策略分析多个类别的监控数据以得到对应类别的指标数据；以及采用准入标准分析多个类别的指标数据，以确定所述应用灰度包是否满足准入条件。所述系统包括数据分类模块、分析模块和准入确定模块。本发明从多维度对互联网产品的灰度包进行评估以得到具体的指标数据，并根据设置的准入标准、条件确定当前灰度包是否符合准入条件，既节省了人工，也能够及时发现当前灰度包的问题，在提高了评估效率的同时，也保证了灰度包的质量，从而提升了产品的线上质量。

Description

一种产品灰度包准入评估方法及系统

技术领域

本发明涉及网络应用技术领域，特别地涉及一种产品灰度包准入评估方法及系统。

背景技术

随着网络应用技术的发展，各种功能、类型的应用(Application，简称App)为人们的生产、生活带来了极大的便利。网络应用企业会根据用户需求发展多种不同的App，对于企业而言，可将不同的App称为相应业务的产品。产品在上线后是否能够按照预期设计健康运行，是该产品能够生存下去的重要因素之一。为了保证产品上线后能够健康运行，通常从以下几个方面入手：一是在设计、开发阶段，二是在测试、调试阶段，三是进行灰度测试。其中，对于一些产品在增加新模块或调整现有功能模块时，进行灰度测试是保证新版本上线后正常、健康运行的一种重要措施。现有技术中的灰度测试需要工作人员投入大量的时间、精力分析测试数据以确定该灰度包是否可以准入。由于产品的不断更新，灰度测试为工作人员带来的工作量越来越大，因而亟需一种灰度准入评估的方案以减少工作人员的工作量，并提高灰度准入效率。

发明内容

针对现有技术中存在的技术问题，本发明提出了一种产品灰度包准入评估方法及系统，用以评估产品灰度包的监测数据，提高灰度准入效率。

为了解决上述技术问题，本发明提供了一种产品灰度包准入评估方法，包括以下步骤：

根据数据监控类型，将收集到的应用灰度包的监控数据分为多个类别的监控数据；

按照相应类别的分析策略分析多个类别的监控数据以得到对应类别的指标数据；以及

采用准入标准分析多个类别的指标数据，以确定所述应用灰度包是否满足准入条件。

根据本发明的另一个方面，还提供了一种产品灰度包准入评估系统，包括数据分类模块、分析模块和准入确定模块，其中，所述数据分类模块经配置以根据数据监控类型，将收集到的应用灰度包的监控数据分为多个类别的监控数据；所述分析模块经配置按照相应类别的分析策略分析多个类别的监控数据以得到对应类别的指标数据；所述准入确定模块经配置以采用准入标准分析多个类别的指标数据，以确定所述应用灰度包是否满足准入条件。

本发明从多方面、多维度对互联网产品的灰度包进行评估以得到具体的指标数据，并根据设置的准入标准、条件确定当前灰度包是否符合准入条件，既节省了人工，也能够及时发现当前灰度包的问题；在提高了评估效率的同时，也保证了灰度包的质量，从而提升了产品的线上质量。

附图说明

下面，将结合附图对本发明的优选实施方式进行进一步详细的说明，其中：

图1是根据本发明的一个实施例的产品灰度包准入评估系统原理框图；

图2是根据本发明的一个实施例的分析模块功能框图；

图3是根据本发明的一个实施例的按照Crash数据的基本类型进行统计得出的统计指标数据示意图；

图4是根据本发明的一个实施例的对类型为Native的Crash数据进行的统计排序示意图；

图5是根据本发明的一个实施例的按照通用指标进行统计的统计指标数据示意图；

图6是根据本发明的一个实施例的对类型为Java的Crash数据进行的统计排序示意图；

图7是根据本发明的一个实施例的性能指标的统计数据示意图；以及

图8是根据本发明的一个实施例的灰度包与其参考包的核心一级指标数据对比数据示意图。

具体实施方式

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

在以下的详细描述中，可以参看作为本申请一部分用来说明本申请的特定实施例的各个说明书附图。在附图中，相似的附图标记在不同图式中描述大体上类似的组件。本申请的各个特定实施例在以下进行了足够详细的描述，使得具备本领域相关知识和技术的普通技术人员能够实施本申请的技术方案。应当理解，还可以利用其它实施例或者对本申请的实施例进行结构、逻辑或者电性的改变。

本发明提供了一种产品灰度包准入评估系统和方法，所述的产品包括各种应用(Application)。在现实情况中，一个应用由于增加功能、完善性能等原因可能包括多个版本，本发明在评估一个产品的灰度包的监测数据时，可根据需要选择或设定需要评估的灰度包及其参考包版本。

图1为根据本发明一个实施例的一种产品灰度包准入评估系统原理框图。在本实施例中，本发明从产品灰度包在测试时发生的Crash、测试时的性能表现及特定的核心一级指标等几个方面来评估一个产品灰度包是否可以准入，其中，所述系统包括应用数据分类模块1、分析模块2及准入确定模块3。

所述数据分类模块1根据数据监控类型，将收集到的应用灰度包的监控数据分为多个类别的监控数据。例如，在本发明的一个实施例中，将收集到的监控数据分为Crash类型数据、性能数据、特定的核心一级指标数据三个类别。其中，所述监控数据可以通过各种数据采集单元和数据接口获得。所述数据采集单元可作为一段采集数据的代码集成在产品应用包的客户端或/和服务端中。在用户下载应用的客户端时，采集数据的代码随之一起安装到客户端终端上，在用户端采集各种灰度监控数据。集成在服务端的采集数据代码可获取到服务端的各种灰度监控数据。本发明还包括与其他数据平台、监测系统等现有平台连接的数据接口，以获取相应的灰度监控数据。

其中，所述Crash类型数据包括用户ID、发生的版本、对应的业务模块、发生的时间、发生的次数、用户数量、发生时正在创建的线程、基本类型(如OOM、非OOM、Native、非Native或Java)、发生Crash的页面等等信息。每发生一次Crash，将包括上述信息的Crash数据记录为一条Crash记录，并为其编号以方便管理。

为了能够从不同维度获取Crash信息，所述数据分类模块1从多个分类维度分析所述Crash数据以得到所述Crash数据的对应分类维度指标数据作为评估指标数据。其中，所述的分类维度包括“Crash出现阶段”、“SDK类型”、“Crash基本类型”、“Crash出现的页面”和“Crash状态”。其中，所述“Crash出现阶段”是指当前的Crash发生在该产品的当前最新版本，还是从前的版本。在“Crash出现阶段”这一维度，在一个实施例中，将当前最新版本首次发生的Crash设置为“新增”，将最近N天在其他版本中发生的Crash设置为“近期”，将N天之前在其他版本中发生的Crash设置为“历史”。通过“Crash出现阶段”这一维度对Crash进行分级，可以快速确定该crash是否为新增问题，以避免重复分析历史问题，进而提高分析效率。

“SDK类型”这一分类维度指标用于代表发生Crash的业务线的相应业务模块，例如，对于一个企业或公司而言，其产品包括不同类型的各种应用，如广告类、直播类、阅读类的应用等等，方便相应业务部门的负责人在查看各种健康数据时可以快速跟进。

“Crash基本类型”这一分类维度指标包括OOM(Out of Memory)/非OOM、系统Native/非Native、Java或创建线程，用以区分Crash的类型。

“Crash出现的页面”这一分类维度指标用于标记Crash发生的页面类型，例如游戏页面、广告页面、应用服务页面等等。

“Crash状态”这一分类维度指标用于标记所述Crash是否根据所述Crash创建缺陷、已创建缺陷的处理状态，如已处理、待处理等状态。

对一条Crash记录，按照上述分类维度进行分类标记，从而得相应的分类维度指标数据。

其中，Crash类型的监控数据包括Crash(崩溃)数据和ANR(应用无响应)数据，上述对Crash的分类同样适用于ANR数据，在以下的说明中，如无特别说明，Crash数据包括了ANR数据。

所述的性能数据包括冷启动指标、热启动指标或页面加载指标。其中，所述页面加载指标数据包括加载时间均值和/或P90。

所述的核心一级指标数据根据产品的不同而不同，例如，对于一款新闻阅读类APP产品，其核心一级指标可包括总人均PV(Page View，访问量)、人均使用时长、次留率、人均运营成本等等。

所述分析模块2按照相应类别的分析策略分析多个类别的监控数据以得到对应类别的指标数据。在一个实施例中，所述分析模块2包括三部分，分别用于分析处理Crash类型数据、性能数据、特定的核心一级指标数据三个类别的监控数据。如图2所示，为分析模块2分析处理Crash类型数据的部分。其中，所述分析模块2包括Crash统计单元201、Crash监控单元202、缺陷跟踪管理单元203和插件包监控单元204，其中，所述Crash统计单元201以按照灰度统计指标统计所述Crash类型的监控数据以得到相应统计数据。灰度统计指标统计包括Crash次数、Crash次数占比、Crash个数、Crash个数占比、Crash影响用户数、Crash率中的至少一个，ANR次数、ANR次数占比、ANR个数、ANR个数占比、ANR影响用户数、ANR率中的至少一个。所述Crash统计单元201根据进行上述统计指标进行统计时，可根据Crash数据的不同维度进行统计，例如图3所示，为按照Crash数据的基本类型“系统Native”、“Java”、“OOM”进行的统计；如图4所示，为按照Native类型，以Crash发生的次数为排序标准，对Crash进行的排序。如图4可见，每一条Crash包括维度类型、Crash用户数、版本号、是否创建缺陷及其状态。其中，还包括创建缺陷的接口，通过该接口可以对该条Crash记录创建缺陷。

其中，所述Crash统计单元201还根据通用指标进行统计，如图5所示，通用指标例如为所述灰度包的版本号、开发负责人、测试负责人、创建时间、灰度时间或灰度包体积(图中未示出)等等数据。通过统计灰度包对应的开发和测试负责人，可以更好地推动流程实施。而灰度时间是判断能否上线的一个重要条件，只有当前灰度包的灰度时间达到了预置灰度时间阈值，如8个小时，才满足准入上线的一个条件。另外，灰度包体积也可以作为是否可以准入的一个条件，在所述灰度包体积与市场包体积之差小于预置体积阈值时，所述应用灰度包满足准入条件之一。

Crash监控单元202用以监控所述Crash类型的监控数据及统计数据，在满足报警条件时报警。例如，在收集到一个新增Crash类型的监控数据时报警，说明此时的灰度包异常；在某些统计数据超过其对应的阈值时报警。例如，Crash次数、次数Crash率、影响用户Crash率等统计指标数据超过其各自对应阈值时报警。报警信息可以通过多个渠道发送到不同的地方，例如可将报警信息发送给所述缺陷跟踪管理单元203，也可以发送给企业内部的报警平台，也可以发送给相关指定工作人员。由指定工作人员利用缺陷创建接口创建缺陷，从而可以使相关人员可以及时对所述灰度包进行改进。

Crash监控单元202还监视Crash类型的监控数据的统计数据，在其超过其对应阈值时确定其为严重问题。例如，根据Crash的类型占比及其阈值用来判断是否有某一个类型的严重问题。如图4所示，其中排序最高的一个Crash记录为91450707的Crash次数为4，该类型的Crash总次数为25，因而91450707Crash记录的Crash次数占比为4/25。对比图6中排序第一的93389252Crash记录的Crash次数为3，该类型的Crash总次数为7，因而93389252Crash记录的Crash次数占比为3/7。当Crash次数占比阈值为1/5时，3/7>1/5>4/25，因而可以判断Java类型的Crash 93389252具有严重问题，根据列表中的状态可知该问题是否已解决。

在一个实施例中，所述缺陷跟踪管理单元203在接收到所述报警时，针对报警对应的Crash类型的监控数据或统计数据创建缺陷，并跟进监控所述缺陷。例如根据缺陷的处理信息定期同步缺陷的状态，如图4、6中的待处理状态、待建状态等。对于已建缺陷的Crash数据，通过“缺陷”项中的“查看”可查看具体的缺陷信息。所述缺陷跟踪管理单元203还可以定期统计缺陷，以列表的形式标记出每一个缺陷的ID、发生次数、负责人、对应的业务或业务模块及最近一次发生时间等，还可以以图表(柱状、饼图)的形式表现出具体负责人应解决的缺陷数量。统计数据的展现方式可以多种多样，并不局限于本实施例所述的形式。

所述插件包监控单元204经配置以监控插件包灰度时间及数据变更信息。当灰度监控数据还包括插件包数据时，在一个实施例中，在流程上对插件包进行监控，即监控插件包的灰度时间和数据变更信息，在满足预置灰度时间预置，如8小时内没有数据变更，可以确定插件包满足准入条件。则可以将所述插件合并入该应用的主版本中。如果有数据变更，则需要继续8个小时的监控。

对应于灰度监控数据中的性能指标数据，所述分析模块2包括性能监控单元210。其中，性能监控单元210以预置时间段，如天或小时作为统计时间段，统计当前预置时间段内灰度包的各种性能数据，如冷起动时间、冷起动P90时间、页面加载时间等性能指标数据；对比所述性能指标数据与其对应的预置基准值以获得二者的差异；对比所述性能指标数据与其对应的预置基准值的差异与预置差异阈值，在所述性能指标数据与其对应的预置基准值的差异大于预置差异阈值时，确定所述性能指标异常。通常在输出时以红色或特定符号对异常的数据进行标识。如图7所示，为输出时的性能指标数据示意图。其中包括三项性能指标的监测值及其基准值、差异值，并采用红色表示异常的指标及数据。

当数据监控类型为核心一级指标数据时，所述分析模块还包括核心一级指标单元220。核心一级指标单元220分别统计灰度包和参考包的对应核心一级指标数据。分别对比灰度包与参考包的核心一级指标数据以获取二者的差异；对比灰度包与参考包同一核心一级指标数据的差异是否在预置阈值范围内，如果超出了预置阈值范围内，则确定所述核心一级指标异常。通常在输出时以红色或特定符号对异常的数字进行标识。如图8所示，为输出时的核心一级指标数据示意图。通过对比较当前灰度版本和基准版本的核心一级指标数据，将异常的指标数据飘红展示，方便识别严重影响上线的指标。

准入确定模块3采用准入标准分析多个类别的指标数据，以确定所述应用灰度包是否满足准入条件。其中，所述准入标准包括灰度时间应达到预置的灰度时间阈值、一些特定指标达到对应的要求，如设置Crash和ANR次数阈值，在Crash和ANR次数大于阈值时，所述应用灰度包不满足准入条件，只有在Crash和ANR次数小于阈值时，达到准入标求。所述准入标准还包括当前是否有未解决的严重问题，如果没有，则满足准入条件，否则不满足准入条件。在一个实施例中，根据前述分析模块2得到的各种指标数据，在所述灰度包的灰度时间达到了预置时间，如8小时，特定的指标达到了要求且没有未解决的严重问题，则确定所述灰度包符合准入条件，予以通过评估，否则不予通过评估。

输出模块4以图表、文字等方式输出前述分析模块2得到的各种指标数据，并对异常的指标数据进行标注，参见图3、图5、图7-8的红色标注。输出模块4根据准入确定模块3的判断，标示出是否通过评估，如图5所示的“通过”图例。输出模块4可以输出对所述灰度包的完整的评估报告，并可以包括详细的指标数据、异常指标数据的标注、是否通过的评估结果及未通过的理由等等。

本发明提供的产品灰度包准入评估系统和方法自动获取灰度监控数据，对其进行多方面、多维度的分析；通过报警、异常标注可使工作人员有针对性地解决当前存在的问题以提高灰度包质量；通过设定的准入条件评估所述灰度包是否符合准入条件，从而可以快速、准确地得到准入评估结果，因而本发明能够将工作人员从复杂的数据分析中解放出来，并保证灰度包质量，提升产品的线上质量。

上述实施例仅供说明本发明之用，而并非是对本发明的限制，有关技术领域的普通技术人员，在不脱离本发明范围的情况下，还可以做出各种变化和变型，因此，所有等同的技术方案也应属于本发明公开的范畴。

Claims (20)

1.一种产品灰度包准入评估方法，包括：

根据数据监控类型，将收集到的应用灰度包的监控数据分为多个类别的监控数据；

按照相应类别的分析策略分析多个类别的监控数据以得到对应类别的指标数据；以及

采用准入标准分析多个类别的指标数据，以确定所述应用灰度包是否满足准入条件。

2.根据权利要求1所述的方法，其中当数据监控类型为Crash时，进一步包括：

按照灰度统计指标统计所述Crash类型的监控数据以得到相应统计数据。

3.根据权利要求2所示的方法，其中所述Crash类型的监控数据包括Crash数据和ANR数据。

4.根据权利要求3所述的方法，其中所述灰度统计指标包括Crash/ANR次数及次数占比、Crash/ANR个数及个数占比、影响用户数和Crash/ANR率中的一个或多个。

5.根据权利要求2所述的方法，其中进一步包括：将Crash类型的监控数据按照预置的多个维度分类，分类统计所述Crash类型的监控数据以得到相应类型的统计数据。

6.根据权利要求2所述的方法，其中对应Crash类型的监控数据的准入标准包括Crash和ANR次数阈值，在Crash和ANR次数大于阈值时，所述应用灰度包不满足准入条件。

7.根据权利要求2所述的方法，其中进一步包括：监测Crash类型的监控数据及其统计数据，在满足报警条件时报警。

8.根据权利要求7所述的方法，其中进一步包括：在监测到新增Crash类型的监控数据时报警；或在Crash次数、次数Crash率、影响用户Crash率分别超过对应阈值时报警。

9.根据权利要求7所述的方法，其中在接收到所述报警时，针对报警对应的Crash类型的监控数据或统计数据创建缺陷，并跟进监控所述缺陷。

10.根据权利要求9所述的方法，其中在Crash类型的监控数据的统计数据超过对应阈值时确定其为严重问题；在严重问题未解决时，所述应用灰度包不满足准入条件。

11.根据权利要求1所述的方法，其中在所述数据监控类型为插件包数据时进一步包括：监控插件包灰度时间及数据变更信息；在插件包灰度时间符合预置准入灰度时间时所述插件包满足准入条件。

12.根据权利要求1所述的方法，其中当数据监控类型为性能数据时进一步包括：

统计预定时间段内的性能指标数据；

对比所述性能指标数据与预置基准值的差异；以及

响应于所述性能指标数据与预置基准值的差异超出预置阈值范围，确定所述性能指标异常。

13.根据权利要求1所述的方法，其中当数据监控类型为核心一级指标数据时进一步还包括：

获取参考包的对应核心一级指标数据；

对比灰度包与参考包的核心一级指标数据的差异；以及

响应于灰度包与参考包的核心一级指标数据的差异大于预置阈值，确定所述核心一级指标异常。

14.根据权利要求1所述的方法，其中所述数据监控类型为通用指标数据时，所述通用指标至少包括灰度时间和/或灰度包体积；在所述灰度时间大于预置灰度时间阈值时，所述应用灰度包满足准入条件之一；和/或，在所述灰度包体积与市场包体积之差小于预置体积阈值时，所述应用灰度包满足准入条件之一。

15.一种产品灰度包准入评估系统，包括：

数据分类模块，经配置以根据数据监控类型，将收集到的应用灰度包的监控数据分为多个类别的监控数据；

分析模块，经配置以按照相应类别的分析策略分析多个类别的监控数据以得到对应类别的指标数据；以及

准入确定模块，经配置以采用准入标准分析多个类别的指标数据，以确定所述应用灰度包是否满足准入条件。

16.根据权利要求15所述的系统，其中还包括输出模块，经配置以输出多个类别的指标数据及准入确定结果。

17.根据权利要求15所述的系统，其中所述多个类别的监控数据包括Crash类型数据、插件包数据、性能数据、核心一级指标数据中的一者或多者。

18.根据权利要求17所述的系统，其中所述分析模块包括：

Crash统计单元，经配置以按照灰度统计指标统计所述Crash类型的监控数据以得到相应统计数据；

Crash监控单元，经配置以监控所述Crash类型的监控数据及统计数据，在满足报警条件时报警；

缺陷跟踪管理单元，经配置以在接收到所述报警时，针对报警对应的Crash类型的监控数据或统计数据创建缺陷，并跟进监控所述缺陷；以及

插件包监控单元；经配置以监控插件包灰度时间及数据变更信息。

19.根据权利要求18所述的系统，其中所述分析模块还包括：

性能监控单元，经配置以统计灰度包的性能数据，并按照对应性能指标的基准值确定异常性能指标。

20.根据权利要求15所述的系统，其中所述分析模块还包括：

核心一级指标单元，经配置以获取灰度包与参考包的核心一级指标对比数据，并按照阈值确定异常核心一级指标。

Images