如何创建起一套有效的APP监控体系

概论：

移动APP有着本身独特的运行环境和使用场景，相比后端服务，移动APP质量一样须要作到可视、可控。移动APP是近几年刚刚出现的新产品形态，如何保障 移动APP质量是一个新的挑战和话题。今天，咱们重点介绍APP端问题如何发现、如何定位、如何止损，以及如何创建起一套有效的监控体系，为APP稳定应用保驾护航。分为“端问题概述、端质量监控方案、端监控能力建设”三个章节。

1端问题概述

app客户端产品上线前，会通过全面并且严谨的测试再发布到应用商店。但，发布后产品质量如何，以往更多地依赖于用户的反馈信息。对于较大规模的app产品，测试人员没法作到覆盖到所有的手机机型和ROM。在这种状况下，如何知道一款产品到用户手中的质量呢？此时，须要一套完善的质量监控方案，创建一套牢固的监控体系。这样，对线上产品的APP质量问题才能第一时间召回，并作到快速修复。

1.1常见问题

1.适配问题

客户端测试过程当中，测试工程师会覆盖当前比较主流厂商的机型和ROM,以及市面用户量比较大的Android/iOS版本。但，毕竟没法覆盖到市面上全部的机型和ROM，尤为是android系统的手机。因此，用户在下载一款app后常常反馈在本身的手机上页面很丑，甚至有的文字重叠，控件位置显示不正确等问题。

举一个实际遇的问题，当app上线后收到用户反馈，提到有些页面滑动比较卡顿，容易形成误点击，用户使用的机型是一款比较主流的手机。在获取到用户反馈后，测试工程师立刻找到同款手机进行复现，但未复现用户反馈的问题。后来从用户得知复现的手机和用户的手机虽然相同，可是厂商本身定制的ROM版本不一样，后来经过研究ROM代码发现厂商在新版ROM中设计了一些新的逻辑处理，会直接致使app出现卡顿。研发人员对此作了适配解决了卡顿的问题。此类案例证实，务必对主流手机及ROM更新保持较高的质量敏感性，时刻关注厂商升级。快速应变，及时适配到主流机型和ROM。

2.用户体验问题

一般，产品经理设计产品功能时，考虑得也不必定很全面，每每抱着试错的心态来设计产品，并但愿经过用户反馈来得知产品的好坏，以及用户的进一步需求。一旦考虑不周，每每就是取悦一部分用户，同时伤害到一部分用户。举一个实际例子，某一搜索类产品，产品经理为让用户在夜间浏览时有更好的视觉体验，增长了夜间浏览模式的功能。考虑到让用户更方便的设置夜间模式，产品设定为晚上20点之后自动弹出一个浮层，询问用户是否设置夜间模式，并且一键便可设定，方便了用户对夜间模式的启用。但，产品经理忽略了一个重要的问题，晚上用户启用夜间模式后，次日早上如何便捷地切换回白天模式？ 而产品并无在早上也设置一个浮层作一键切换。这样，不少用户在白天也开启了夜间模式，使用体验是很糟糕的。问题在于，切换回白天模式的功能虽然具有，可是入口隐蔽，用户很难找到。从这个问题能够看出，产品体验是设计出来的，须要在用户的实际应用中获得检验。

3.流量问题

 

当前，中国的4G资费相对欧美和日韩目前仍是比较高的，同时免费的公共wifi覆盖也不高，用户对非wifi下的移动流量消费是很在乎的。那么，一款移动app产品如何利用最少的流量下提供更多的功能？经过客户端缓存是一个常见的技术。举一个实际例子，以小说阅读为例，小说目录通常是罗列不少书籍供用户来选择，这些书籍通常都有书籍名，数据封面图及书籍简介组成。一个页面的数据有150kb，并且这个页面是小说书单的主入口，全部关于小说的操做都要由这个页面开始。若是用户反复请求这个页面，不只形成流量的浪费也会给服务端带来很大的请求压力。为此，将这个页面的数据缓存到客户端本地，若是用户在非wifi的网络下就不发送请求，若是在wifi网络环境下每间隔必定时间去服务端请求一次数据，而后将老数据删除，并将新的数据写到本地，以便用户可以获取到最新内容。这样，不只解决了流量问题，也解决了一些低配手机本地内存常常不足的问题。从这个问题来看，在产品设计时多从用户的角度出发考虑问题，用户不必定直观地感知到，但实实在在的增长了用户体验，且减小没必要要的流量消费，你说何乐而不为呢。

1.2 问题特征

上节介绍了三类常见问题。有些问题是比较容易复现和解决的，也有一些问题相对是有难度的。举几个例子：

场景一：用户反馈在WIFI网络下没法发起搜素，搜索结果异常。在WIFI环境下复现，没法复现用户反馈的问题，这时每每会归结为网络不稳定形成的。但用户可能当时确实是遇到了问题，这种没法稳定复现的问题，每每归结为偶发性的问题。

场景二：用户反馈离线下载的小说为何有时候还须要网络。因为用户离线的小说是个连载的小说，当用户阅读完离线的内容后，假设这时候小说有更新了，产品经理为了让用户可以连续的阅读就将产品设计成联网发送在线请求才能继续阅读，这和用户的认知就比较相违背。但，若是用户阅读完已经离线的部分，用户看到书没写完，也会关心为什么没有新的内容呢。相似的这种问题归结为长尾问题，须要从产品策略上持续优化来解决。

APP运行在用户手机端，而且联网到后端服务，许多质量问题也有其本身的独特性。所以，须要经过不一样手段，来实现问题的发现、定位和修复。

1.3 面临挑战

 

对于上述提到的问题，你们可能会问：这些问题该如何发现，对于这些问题如何肯定是否作立刻修复，哪些问题才算长尾问题？这就是下面将要介绍的线上问题的召回方式和问题影响面的评估。用户反馈是召回问题的一种方式，可是这种被动的召回不足以知足快速召回线上问题的要求，因此搭建一整套完善的监控系统就很是必要了。

1.监控的挑战

对于客户端产品，一旦发布出去就很难有效的控制产品的质量。为此，产品经理和数据分析师每每在产品发布前提出的监控及统计需求，研发工程师开发设计用于监控统计目的的代码，将用户的行为、产品的crash等核心质量信息以日志的方式上传到服务端，这些用户所产生的数据就为后续分析产品及质量问题提供了原始的数据依据。

2.影响面的判断

利用客户端上传的用户日志及客户端崩溃信息，进行统计分析。结合线上问题，可进行影响面的评估。影响面评估主要有三类，包括严重问题，特定场景复现问题，不影响主要功能问题。

1) 严重问题通常是要发小版原本修复的问题

2) 特定场景复现问题通常不会发小版本修复，但必定会在下一个版本进行修复

3) 不影响主要功能问题视下一个版本的排期进行修复或删减掉

2端质量监控方案

因为APP载体多种多样，产品质量问题表现形式有不少种。咱们以最通用的APP为例，总结为如下几种：

- 来自APP产品所依赖的后端服务的问题

- 来自APP产品自身的问题，包括稳定性问题，表现为： 应用crash（崩溃）、ANR（APPlication Not Responding）、网络错误、请求响应时间长、用户交互不流畅、机型、ROM适配度不够引发的兼容性问题。

- 来自APP和后端服务之间的链路问题，通 常有：网络问题形成的丢包、TCP重传等等。

对于APP质量监控，能够从三个方向去布局一套完善的监控体系：问题发现、问题定位、问题止损。

2.1 问题发现

因为APP受用户机型、手机ROM、网络环境、用户操做路径差别的影响较大，QA没法保证在测试阶段暴露全部问题，这就要求咱们创建一套线上问题发现体系，及时召回已经交付到线上的移动产品。一套完善的线上问题发现体系，一般来讲须要根据产品的核心业务，抽象出核心指标，实现指标量化；制定质量标准，提供实时监控报警。 

根据咱们的经验，APP应用的质量指标包括但不局限于：安装成功率，崩溃率，ANR比例，网络错误比例，请求响应时间等。质量指标与具体的应用功能紧密相关。理论上抽取指标后，如何量化是最关键也是最困难的一步。量化须要有效的问题信息获取途径，日志埋点是一种很是通用的方法，而另一种途径，用户反馈， 虽然经常被开发者忽略，却一样重要。 

2.1.1 用户反馈：海纳百川

一款应用想要在应用市场份额中分得一杯羹，长久地留住用户，须要依赖良好的应用功能和产品体验。用户反馈表明着市场对这款应用的满意度，可以直接反映用户的判断和诉求，也是这款应用迭代改进的第一手资料，前期咱们能够经过市场调研等方式获取反馈，可是受限于人力和时间成本，咱们很难在用户量巨大的时候复用此法，或者说市场调研始终只能采样而没法全量覆盖。 

基于上述，只有提供一个入口，让全部用户的反馈能够如江河入海，汇于一处，咱们才能获取到来自不一样地域、不一样网络、不一样机型、不一样场景下的用户反馈，进而聚类、分析、改进咱们的产品。

用户反馈的通用方法并没有太多新奇之处，市面上不少移动应用都会在应用设置页面中附上一个用户反馈的入口，如图2.1中百度云和爱奇艺视频的用户反馈界面。

 

咱们必需要明白一点，现在快节奏的生活中，用户愿意提交一个反馈，那这个问题对他/她来讲必定是一个很大的困扰，并且他/她又是一个比较忠实的用户，同时对这款应用抱有期待，但愿开发者能够改进。因此一旦这个产品开始提供更稳定或者功能更多的收费服务来尝试变现，那么这部分用户会是最大的潜在群体。

 

一个普通的用户反馈页，倒是于细微处见真章的最好实例，这两个页面的设计告诉咱们用户反馈的重要原则：

• 反馈入口路径尽量短：上述的两个反馈入口都在应用的设备界面，进入反馈页面须要2步操做。这一复杂度刚恰好，若是一个反馈须要用户操做四、5步才能找到，那么用户的热情会被这种来自技术的傲慢消磨殆尽。

• 反馈内容的提交成本尽量低：左侧图片中爱奇艺的用户反馈，不只事先列出了用户最可能遇到的几种问题，还在页面下方给出了常见问题的FAQ。不要小看了这一细节，咱们能够经过这样的方式，在无形之中完成一次用户问题反馈+调查问卷。

• 对用户的答复应该尽量的快：若是想要给用户反馈的过程提供更实时的体验，那就要求咱们在用户反馈页面完成一个IM的功能，这对大多数处于创业阶段的开发者来讲并不现实，因此咱们建议采用集成插件的方式来达到这一目的。

 

下面推荐几款经常使用的用户反馈平台：

1)    美洽，基于HTML5开发，只需在IOS/Android支持H5的浏览器中打开便可，无需安装任何软件程序，代码植入，一步到位，简化沟通流程。

2)    Udesk：支持Android、IOS以及APIcloud三大平台，能够对用户反馈的数据作统计分析，并展现结果。

3)    Freshdesk，致力于中小企业网站在线客服技术支持的网站，提供中小企业网站的在线服务质量和用户体验度。

 

除了在应用中直接反馈，也能够建立用户群（QQ，微信或其余企业级IM），针对严重问题能够第一时间发现，直接与用户沟通，辅助复现、抓取问题现场信息等，这些对问题的定位和解决是相当重要的。

 

2.1.2 日志埋点：秣马厉兵

 

在一个移动应用设计之初，开发者一般考虑的是功能、架构、开发周期等问题，这一类问题一般直接影响应用的发布周期，可是你们每每会忽略一个重要的过程，那就是日志埋点。

为什么要埋点

经过用户反馈发现问题毕竟有必定的延时，甚至有一些线上问题会阻塞用户反馈，例如：连续频繁的崩溃，用户反馈模块自身的Bug等。要想更迅速及时的暴露问题，须要咱们主动出击，获取用户操做的关键信息。

埋点于何处

日志埋点的原则：好的埋点能够达到一夫当关万夫莫开的效果，将全部咱们须要的信息经过日志的形式打印出来，选择性或者全量的上传给应用的后端服务，用于支持问题发现或服务改进。

受限于APP应用的运行环境，咱们不可能在全部的地方进行埋点，笔者在多年的软件开发维护过程当中，也见过因为日志添加不当引发程序崩溃问题。

 

根据自身经验，咱们总结出下列日志埋点的建议：

1）   由目标驱动埋点：一个移动应用，开发者或者用户但愿了解的服务指标，必须由日志埋点解决；

2）   日志框架通用：应用的第一个版本在日志框架上面花的时间，直接影响后续版本的开发效率。通用和稳定是这个框架必需要考虑的问题。

3）  日志上传：对于已经获取的埋点日志，咱们必须考虑它对用户流量及交互流畅度方面的影响——毕竟它的上传使用的是用户网络，尤为是在收费的移动网络下更要慎重。有以下手段可参考：日志压缩和私有协议、用抽样上传代替全量监控；若是日志对时效性的要求不高，能够考虑采用打包总体上传代替实时上传的方式，甚至能够天天上传一次。这些都须要在框架中提早作好部署工做。

4）    日志安全：用户日志中可能包含用户我的信息、用户行为及隐私，一旦信息泄露，可能给用户形成经济、安全等方面的损失，严重影响用户对应用的信任。故日志安全是重中之重，目前行之有效的方法主要有加密和使用安全协议。相对于加密算法较容易被破解的风险，安全协议提供了更严密的保护。目前应用比较普遍的安全协议主要有https，spdy等。

2.问题定位

线上问题的快速定位和解决能够直接缩短用户体验受损的时间，一般有如下几种定位思路：

1）日志分析法

当遇到一个问题时，咱们最早想到的可能就是查看日志，用户日志是定位问题的最直接的信息来源和方法。日志分析又能够分为两种手段：一是从统计学的角度分析大 量的问题日志，总结聚类，经过其中共性的特征，发现潜在的问题；另外一种是针对某个有明确问题反馈的用户，查询其一段时间内的全部操做流程及结果，经过上下 文推测问题缘由，也能够辅助线下复现。

固然并非全部的问题均可以经过用户日志定位，好比日志不全或日志提供的信息并不足以精肯定位问题，怎么办呢？那就要求咱们可以复现这一问题。

2）问题复现法

经过用户对问题的现象描述，以及已有的用户日志，尝试线下复现。复现时须要关注用户的机型，平台，网络类型，是否设置了代理，甚至是用户所处的地理位置（不 同地域的运营商网络可能有较大差别）等，结合应用所提供服务的逻辑，推测可能出现该问题的缘由，尽可能增长复现的可能性。

3）推测验证法

固然，APP的问题很大程度上依赖于当时的问题环境，包括机型，平台，网络状况，手机安装的应用等，都给线下复现带来了巨大的困难。而现有的问题日志又不足 以精准定位。在这种状况下，能够经过问题的现象描述和以有的日志，推测可能的问题缘由，埋点监控，经过分级发布的模式，当问题再次发生时，验证哪一个推测是 root cause。

4）上下游合做分析

有些功能须要多方合做实现，当这些模块出现问题时，你们通力合做，可能就会离问题的解决更近一步。

3.问题止损

线上问题时时刻刻影响着用户体验，及时止损颇有必要。问题止损不只仅是指定位到了问题的root cause从而实现完全解决，也包括在问题完全解决以前，如何将对用户的不良影响降到最低。

 

对于APP产品，不能像后端服务那样经过紧急下线/上线补丁解决问题，只能依赖于应用发版，而用户的升级转化也是一个比较漫长的过程。在这种困境中，云端控制和热修复为咱们带来了曙光。下面主要阐述云端开关控制的思路。

 

针对APP上影响/风险比较大的功能模块，预先设置好开关，发生问题时，能够经过云端下发关闭指令，及时止损。云端控制是一个概念，实现方式因业务和功能而 异。受限于自身经验，咱们没法提供通用的多平台解决方案，可是大道至简，咱们但愿提醒开发者的是：从代码设计开始，考虑应用、系统、服务三个维度的容灾 性。

 

一个简单的例子：咱们能够把功能开关置于一个独立的Web Server中，APP采用轮询或者更加精准的动态策略去访问这个静态文件，当服务某个环节出现问题时，只须要修改WebServer中的开关文件，关闭相关功能或者将相应的服务导向备用地址，便可快速的止损。

另一种方式和上述方案相似，只不过实现的时候不使用访问云端文件，而是由服务端直接向全部APP应用下发指令，用于启停某些功能甚至调整某些内部模块的逻辑。这种方式更直接，可是对APP的代码的开发提出了至关高的要求：

1）  模块间代码耦合度要极低，从而可以作到动态调整逻辑；

2）  若是云端控制只用于事故止损，那么就要求全部受影响的应用必须保持后台在线或者前台运行的状态。不过具体到当前市场份额最大的几个手机/移动操做系统，咱们能够经过推送通知的方式的，尽量由用户主动唤起应用，借此来得到下发云端命令的机会；

 

咱们建议开发者能够综合考虑应用的代码风格、业务类型、风险类型，来选择某一止损的方案。上述两种方案并不是最优解，实际的开发过程当中可能须要综合多种方案来达到高可用服务的标准。

 

同时，目前业界也涌现出一些成熟的解决方案，如iOS平台的APP动态更新服务JSPatch(http://jspatch.com)就是一个专一于此领域的平台，开发者能够试用、借鉴。

 

3监控体系建设

3.1质量标准

1.什么是质量标准：

质量标准是产品生产、检验和评定质量的技术依据。产品质量特性通常以定量表示，例如强度、硬度、化学成分等；所谓标准，指的是衡量某一事物或某项工做应该达到的水平、尺度和必须遵照的规定。而规定产品质量特性应达到的技术要求，称为“产品质量标准”。--（百度百科）

客户端做为与用户直接与用户打交道的产品，其用户体验是衡量一个客户端的重要部分。用户体验包含了视觉、友好性、易用性等等方面。可是其视觉等方面很难经过量化的方式进行度量。可是产品的核心功能等倒是经过一些数据的度量来衡量产品的易用性等。所以，产品的质量标准就应运而生。

在服务类产品中，经常使用SLA（Service-Level Agreement）做为衡量产品服务等级的量化指标。按照业务的需求对业务的，对业务的服务指标制定量化的标准，经过量化的标准来衡量和驱动产品的服务愈来愈好。例如做为APP产品中的crash率，是衡量一个APP稳定性的数据指标，经过对crash率的统计数据衡量分析，来保证每一个发版的APP健壮性获得保障。

2. 质量标准应如何制定：

质量标准的目的是经过对业务数据的量化与衡量来保证服务的质量，经过质量标准的衡量来推进业务质量变得愈来愈好。那么应该如何来制定质量标准呢？

根据百度云的经验，质量标准的创建大体总结为：一个核心、三个阶段：

一个核心：时刻以产品线的业务发展为核心

三个阶段：初期阶段、中期阶段和进阶阶段

为何质量标准的创建要围绕发展来制定。举个例子，好比百度钱包，钱包在初始阶段，其核心的业务指标为发展用户，那么用户的登陆，日活等指标为钱包的最核心的指标，当时钱包尚未APP端，显然，更不会有Crash率等方面的标准。在钱包发展到必定阶段，绑卡用户变成了钱包的另外一个核心指标。那么帮卡率变成了业务的核心发展指标。相应的核心质量标准也应该变为绑卡成功率。所以，质量标准的制定必定要围绕业务发展为核心。

在业务发展的不一样阶段所设定和采纳的质量标准也是不尽相同的，按照标准由粗到细，量化难度由易到难的阶段一步一步发展而来的。

初期阶段：业务发展的初期或者业务发展到必定的阶段，经过需求或者用户反馈来收集到产品线在发展过程当中须要核心保证的top功能，这个核心的功能是一个产品生存的支柱，也就是咱们须要经过质量标准来衡量咱们核心业务提供的服务好坏程度。举个例子，客户端的崩溃状况，是每一个产品线所要保证的最基本的质量防线，崩溃率的高低，决定了用户的留存状况，所以，全部产品线都应将崩溃率做为最基本质量标准。而对于不一样的产品线，则有各自自身的核心业务指标，好比手百，死链的状况则是关系到用户体验的最核心指标；下载的成功率是百度云用户体验的最核心指标；定位和路线的准确性是地图最核心的用户体验指标。这些也就是各个产品在最初创建质量标准时最关系的方向。

中期阶段：中期阶段，是在初期阶段的质量指标创建完以后，而且在指标的数据获取，指标的计算公式都获得检验以后（尤为是获得peer角色的承认），进入到成熟阶段。中期阶段的目标是创建多个完整的子业务质量闭环。客户端的呈如今用户面前的服务能力和用户体验，是每一个业务的综合能力体验，对于客户端自身的业务、服务端的服务能力、中间网络抖动状况都密不可分。所以，想要达到一个服务单元的完整质量闭环，必须能cover到整个业务链条中的每一个质量节点。好比百度云的下载业务，一个完整的下载，从层级上面看，大体分为三个层级：1.APP自身下载逻辑，主要涉及到下载的重试、并发、容错等 2. 中间业务层， 主要是在下载过程当中的下载分发、防盗链、PASS校验、CDN回源等等。3. 底层数据拉取，主要是分片数据的重组文件、跨机房的文件拉取等等。因此要完成一个整个下载的质量闭环，必须cover整个质量闭环的关键节点， 每一个关键节点都会指定相应节点的标准，每一个节点的质量好坏的变化，都会在端的质量数据中有所体现。 

进阶阶段：进阶阶段是在中期阶段相对成熟以后，针对于业务复杂的每一个子业务都能经过服务单元中的核心节点数据来对质量作出评价。进阶阶段，对于每一个细节的标准都很全面。任何影响到产品体验，和客户端的运行质量的，都能经过数据分析获得。在中期阶段，有了各个垂类业务的数据，以及在垂类的链条上面的关键节点的数据，可以清晰的知道垂类业务的质量。对于比较复杂的业务，其每一个质量节点影响的不仅仅是一个垂类的业务。在进阶阶段，经过对详细子业务以及子业务之间的关系进行联系与刻画，造成了一张联动的质联网。

3.质量标准的用处：

质量标准的设定主要的目的是经过质量标准的驱动来驱使业务质量变好。质量标准按照覆盖范围来分主要分为两大类：一是通用型，好比 crash率；二是与自身业务紧密相关的。

 

1)    质量标准最初级的用处：衡量业务的好与坏。经过量化的手段，对于业务的服务，APP的运营质量，进行度量。

2)    发现业务中的缺陷：经过对服务单元中的质量数据度量，发现业务质量中的薄弱环节，对于问题的发现和业务的优化提供数据支撑。

3)    业务贡献：经过对质量数据的分析与整合，对于产品策略提供数据支撑和评判。

 

3.2能力指标

1. 数据获取的能力：

基础数据是质量标准创建的基石，数据获取是一个产品线成熟度的一个标识。通常APP的数据获取途径主要有两大类：1. 通用第三方统计平台：例如mtj以及一些第三方的数据统计平台，经过提供SDK的方式，对APP的运行状态等指标进行统计上报，并给出图形化的分析报告。2. 自身业务的数据上报：经过业务埋点或者本身编写的SDK捕捉上报。针对自身埋点或者本身编写SDK的方式，更加灵活。可是须要投入相应的人力和机器资源。

2. 数据分析的能力：

在数据获取的基础之上，数据分析是数据转化成质量数据、质量标准的必经之路。数据分析的过程，是离散的业务数据，经过按照对业务梳理的方面进行划分、统计聚合，变为对业务有用的数据。业务数据的分析的能力集中体如今两个方面：1. 数据计算能力，对于离散数据的计算，须要大量的数据计算才能完成，一套高效、运行流畅的计算框架是对于大数据计算的前提。2. 业务梳理能力，须要对业务的理解和上下游串联有比较细粒度的认识。3. 业务数据分析的能力，对于统计后的数据，可以对应到业务的表现，并能经过数据的变化来预测或者对于平台业务的好坏。

3. 质量数据的闭环：

质量数据的闭环是一个比较长期的过程，经过对数据的获取、数据的分析后，得出业务中不合理或者比较薄弱的地方，经过制定合理的优化方案，对业务进行调整优化。而后循环往复来达到质量数据的闭环。

3.3数据利用

数据分析，是整个监控的最核心，也是难度最大的工做。数据分析，是结合业务的逻辑，经过基础数据进行计算统计后，分析对应到业务逻辑。经过数据的变化，来解释业务的变化与好坏程度。

数据可视化，是数据监控的一个效果展现。好数据展现，能保证用户更好的分析数据的变化与数据直接的内在联系。数据的可视化的重要程度也是不言而喻，其像发动机的润滑油，可以让整个监控体系，更高效，更加顺畅的运转起来。