超实用案例：美团终端主动监控平台的建设

摘要

本次演讲主要分享美团的终端主动监控平台建设过程，分别介绍了目前的被动监控的局限性，以及主动监控的实现难点。

很多公司都会有监控系统，包括前端的性能监控，业务数据监控，后端API服务质量监控等，从运维层面来看这些都非常重要。

一般来说监控在服务端应用的会比较多一些，那么为什么我们终端也要做主动监控呢？在讨论这个问题之前，我们先来看下上图展示的两个场景。一个在退票环节中遇到白屏，另一个是应用loading时间过长。

对于前端来说出现白屏的原因有多种，有可能是Webview初始化的时候出现问题。目前在使用了React 、Vue等框架之后，页面已经成为了一个大的模块，其他模块都是由这个入口进入，已经没有了静态的内容，因此无从判断具体问题的出处。这种情况其实在测试阶段很难被发现，因为它并不是普遍现象。

最后我们对这两种情况经过排查发现，白屏问题是由运营商劫持造成的。第二种问题是由于在美团应用中用户选择的城市和定位城市不一致，导致数据接口返回数据出现问题。

目前业界的监控系统基本上分为3类。一类是业务监控，这应该是每个公司都必备的，比如订单和GMV的监控。第二类是客服，是否存在客服主要由公司的性质决定。第三类是用户反馈，最直接的方式就是App Store的用户评价。以上这三类监控方式其实都是被动式的。

被动监控主要面临的问题有三个。一是滞后，只有在问题发生且已经造成损失之后才能去着手解决。二是发现难，因为在上线之前已经通过测试解决了普遍性的问题，等到上线之后所出现的问题其实都不具备普遍性。三是复现难，综合考量用户基数、设备、网络环境等各方面的情况就会发现问题的出现有着很多可能，即使用户给予了反馈也很难再现问题发生时的环境。

既然被动监控存在各种问题，那么就要开始做主动监控，其目的是为了先于用户之前发现问题。初期我们的目标是能够监控白屏、运营商劫持、客户端接口错误等问题。

主动监控的实现需要达到几个目标。第一个是覆盖尽可能多的样本率。第二个是要有时效性，虽然从被动监控的业务数据波动中也能发现问题，但是不同情况下灵敏度会出现差异。第三个是覆盖，这里主要指的是覆盖业务的整个流程，以及各种平台。最后是自动化，尽可能的减少人工干预的时间。

接下来我们来看下这四个目标所涉及的具体问题。首先是样本率，主要涵盖台、设备、网络和操作方式四个方面，就以平台来说移动端的优先级要高于PC端，另外网络环境不能仅限于WiFi下。其次是时效性，一方面要保证实时性，另一边要配备相应的报警系统，最后还是要有人值班。到了自动化阶段，稳定性是优先要求，其次要有日志存储的功能，因为有些问题并不能轻易的复现，另外还要选择合适的测试框架。最后是覆盖，我们希望覆盖的范围足够的广，包括搜索、支付、退票、验证码等。

可以发现这里面所涉及的问题还是比较多的，也存在不少难点，所以我们一期做的还是比较简单。首先是样本率方面，虽然我们的安卓用户较多，但同时碎片化也非常严重，因此初期只选择了PC和iOS这两个平台。设备上则使用ipad和MacBook Pro跑自动化流程。自动化方面，iOS上采用的是Appium加WDA的方案，PC端采用的是Google的Headless Chrome（puppeteer）。

我们先看下PC的初期方案。这里首先会有一些业务的case，用来保证整个流程的顺利执行，有点类似于自动化的case。图中左半部分运行在node上，通过Headless Chrome来承载抓包、打码、diff这几个功能。

抓包的主要作用是抓取每个请求的包，然后转化成HLR的包，最后存储起来方便后续分析问题。

打码针对的是内部验证码，主要是为了满足自动化的需求。

Diff是为了应付运营商的劫持，我们首先会跑一遍整个业务的流程，然后抓取到所有的js和css，最后将它们与git仓库中最新的业务代码做diff。如果发现有代码被篡改就实时发出警报。这套系统之上还有一个消息系统，用来通知每个负责的人，以及负责收集消息，它还会连接到报警系统，由报警系统通过短信或邮件的方式向内部报警。这里还需要有日志系统，一方面记录业务流程的进展，另一方面记录每一步请求所抓的包。

最后是值班系统，我们这边是每周固定一个人值守，值班系统每天会按级别分拣出报警。

我们将一期的方案整个跑下来之后，发现只能算是勉强可用，还是存在各种问题。首先样本还是太少了，毕竟只有ipad和MacBook Pro，发现问题的几率太小。其次是流程经常中断，比如支付环节中输入验证码就无法做到自动化。第三在ipad上运行的时候app会有crash，这自然就会中断流程。第四是case变动频繁，一旦业务功能发生改变case就要随之改变。第五是上线的js会压缩混淆，这样diff的时候每次都会不一样，并没有什么意义。最后是存在大量报警，其中有效的并不多，需要依靠人工筛选。

为了解决面临的样例过少的问题，我们接入了内部的美团点评云测。它是一个自动化测试系统，包含一个Jenkins和多个server，有着各种测试设备以及一个存储系统，可以自动或人工的提交自动化测试任务。

上图是二期接入美团点评云测后iOS的解决方案。首先Jenkins会自动的跑任务，之后还是一堆的测试case，再通过Applum加WDS实现流程自动化，测试设备iPad使用Usb hub连接起来。其他的消息系统、报警系统和值班系统还是没有变化，不过这里多出来了proxy和server。Proxy是为了app中的抓包，抓取的是与服务端的一些请求，包括js、css以及图片。

对于支付的自动化问题，其实只要开通支付宝白名单就可以免验证码，Js的diff改为基于AST之后也能够正确的验证。

我们针对Case变动频繁的解决方案可能会比较激进。就是iOS、Android、H5只做展现，单独有一层完全使用js写的业务逻辑，这同时也解决了客户端的动态化问题。但该方案也存在缺陷，即Android的webview只支持ES5。

大量报警的问题主要是通过人工标记配合决策树来解决。先通过人工审查标记报警，然后由决策树对它们进行分类，标记有效报警和无效报警，在积累到一定量之后决策树就会将某一类的错误全部归类为无效。

经过两期的实践，iOS和PC上已经可以自动化，流程覆盖率达到了95%，报警的时效性基本上在5分钟以内，上线一个月后发现了4次问题，其中一次较为严重。最终我们的可监控范围包括白屏、页面性能、资源加载、业务接口、js报错。

虽然已经做了两期主动测试，但还是有一些遗留问题。一是对比海量的用户之后样本率还是不足。二是地域问题，PC上还可以通过代理模拟地域，但是iOS上暂时不好解决。三是业务的强耦合，针对每个业务都要再去做一套主动测试。

未来我们还准备接入android平台，解决地域问题，以及其他业务的自动接入。

整个过程总结起来主要有两点。一是主动与被动相结合，其实大业务量的情况下其实被动监控会更灵敏，所以要发挥他们各自的优势。二是与自动化测试相结合。

这张图是我们总结的选型方案，分为普遍性问题和业务量大两个方向。普遍性问题可以直接通过自动化和人工测试解决。业务量大且又是普遍性问题的情况下被动测试会更灵敏。