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 总结客服各零碎自接入监控至今也有半年多的工夫，监控是咱们零碎公布上线的定心丸，同时通过监控数据也可能帮忙咱们看出不少零碎存在的问题，为咱们的零碎稳定性晋升以及零碎体验优化做出不少奉献。好消息是咱们得物自研监控平台也正逐渐建设欠缺中，目前前端平台、稳定性监控平台和效率工程一起合作开发的前端监控产品初版曾经实现，客服前端这边也逐渐将利用迁徙至自研的监控平台，置信随着自研监控能力的的不断完善，咱们可能在前端监控这一块获得更好的问题。