演讲 PPT: GMTC 2021 参会分享之-前端质量保障专题

演讲场所: 网易-音乐事业部-技术沙龙

演讲简介: 刚刚过去的 GMTC 大会，是技术界的一次盛宴，大前端技术部派出代表北上取经。本次演讲介绍业界公司在前端线上质量保障方向的探索与实践。

演讲时间: 2021-07-13

信息

以下为演讲逐字稿

演讲逐字稿

前言

大家好，我是 kkdev163，今天为大家带来的分享是 GMTC 前端质量保障专题。

本次分享的议题基于 「快手-前端监控体系建设」、「蚂蚁-前端灰度监控与变更防御」

这里加个免责声明：本分享的全部素材取自以上议题。

一.快手

首先我们来看 「快手的前端体系建设」，原分享主要分为三块：

• 1 监控指标定义
• 2 快速分析定位原因
• 3 监控平台的搭建和稳定性保障

由于时间的关系，第三部分我们不作展开。

1.1 监控指标定义

首先来看快手的 页面性能监控指标定义。

从页面请求开始 到 页面加载完毕的时间线上，有多个关键的时间节点。。快手提出 如果我们只能用一个指标来代表前端页面性能，应该用哪个呢？

快手排除了

• Load, 由于他在长页面下 不能很好地反应用户体感
• First Paint，骨架屏下，他无法体现页面核心内容渲染时间
• FMP，他没有标准的实现
• LCP, 最大元素不一定是最重要的元素，并且该指标的浏览器兼容性还不太高。

最终快手给出的方案是 自定义 FMP, 快手对该指标的定义是在 API 数据渲染到 DOM 后的时间。

在分享中，讲师提到 自定义 FMP 指标的采集 有 SDK 自动采集 和 开发人员手动上报 两种途径，但目前 SDK 自动采集的 算法有效性还有待验证，所以目前快手主要还是依赖开发人员的手动埋点。

除了页面加载耗时，快手也针对其核心的业务场景，视频播放、视频直播，设计了专门的监控指标。如：

• 播放失败率
• 启播耗时
• 百秒卡顿率

同时快手也提出，作为前端开发者，我们也需要去关注 H5 容器的监控数据。。讲师举了个案例，有用户反馈一个页面很慢，然后开发者把 页面完全加载时间从 6.5 秒 降低至 4.5 秒，有了很大的提升，但用户的实际感受，还是很慢。。为什么呢？

分析下来后发现，原来从 点击 H5 入口 到真正开始加载 H5 页面，中间有一个 5.9 的秒的 Webview 启动时间。如果把 Webview 加载过程放大，会发现有

创建 Webview、注入 JS 桥、注入 Cookie 等环节。。所以如果我们只关注纯前端部分，而忽略 H5 容器的开销，我们监控到的性能其实是与 用户感受有较大偏差的。

所以快手针对容器，也设计了一系列完善的监控指标。

1.2 快速定位问题

在完善了监控指标的采集以后，快手又是如何帮助开发者快速定位问题？

快手提出了 数据归因 诊断能力

简单来说，快手会先建立指标的 依赖树，比如 自定义 FMP, 他可能会受

• tcp 建连时间
• 网络传输时间
• api 加载耗时

等等 原子指标 的影响。

在 FMP 波动了 10% 的情况下，会根据每个 原子指标 的波动率，进行归因，计算每个波动因子的贡献度，最后选出 Top3 的贡献因子。

这张截图展示了，在 FMP 波动后，给出的智能归因。

除了数据归因诊断能力，快手也做了 访问级别 的请求还原，给到一个 userId，就能查出 详细的 访问情况，接到客诉的时候，就能快速排查出，他为什么慢。

1.3 总结

• 快手建立了以 FMP 为主的 前端度量指标体系
• 并且通过智能数据归因、访问级别的请求还原，来帮助开发者快速定位问题。

二.蚂蚁

接着我们来看蚂蚁的灰度监控与变更防御。内容主要分为两块：

• 建立前端灰度监控体系
• 基于灰度监控的发布变更防御

2.1 灰度监控

这里的关键词是 灰度监控，我们先来看下什么是 灰度发布。

蓝绿发布简单来说，就是在 新版本 准备完成后，一次性将流量全部切换至新版本。

而灰度发布简单来说，可以选择为 部分的用户 提供 新版本 进行线上灰度验证，待验证无误后，逐步扩大灰度比例，直至 100%。

对于不同的应用类型，实现灰度发布的方案都有不同的区别。

以 支付宝官方小程序 的灰度为例。

当用户访问支付宝客户端时，根据灰度决策，会判断 当前用户是否进入 灰度池子，如果是的话，就拉取灰度小程序包，没有的话，就拉取 正式包。

这样的灰度发布看起来很完美啊，那支付宝遇到了什么问题呢？

讲师提到，在灰度变更的过程中，线上和灰度数据混在一起，监控无法感知应用当前正在灰度。。开发者想象中，在迭代发布后，会有明显的指标变动趋势，但实际的指标变化却是这样。

所以 开发者并不知道，灰度过程中，到底发生了什么，同时也不知道，这个版本对比线上正式包，情况到底如何。

也就让这个发布过程没有安全感，同事变更相关的故障率极高。

为了解决这个问题，支付宝建立了 前端灰度监控体系。。从流程上来看，在构建阶段，自动注入 此次迭代的标识，在用户访问时，使用 迭代标识 去 初始化监控，最后在监控数据上报时，携带上 迭代标识。

在数据做 清洗 的时候，把 迭代标识 作为顶层的维度进行聚合。这样就可以得出不同迭代版本的 数据。

在平台上就可以精确地区分出 此处迭代 引起的数据变化。

• 不同灰度版本 的流量占比
• 以及不同版本下的错误数

2.2 基于灰度监控的发布变更防御

当蚂蚁建立起 灰度监控 后，蚂蚁进一步又做了发布变更防御。

我们来看下整体的流程：

在进入灰度前，会有一个前置的校验卡点，如果没有通过会直接终止发布，通过后，会开始向客户端下发灰度策略 比如 5%，在灰度策略下发后，会有一个灰度后置校验，如果验证成功，会进一步扩大灰度比例，如果失败，就立即终止发布。

我们可以看到，这里的关键节点是 灰度后置校验。我们来看下蚂蚁到底

• 要进行哪些验证？
• 又要对哪些指标做验证？
• 这些验证又是如何保障灰度发布的？

进行哪些验证

平台希望用户去关心

• 灰度有没有充分
• 有没有把应用、页面、小程序搞挂
• 有没有引入新的异常
• 异常相比于线上有没有增多

为此建立了

• 灰度流量
• 新增异常
• 异常率等指标

有了这些验证 和 指标，又是如何保障灰度发布的呢？

• 1. 当设置 5 % 的灰度比例，为了保证充分灰度，则要求当前迭代标识的流量必须接近全量的 5% 才能进入下一个灰度梯度。
• 2. 在每个异常出现时，系统会记录 该异常的首次出现时间、首次出现迭代，若判断出，该异常是此次迭代中引入，则拦截此次发布。
• 3. 计算出 此处灰度的 异常率，若明显高于基线版本，则触发拦截。

总结下:

• 蚂蚁通过 监控数据 与 发布流程结合，建立起了 发布变更防御体系。为用户带来了发布安全感、也让监控数据发挥出更大的价值。