作者：悠酱
出品：大淘宝技术
本文将介绍更聚焦灰度监控的报警配置。
背景
回顾过去3年，前端故障总量并不算太大，但背后的数据反映出经济体前端的安全生产，特别是高可用这个子域，正处于一个相对比较低的水位：
经济体故障监控发现率46.8%，但其中前端故障的监控发现率仅为22.7%，与期望的监控水平相去甚远！
因此我们开始专门起项治理前端质量，主要抓手通过监控报警，进行一段时间也取得了一定成效。
在分析遗漏的几个线上问题，尤其是报警没有报出来的，且较为严重（白屏、跳转故障等），都有以下共同点：
新变更导致的
非全量，只有部分流量 某些特定情况才会出问题
发布阶段本可发现，但遗留到线上一段时间
因此在报警已经配置的比较全面的下一阶段，我们更需要聚焦于灰度监控
灰度监控的重要性
从保稳定看
1. 预发测试的局限性：不能全面覆盖到线上用户场景（包括多样的用户行为，丰富的客户端设备，海量的业务数据等）
2. 发布时间节点时效性：技术同学对问题更为关注，更有积极性
3. 及时止损：小范围的试错阶段及时发现，避免到全量发布造成较大影响后
从提效看
1. 多端测试提效：某些多端导购页面，10%的时间就能cover掉80%以上的测试点，而剩下90%时间都可能在测多
端个别异常场景，这里可以尝试用灰度方式替代
2. 灰度验证：灰度发现的问题，修复后，除了预发测试外，某些非主流程场景可以继续小比例灰度测试
灰度监控的效果非常明显：
以我们detail详情页为例，接入监控4个月共发布27次，在灰度阶段共发现5个问题，遗漏1个问题但不影响主流程
灰度阶段如何监控
灰度阶段的日志监控过程
灰度监控主要从开始灰度到灰度99%阶段保持一定频率的监控发送报告
为什么是发送分析结果报告？
1. 现在报警太多且噪音太多，相关技术人员很容易下意识的忽略掉，
2. 发送监控分析报告的是增加一种仪式感，让大家能重视这个报告结果内容，
3. 部分问题通过报警发现比较难，而通过分析报告能明显发现
4. arms系统已具有成熟报警能力~已经配置上了相关告警，我们重点做分析报告
带你读《2022技术人的百宝黑皮书》——前端质量之灰度监控的有效实践（2） https://developer.aliyun.com/article/1242721?groupCode=taobaotech
