前端质量之灰度监控的有效实践

·  阅读 2641
前端质量之灰度监控的有效实践

本文将介绍更聚焦灰度监控的报警配置。

背景

回顾过去3年,前端故障总量并不算太大,但背后的数据反映出经济体前端的安全生产,特别是高可用这个子域,正处于一个相对比较低的水位:经济体故障监控发现率46.8%,但其中前端故障的监控发现率仅为22.7% ,与期望的监控水平相去甚远!因此我们开始专门起项治理前端质量,主要抓手通过监控报警,进行一段时间也取得了一定成效。
在分析遗漏的几个线上问题,尤其是报警没有报出来的,且较为严重(白屏、跳转故障等),都有以下共同点:

  1. 新变更导致的
  2. 非全量,只有部分流量 某些特定情况才会出问题
  3. 发布阶段本可发现,但遗留到线上一段时间

因此在报警已经配置的比较全面的下一阶段,我们更需要聚焦于灰度监控\

灰度监控的重要性

图片
从保稳定看

  1. 预发测试的局限性:不能全面覆盖到线上用户场景(包括多样的用户行为,丰富的客户端设备,海量的业务数据等)
  2. 发布时间节点时效性:技术同学对问题更为关注,更有积极性
  3. 及时止损:小范围的试错阶段及时发现,避免到全量发布造成较大影响后

从提效看

  1. 多端测试提效:某些多端导购页面,10%的时间就能cover掉80%以上的测试点,而剩下90%时间都可能在测多端个别异常场景,这里可以尝试用灰度方式替代
  2. 灰度验证:灰度发现的问题,修复后,除了预发测试外,某些非主流程场景可以继续小比例灰度测试

灰度监控的效果非常明显: 以我们detail详情页为例,接入监控4个月共发布27次,在灰度阶段共发现5个问题,遗漏1个问题但不影响主流程

灰度阶段如何监控

灰度阶段的日志监控过程

灰度监控主要从开始灰度到灰度99%阶段保持一定频率的监控发送报告 为什么是发送分析结果报告?

  1. 现在报警太多且噪音太多,相关技术人员很容易下意识的忽略掉,
  2. 发送监控分析报告的是增加一种仪式感,让大家能重视这个报告结果内容,
  3. 部分问题通过报警发现比较难,而通过分析报告能明显发现
  4. arms系统已具有成熟报警能力~已经配置上了相关告警,我们重点做分析报告

具体步骤可见下图 图片

  1. 灰度发布会触发日志监控,先灰度5%
  2. 在10min(一般保持在灰度5%~20%)后自动发出日志分析报告,列出各项数据,以及分析后的异常(具体见图2)
  3. 如确认为风险,则退回灰度0%,修复bug-》回归测试-》发布灰度,如此循环
  4. 如确认无异常风险,继续扩大灰度,并继续保持高频监控
  5. 灰度到99%前保持通过,发布上线

监控指标和异常分析

我们捞取sls日志,分别对api错误,js错误,流量,业务埋点,性能埋点的各项异常数据进行分析,而在灰度阶段新增错误尤为重要,存量错误和总计数据会进行环比、日同比、周同比这类的比较分析 图片 以下进行具体数据拆解

api错误

因为api错误的统计标准与我们的实际需求有出入(见下图)我们主要看新增错误、同比环比数据 图片

  • 错误率:主要统计同比环比。为什么不看api成功率?成功率99.5%下降到99%(下降了0.5%)数据非常不明显,失败率0.5%提升到1%(上升100%)很明显,才更能发现问题。比如我们有个detail页接口成功率常年维持在99.5%,有次发布前端bug成功率仅仅掉到99.3%,但影响了1w+用户一天
  • 错误数:(某api新增错误信息)错误数,1~2(每10分钟)是warn级别
  • 影响用户数:(某api新增错误信息)影响用户数,
    • a.会结合错误数一起看,辅助分析大量错误是否集中在个别用户上,
    • b.影响用户数权重大于错误数,说明影响面更广
  • 调用量:调用量异常也能反映前端bug,0一般是错误导致无调用,异常高一般是多次调用
    • 案例:2020.12.01 - 异常日志排查到订单结果轮询的 bug
    • 图片
    • 观察日志时发现有个接口突然调用量相对平日大涨,排查日志发现有同一个用户一直重复请求同一个接口,猜测可能是轮询逻辑有问题,通过排查代码发现一个取数逻辑有误引起的 bug

js错误

  • 错误率:同比/环比的大幅度提升,需要着重关注
    • 案例:2020.07.29 - 珍品 detail灰度中,监控发现报错率激增到10%,报错数激增到 5.6w,

图片

  • 错误数:(新增错误信息)错误数,1~2(每10分钟)是warn级别
  • 影响用户数:(新增错误信息)影响错误数,
    • a. 会结合错误数一起看,辅助分析大量错误是否集中在个别用户上,
    • b. 影响用户数权重大于错误数,说明影响面更广
    • 案例:2020.11.26 发布珍品详情页,在灰度25%时,发现
    • 图片
    • 图片
    • 报错原因:部分拍品url上的spm存在数组引起split 方法不存在。

流量异常

  • 主要看pv和uv,但需要排除大促活动、手淘大量引流等非常规因素对同比环比数据带来的影响,需要同时结合日同比、周同比、环比的各项数据都有大量偏离了才会判为异常(具体见后面的杂音处理)

业务埋点异常

用于业务自定义的埋点,方便做含有业务属性的统计 图片

  • 成功总量埋点:需要同时结合日同比、周同比、环比的各项数据都有大量偏离了才会判为异常(具体见后面的杂音处理)
    • 案例:2012.12.1发现apush连接100%挂,以下是发送apush的opcode统计,可见12.2修复问题前它的样本量一直为0

图片

  • 异常总量埋点:专门对异常数据进行了埋点,结合具体业务场景分析异常

性能监控

前端在各个环节加上埋点上报,然后做数据统计,性能的变化建议多点时间观察
(这里给的图是每日的趋势图,只为举例说明,灰度阶段是看灰度时间段和灰度前的数据,整个周期最好2天以上)

  • 页面完全加载时间:
    • p50,表示所有样本,按从小到大排名第50%位的数据,例如下图p50=1324说明50%的页面打开小于1324毫秒,
    • p70,表示所有样本,按从小到大排名第70%位的数据,例如下图说明70%的页面打开小于1730毫秒,
    • validAvg,表示去掉尖刺(>15秒异常数据)后的平均值
    • wellRate,表示<2s的比例,下图说明约78.16%用户访问在2s内,

(从下图趋势看,detail页12.24的发布导致前端性能变差,需要查下原因) 图片

  • 页面白屏率:认为完全加载时间在5s以上(从用户体感来说5s以上已跳失,宽松点可以按照15s以上)的都是异常白屏的情况,
  •  接口耗时:接口返回耗时也会影响前端性能,主要看平均耗时(去掉了>10s杂音)参考看成功耗时和失败耗时,耗时在>500ms的重点列出,warn级别

性能监控以及分析有个更详细文档,后面会出

剔除杂音,提高洞察风险有效性

存在的大概率报异常场景

(不过一般来说发布都会人为避免以下情景)

问题举例描述措施
业务在不同时段波动不一致在凌晨量级小时剧烈波动、在白天量级大时较稳定的现象自动动态调整阈值,避免误报
业务的冲高回落现象拍卖接近固定时间点结拍时的大量出价,整点客户端push、商家活动带来的1h内冲高回落若是回落到基线附近,则不报
业务的定时下跌现象业务在固定时间点附近会出现骤跌,如01:00~07:00设置不报时间点
大促现象业务在每年双十一、双十二、红包期间数据和日常不一致特定日子的数据波动实时监测,自动路由到大促模型
错误码监控中自动过滤短暂抖动在错误码监控中,错误码经常会出现短暂的抖动后恢复到正常水位需支持过滤历史相似的冲高抖动立即恢复现象,专注于对过高冲高、错误持续未恢复的情况进行告警

需要剔除的无效数据

api错误

长连接,统计到的taobao站外的接口数据,通常我们通过like('m.taobao.com/%')直接筛选出域内数据

js错误

a.与客户端交互的日志数据,webview框架数据等

b.业务含义的报错,如下图举例Uncaught TypeError: Cannot read property '0' of undefined。存量的报错是因为用户手势滑动操作头图区域导致的报错

图片

c.长连接、websocket、后端接口等引发的错误

abc三类,见下图举例

图片

d.黄牛、机器人问题

一般加上影响用户数就可规避大部分,如下图中实例:js错误率很高的时候,影响人数其实只有1个 图片 剔除无效数据,是个需要一定时间打磨的过程

建议主动自定义埋点+通用兜底

这是最好的排除无效数据的方法,但也需要进行梳理、以及手工埋点

总结

前端质量中,灰度监控,在保稳定和提效 多方位,都有明显效果,非常推荐! 同时也是需要业务前端开发和测试,甚至也会涉及到后端开发,共同齐心积极配合。 除了灰度监控,我们还有监控报警、线上巡检、性能分析,多个前端质量方案,全方位保障。

分类:
前端
标签:
分类:
前端
标签:
收藏成功!
已添加到「」, 点击更改