1. 前言
作为一名自信的 QA,对于测试通过的项目,如果有人反馈有问题,脑海中的第一反应一定就是:不可能!一定是操作有问题。入职以来经手大大小小的项目也有 40 多个,一直没出过问题,也让我在年度的总结上自信地写到:所有项目按时按质发版,未出现线上问题。
但是,这种自信让我掉以轻心,使得微信小程序 SDK 的第一个线上问题也随之而来了。
对于线上问题,可能很多人都以为把问题解决了就完事了,并不重视对问题的复盘。事实上,复盘的作用可能远大于解决问题本身。
在神策的企业文化中重要的一项就是复盘,每一个问题对于我们来说都是一笔宝贵的财富。通过对于问题的复盘,总结经验教训,能够更好地促进我们成长。
下面我们来看下对于这个问题是如何进行复盘的。
2. 回顾目标
神策微信小程序 SDK 的目标是实现对于主流小程序开发框架的全埋点功能。但是,在测试过程中发现由于 Taro3.0 框架重新定义了标签点击行为的逻辑,使得一次点击行为会触发 SDK 的两次点击事件 $MPClick,造成了埋点数据重复。
因此,这次发布的 v1.14.3 版本旨在解决 Taro3.0 框架下点击事件重复触发的问题,实现神策微信小程序 SDK 真正意义上的无框架障碍全埋点采集。
3. 评估结果
3.1. 符合目标
- 解决了 Taro3.0 框架下点击事件重复触发的问题;
- 实现了神策微信小程序 SDK 真正意义上的无框架障碍全埋点采集。
3.2. 低于目标
- 本次发布的版本存在严重的线上问题。
4. 分析原因
4.1. 回顾过程
- 2020 年 12 月 17 日 19 : 05 微信小程序 SDK 发布了 v1.14.3 版本,新增了 $MPClick 事件可自定义属性,修复了 Taro3.0 框架下点击事件重复触发的问题;
- 2020 年 12 月 18 日 16 : 27 技术顾问收到客户反馈:微信小程序 SDK 更新到 v1.14.3 版本后,测试过程中发现 SDK 篡改了他们方法的返回值,属于破坏型 proxy;
- 2020 年 12 月 18 日 16 : 30 技术顾问查看代码发现这个问题以前在支付宝小程序出现过,并和 QA 一起复现了问题;
- 2020 年 12 月 18 日 16 : 35 问题同步给研发和 QA 组长,并分配下一步具体工作:QA 去 GitHub 上删除对应版本代码,研发组长协助删除 npm 上的版本,研发开始修复问题;
- 2020 年 12 月 18 日 16 : 37 研发组长和 QA 完成版本删除;
- 2020 年 12 月 18 日 16 : 45 研发修复完成,交由 QA 测试;
- 2020 年 12 月 18 日 18 : 05 QA 测试完成,并发布了最新的修复版本 v1.14.4,完成了线上验证;
- 2020 年 12 月 19 日 11 : 31 技术顾问组长找出了所有使用问题版本 v1.14.3 的客户并同步给技术顾问;
- 2020 年 12 月 19 日 15 : 00 技术顾问通知了所有使用 v1.14.3 的客户,告知他们存在的问题并提醒他们更新版本。
整个问题的生命周期从 2020 年 12 月 17 日 19 : 05 发版,到 2020 年 12 月 19 日 15 : 00 所有客户通知完成,总共历时 44 个小时。可以分为如图 4-1 中的 6 个阶段:
图 4-1 线上问题生命周期
这次问题是我经历的第一个线上问题,这次经历不仅让我完整了解到线上问题的处理流程,更让我充分地感受到各个环节上团队人员的密切配合。从问题开始到问题解决,小程序团队全员时刻处于待命状态,每个环节都争分夺秒,确保了此次问题的快速修复,没有造成较大的影响。
回顾线上问题的整个过程之后,我们需要分析产生这个问题的具体原因。
4.2. 原因分析
4.2.1. 自动采集点击事件
在进行具体的原因分析之前,我们先来看下神策微信小程序 SDK 自动采集点击事件的原理。
1、在重写 Page 函数时,先通过 _.getMethods 获取除 Page 钩子以外的自定义事件处理函数集合 methods:
Page = function