2022年9月23日，字节跳动在北京举办了掘力计划第25期"性能专场"技术沙龙。本次活动的主题是《前端研发全流程的性能监控实践》，由字节跳动架构前端 APM 团队的李俊安和嵇晓濛两位讲师进行分享。
长期以来，对前端监控的理解局限于对线上应用进行数据采集和监控，以便及时发现问题。但随着业界对应用质量和稳定性要求越来越高，仅仅依靠线上监控已然不能满足需求。因此，业内开始探索在研发流程中"左移"监控点，使质量监控覆盖更早的开发阶段。
研发流程左移的动机
李俊安讲师首先解析了典型的研发流程，包含计划、开发、测试、构建、部署、全量发布、灰度发布、监控等8个节点。过去，监控节点主要位于全量发布之后，意味着问题往往已经暴露给大批用户，无法避免对用户造成影响。
随着业务团队对端监控能力要求不断提高，对应用质量和稳定性的需求也在提升。这要求端监控能力需要从简单的线上监控，逐步向研发流程的更早阶段扩展。业界传统的端监控集中在全量发布之后，一旦出现问题就已经影响到大量用户。为了能够尽早发现问题、减小问题影响，需要将监控点逐步左移。
首先可以从全量发布后左移到灰度发布，在小流量环境下测试新版本。再进一步可以左移到持续集成环节，在交付过程中的各个节点实施监控，对问题 adoption 采取措施。这对应了业务团队的诉求，从最初简单追求尽早发现问题，到关注降低问题影响范围，最后希望能够防患于未然、杜绝低级错误反复出现。
从全量发布到灰度发布
相比日常监控，灰度监控有自己的特点。嵇晓濛介绍了灰度监控的3个关键点：
-
区分灰度流量数据：在数据采集时通过版本号标记灰度数据，在后续处理中以版本号筛选。
-
按比例调整报警阈值：根据灰度比例动态调整报警阈值，保证敏感度。还可以通过复合指标监控灰度放量异常。
-
关注版本引入的新问题：主要通过核心业务链路指标、异常指标发现问题，辅以性能指标。
技术实现上，主要是在数据采集时打标签，后续处理和报警以标签区分灰度数据。此外，监控灰度覆盖率指标以确保放量正常。另外，设计了动态报警阈值机制，可以根据不同的灰度放量比例来调整报警触发阈值。
报警之外，还可以在监控看板上设计多指标联动观测，比如同时观察灰度版本的错误率和所有版本的错误率，判断是否存在明显差异。如果放量比例不精确，可以通过设计复合指标来动态适应。
针对灰度监控的指标选取，要优先关注稳定性问题，如核心业务链路的异常、JS 错误、网络请求错误等高优先级指标。同时要关注灰度放量本身的异常，确保放量符合预期。
从上线后到上线前
嵇晓濛讲师提到，即便我们能通过灰度监控能力减少问题影响的范围，也不可避免地将问题直接暴露给了部分用户。我们如何在上线前就发现和拦截问题，不让这些问题直接暴露到用户面前呢？
1. 页面快照与端到端测试：预览环境的模拟验证
为了避免将缺陷及性能问题暴露给用户，我们将监控能力左移到上线前的节点，即持续测试阶段，在测试环境或预览环境就对应用做一次全面的体检。
具体来说，可以采用以下措施：
-
使用基于 Lighthouse 的线下性能分析能力，Lighthouse 可以分析网页首屏加载、渲染、运行时的性能瓶颈。
-
通过平台化手段增强 Lighthouse 的归因能力和跨版本追踪能力，可以更好地定位性能瓶颈。
-
使用基于 Puppeteer 的端到端测试。通过编写业务核心链路的交互流程，自动化测试不同场景下应用的性能。
2. 产物分析：分析打包产物对应用的影响
除了页面交互外，构建产物本身也会对性能产生很大影响。所以我们将监控继续左移到了持续集成阶段，对构建产物进行分析：
- 收集 Webpack、ESBuild、Rollup 等构建工具产生的构建信息。
- 增加产物信息的跨版本追踪、报警等能力。
- 引入规范，给出产物优劣的评判结果。
- 从多个维度分析产物对性能的影响，如文件体积、重复依赖等。
通过上述措施，我们能在上线前发现绝大部分问题，最大限度地减少问题对用户的影响。
总结
通过逐步左移监控点，可以在更早开发阶段发现问题，有效防止缺陷暴露给用户，提高产品质量。线下性能分析的能力已经被集成到开源平台 perfsee.com 中，供更多团队使用。本次分享从研发流程的全局视角审视端监控，分享了许多可操作的方式来提升应用性能，对于其它前端团队也具有很好的借鉴意义。
掘力计划
掘力计划由稀土掘金技术社区发起，致力于打造一个高品质的技术分享和交流的系列品牌。聚集国内外顶尖的技术专家、开发者和实践者，通过线下沙龙、闭门会、公开课等多种形式分享最前沿的技术动态。