让偶现Bug无所遁形：贝壳自研时光机如何解决前端行业痛点？

随着页面展示形态的多样化发展，用户使用环境的日趋复杂，当代监控越来越无力。传统监控可以做到在错误发生时上报错误堆栈信息，甚至更多地引导数据。但当前端出现偶发 Bug 时，最令开发人员困扰，因为它们大大地增加了排查成本。 针对偶发 Bug 的问题，贝壳找房于 2019 年年初自研了操作回放系统——时光机，作为灯塔前端监控的扩展系统，时光机通过对用户操作路径和动作的收集，关键数据的快照存储，以及并行组装等能力，提供了一套用户回放操作技术方案，实现了 100% 用户操作回放。InfoQ 近日采访到贝壳找房基础架构中心前端架构委员会专家陈辰，就目前企业前端监控现状、攻克偶发 Bug 的技术难点，以及贝壳自研操作回放系统时光机的过程进行了详细探讨，以下为采访全文整理。

InfoQ：请介绍您在贝壳找房主要负责的工作。

陈辰：我在贝壳找房主要负责整个公司的架构团队和前端横向委员会的工作，对接新房、租赁、二手房、装修、交易团队等一线业务团队的 FE。除去部分编码工作，还负责技术梯队的搭建、人才培养、公司架构或业务的技术选型、横向通用能力的支持等等。

InfoQ：您在即将召开的 ArchSummit 全球架构师峰会（北京站）上分享《监控进阶前端操作完美回放》这一演讲主题的原因是什么？

陈辰：在日常的业务开发中，各种监控层出不穷。监控本身可以通过类似报警、错误堆栈信息发现一些问题，但有些问题只能在特定操作流程下出现。而且在修复某些偶现问题时，我们可能不清楚这个问题是否真正修复，因为问题的偶现性无论排查问题，还是验证修复问题都是非常困难的。也就是说，在许多业务中出现的 Bug 无法得到解决的主要原因是无法复现。基于上述问题，贝壳在 2019 年初启动了自建的回放系统——时光机，目前已在贝壳大面积应用，因此想就这一项目和大家做一次技术分享。 其实，时光机的出现是由一个很偶然的问题引出来的。产品经理之前总向我们反馈不清楚用户是如何使用产品的，尤其是房屋交易、查看这种强流程交互类的产品。虽然通过产品数据、漏斗等方式可以观察到用户的趋势，但还是很难分析用户在操作系统时点击了什么，在操作某一步停下来是报错了，还是在思考，还是不知道下一步如何操作，抑或是验证码看不清等问题。最关键的是，一个新模块上线的时候，用户到底用不用，如何使用等，都是我们想要知道的问题。后来我们做了时光机来满足这个需求，但是没有想到的是，时光机在解决 Bug 时发挥了更强的作用。

InfoQ：什么情况下会出现偶发 Bug？它对开发人员会造成什么影响？传统监控还存在哪些不足？

陈辰：其实偶现 Bug 最常出现在流程长的操作中。如果是一个非常简单的场景，问题还比较容易复现。因为可能出现的问题点就那么几个，比如：接口错误、返回结构与解析接口不符、常规 JS 运行时报错等。但在一个长流程中，可能在流程第四步报错，而问题的原因在操作的第一步就已经埋下了。 在传统监控中，预警问题已经不是难事。但是对研发人员而言，除去预警问题，解决问题才是最重要的。监控本身提供给我们的信息，包括操作截图、堆栈信息、报警趋势都没有操作回放来得直接。

InfoQ：解决偶发 Bug 难在哪？

陈辰：解决偶发 Bug 的难点在于『偶发』二字。主要有两个难点，第一个难点在于，偶发 Bug 意味着你无法知道 Bug 出现的具体场景。就像一个普通的 JavaScript 报错，这个错误可能出现在成千上万的场景中，仅凭错误的堆栈信息往往还是无法 100% 定位问题；另一个难点在于，即使研发人员修复了也没有办法验证，因为研发人员不知道如何才能触发这个 Bug。所以，偶发类 Bug 是前端公认的最难修复的 Bug 之一。

InfoQ：操作回放在前端监控中的主要作用是什么？

陈辰：主要作用还是针对偶发 Bug 的处理，还有定位一个 Bug 是不是前端 Bug。比如我们的系统经常回放已经修复的偶发 Bug 的操作路径，来确定 Bug 是否修复。再比如产品本身的逻辑就存在死逻辑，用户无论如何操作都无法进入下一步操作。这类问题用户也会以 Bug 的形式报给客服，但是前端工程师接到这种问题根本无从下手，唯有看一下用户究竟是如何操作的回放，才能定位这个问题的原因。

InfoQ：您了解到的一些公司的监控现状是怎样的？可否结合实例谈谈？

陈辰：没有实践就没有发言权，我谈谈我服务过的几家公司。我在百度的时候，监控是自建的 DP 平台，当时大概是 2013 年，主要是收集用户设备信息，帮助监控前端返回一些前端错误，当然也有常规的产品指标 PV、UV 的数据。后来所在的公司采用的是第三方的听云监控，在业务中使用听云做一些自定义数据的收集也不错，而且对于前端系统侵入性也少一些。后来我们发现研发工程师修复问题时有很强的操作回放的功能需求，因为我们主要的用户是经纪人，他们在描述问题时，可能并不像互联网用户那么专业，而且有的堆栈信息可能确实无法排查问题，所以才自建监控，并研发了操作回放的功能。

InfoQ：请您介绍下贝壳自研项目——时光机的技术原理、实际应用情况，以及与灯塔的关系。

陈辰：时光机的技术原理其实是利用了一个监控底层的 SDK 把用户操作信息做脱敏操作，加密之后上传到数据收集服务器，通过任务清洗的方式把有效数据和报错信息做关联，最终在用户需要查询错误信息报错的时候，我们能够看到用户的回放信息。目前，它已经在贝壳得到大面积推广，而且口碑也非常不错。至于与灯塔监控之间的关系，可以说，时光机是灯塔前端监控的扩展系统，也是可以单独提供用户操作回放服务的系统。

InfoQ：时光机最大的亮点是什么？请您用三个词概括。它可以在多大程度上避免偶发 Bug？

陈辰：最大的亮点是模拟用户操作，让开发人员站在用户操作的角度。 第一，100% 回放用户操作。也就是说，用户做什么我们就回放什么，相当于我们站在用户身后看着用户操作。这部分最主要的能力就是解决偶发 Bug，因为对于偶发 Bug 来讲，用户的操作过程以及依赖数据尤为重要。 第二，真实操作数据。根据用户操作可获取操作信息，根据数据分析用户场景。尤其在分析某类用户如何使用具体产品功能时，我们会获取用户相关的数据，但是相关数据都会经过脱敏处理，并且在用户协议中告知用户数据用途，且做到不上传、不存储用户敏感信息。最关键的是，时光机服务的系统均为公司内部经纪人系统，不会收集普通用户信息。 第三，时间维度 1：1。用户三小时不动屏幕，我们就回放三小时（当然有快进和跳过无操作的功能）。

InfoQ：贝壳目前在监控平台的研发投入情况是怎样的？

陈辰：目前，贝壳监控系统已经覆盖了 99% 的项目，大概 300 多个项目，包括新房、二手房、装修、租赁等事业线。大家耳熟能详的链家网、贝壳网等均接入了贝壳前端监控系统。在贝壳，新的前端项目默认接入前端监控已经形成了一种习惯。其实起初，贝壳前端并没有监控，大多数 Bug 均来自于我们优秀的 QA 同学和一线用户的客诉，后来我们引入了听云系统做一些常规设备的检查、PV、UV 等数据的统计，但是针对前端报错、前端报警、强定制化这类问题还是没有得到解决。所以后来，我们以“比用户先发现问题“为目标开发了贝壳前端监控灯塔系统。

InfoQ：结合贝壳在监控开发过程中踩过的坑，请您谈谈企业在搭建监控时要规避的问题。

陈辰：主要是前端工程师在搭建监控时，存在服务器端知识欠缺、整体的系统设计性差，以及对任务调度、数据清洗等概念缺失的问题。其实前端监控还是由前端工程师来做最好，一是我们很少能在公司内部争取到后端资源；二是就算争取到资源需求，项目本身的需求翻译、原型图、效果图、需求文档也不是程序员所擅长的。

InfoQ：下一步贝壳要攻克的技术难点是什么？

陈辰：整体前端的产业升级是我们贝壳下一个阶段的主要目标，我们要把贝壳的前端开发模式从作坊式的开发，转变成为工厂、车间这种标准化、流程化、统一化的前端生态体系。目前，贝壳前端也在专注探索人效的科学计算、科学排期，评估人效比等这类问题。

专家介绍： 陈辰，贝壳找房基础架构中心前端架构委员会专家、前端架构师、前端开源项目负责人。著有《前端性能优化 - 基础认知》、《前端性能优化 - 缓存 SDK》。2019 GMTC 大前端大会明星讲师，2019 GIAC 全球架构师大会分享嘉宾。《从零开始搭建前端监控》一书作者。