Dd887610533107c426bddac9c431ce13
不可忽视的前端监控

背景

前端监控是相对于后端监控提出的,是指从用户端的角度来检测系统的可用性。前端监控一般分为两类,一类是事件监控,另一类是错误监控。由于用户端复杂度的上升和精细化运营的需要,前端监控的重要性在不断提高。本文中的前端也泛指所有用户端。

用户端复杂度上升

随着移动互联网的快速发展,互联网产品获取流量的渠道越来越多样化。从早期的搜索引擎,到后来的应用市场,再到O2O领域的线下流量,还有寡头应用的流量二次分发,流量来源在哪里,产品的用户端就要做到哪里,这样导致用户端随着流量来源的多样化而越来越复杂。

通常是一个后端对接iOS、Android、公众号、移动Web甚至小程序等多个用户端,每个用户端的功能可能大部分是相似的,但是各有侧重。这种情况下只做后端监控是远远不够的。

精细化运营需要

随着移动互联网人口红利期的结束,行业进入需要精耕细作的下半场。各公司逐渐告别之前粗放式的发展状态,从每个环节挖掘增长点和利润空间。这就需要我们在技术方面加强周边保障系统的建设,提升全流程业务运行的效率与稳定性。

四种质量保障方式

功能测试的局限性

对于传统的开发流程,保障产品质量的手段是上线之前的功能测试和上线之后的缺陷反馈。

对于前端而言,很多问题只在特定的使用条件下出现,而随着用户端复杂度的上升,条件组合会越来越多,使用测试用例覆盖所有情况成为不可能完成的任务。

拿用户当测试

由于功能测试只能覆盖少部分用例,很多产品缺陷是在上线之后根据用户反馈来修复的。所谓“拿用户当测试”并不是开玩笑,而是在功能测试的局限性背景下的一种现实做法。但是真正找到开发者反馈问题的用户比例是极低的,我们除了被动地等待反馈问题之外,还要主动地发现问题,这也就是我们做监控的意义所在。

幸存者偏误

一般情况下我们都会对后台的关键指标做监控,监控的对象通常是访问量、订单量等业务指标,或者后台机器的内存、响应速度、错误日志等运维信息。

只在后端做监控会导致对于系统可用性的判断存在严重的幸存者偏误。很多错误产生的环节是在用户发出请求到后台之前,这类错误显然不能通过后台监控发现。还有一种情况是,如果用户端有兼容性问题,那么就会发现来自某个渠道的订单量少,但是无法确定是这个渠道本身的用户量少,还是这个渠道的用户因为缺陷而流失了。

功能测试只能覆盖小部分用例,用户反馈出来的缺陷也只是有限的个例,只有前端和后端监控并重,我们才能全面地保障线上产品的可用性。

从用户端的角度看可用性

从用户端的角度来看,一个应用的信息流动过程大致如下:


这其中的每一个环节都可能产生缺陷:

  • 到达环节
    • CDN资源加载错误
    • 资源响应超时导致用户跳出
  • 渲染环节
    • 排版错乱
top Created with Sketch.