一种基于用户反馈检测大型在线系统前台故障的方法

卢皓川 郑吴杰 周扬帆 王 新

1(复旦大学计算机科学技术学院 上海 200433) 2(上海市智能信息处理重点实验室 上海 200433)3(深圳市腾讯计算机系统有限公司 广东 深圳 518000)

0 引 言

大型在线服务系统在当今互联网时代已广泛普及，许多公司、企业均上线了大量服务于生活方方面面的大型在线系统(如支付宝等)[1]。这些系统依托于庞大的后台大型业务系统来实现服务功能，并利用前台复杂精巧的客户端来为用户实现对服务的接入。然而，由于系统的前后台都具有很高的复杂性，并且需要频繁的快速迭代开发，系统往往会出现多种类型的故障，而这些故障会引发不良的用户体验，降低系统的可靠性[2]。因此，如何检测系统中的故障是一个重要的任务。

传统上，为了更好地反映系统中存在的故障以帮助检测，许多研究及工业界方法均采用后台指标监控的方式。这一方法通过根据以往运维经验预设一些与系统后台相关的关键运行指标[3-4](如后台CPU工作负荷[5])，来反映系统后台的运行状态，从而通过异常指标表征其中存在的故障。然而，在实践中我们发现，系统的故障不仅存在于后台业务系统中，同样也会广泛地存在于前台界面中，这些前台故障同样会对用户使用体验带来严重的影响[6]。例如，前台界面控件(如按钮等)异常遮挡的故障将导致用户无法正常进行相关操作；又如前台界面中的内容错误(如乱码)，会对用户使用产生困扰和误导。面对此类故障，上述基于系统后台的指标监控方法难以奏效，因为后台相关运行指标难以反映前台中的故障症状。更进一步地，由于前台故障的类型与症状更为繁多且不可预知，若采用类似方法在前台通过经验人为预设一些指标进行监控，则难以达到良好的覆盖面，许多未被事先考虑、甚至是新出现的前台故障难以被预设的指标所表征。因此综上，这类前台故障尚需有效的方法对其进行合理的监控与检测。

为了解决面对前台故障时后台预设指标效力不足的问题，我们认为随着故障发生而动态地构建指标是一个良好的方式。我们发现，前台故障更直接面向用户。由于用户为系统前台最直接的使用者，他们会对其中产生的故障有及时的感知，因此我们将问题转化为从用户的角度进行针对于前台故障的动态的指标构建。为了避免直接使用收集用户数据可能造成的隐私问题，我们采用用户反馈数据来构建动态指标。我们发现用户往往会对所遭遇的故障实时地提出大量的反馈(通过客户端接口、客服、官方论坛等方式)，这样的反馈主要为文本形式，其中会包含对于故障症状的具体描述。因此我们可以通过设计合理的自然语言处理方法从中抽取出能够表征前台故障的指标，以便进行对前台故障的监控。由于这种指标构建方式可以随着不同出现的故障所对应的反馈文本进行实时抽取，因此实现了动态构建，以及对不同故障的高覆盖率表征。

进一步地，通过基于用户反馈文本的动态的指标构建我们将获得海量的针对于前台故障的指标。由于故障检测的时效性十分重要，因此在海量指标上实现快速的异常检测也是一大关键要求。本文基于从反馈文本中构建的指标，设计了一种两阶段的检测算法。该方法通过一个基于规则的快速过滤粗筛，以及一个基于机器学习分类模型的精细检测，来做到准确、快速地对海量动态指标的实时监控，从而实现对前台故障及时的检测。

本文所提出的基于用户反馈的动态指标构建方法以及异常检测方法，被实际应用于多个真实的在线服务系统中，协助进行更全面的前台故障检测。我们通过在实践中收集的数据来反映该方法效益，实践结果证明提出的方法可以达到针对前台故障良好的检测效果。

本文所提出的具体贡献总结如下：

(1) 为应对检测系统前台故障时传统指标监控方法的局限性，我们提出了动态构建指标的新方案，并开创性地使用了利用用户反馈数据来进行指标构建。该方法所构建的指标可以针对于前台故障实现更大的覆盖面，从而更全面地表征前台出现的各种类型故障。

(2) 为在动态构建的海量指标上实现快速检测，我们进一步提出了一种两阶段的异常检测算法，该方法通过快速过滤与机器学习的结合，实现在海量动态指标上的实时异常检测，保障了故障检测的时效性。

(3) 将该方案制作成工具以实际服务于真实大型在线系统。在多个真实系统上部署了我们提供的技术方案用于前台故障实时检测，实践证明该方法可以取得良好的效果。

1 预备知识

1.1 大型在线服务系统前台故障

近年来，许多大型的服务运营商均上线了大量大型在线服务系统开放给公众使用。这些系统均为前后台分离的架构[7]，一方面，庞大的后台系统为其业务功能提供支持，通常以上百台云服务器的超大规模的方式进行部署。另一方面，前台客户端为用户提供了服务接入的入口，通常安装于不同类型的终端上。由于部署前台的终端环境十分复杂且不可预知，可能产生不同的兼容性问题，因此系统前台常常产生前台故障[6]。这类前台故障种类和症状十分多样，如乱码、界面控件错乱遮挡或是部分控件无法显示和响应等等。图1给出了一个应用前台故障的样例，其按钮控件被错误的遮挡，且界面上出现了乱码。此类故障由于对系统后台不产生明显影响，因此很难由传统后台指标监控的方法监控到。即使有针对于前台预设的指标，也难以良好地覆盖和表征各种类型的前台故障。然而，前台故障在同样系统用户侧均会造成较大的影响(如界面无法响应等)，从而严重降低系统可靠性，影响用户体验，因此它们是一类无法忽略并且十分重要的故障问题。所以亟需一个更全面、有效的故障检测方案来应对更多类型的故障。

图1 大型在线服务系统前台故障样例

1.2 用户反馈

大型线上系统通常具有海量用户。部分应用的日活跃用户数量可达上亿级别。由于用户是前台系统的直接使用者，会对各种前台故障产生及时的感知，而这样的故障也会在用户群体中引起比较强烈的反响。用户反馈就是反响的一种主要形式。当用户在使用过程中发生不良体验时，用户就会试图通过多种渠道来进行对这些不良体验所对应的故障的反馈。这些渠道包括服务客户端中自带的反馈接口，或是系统官方论坛等等。由于巨大的用户量，系统运营商每天可以收集到大量的用户反馈，数量达到百万级别。这些用户反馈都是以自然语言的文本为主，内容包含了各种各样对于系统故障的描述。表1是一些用户反馈的示例。

表1 用户反馈示例

1.3 故障检测相关研究

系统故障检测是维护大型系统可靠性中的一个重要任务，引起了许多学术界和工业界的研究。对于后台故障，已有许多研究利用系统后台预设的关键运行指标来进行故障检测。例如，Laptev等[8]提出了EGADS系统，利用后台指标的时序信息通过多种异常检测及趋势预测模型组合来检测指标异常。Liu等[9]提出了Opprentice系统，其面向于某一个时间窗口内的后台指标采用了机器学习的分类技术检测异常。然而，利用预设的后台指标无法有效表征和定位前台故障。前台故障由于症状繁多且复杂，目前研究方法仅针对了其中部分故障类型提出了解决方案，如Wang等[10]提出利用卷积神经网络技术识别前台界面中产生的文字堆叠故障。而本文利用用户反馈进行的动态指标构建与监控方案，不仅可以有效应对前台故障，更可以实现各种故障类型的全面覆盖。

用户反馈数据在过去的研究中也体现出了对于推动软件的开发、迭代和维护的重要价值。例如，Di Sorbo等[12]提出利用主题模型总结用户反馈中的关键用户需求来辅助软件迭代。Vu等[13]提出基于短语的聚类机制来分析App市场中的用户评价，从而分析App的优缺点。Gao等[14]提出了IDEA工具，同样利用主题模型分析历史上所有的用户反馈，从中发现与系统故障相关的主题内容。然而，以上方法只可将历史上的用户反馈视为一个静态的数据进行分析，无法做到基于用户反馈进行动态的故障检测。同时，以上方法都需要基于复杂的自然语言模型算法，其面对海量反馈文本的时候难以快速地得到分析结果。因此，这些工作无法有效胜任实时的系统故障检测任务。

2 方案架构

本文所提出的基于用户反馈进行前台故障检测的技术方案整体流程架构如图2所示。可以看到，该方案主要分为两个部分：(1) 前台系统关键指标构建阶段以及(2) 指标异常分析检测阶段。

(1) 前台系统关键指标构建阶段 (2) 指标异常分析检测阶段图2 基于用户反馈的前台故障检测方案整体流程架构

在第一部分中，我们先通过对反馈文本进行词语抽取，来形成监控指标的定义；并进一步对这些指标的监控值进行量化和收集，从而构建出海量针对前台故障的监控指标。通过反馈文本抽取的指标定义实现了对不同故障症状的覆盖，而对监控值的收集可以形成指标趋势从而进行异常检测。

在第二部分中，我们提出了两阶段的异常检测算法来对前一部分中构建的海量指标进行检测。首先我们通过一个基于规则的快速过滤，找到具有潜在异常风险的部分指标；进而再对这些指标进行基于机器学习的精细检测，从而精确找到其中包含异常的指标。在第一阶段中我们快速过滤掉了绝大部分不包含异常的指标，极大地减少了第二阶段精细检测的工作量，从而实现了快速、实时的故障检测。

两部分设计中涉及到的关键技术点为：文本指标抽取及量化和两阶段异常检测算法。

3 技术细节

3.1 指标构建

(1) 指标内涵定义。我们通过对用户反馈文本进行处理来构建指标的定义。图3展示了这一文本处理过程。首先，通过jieba分词技术[15]对文本进行分词处理。进一步地，通过构建常用的停用词表，过滤掉部分无关的停用词。这一步操作使得我们可以分离出反馈中与故障描述相关的元素。接下来，将分离出的词语进行两两组合，将每一对组合作为一个指标的定义。我们将通过这一构建方法得到的指标称为“词语组合指标”。

图3 文本处理构建指标内涵定义过程

构建词语组合指标有以下几个方面的优点：首先，词语组合可以提供更多的语义描述信息，例如，“[图片，加载]”这样的指标可以表征前台在图片显示方面的故障；“[按钮，覆盖]”这样的指标可以体现前台界面上出现控件重叠的故障。也正是由于用户反馈往往是以短句、短文本的形式呈现的，采用其中词语组合即可对句子的核心语义有比较好的表征。因此，词语组合指标这种构建方式在语义保留方面是有优势的。

其次，词语组合指标的设计同样实现了对多种故障类型的大范围覆盖。通过两两词语组合，我们能迅速构建出极其海量的指标(可达到十亿级别)。我们可以在其中找到关于各种类型、症状的故障进行表征的指标，并且可以做到非常细的覆盖粒度。相比于基于主题模型的直接主题聚类的方法，利用这种海量、细粒度的指标进行基于指标的异常检测分析可以更有效地精确区分相似但不同的故障。

最后，构建词语组合指标比使用复杂的自然语言处理算法模型更加高效。由于该构建方法仅需要简单的词语切分和词语组合过程，因此可以在非常短的时间内完成对海量反馈文本的处理。而形成的海量指标可以利用底层数据库系统加以维护，从而实现良好的存储和管理。而复杂自然语言处理模型则对于单个文本需要很长的处理时间，无法实时在海量反馈文本中完成分析。

(2) 指标量化。当通过词语组合完成指标的定义后，我们进一步收集与指标相关的数据，从而量化指标用于监控的数值。我们使用每个指标中词语组合在每小时内所有反馈文本中的出现频数作为其指标监控值。例如，“[菜单，遮挡]”这一词语组合在某日18:00至19:00这1小时内所有反馈文本中出现5次，则其这1小时的指标监控值即为5。值得注意的是，这样的指标监控值统计起来是非常迅速的，只需在对每个文本分词并构建词语组合指标的同时，在数据库中查询，若已存在该指标的索引，则在该指标的在当前时间戳下对其频数进行累加统计，若没有这一指标索引，则新建这一指标索引，并且初始化其当前时间的指标值为1，作为后续累加的基础。这样一来，随着时间的进行，词语组合指标在每小时的监控值会形成一个时间序列趋势，我们将它称为“历史频数趋势”。图4给出了一个历史频数趋势的样例。

图4 指标对应历史频数趋势样例

从上述的定义可以看出，每一个词语组合指标都将对应着一个专属于它的历史频数趋势。每一个指标的趋势曲线都可以体现出其对应词语组合在某个时间区间内的出现次数的频数变化。我们进而就可以根据这样的趋势曲线分析出其中异常的变化趋势，从而发现其对应词语描述的严重系统故障。

3.2 异常检测

(1) 快速规则过滤。由于基于词语组合生成的指标数量庞大，可达上千万级别，直接对每个指标都进行复杂的机器学习异常检测所需要的开销是无法承受的。因此，我们首先设计了一个快速过滤机制，利用规则对指标进行筛选，选择出少部分具有潜在异常风险的指标。通过这一方式，我们大大地减少了后续机器学习精确检测的处理量，为实现实时异常检测奠定了基础。

这一过滤方式所基于的规则介绍如下：对于一个词语组合指标I及其对应的历史频数趋势HI，在t时刻时，我们设计逻辑函数Rem(I,t)来决定当前时刻这一指标是否被留下，即筛选为潜在异常风险的指标。这一函数的定义如下：

(1)

由式(1)可见，当两方面条件同时被满足时，这一指标将被留下作为具有隐含故障可能性的候选指标，以待后续更精确的检测判断。若任意一个条件不满足，该指标将被视为正常而过滤。该过滤策略具有较好的可控性和合理性。

这样的过滤对于后续异常检测工作量的减少是十分有效的。一方面，这一过滤手段仅仅基于直接的数值计算和比较，可以通过底层简单的数据库查询实现。另一方面，根据统计显示，在一周的利用反馈数据做异常检验的过程中共能产生千万级别的词语组合指标，而经过这一阶段的过滤后，仅留下了数万个具有潜在风险的词语组合指标以供后续分析。因而这一过滤阶段减少了超过99.9%的工作开销，成为实现检测实时性的关键。

(2) 机器学习检测。通过上一过滤步骤获得了少量具有潜在风险的指标，我们进一步利用精细的机器学习算法对其中真正具有异常的指标进行检测。首先对这些指标进行了特征抽取。特征包含两个方面，一是时间趋势特征，我们将这些指标的过去7天及过去24小时内的趋势监控值进行了提取，并计算平均数、方差等统计值，作为不同的特征维度。另一方面的特征为文本特征，我们利用词袋模型的Jaccard距离计算了当前这一小时内与该指标词语组合相关的反馈文本的文本多样性，并将这一值作为特征之一。我们认为当出现故障时，用户的反馈会集中在这一故障的描述上，因此会有较低的文本多样性。综合这两方面的特征，构建出了对于每个指标的特征向量。

进一步利用XGBoost模型[16]来对这些特征向量进行分类，来识别每一个指标是否属于异常。我们事先通过部分人工标注了千余条数据来进行训练，来获得具备识别功能的模型。这一标注过程引入了专家经验来指导模型识别，使得这一检测过程更为精确。

通过以上方式，我们利用机器学习算法精确识别出了存在异常的指标，而这些指标对应着系统存在的故障。可以将这些异常指标根据指标词语之间的相似性进行归类，从而具体汇总出其中的故障。这样，该方案就完成了利用用户反馈对前台故障进行实时检测的过程。

4 实验测试

4.1 实验环境及目标

本文提出的基于用户反馈的前台故障检测方法被真实地应用在多个大型线上服务系统中进行辅助性故障检测，这些系统包括某社交媒体应用、某企业办公应用、某游戏运营平台、某日常娱乐类应用、某资讯类应用等。这些线上服务系统均在各大终端平台上有不同的前台客户端，并时常有频繁的更新和迭代，因此，这些在线服务系统对于前台故障的监控有着明显的需求。

另一方面，由于这些系统均拥有大量的用户群体，这些用户每日可以提供大量的用户反馈数据来作为分析的数据源。根据统计，这些服务每日收集到的反馈量可以达到两百万条，其历史反馈数据总量已达到上百GB。这样丰富的反馈数据为本文提出方法的有效使用提供了有利条件。

作为一个检测前台故障的技术方案，本实验的主要目的为检测其检测故障的准确率、以及对严重故障的召回率。此外，我们还对比了该方案与传统上已人工方式检测前台故障之间的效果差异，从而体现该方案的效能。

4.2 检测准确率

准确率是考察该方法检测出的所有故障中，对应着真实出现的故障的比例。检测准确率体现了一个故障检测方案是否可以精确地对真实故障进行报警，避免误报的产生。

为了验证准确率，我们对于检测出的故障进行了人工审查，从而确认检测到的故障中正确发现故障的数量以及误报故障的数量。我们从两个维度进行了实验来评估本文方案检测故障的准确率。一方面，以不同的服务系统为维度，研究在多种服务应用中，该方案进行故障检测的准确性表现。这一维度主要验证该方案在不同的服务系统场景下，是否均具有良好的通用表现。我们采用了前文所述部署该方案的五个服务系统(即社交媒体应用、企业办公应用、游戏运营平台、日常娱乐应用、资讯应用)为实验对象，统计了这些应用在一个月内各自被检测出的所有前台故障数量，并通过人工标注获得正确对应真实故障的检测数量，进而计算出准确率。实验结果数据如表2所示。

表2 不同应用系统中故障检测准确率

可以看到，该故障检测方案在不同应用上总体可以达到比较良好的检测准确率，均达到70%及以上水平，在某些应用中甚至可以达到90%以上或更高。注意这一检测是从上百万用户反馈中进行的有效筛选而得出的数十个乃至数个故障检测，因此这样的准确率已经可以达到满意的水平，开发者可以以此检测结果为依据在一个很小的范围内精确、高概率地定位真实故障。

另一方面，我们以时间为维度，研究该方案在一个较长的时间过程中是否能持续保持良好的检测准确性。我们收集了在五个月内在上述应用中的故障检测情况及其人工审查结果，并统计其准确率，结果如表3所示。

表3 不同时间内故障检测准确率

可以看出，该方案在几个月内的综合准确率表现相当稳定，准确率均能保持在70%左右的水平。这体现了该方案可以应对不同时期出现的不同反馈描述内容，在长期运维任务中也能做到良好的表现。

综上所述，在本文提出的基于用户反馈进行前台故障检测的方案在检测准确率方面具备良好的效果。

4.3 检测召回率

召回率考察的是系统出现的所有故障中，被该故障检测方案检测到的故障数量。召回率体现了故障检测是否可以将各种出现的故障均覆盖到，避免漏报。

在这些服务系统中，有专门通过人工测试的方法前台故障进行的收集。这些故障都是真实存在且经过审核的。我们以这些故障为基础，来考察本文提出的检测方法是否能够高覆盖率地检测到这些故障。表4展示了一周以内所有人工验证到的故障数量及其被该方案检测到的数量和比例。

表4 人工验证故障的召回率

可以看到，本文方案这批故障有着非常高的召回率(>90%)，并且仅有非常少的故障被遗漏。这体现了该方案对于故障良好的覆盖面，具有良好的召回表现。更进一步地，随着数据的积累，我们事后可以使用更多的标注数据进一步训练异常检测模型，使得模型的检测能力更强。被遗漏的故障也都在模型进一步训练后可以被检测出。因此，本文提出的基于用户反馈的故障检测方案可以实现全面、高覆盖的前台故障检测。

4.4 效益对比

为了更好地体现本文提出检测方案的效益，我们进一步将对比了本文提出的检测方案与前文提到的人力测试检测发现前台故障的能力。由于前台故障种类繁多且不可预知，在以往的运维方式中人力检测是一个尚能奏效的传统方法。而由于本文提出的方案具有不同的检测方式，使得它具有更全面的对故障的覆盖能力，同时它可以自动化执行检测流程，也比人力检测更为高效。因此，该方案可以发现很多传统人力前台故障检测中难以发现的故障。图5展示了一组数据，展示了在该方案一个月检测出的故障中，未被传统人力方法检测出，以及比传统人力方法更快检测出的占比。

图5 基于用户反馈检测故障与传统人力检测对比情况

从这组数据中可以发现，在所有被本文提出方案检测到的故障中，有超过四分之一是没有被传统人力检测发现的故障，这体现了该方案发现并覆盖多种类型前台故障显著的效果，对于更全面的故障检测具有明显价值。更进一步地，在其他可以同时由本文提出方案与传统人力检测到的故障中，有接近一半的故障是由该方案更快检测出的，说明该方案检测前台故障方面具有良好的实时性与时效性，可以获得更好检测效果。

5 结 语

大型线上服务系统中频繁出现前台故障问题。此类故障区别于后台故障，其种类繁多、症状复杂且不可预知，因此无法通过传统的预设后台指标监控来检测出。本文提出了基于用户反馈文本动态构建指标的方式，巧妙地将无法有效检测前台故障从用户体验反馈中挖掘出来。本文提出了利用抽取反馈文本中词语组合构建动态指标的设计，这种动态指标实现了对各种故障类型的描述和覆盖。进一步地，本文针对于构建的海量指标设计了特制的两阶段检测算法，实现对指标中存在的异常进行快速的检测，并通过异常指标表征了存在的前台故障。这一整体方案可以良好地检测多种类型的前台故障，其被实际应用于多个真实的在线服务系统中，并获得了实时、有效的故障检测效果。该方法为实际系统中的故障检测提供了新的思路和方案，作出了创新性贡献。