从零到一的探索：如何用技术解决业务中的“看不见”问题
背景介绍：一次突如其来的故障报警
记得去年年底，我所在的公司正处在双十二大促前夕，各个系统都在严阵以待。突然有一天，我们在监控后台发现一个奇怪的现象：用户登录流程中，有一部分用户在点击“登录”按钮后没有任何响应，页面处于卡顿状态。
最初大家以为只是个别用户的网络问题，但随着类似反馈越来越多，我们意识到这可能是系统层面的一个潜在缺陷。更严重的是，这部分用户既没有上报错误日志，也没有进入埋点统计链路，等于说他们在整个系统的监控体系中“消失”了。
作为一个长期从事前端和工程化方向的技术人，我接下了排查并解决这个问题的任务。这次经历让我对技术如何真正落地服务于业务有了更深的理解，也促使我写下这篇文章，希望能给同样面临类似挑战的开发者一些启发。
问题分析：那些“看不到”的问题最难搞
刚开始调查时，我们尝试从多个维度切入：
- 日志分析：所有用户行为的日志数据都没有异常；
- 接口调用监控：服务端没有出现超时或报错；
- 客户端性能追踪工具：比如 Lighthouse、PageSpeed Insights 等都没显示出明显问题；
- 用户复现反馈：只有极少数用户能稳定复现。
那问题到底出在哪里？
痛点一：问题不可视化
由于这类“卡住”的现象无法通过常规方式捕获，导致我们几乎是在黑暗中摸索。这时候我才意识到，真正的技术挑战往往不是复杂算法或高级架构，而是如何把不可见的问题“可视化”，让它暴露在我们可以操作的范围内。
痛点二：环境高度碎片化
我们很快发现，这个问题主要发生在低端 Android 手机上，尤其是运行较老版本浏览器（如 UC 浏览器、QQ 内置浏览器）的用户群体。这说明问题可能与设备性能、JS 引擎优化、异步加载策略有关。
于是我们开始着手搭建一套完整的异常感知和追踪机制，目标是：让每一个用户的每一次交互行为都能被“看”到。
技术方案：构建细粒度异常监控 + 用户行为回放系统
为了解决这个问题，我和团队一起设计了一套解决方案。整体思路分为两步：先发现问题，再定位问题。
第一步：异常行为的自动采集与分析
为了捕捉这些“消失”的用户，我们需要建立一套轻量级的全局异常监听机制，覆盖用户从进入页面到完成操作的整个生命周期。
实施细节如下：
资源加载性能埋点： 我们使用了
PerformanceObserver来监听 JS、CSS、图片等关键资源的加载耗时，并记录白屏时间、首屏时间等指标。错误拦截机制：
- 监听全局
window.onerror、onunhandledrejection - 捕获自定义异常（如接口返回码错误）
- 对某些第三方 SDK 进行封装，统一错误上报格式
- 监听全局
空转/卡顿检测机制： 我们引入了一个“心跳检测”模块，在每次事件循环结束后插入一条标记。如果超过指定时间未收到新心跳，则判定当前线程卡死，触发上报。
let lastHeartbeat = Date.now();
const HEARTBEAT_INTERVAL = 500; // ms
setInterval(() => {
const now = Date.now();
if (now - lastHeartbeat > HEARTBEAT_INTERVAL * 2) {
console.warn("检测到主线程卡顿");
reportError("js_long_task", { duration: now - lastHeartbeat });
}
lastHeartbeat = now;
}, HEARTBEAT_INTERVAL);
这个模块帮助我们成功识别出了一些长时间执行的脚本，特别是某些懒加载组件在低端设备上的性能问题。
第二步：用户行为回放能力接入
虽然我们已经可以采集到大量异常数据，但对于具体的行为路径还是一头雾水。于是我们决定引入一个轻量级的用户操作录制系统——它不是视频录制，而是一个结构化的 DOM 行为还原系统。
我们参考了开源项目 rrweb，并在其基础上做了定制化开发：
- 只录制核心用户操作区域：减少录制体积
- 敏感信息脱敏处理：输入框内容模糊处理，避免隐私泄露
- 按需上传：仅当发生异常时才触发完整回放包的上传
- 低侵入性实现：不影响原有主流程性能表现
这样一来，我们就可以在用户遇到问题的时候，准确还原他在页面上的所有点击、滚动、输入操作，甚至能看清页面渲染的延迟过程。
关键选型考虑
在整个过程中，我们做了一些关键技术决策：
| 组件 | 选型理由 |
|---|---|
| 错误监控平台 | 接入 Sentry，快速部署且社区活跃 |
| 埋点收集方式 | 自研 + 结合 Mixpanel 做交叉验证 |
| 回放系统 | 使用 rrweb 社区版并定制，不依赖商业方案 |
| 日志聚合 | Elasticsearch + Kibana，便于多维分析 |
实施效果：从被动救火到主动防御
这套系统上线之后，我们的线上故障响应效率提升了70%以上。更关键的是，以前很多“疑似偶发”、“无法复现”的问题现在都有了清晰的排查路径。
举个例子，之前有用户反馈在支付页卡顿，我们通过异常检测发现该页面存在一个“长任务”：某个第三方 SDK 在加载完成后一次性执行了大量的 DOM 操作。通过行为回放可以看到，用户等待的时间长达 8 秒，甚至触发了浏览器强制终止页面的风险。
最终我们优化了该 SDK 的加载逻辑，将关键操作延迟执行，并拆分成微任务队列。优化后的页面卡顿率下降了95%。
此外，我们也开始基于这些数据构建“用户体验热力图”，定期对重点页面进行性能评分和改进建议输出。
经验总结：技术要解决真实问题，而不是炫技
在这次实战中，我总结了几点非常实用的经验，想分享给大家：
1. 不要怕“看起来很简单”的问题
有时候我们会被表象误导。看似普通的页面卡顿，背后可能隐藏着复杂的性能瓶颈或兼容性问题。面对不确定的问题，最好的方法就是“看见它”。
2. 监控系统不是越全越好，而是越精准越好
别想着一开始就搞一套完美无缺的数据平台，建议从小场景切入，逐步扩展。先解决最痛的那个问题，再慢慢补足其他环节。
3. 异常感知要前置，不能靠“用户吐槽”来驱动
如果你总是等到用户打电话投诉才知道问题，那就太晚了。我们要做的不是事后修复，而是事前预警和实时干预。
4. 技术方案要符合当前团队能力和业务节奏
在我们决定采用 rrweb 的时候，曾有同事提出要不要自己开发一套录屏引擎。但考虑到时间成本和维护难度，我们还是选择了成熟的开源方案。事实证明，这种“站在巨人肩膀上”的做法非常明智。
写在最后：技术的温度在于服务真实用户
回头看，这个项目其实并不是什么高并发架构、AI 算法或者云原生改造，但它实实在在地影响了数万用户的体验，也让我们更深刻地理解了：技术的价值，从来不在于多么先进，而在于它是否解决了真实世界的问题。
作为一名一线开发者，我始终相信，只有贴近业务、深入问题本质的技术探索，才是最有生命力的实践。
希望这篇文章能给你带来一些新的思考，如果你也经历过类似的“隐形问题”，欢迎留言交流，我们一起探讨更多落地可能性。
文 / @Coze 开发者 · 坐标上海互联网圈
如果你也正在构建自己的监控体系，或者对用户行为回放感兴趣，欢迎私信交流。
评论 0