一、前言
在当今数字化时代，B 端系统作为企业运营的核心工具，通常涉及大量的数据处理和复杂的业务逻辑。前端，作为用户与系统接触的“第一窗口”，其稳定性犹如大厦根基，直接关乎用户的操作体验与工作效率。随着业务持续拓展和用户需求的水涨船高，B 端系统的复杂程度也呈螺旋式攀升，这无疑凸显了前端系统稳定性监控体系建设的紧迫性与关键性。一个全面的前端稳定性监控体系，能够助力开发团队及时发现并解决潜在问题，提供坚实的数据支撑，从而提升系统的可靠性与用户满意度。本文将深入剖析如何打造一个高效且可靠的 B 端前端稳定性监控体系，涵盖数据指标的定义、数据采集的方式、数据可视化呈现、告警监控机制以及数据解读 SOP 规范等诸多关键环节。
二、监控体系建设
2.1 指标定义
指标主要可以分为以下几类：
- “数值”类：用于衡量具体数值的指标，例如用户体感耗时、关键交互耗时等；
- “次数”类：用于统计事件发生次数的指标，例如错误数、白屏数、崩溃数等；
- “均值”类：用于反映平均水平的指标，例如页面加载平均耗时等；
- “率”类：用于衡量比例或概率的指标，例如崩溃率、白屏率、错误率等；
- “区间”类：用于分析数据分布情况的指标，例如用户耗时1s/3s/5s分布等；
- “分位值”类：用于评估极端情况和整体情况的指标，例如用户体感耗时P99值等；
2.1.1 通用场景指标
页面性能指标作为全平台通用场景中的关键监控要素，贯穿于系统运行的整个生命周期。在当前 Web 性能优化领域，业界已提出众多基准化性能指标，包括但不限于首次内容绘制时间（FCP）、交互下次绘制时间（INP）、累积布局偏移（CLS）、首次有效绘制时间（FMP）、总阻塞时间（TBT）、DNS 解析时间、TCP 连接时间以及资源加载时间等。更多详细的性能指标可参考性能监控商业化产品，如火山引擎应用性能监控和腾讯云可观测平台性能监控等。尽管这些基准化性能指标为我们提供了重要的参考依据，但用户在实际使用过程中最直观感受到的系统性能主要体现在两个方面：页面加载速度和页面响应速度。然而，现有的性能指标往往无法直接反映用户的这些主观感受，或者需要结合多个指标进行综合评估。此外，页面性能的表现不仅取决于前端渲染，还受到后端接口响应等多种因素的综合影响。基于上述情况，我们引入了“用户体感耗时”和“关键交互耗时”这两个业务自定义的性能指标，以更贴近用户真实体验的视角来衡量页面性能。这两个指标旨在更准确地捕捉用户在页面加载和交互过程中的实际感受，从而为性能优化提供更具针对性的指导。
- 用户体感耗时：即用户进入页面展示关键内容耗时，time = 页面核心内容渲染完成时刻 – 进入路由时刻；用户刷新进入页面到核心接口返回并且页面渲染完毕或 SPA 页面首次进入指定 Tab 到 Tab 核心接口返回并且页面渲染完毕。
- 关键交互耗时：即用户交互操作的响应耗时，time = 交互自定义结束时间 – 交互自定义开始时间；用户通过页面可交互区域触发某个行为场景到该场景结束（查询类：伴随接口调用结束；非查询类：纯 JS 逻辑计算）。
对于性能指标主要选择 P90 分位值 + P95 分位值 + P99 分位值 进行关注，对性能的要求越高，关注视角就需要使用越大的分位值，例如承诺 99% 的用户体感耗时都小于 3s，那我们就关注 P99 分位值。
数据要求“精准”的背景下我们需要自定义数据采集的逻辑，由人工来定义什么是页面核心内容，但如果数据要求“全面”的场景下，我们可以考虑由算法来自动采集性能数据，其关键在于如何定义页面核心内容，推荐阅读 👉 前端监控实践——FMP的智能获取算法。
2.2.2 特定场景指标
从用户使用的受影响程度来看，不同特定场景的影响程度从高到低进行排序，依次为页面崩溃、页面白屏、页面报错、页面卡顿。其中，页面崩溃是最为严重的情况，此时系统完全崩溃且无法恢复，用户将彻底无法使用系统。紧随其后的是页面白屏，当出现这种情况时，系统无法加载出任何预期内容，用户面对的是一片空白的页面，无法进行任何操作。再往下是页面报错，这可能会导致用户无法完成某些关键操作，其影响程度相对白屏稍低，但也不容忽视。而页面卡顿则是在页面使用过程中出现的较为常见的情况，它会使页面的响应速度变慢，但在等待后可能会恢复使用，虽然其影响程度相对前三种情况较轻，但在频繁出现时也会对用户体验造成较大困扰。针对不同的特定场景可以设定相应的指标：
- 通用指标：
- 发生次数：在一定统计周期内崩溃&白屏&报错&卡顿发生的次数
- 影响用户数：在一定统计周期内发生崩溃&白屏&报错&卡顿的去重用户人数
- 影响用户数比：在一定统计周期内发生崩溃&白屏&报错&卡顿的去重用户人数/UV
- 页面TOP5：在一定统计周期内发生崩溃&白屏&报错&卡顿次数最多的 5 个页面
- 其他指标：
- 崩溃率：在一定统计周期内崩溃次数/PV
- 白屏率：在一定统计周期内白屏次数/PV
- 错误率：在一定统计周期内接口出错数/请求总数或资源请求出错数/请求总数
- 报错原因TOP5：在一定统计周期内发生报错出现最多的 5 个原因
- 接口失败率：在一定统计周期内非200接口状态码请求次数/接口总请求数
- ……
上述所列举的指标都是较为常见的通用指标，但是在实际应用中数据上报会附带许多额外的信息，我们会根据这些信息来进行更多的维度拆解，例如不同报错原因的发生次数、前端和后端导致报错的发生次数等。
2.2 数据采集
本文主要介绍自定义稳定性指标数据采集技术方案，当前业界也提供了非常多的监控工具/库来提供采集和监控解决方案，例如 Lighthouse、 Sentry、fundebug、Bugsnag、trackjs、New Relic、Datadog 和 AppSignal 等。在数据采集的实践中，我们主要考虑：
- 全面性：尽可能覆盖系统运行的多环节多场景全链路；
- 高效性：数据采集所产生的开销一定是不能影响性能；
- 通用性：数据采集方案尽可能适用 React/Vue 等框架；
2.2.1 页面性能数据
完整内容请阅读 👉 《B 端前端性能优化全链路实践》
页面性能数据主要分为业界基准化性能指标和业务自定义性能指标两类。业界基准化性能指标是指被业界业界广泛认可且普遍应用的衡量标准，例如 LCP 体现了加载性能、INP 体现了可交互性和 CLS 体现了视觉稳定性。业界基准化性能指标的采集当前已有众多先进的工具库和监控平台可供选择，这些工具能够高效地支持完成数据采集工作。数据采集主要分为合成监控和真实用户监控两种模式。我们可以通过 web-vitals 库、PerformanceNavigationTiming API、lighthouse、PageSpeed Insights 和 webpagetest 等进行采集。业务自定义指标是开发者根据业务需求人为定义的指标或需要人为采集数据的指标，用户体感耗时为页面核心内容渲染完成时刻 – 进入路由时刻，关键交互耗时为交互自定义结束时间 – 交互自定义开始时间，具体埋点代码请阅读 👉 《定义更贴近用户的性能指标，手把手教你前端埋点》。
2.2.2 页面崩溃数据
完整内容请阅读 👉 《捕捉异常 🔍 前端页面崩溃监控技术方案》
页面崩溃意味着整个页面彻底失效，不在后台继续运行，即使等待一段时间也不会恢复，页面崩溃后我们的代码变得无效，常规监控上报方法也无法进行，有效地监控和预防页面崩溃成为了前端开发面临的难题之一。当前页面崩溃数据采集主要有 3 种方式：
- 本地状态存储对比：当前执行流程无法完成上报，可以利用 IndexDB 或 localStorage 等方式存储本地状态，当用户下次打开页面时，主线程读取这些数据，然后进行对比判断是否发生崩溃并进行上报。
- Service Worker 心跳检测：Service Worker 在浏览器中有自己独立的线程，浏览器崩溃后，其所在的线程不受影响，并且可以通过 postMessage API 与主线程进行通信。
- Reporting API 上报：Reporting API 引入了一个 HTTP Header Reporting-Endpoints，其允许开发人员以自定义的方式来将浏览器的报告发送到指定服务器。通过该方式我们能够捕获和报告网站中可能发生的各种错误，包括页面崩溃。
2.2.3 页面白屏数据
完整内容请阅读 👉 《屏幕检测 🔍 前端页面白屏检测技术方案》
白屏指用户进入页面在加载过程中长时间无法正常展示内容，常见的表现为页面空白始终没有内容、页面仅展示骨架屏加载态、页面仅展示背景色或背景图或页面只有侧边导航菜单等。白屏产生的原因是非常复杂且多样的，例如 JS 异常、样式问题、网络问题、兼容问题、第三方服务等。当前主流的白屏检测方法主要有以下几种：
- 可见元素识别检测：可见元素识别检测专注于检查页面上是否存在真正可见的元素内容，例如图片、文本、视频和特定 DOM 元素等；
- 页面内容得分检测：通过广度优先遍历白屏检测区 DOM 树上的节点来收集数据，每遇到一个可视元素则相应计分，白屏得分越低越可能白屏；
- 页面采样识别检测：在页面确定多个采样点，判断采样点元素是否为无效元素，当存在一定比例的采样点元素为无效元素则可以判定为白屏；
2.2.4 页面报错数据
完整内容请阅读 👉 《捕获错误 🔍 前端运行报错捕获技术方案》
页面报错指标是至关重要的部分，其主要分为 3 部分内容存在报错情况：
- 前端代码出错：指在页面加载和运行过程中，JavaScript代码执行时出现的错误，例如语法错误和逻辑错误等；
- 资源加载出错：指页面中的资源（如图片、CSS、JS等）加载失败的情况，例如资源路径错误和资源服务器问题等;
- 接口请求出错：指在前端页面发起API请求时，请求失败或返回错误响应的情况，例如服务器出错和网络错误等;
2.2.5 页面卡顿数据
完整内容请阅读 👉 《实时洞察 🔍 前端页面卡顿监测技术方案》
页面卡顿是用户在使用过程中最为频繁遇到的问题之一，其主要表现为页面渲染延迟、动画不流畅、输入等交互延迟、滚动拖动卡顿等。卡顿通常由浏览器主线程被阻塞引起，每当主线程任务过多，尤其是 JavaScript 执行时间过长时，就容易出现卡顿。当前卡顿检测主要有以下方案：
- 帧率检测：通过requestAnimationFrame 来计算帧率，页面的帧率应维持在 60FPS 或更高水平才能让用户感受无卡顿；
- 心跳检测：与崩溃检测一样，卡顿也能使用心跳检测来进行，通过定时器来定期检测页面是否响应，如果页面在预定时间内没有响应，就可以判断为卡顿；
- Long Tasks 监听：任何主 UI 线程连续不间断繁忙 50 毫秒及以上的时间区间定义为长任务，通过 PerformanceObserver 我们能够精准地定位长任务。
2.3 监控方式
监控体系建设完成数据上报这只是迈出了第一步，真正关键的是如何利用好这些上报数据，建立数据监控体系，数据监控主要手段是数据看板、监控告警和数据推送。
2.3.1 数据看板
通过建立全方面数据看板，我们能够实时展示所定义的稳定性指标，从而直观地了解系统的当前状态，并及时发现潜在问题。此外，该看板支持多维度的数据分析和交互式功能，用户可以根据不同的时间和维度进行数据展示，以便查看更详细的数据，进而进行更深入的分析和决策（数据看板因不同公司的数据 BI 基建情况各有差异）。
2.3.2 监控告警
告警机制用于在监控指标出现异常时及时通知开发团队，以便快速响应和处理问题，最为常用的告警方式是阈值告警，即当关键指标超过阈值时触发告警，其主要包括两种阈值：
- 绝对值阈值：绝对值阈值是指为指标设定一个具体的数值范围，确保其不低于或不高于某个预设值。例如，在核心页面的性能指标中，用户体感耗时天 P90 不能超过 5 秒，一旦指标超出该阈值范围，就可能意味着页面加载速度过慢，影响用户的使用感受，我们需要立即采取措施对该页面进行排查问题并进行优化。
- 相对值阈值：相对值阈值基于历史数据及波动情况来设定，为绝对值阈值的有力补充。根据实际业务场景或指标的重要程度，选择合适的历史数据周期，然后计算该周期内指标数据的标准差，将其作为相对值阈值。标准差反映了数据的波动程度，当指标的实时值与历史均值的偏差超过设定的标准差一定值时，即可视为异常。
告警可以根据严重程度和紧急性，通过邮件、短信、即时通讯工具等多种渠道发送通知，确保相关人员能够第一时间收到告警信息并迅速响应。当触发监控告警时，立即进入数据解读阶段，进行定位、归因和解决。除此之外还可以设置趋势告警，通过分析指标的历史趋势，当出现异常波动时进行告警；或利用 AI 算法对指标进行分析，自动识别异常模式并触发告警。
2.3.3 数据推送
在前端稳定性监控体系中，数据推送不仅涵盖异常情况下的实时告警，还包含常态化的稳定性数据推送。根据数据的重要性和应用场景，推送频率分为日、周、月度以及季度等多个维度，确保监控信息既及时又具有针对性。
- 每日报告：每日生成监控报告以总结前一天的前端稳定性情况，包括关键性能指标的平均值、峰值和分位值，错误事件的总数和类型，以及重点关注页面的性能表现等。报告可以通过邮件或即时通讯工具发送给相关人员，帮助团队快速了解运行状况。
- 每周周报：每周生成一份前端稳定性周报，内容涵盖本周的整体性能趋势、错误事件的汇总分析、性能优化的成果展示，以及下周的重点关注事项和优化计划等。周报为团队提供全面的稳定性监控总结，便于团队进行复盘和规划。
- 月/季度报告：每月/季度生成报告，对整个月/季度的前端稳定性进行深度分析，结合历史数据对比，评估性能优化的效果，分析长期趋势，并提出下一阶段的优化方向和策略。月/季度度报告通常以更正式的文档形式呈现，供管理层和技术团队参考。
三、监控体系运行
当完成监控体系建设后，要想真正发挥数据监控的价值，关键在于构建一个良性循环且可持续防裂化的运行机制。在此过程中，以监控体系作为核心基础，辅以数据看板&数据推送常规数据解读和告警异常数据解读。一方面，根据不同的解读周期，进行常态化现状分析，对常规数据进行深入解读，以便及时掌握系统运行的正常状态和趋势；另一方面，对告警中的异常数据进行精准解读，当触发监控告警时，则立即进入数据解读的定位异常阶段，准确定位并归因异常情况，并对问题进行跟进解决。通过这两种机制的有机结合，能够实现预防问题的发生以及防止问题的恶化，为系统的稳定运行提供坚实的保障，形成一个从数据监控到问题解决再到系统优化的完整闭环，推动系统向着更加高效稳定的方向发展。
3.1 解读周期
首先，我们需要根据数据的重要性来确定每个数据的常规化解读周期，如周、月、季度或年等。原则上，数据内容越重要，其解读周期应越短，以便及时发现该模块的异常表现并迅速解决问题。例如，对于业务重要性高或 PV 高的核心页面的页面性能指标，我们会选择每周进行解读；而对于非核心页面的数据，除了异常告警外，其解读周期可以按月或季度进行。
3.2 现状分析
现状分析是数据解读的重要环节，其核心在于全面评估当前解读周期内的数据表现。具体来说，我们关注以下几个关键方面：
- 当前周期内指标的绝对值：这是最直接的分析维度，我们可以迅速了解该周期的整体表现；
- 相比于上一个周期指标的变化绝对值：这一指标可以量化感知数据的发展趋势或波动情况；
- 相比于上一个周期指标的变化相对值：这一指标有助于我们更准确评估变化的幅度和影响；
3.3 定位异常
在常规的解读周期中，异常阈值通常比监控设置的阈值更为宽松，以便于进行更为常规的分析和解读，在监控告警中设置的阈值则针对较为严重的情况。此外，我们关注本周期内的异常数据点，这些数据点主要包括以下两个方面：
- 绝对值异常数据点：当指标值的绝对值超过设定的绝对值阈值时，该数据点被视为异常，这些异常数据点通常需要 case by case 地分析其原因并采取相应措施。
- 相对值异常数据点：当指标绝对值减去周期内指标均值后，所得的差值大于设定的相对值阈值时，该数据点也被视为异常，相对于整体趋势或平均水平存在偏差，应引起关注并分析。
3.4 异常归因
在对定位到的异常数据进行问题排查时，可以按照以下步骤进行：
- 数据有效性检查：进行数据有效性验证是排查问题的基础，我们需要确认数据本身是否存在问题，例如检查是否有部分数据未产出导致整体数据异常和确认数据产出任务是否被修改或执行异常等。如果数据有效性存在问题，那么异常可能并非由系统本身引起。
- 拆解异常的数据：将异常数据点拆解到最小可分析的粒度，以便更精准地定位问题。例如，对于用户体感耗时这一指标，可以将其拆分为前端渲染耗时和接口请求耗时。
- 分析异常的原因：对于每个最小可分析粒度的指标，逐一分析其异常原因，定位具体的异常点和原因。通常按照以下顺序进行排查：
- 外部原因：公司基建平台是否异常和集群资源使用是否不足或分配异常等；
- 内部原因：在异常时间点前后，是否有对该模块代码进行修改；上线了其他相关逻辑是否有影响；检查系统配置是否在异常期间发生了变更等；
在产生异常时除了对异常数据进行异常归因之外，也可以周期性基于异常情况来对告警阈值设置来进行策略优化，以便更好的适合平台的迭代演进，形成”异常告警 -> 定位异常 -> 异常归因 -> 数据分析 -> 策略优化”的动态平衡。
3.5 问题解决
定位到异常原因之后，协同相关团队成员解决问题，并给出日后避免此类问题发生的保障方案，包括但不限于具体行动措施、参与方、预期解决时间等。在问题得到解决且保障方案顺利落实后，我们将及时向所有相关人员通报情况，确保信息的透明与同步。此外，我们会持续监控数据表现，至少观察两个解读周期，以验证问题是否得到彻底解决，并确保业务运行的稳定性。整体目标是“遇到一个问题，解决一类问题”。
四、总结
本文系统阐述了 B 端系统前端稳定性监控体系的建设实践，重点围绕关键指标定义、数据采集、监控看板构建、告警机制设计等核心环节展开论述，并深入探讨了数据周期性解读与异常归因的方法论。实践表明，B 端系统前端稳定性监控体系的构建是一个持续迭代、不断优化的系统工程，需要结合业务特性和技术发展趋势进行动态调整。完善的监控体系不仅能够显著提升前端系统的稳定性，更能为用户提供优质高效的使用体验，从而为企业业务的可持续发展提供有力支撑。
作者：植物系青年
链接：https://juejin.cn/post/7469324792941051967
