09777777
09777777
4月前 · 19 人阅读



内容来源:2018 年 01 月 05 日,美团高级技术专家李燕青在“2018 移动技术创新大会”进行《终端主动监控平台的建设》演讲分享。IT 大咖说(微信id:itdakashuo)作为独家视频合作方,经主办方和讲者审阅授权发布。

阅读字数:3430 | 9分钟阅读

嘉宾演讲视频PPTt.cn/RdtLzmF

摘要

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

为什么要做主动监控?

很多公司都会有监控系统,包括前端的性能监控,业务数据监控,后端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流程图

我们先看下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流程图

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

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

Case变动频繁

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

大量报警

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

实践与效果

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

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

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

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

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


收藏 0
运维 android ios javascript
评论 ( 0 )