从零开始搭建前端监控(第五讲)
第2章 我们就是产品经理
把从各个研发那里收集来的信息转换成需求、形成文档也是一项非常有挑战性的工作。我们首先要定位产品用户(这里用户指的是使用前端监控平台的研发、测试人员,而非第一章中提到的站点的普通使用者),然后再确定需求来满足用户。这些工作往往由我们自己完成,因此我们自己就是产品经理。
2.1 定义平台边界
在8年的开发生涯里(大多数业务需求都是跟产品经理打交道),我从来没有感觉产品经理什么都不会。尤其这次在我梳理这个监控项目需求,以及对接各个方向业务方所提出的需求时,我感觉产品经理尤其重要。
回到前面已经说过的,开发这个项目的目的是打造一个能监控线上前端错误、可支持私有化部署的平台,那么这些就是我们的需求。除此之外,周围总是或多或少有其他的声音,比如,我们能支撑首屏展示模块的个数以及展示的频率吗?我们能提供页面的产品漏斗吗?这种声音来自各个方向,有的来自兄弟部门的技术负责人,有的来自产品经理,也有的来自老板。
那么我们做事情的边界在哪里呢?我在公司见过有人想做大而全的项目,最后什么都做不成,因为包袱太重,致使项目下马。在做前端监控平台的时候,我突然想到了一个词——使命。了解我们做前端监控平台的使命是什么,与这个使命无关的事儿都要剔除,因为那不是我们想要的产品。
在第1章中,前端监控平台的使命已经明确,接下来就是确定要做的具体的工作。“让我们能够比用户更早发现问题”,意味着我们要做的平台是一个报警平台;“并且能在用户发现问题之前解决问题”,意味着我们需要在不打扰用户的前提下(不做电话回访)通过已知的平台数据来解决用户问题;“通过产品或者业务数据体现前端工程师的价值”需要前端监控平台有观察业务模块使用情况的功能,以及用户在某个页面的在线时长等功能,并且强调做所有的事情都需要边界。
2.2 把需求翻译成研发文档
前端监控平台为了完成“让我们能够比用户更早发现问题”这个使命,我们需要一些指标,一些让用户感觉系统无法使用或者明显操作不畅的指标,而且这些指标技术人员要能看懂具体含义,并且能够通过这些指标发现用户使用的系统真的出现问题了。在开发前端监控平台项目第一期的时候,我们列出了几个一定会影响到用户操作的指标。
2.2.1 用户登录失败
涉及登录的问题都是严重的问题,因为如果登录不了,用户就没有办法进行后续操作,对于用户的导向、广告投放以及对于用户行为的分析、产品后续决策也都无从谈起。也就是说,如果用户没有登录,关于用户的一切我们都无法知道。因此,我们的数据中有了要监控的项,就是用户登录失败的情况,suo所以需要一种提供启动能力监控的项,比如一个登录页面在加载或者初始化的过程中失败,致使登录失败,这类登录错误是在我们开发过程中最常出现,如图2-1所示。

2.2.2 服务器页面加载失败
一般情况下,错误会出现在数据交互的过程中,所以我们把错误拆分一下,一种是交互过程中,服务器本身出现错误,这类错误可能导致服务访问的过程中出现404、500、503,我只拿出一个404样例观察一下,如图2-2所示。

2.2.3 混合APP内部报错
还有一种情况与上面的情况类似,但是属于套壳(就是HTML5页面嵌入在客户端的WebView中,或者嵌入在使用NW.js、Electron开发的客户端中),这种情况难免会出现正常访问没有问题,但是在套壳程序中访问不到的情况。WebView内核版本问题或者套壳程序中出现代理错误这类问题往往更不容易排查。如图2-3所示,这是我做过的一款Android应用程序中的WebView地图界面,这款Android应用程序刚上线的时候是没有任何问题的,但是突然有一天WebView中加载的地图URL更新了,有人告诉我地图功能失灵了,但没有人知道从什么时候变成这样的。我直接访问WebView地图加载的URL,发现返回的界面如图2-4所示,服务页面已经访问不到了。这类问题就是混合APP内部报错的具体场景。
提示
Webview含义:WebView也就是我们熟悉的“网络视图”,能加载并显示网页,可以将其视为一个浏览器,主要用于展示网络请求后的内容,就是将网络地址请求的内容展示在里面。通常情况下Webview是HTML5页面嵌入Android、IOS手机应用中所需要的外部容器,目前市面上大多数混合开发的移动端应用都是使用这种方式。


2.2.4 服务器接口返回错误数据
最后,就是我们提交的数据本身被服务器端接收到了,也把数据返回给我们了,但是数据结构本身出现了问题,在这种情况下,服务器端监控平台是比较难监控到这类问题的,因为这类问题太趋近于业务了。然而这类问题对用户来说是毁灭性的,因为如果服务器返回的数据中某个字段是空的,那么用户看到的界面就存在部分空白的情况,还可能有更糟糕的情况出现,例如,被解析字段不存在,所以页面报错(相信不会每一个前端工程师在使用一个属性之前,都会判断该属性是否挂载在目标对象上)致使整个页面白屏。
因此,截至目前,我们确定的监控指标包括登录异常、启动过程异常、服务器错误、加载页面失败、接口结构错误等。
另外,我们还需要一些支撑我们做决策的数据,如操作系统类别、版本号、浏览器类型等,以便我们在解决问题时了解用户的运行环境,这就出现了一个新指标——设备信息。
最后总结一下前端监控平台的主要功能:
● 提供饼状系统分布图功能、饼状设备分布图功能(展示为形式饼状图);
● 提供系统内部菜单点击量详细点击量展示功能(展示形式为柱状图);
● 提供统计用户平均用户在线时长的功能(展示形式为折线图);
● 提供用户登录失败检测、服务器页面加载失败检测、混合APP内部报错检测、服务器接口返回错误数据检测功能;
● 提供报警功能(可能是微信报警、邮件报警、短信报警等)。
2.3 小结
本章提出了前端监控平台使命的概念,进而衍生出平台的功能边界,并强调了监控平台的核心需求都是以此为中心,既不能改变边界,也不能逾越边界。并且,本章通过收集具体的问题场景,分析问题出现的详细原因,逐步产生平台的功能性需求。其次,通过站在用户的角度观察问题,总结出用户最想拥有的需求。以上两者相结合就是前端监控平台最急迫要做的事。
陈辰(CC老师)978563552@qq.com