ABTest 平台设计 - 灰度发布和早鸟用户

上篇《ABTest 平台设计 - 实验开关和分组信息传递》简单介绍了 ABTest 实验开关和数据收集的一些实现,从流量划分、到实验开关、到数据收集,基本实现了 ABTest 的主要功能。下面则扩展谈一下 ABTest 的衍生功能:

基于 ABTest 的灰度发布

与 ABTest 一样,灰度发布也是圈出来一部分流量进行新功能的线上验证,验证基本能力没有问题之后再逐渐扩大覆盖面,支持扩展到全流量。

灰度发布本身也有很多种机制,例如最常用的:上线时先上单副本,再扩展到多副本,再扩展到单机房,再扩展到其它机房。这种方式非常自然,逐步扩量观察保证了服务稳定性。

但这样在上线的中间过程中,总不可避免地会出现一些用户体验问题。比如用户相邻的多次刷新请求被路由到版本不同的副本上,导致请求结果的跳变

既然 ABTest 同样具备划分流量的能力,而且这种划分对于单个用户来说是稳定的,其实在很多情况下可以利用 ABTest 能力来实现灰度发布。

但基于 ABTest 的灰度发布,要求在架构上提供一些支持

比如要发布新版本的网站静态文件(css/js 等),可以全量发布多个版本,然后通过 ABTest 圈定部分用户路由到新版本的静态文件,其余则路由到原版本的静态文件。

比如要发布新版本的服务程序,可以用新的 Docker 部署新版本程序,通过 ABTest 圈定部分用户请求路由到新的 Docker 上,其余则路由到线上的 Docker 上。

基于 ABTest 的灰度发布,很多情况下可以简化服务的部署和回滚操作,也保证了用户在灰度上线期间的体验稳定性。

服务好早鸟用户

在很多时候,企业的内外部总存在着一些早鸟用户,他们对灰度 / AB 新功能有着非常迫切的需求。

最典型的早鸟用户,就是公司的老板。当你开发了一个新功能,向上汇报了一下这功能多好多好。老板会问:

“为什么我没有看到这个新功能?”

你可能不得不解释说:

“老板你的 ID 没有被随机分到实验组里。”,

或者:

“老板这个功能只上了广州机房,北京访问不了。”

还有一种早鸟用户,是产品经理、测试人员,甚至可能包括提交 BUG 的外部用户。他们需要去回归新功能的线上效果是否达到预期,而且甚至他们需要一直不停地在不同的 AB 分支上切来切去比较效果。

这时候就需要一种灵活的机制,让这些早鸟用户有办法切换 AB 功能。

很多人最直接想到的方法,是在随机分桶之外搞一个 ID 分桶,收集上来早鸟用户的 ID,手动配置实验分组。这能在一定程度上解决问题,但设想这样的场景:

“老板,把你 UserID 发来一下,我给你配一下小流量实验。”

老板心里肯定在嘀咕,我要给了你 UserID,岂不是我看过啥发过啥你都能查出来了?这以后还能有隐私么?

而且配置 ID 的方式会增加运维的工作量,尤其是用户需要切来切去的时候。所以这时候不如提供一些强制命中灰度 / AB 的后门功能,能够大幅度降低沟通和维护的复杂度。

这种给早鸟用户的后门可以有很多种做法:

写 Cookie 机制。提供一个特殊的 URL,访问该 URL 就会种下一个强制命中的实验分组 Cookie,此后带着这个分组 Cookie 的访问都会中这个实验。这种适用于 WEB 端产品。APP 端使用的话,需要做一些 Cookie 同步工作。

配置注入机制。提供一个二维码,二维码内容是一段特殊的代码,APP 扫描到该二维码,就会被注入实验分组配置。这种适用于 APP 端产品。

隐藏功能机制。在某些内容上连续点 N 下,就会弹出一个配置面板,可以用来查看和调整当前所中的实验分组。

ABTest 平台如果能够提供这样的后门机制,将会大大方便与早鸟用户的沟通和合作。

下篇,我们聊一下流量分布问题。

《ABTest 平台设计 - 灰度发布和早鸟用户》上有3条评论

  1. > 例如最常用的:上线时先上单副本,再扩展到多副本,再扩展到单机房,再扩展到其它机房。这种方式非常自然,逐步扩量观察保证了服务稳定性。

    这就是滚动发布了。

    > 比如要发布新版本的服务程序,可以用新的 Docker 部署新版本程序,通过 ABTest 圈定部分用户请求路由到新的 Docker 上,其余则路由到线上的 Docker 上。

    上一篇提到,很多ABTesting逻辑是耦合在业务代码中的,如果一个试验多个实验组A B C D...,从源码管理角度来说,我们是每个试验逻辑单独创建一个代码分支,分支单独部署、网关路由的方式来做test呢,还是都包含在master里,有业务代码自行判断执行路径(if tagA elseif tagB else ... )更好呢?

    1. 理论上来讲,路由的方式更理想。单独分支部署是一种手段,也可以有其他手段,比如还是大包部署,但是由配置控制功能开关。具体选哪种方式,还是看基础设施的完善程度。比如本来团队的运维自动化程度和服务管理方式就很先进,可以选择顶层路由的方式;如果本来团队规模小,资源也少,那可能从配置控制代码分支的方式更好。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注