文章背景

面向用户使用的产品，即使项目加入了埋点，某些用户描述的操作场景，也比较难确定实际情况。比如提示对话框，有些页面的数据权限是对话框的展现形式，用户这个时候操作了对话框，进行了页面跳转，是正常的业务逻辑。但是有些情况下，用户跟客服反馈问题时，会有表达上不清晰或者遗漏自己做过的操作等情况。

有些时候，因用户提供的信息不准确，研发在日志系统和埋点系统查找上报数据的时候，犹如大海捞针。为此，产品同事和研发同事共同做了多次操作优化。

但是用户提供信息不准确这种情况是无法完全避免，所以我开始思考别的解决方案。

逆向思维

做了一些正向思维的操作优化，发现还是有用户提出的问题，无法进行快速定位。虽然，已知的业务场景就那几个，但是在日志系统里，很难找到帮助支撑结论的数据。

等等，已知的业务场景，我既然知道了哪些业务场景，为什么不按照这个维度进行数据收集呢？我收集到数据，即使用户提供的信息是错误的，但是场景是真是发生的，我只有找到场景数据，反推用户信息，然后跟用户确实反推出来的信息，不就能解决问题了。

逆向思维，真是解决问题的「良方」之一。

功能设计

上报公共方法

上报方法里主要讲需要上报的数据整理成请求的入参，然后传入日志上报的接口中。

• apiMethod：接口请求方式，有GET和POST两种；
• params：操作场景的主要参数；
• httpApi：如果场景属于异步请求返回值场景，则上报它的api接口相对路径；
• res：如果场景属于异步请求返回值场景，则上报它的响应体；
• describe：场景描述，这个很重要，把用户方操作逻辑描述成文字，方便查询问题时，找到进行过的操作。

/**
   * 日志上报功能
   * @param {Object} data 上报数据
   * @return {void} 无
   */
apiLog(data) {
  // 接口请求方法
  const apiMethod = data.method ? data.method : 'GET';
  // 调用公共上报方法
  const reqData = {
    method: apiMethod, // 此接口请求方法
    params: data.params, // 入参
    url: data.httpApi, // api接口相对路径
  };
  // 调用上报接口
  reportApi(reqData, data.res, data.describe);
}

特定业务场景上报

以用户查看订单信息为例。

早上，叶一一刚进入办公室，就看到问题群里信息在闪烁。打开发现客服反馈了一个问题，用户说看不到订单记录。测试的同事正在帮忙筛查问题，测试的同事第一反应是，用户登录的账号不是之前下单的账号。但是用户比较坚持说确定了账号是下单的账号。

测试的同事用提供的账号确实查到了信息，但是研发的同事查登录日志没有查到信息。

此时叶一一打开业务日志的面板，开始筛选操作场景，然后根据用户操作时间，确实了一个大概的操作范围，成功找到几条数据中的账号，该账号和用户提供的信息只有结尾的数字不同。于是叶一一让测试的同事帮忙，让用户确认登录账号是否是家人的账号。果然用户检查了账号后发现登录错了账号。

订单数据为空的时候会上报一条业务数据。

// 日志上报
utils.apiLog({
  httpApi: '/api/order',
  params: {
    accountId: '111',
  },
  res: {
    userName: '张三',
    orderList: [],
  },
  describe: '当前订单数据为空，可能原因：1、用户账号没有进行过下单操作，2、用户登录的不是下单账号。',
});

总结

依靠这个简单的有点简陋的功能，帮助解决了问题群里60%左右操作问题，大部分因为缺少关键操作描述或者描述信息不准确，而不好排查问题。

实际业务场景比举例中复杂很多，可以根据实际业务场景制定实现策略。

这个功能当时开发主要是为了用极少的开发成本，换取重复问题解决的人力成本，所以功能设计的比较简单。可以根据实际情况，在这个思维上尽情发挥。