本文将介绍更加侧重于灰度监控的报警配置。
背景
回顾过去三年，前端故障总数并不算太多，但背后的数据却反映出经济体前端，特别是高可用性子域的安全生产处于较低水平：
经济的故障监控检测率为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》
