本文将介绍更加侧重于灰度监控的报警配置。
背景
回顾过去三年,前端故障总数并不算太多,但背后的数据却反映出经济体前端,特别是高可用性子域的安全生产处于较低水平:
经济的故障监控检测率为46.8%,但前端故障的监控检测率仅为22.7%,与预期的监控水平相差甚远!
因此我们专门启动了前端质量管理的项目,以监控和报警为重点,经过一段时间的实施,取得了一定的成效。
在分析几起被漏报的线上问题,尤其是报警未报、比较严重的问题(白屏、跳转失败等)时发现,它们都有以下几个共同的特点:
引发的新变化
并非所有流量都会出现问题,只有部分流量在特定情况下会出现问题
它可能在发布阶段就被发现了,但却被留在网上一段时间
所以在下一阶段,当报警配置得更加完善的时候,我们需要更加注重灰度监控。
▐灰阶监控的重要性
从维护稳定的角度
预发布测试的局限性:无法全面覆盖在线用户场景(包括多样化的用户行为、丰富的客户端设备、海量的业务数据等)
发布时间节点及时性:技术同事更加关注问题,积极性更高
及时止损:小范围试错阶段及时发现问题,避免全面发布后造成较大影响
从效率角度
提升多端测试效率:对于一些多端导购页面,10%的时间就能覆盖80%以上的测试点,而剩下90%的时间可能要花在多端个别异常场景的测试上,此时可以尝试用灰度测试。
灰度验证:灰度发现的问题修复后,除发布前测试外,部分非主流程场景可继续小范围灰度测试
灰阶监控的效果非常明显:
以我们详情页为例,监控了4个月,发布27次,灰度阶段发现5个问题,漏掉1个问题,对主流程没有影响。
如何监控灰阶阶段
▐灰度阶段的日志监控流程
灰度监控主要是从灰度开始到灰度99%阶段,保持一定的频率监控并发送报告
为什么要发送分析结果报告?
现在警报太多,噪音太大,相关技术人员很容易下意识地忽略它们。
发送监测分析报告是为了增加仪式感,让大家关注报告结果的内容。
有些问题通过告警很难发现,但是通过分析报告可以很清楚的发现。
兵种系统具备成熟的报警能力,配置了相关报警,重点做好分析报告。
具体步骤见下图
灰度发布会触发日志监控,先灰度5%
10分钟后(一般维持在5%~20%的灰度)自动出具日志分析报告,列出分析后的各项数据及异常情况(详见图2)
若确认有风险,则灰度回归0%,修复bug-》回归测试-》发布灰度,如此循环。
若无异常风险,继续扩大灰度,继续保持高频监测
持续传递直至灰度达到99%并发布上线
▐监控指标及异常分析
我们调取sls日志,分析API错误、JS错误、流量、业务埋点、性能埋点等各类异常数据,灰度阶段新增错误尤为重要,已有错误和总数据会按月环比、日环比、周环比进行对比分析。
以下是详细数据
由于API误差的统计标准与我们的实际需求不同(见下图),我们主要看新增误差、同比和环比数据
调用量:调用量异常也能反映前端的bug,0通常表示由于错误导致没有调用,而调用量异常高通常表示调用多次。
用于业务定义的埋点,方便包含业务属性的统计。
前端对每个环节都添加跟踪点,然后做数据统计,建议观察较长一段时间内的性能变化。
(这里给出的图表是日趋势图,只是为了说明,灰色阶段看的是灰色周期以及灰色阶段之前的数据,整个周期最好是2天以上)
(从下图趋势看,详情页12.24版本发布,导致前端性能下降,需要排查原因)
关于性能监控和分析还有更详细的文档,稍后会发布。
▐ 消除噪音,提高风险洞察的有效性
(不过一般来说,发布时会避免以下几种情况)
问题
示例说明
措施
业务在不同时期波动不一致
凌晨波动剧烈,白天震级较大时相对稳定的现象
自动动态调整阈值以避免误报
业务激增然后下降
固定时间结束前大量出价、整点时客户推送以及商家活动导致 1 小时内暴涨暴跌
如果回落至基线,则不会进行报告。
业务周期性下滑
业务会在固定时间点急剧下降,例如01:00~07:00
不设置报告时间
大促销现象
双十一、双十二、红包期间的业务数据和日均数据不一致。
实时监控特定日期的数据波动,自动路由至促销模型
自动过滤误码监控中的短抖动
在错误代码监控中,错误代码经常会出现短暂波动,然后才恢复到正常水平。
要支持滤除类似历史的高速抖动立即恢复的现象,对未恢复的过高高速连续错误进行重点报警。
API 错误
长连接,统计淘宝站外的接口数据,通常我们使用like('/%')直接过滤掉域内的数据
js 错误
a.与客户端交互的日志数据,webview框架数据等。
b. 有业务影响的错误,比如以下示例:Uncaught TypeError: Cannot read property '0' of undefined.inventory 报错是由于用户在 header 区域做了手势滑动操作导致的。
c.长连接、websockets、后端接口等导致的错误。
有三个类别:abc。示例如下图所示。
d. 黄牛和机器人
一般加上受影响的用户数就可以避免大部分了,如下例:当js错误率很高的时候,其实受影响的人数只有1人
剔除无效数据是一个需要一定时间来完善的过程。
这是排除无效数据的最佳方法,但也需要排序和人工埋点。
总结
从前端质量来说,灰度监控在各方面维持稳定性、提高效率效果明显,非常推荐!
同时,还需要进行业务前端的开发和测试,甚至可能涉及到后端的开发,需要共同积极的配合。
除了灰度监控,我们还有监控报警、在线巡检、性能分析、多种前端质量解决方案,提供全方位的保障。
团队介绍
阿里巴巴拍卖-技术质量团队,创新业务赛道,建立完善了一套适合阿里巴巴拍卖业务的测试体系,结合搜索、数据、算法、导购、营销、交易、直播等多领域测试能力,在自动化、性能测试、业务监控、精准测试、代码覆盖率等方面持续深度拓展测试价值。
关注BAT技术,回复:szh666,下载《阿里巴巴/华为数字化转型100页PPT》