大数据开发工程师网易云微专业-与君歌一曲，请君为我倾耳听

前端监控稳定性数据剖析理论

大数据开发工程师网易云微专业

download：https://www.51xuebc.com/thread-536-1-1.html

1 背景客服一站式工作台集成了在线、热线和工单三个中心应用，支撑着自营客服和 BPO 客服每天处置大量的会话信息，工作台的稳定性就显得十分重要。接入前端监控以来，我们坚持每双周跟进工作台以及客服几个中心应用的线上稳定性状况，盘绕页面的访问状况、JS 错误率、资源加载异常状况、API 接口胜利率、自定义业务模块指标 这五大监控模块，做了细致的数据剖析，从中发现了很多问题并且经过实时告警处理了潜在的问题，也经过数据剖析推进了客服职场完善工作台的运转环境。本文主要论述我们是如何经过监控稳定性数据剖析来提升应用系统的稳定性。2 监控的原理客服一站式工作台接入监控时经过多方调研最终采用了 Arms 的监控计划，并基于 Arms 的监控计划，做了二次开发，整体的监控完成

Arms 提供的 SDK 功用比拟齐全，为满足一些定制化的数据上报诉求、应用数据权限管控以及控制上报本钱，客服域接入时基于 alife-logger 停止了二次封装，对功用愈加的可控， 同时定期从阿里云平台停止数据初始化和生成定制化报表。3 监控的理论3.1 页面 PV&UV 监控场景PV 即页面阅读量，通常是权衡一个网站以至一个模块运用状况的主要指标。UV 即独立访客数，是指某站点被几用户访问过，以用户登录态作为统计根据。页面的 PV 和 UV 很大水平上反应了应用各页面功用的运用状况，能为产品功用优化以及相关业务决策提供很好的数据支持 。我们针对客服域已接入监控的应用连续几个迭代的 PV、UV 数据剖析，主要在如下事项起到了很好的推进和决策作用：新功用上线效果剖析：经过剖析页面业务功用模块 PV 相关数据，能够剖析对应上新功用的运用状况。若发现局部功用客户触达率较低，就能够与业务沟通确认是功用设计问题还是上线功用布达问题，快速做出运营战略调整；下线无用模块：经过页面运用状况剖析，对系统中访问量比拟少的页面做了汇总剖析，同产品运营肯定之后，对在线客服管理系统和工单管理系统中的 9 个页面做了下线处置，减少了页面的维护本钱；支撑技术改造优先级战略：在技术栈迁移的过程中，能够优先对访问量比拟高的页面停止迁移，普通页面访问量高的对应的需求迭代也比拟频繁，经过页面访问排序，按优先级去做迁移能够提升整体投入的 ROI；助力系统体验优化：经过剖析较高 PV 页面用户访问链路，将取消订单、创立赔付单等需求高频但需求翻开其他页面操作的功用集成到客服聊天页座席助手模块，提升客服的工作效率。3.2 JS 错误率监控脚本错误主要有两类：语法错误、运转时错误。简单来说就是用户在一些特殊场景下阅读器上报 JS 的异常，以至会形成系统卡顿、页面不可用等极端状况，这会极大地降低用户体验。因而我们经过监控系统对中心系统关键链路、关键指标做好异常数据剖析设置监控预警 ，到达设定的阈值则发送飞书或短信告警，值班同窗关注告警信息可以及时做出响应，同时针对告警错误内容停止专项管理，到达效果如下：提升系统稳定性: 合计处置 41 个 JS 脚本异常管理，过程中发现异常业务场景并停止专项管理，很大水平上提升系统的稳定性。发现躲藏问题： 经过监控发现 JS 错误数增加，排查发现数量正在上升，实时联络一个正在触发报错的客服远程，发现是接入的三方 SDK 发布新版版本，在特殊状况会呈现报错，及时同步对应的三方同窗停止矫正，有效防止因外部依赖发布带来的躲藏问题。3.3 API 恳求优化监控提供给用中每个 API 的调用状况，包括调用次数、调用胜利率、返回信息、调用胜利或失败的均匀耗时 等数据。经过剖析指定时间段内应用中一切 API 恳求数据，能够深度发掘以下业务代码完成和接口稳定性一些相关的问题：下线不用要调用： 排查过程中发现局部埋点调用频次很高，但是实践报表数据并未运用起来，与业务沟通后发现为历史遗留逻辑，目前已无用，所以停止下架。减少不用要的接口调用，释放更多的阅读器恳求资源。减少冗余调用： 共管理接口高频调用管理调用 5 个，经过剖析发现局部非中心功用的接口调用量较大，代码走读发现此局部接口为实时性请求不高枚举列表的接口，能够经过前端缓存的方式减少接口调用次数，从而进步用户切换会话效率和减少效劳器的调用压力。优化技术计划： 客服一站式工作台存在长链和短链调用分离的状况，在我们日常监控剖析中发现局部短链接口调用量大。经过代码走查和调用链路剖析发现由于业务功用需求，只需客服切换会话，就会拉取当前会话最近五条音讯发起短链恳求，形成切换会话会有卡顿感，同时很容易呈现由于短链并发较多，频繁切换回话后会呈现串线的状况。所以与后端沟通后，将原先技术计划内的短链调用改为长链音讯推送，很大水平上减少接口调用和音讯不实时的状况，提升用户体验和系统稳定性。3.4 静态资源加载异常优化静态资源加载分为页面内的图片、CSS、JS 等 Assets 资源加载失败。目前客服 BPO 职场均有平安管控，所以会呈现运营或者其他应用上传的静态资源链接、图片等资源，局部 BPO 打不开的状况，经过前端监控发现以下几个问题：图片资源加载异常： 随着一站式工作台的业务拓展，陆续支持等其他租户的客户进线。业务上线后，我们经过监控发现资源错误数量呈现上涨，排查后确认由于商品图片等资源都是配置的 CDN 地址，需求 BPO 职场开通网络白名单客服才能够看到指定的图片资源。经过监控快速定位对应的职场，同步对应的职场 IT 担任人停止处置。运营配置错误地址修正： 经过监控数据剖析，发现不少报错的静态资源地址中有飞书内网地址和竹间迁移遗留资源的状况，内网地址外网是无法翻开的，会给客服带来不少搅扰。经确以为运营迁移过程中存在遗漏形成，联络对应的运营同窗停止专项管理，及时减少问题影响面。3.5 页面加载性能优化页面性能对用户体验而言非常关键。每次重构对页面性能的提升，仅靠工程师开发设备的测试数据是没有压服力的，需求有大量的真实数据用于考证；比方客服职场普遍反应商品详情页面翻开慢，影响到了客服的工作效率，体验很不好。为了明白详细加载慢的点，我们针对页面加载到页面可用这个过程中以下几个时间节点停止埋点：e_product_finish【总耗时 ms】: 商品详情页面翻开到一切资源均加载完成(包含图片与恳求)耗时e_product_loadImg【加载图片耗时 ms】： 接口恳求回来到一切图片加载完成耗时e_product_loadAndfetch【恳求耗时 ms】： 商品详情页面加载静态资源 &&发起恳求耗时经过三天的线上数据剖析发现，大局部耗时在加载图片耗时上。剖析耗时较长的商品详情上下链路，发现此类商品的图片大多为 500kb+以至 1MB 左右的图片 ，单个商品最多的状况下商品轮播图近 52 张图，加上商品细节图、商品穿搭效果图等，单个商品详情页面初次翻开居然需求加载 80+张图片，关于阅读器而言是灾难性的

所以经过和产品磋商，我们针对商品详情页面停止了加载略缩图交换高清大图，同时减少初次加载图片个数(初次只加载 5 张图，点击查看更多后才加载剩余局部图片资源)等一系列的优化战略，很大水平上提升了商品详情页面的页面体验。如图下图，为 12 月 19 日我们优化上线后，图片资源加载耗时均值趋向图，有了很明显的降落趋向。

4 监控的效果接入监控至今半年多的时间里，章鱼一站式工作台的稳定性有了十分大的提升，经过管理和告警以及推进各职场运转环境的完善，大大减少了线上 TS 问题的反应以及防止了线上潜在问题的发作。4.1 线上 TS 问题的减少

接入监控以来，经过双周稳定性周会的管理，归因于前端的 TS 问题数量不时的减少，在双十一和双十二大促期间，也持续的稳定在 5 个以下 。## 4.2 潜在问题的发现经过监控诉警至少发现潜在的问题不少于 5 处 ，经过告警信息及时处理了潜在问题的风险，防止了线上问题的发作。这里举一个十分典型的接口超时告警的例子：获取用户标签信息接口超时告警

经过监控诉警发现，查询用户标签信息接口 1 分钟内 1 个用户屡次调用失败 ，这个明显是有问题的。在跟网关和后端对接之后，发现主要的缘由是：一站式工作台里面的在线和离线进线的会话列表有用户标签的显现，当用户重新刷新阅读器的时分，会同时调用在线和离线的用户信息，离线用户未及时关闭的话，会招致较多的超时短链恳求。固然该接口为非中心链路接口，但大量的短链调用是一个潜在的风险，后面跟产品磋商之后，将进线列表的用户标签删除，取消接口恳求。4.3 推进客服职场工作台运转环境的稳定客服职场的环境是十分复杂的，阅读器运用的多样性以及不一样的版本都会带来不可预知的问题，招致前期很多的客服反应，研发同窗投入了大量的时间去做问题定位，最终发现是阅读器版本过低招致。所以针对这个状况，我们定期汇总了阅读器版本的运用状况，告知给业务，让业务推进各职场阅读器版本的晋级和统一。

从监控数据来看，存在火狐阅读器、搜狗阅读器、QQ 阅读器和 android 手机阅读器 ，关于这些阅读器，根本都存在一些兼容性问题，由于一站式工作台里面的技术晋级用了较多的阅读器新特性来对业务模块做了重构，故关于非 chrome 阅读器存在兼容性问题，这也是为什么有些职场客服反应如工单详情打不开、订单详情翻开异常等问题。chrome 阅读器低版本数据汇总：

在几次推进之后，目前因阅读器版本反应的问题曾经大大减少，很大水平减少研发在阅读器版本问题排查的时间。4.4 中心性能指标的监控目前除了上面商品详情页的监控指标，我们还对工单详情页面和订单详情页面的渲染时间以及音讯接纳和发送的耗时做了监控，当超越一定的阈值，就会上报告警信息。目前工单详情和订单详情页面经过屡次的重构，整体的渲染耗时曾经稳定在 500 毫秒左右，做到了秒开，详细能够看近一周的渲染趋向：近 7 天工单详情页面渲染趋向：

近 7 天订单详情页面渲染趋向：

我们也抵消息接纳与发送耗时中心链路做了重构，目前也没有反应音讯接纳和发送耗时带来的延迟卡顿问题。

关于接纳音讯的告警我们只会对超越 700 毫秒的时分做告警，由于大局部的音讯接纳和发送都在 100 毫秒以内，客服是无感知的。5 总结客服各系统自接入监控至今也有半年多的时间，监控是我们系统发布上线的定心丸，同时经过监控数据也可以协助我们看出不少系统存在的问题，为我们的系统稳定性提升以及系统体验优化做出不少奉献。好音讯是我们得物自研监控平台也正逐渐建立完善中 ，目前前端平台、稳定性监控平台和效率工程一同协作开发的前端监控产品初版曾经完成，客服前端这边也逐渐将应用迁移至自研的监控平台，置信随着自研监控才能的的不时完善，我们可以在前端监控这一块获得更好的成果。