基于用户行为的实时问题定位系统
背景介绍
警察破案，讲究重塑案发现场。与此类似，线上客户问题排查，我们也希望能重现问题过程，快速定位问题。但是实操过程需要反复和用户沟通，获取用户的账号，方案等数据，以及他的操作过程，我们再尝试重现，所以问题排查成本和沟通成本很高，能复现还好，有些还无法复现！这个时候，就特别想，要是能有多啦A梦的时光机多好, 通过时光机，回到用户问题发生前，现场查看用户的操作和数据，亲眼见证问题的整个过程以及数据，定位问题！可是我们没有多啦A梦，没有时光机！
现状分析
那我们是不是真的只能纯粹依靠客户的反馈，通过反馈进行问题的进一步跟踪定位呢？当然不是。我们知道用户的很多前台操作都会落下数据痕迹，埋点数据，监控上报数据，前后端请求数据，后端hunter调用链数据等等，只是这些数据由不同系统根据不同目的收集、存储、分析。
如下图，给出了我们现有的各类埋点，以及数据收集方式，及当前使用的业务场景：
从上表可以看到，我们其实已经有大量的数据在不断收集，但是因为分散，所以看不到整体。如果我们可以再次将分散的数据进行重塑，将用户操作，数据，时间，三者关联起来，立体，多维的方式重现用户在特定时间上的操作行为和行为背后具体的数据过程。有了这个时间轴上的用户行为及行为数据，我们是不是就可以大体知道了用户在什么时间点做了什么操作，操作哪些数据数据，帮助我们根据具体的数据进行问题的排查了呢？
解决方案
通过上面的问题分析，以及现有数据的梳理，我们也就有了对应的解决方案：
- 通过对埋点数据、前端拦截数据，进行时序串联，给出用户的完整操作路径，方便问题的复现步骤
- 将用户的后端埋点与后端请求打通，明确用户操作数据内容和后端服务调用信息，方便问题排查
基于以上的问题分析过程和解决方案，联合监控团队，大数据团队，以及拉上定制，业务团队一起搭建了用户行为回溯平台。在用户回溯行为平台，只需要将有问题的方案或者用户id输入，再指定查询时间，系统就会查询出用户在特定时间范围内做的一系列操作，包括用户的所有的键鼠行为、前端埋点详细数据、前端监控相关详细数据等等，方便问题定位。
实际效果验证
案例1：有个客户工单“ctrl-z撤销一次，客餐厅的吊顶丢失了” ，技术支持同学排查发现有些账号正常，有些账号有问题，但是在线上白名单里面没发现异常，不知道问题出现在哪里。
通过平台排查实践：利用这个平台查询，发现有问题的用户所在前端插件的版本和正常的用户所在的前端插件版本version是不同的，进一步确认有问题的账号在单独的分支，该分支没有把已经修复bug的代码合进去。
案例2：有个工单“ctrl-z撤销一次，客餐厅的吊顶丢失了，用户回忆说不记得是不是自己删除了，反正就是没了现在” 。
通过平台排查实践：在平台上输入用户信息，方案信息，相关时间，在整个操作时序上，查看了用户的前端埋点数据，发现用户有删除灯具这个动作的埋点上报数据埋点信息，由此可以知道灯具丢了的原因就是因为用户真实操作了删除这个动作。
由上面两个真实排查案例过程可以非常清晰的看到，通过用户回溯行为平台，可以非常快速回溯用户的操作以及操作的数据，大大提升问题的排查效率。
写在最后
通过这个平台的搭建，我们其实是做了一次底层能力的拉通，将监控，大数据不同团队的能力进行了打通，由这些底层团队提供能力基础。但是纯粹这两个团队就够了吗，答案是，不够。底层团队提供技术能力，提供数据，搭建平台，但是这个平台利用的好不好，或者好不好用非常依赖上游的具体的业务同学。比如系统核心的数据，埋点是由各个业务团队去根据实际业务场景去丰富，去梳理，去标注的，并且这是一个长期的不断进行的过程。所以在项目启动之初，我们就将业务同学一起加入平台的共建。
- 监控团队，提供前端监控数据，结合大数据提供的实时埋点数据，负责整个产品的数据整合，及整个产品上层功能的搭建。在开发和上线过程中，还负责用户侧的运营，技术问题解答，是整个产品的核心技术担当和运营客服。
- 大数据团队，提供前端埋点实时数据流，梳理、新增LMS属性，开放LMS的所有元数据信息，提供底层数据能力给到监控，是整个产品的重要数据基础之一。
- 硬装&定制团队，从项目初期提供项目的需求场景，到中后期配合项目试点，做了大量埋点数据基础建设工作，包括埋点行为的业务梳理、埋点丰富度扩充 和 各维度打标等。是整个项目的重要业务合作及业务数据提供方和试用方。
- 技术支持团队，是系统的重点服务对象，一起帮我们做系统功能验证，利用实际案例进行排查试用，实际的排查成果（效率提升）也是对这个系统的有效性得到了初步验证。
正是多方共创，各司其职，才能让平台提供更强大的能力，真正为我们线上问题排查提效！
推荐阅读
公众号：酷家乐技术质量 知乎：酷家乐技术质量
TesterHome：kujiale-qa (酷家乐质量效能)