学习 ABTest 与灰度发布
蓝绿部署、A/B 测试以及灰度发布
A/B 测试与蓝绿部署的区别在于,A/B 测试目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论,并确信该结论在推广到全部流量可信;蓝绿部署的目的是安全稳定地发布新版本应用,并在必要时回滚。
A/B 测试和蓝绿部署可以同时使用。
怎样才是真正的灰度发布?
- 灰度系统要做的事情其实就是流量控制和数据收集,来控制风险并帮助产品做决策
- 主要有从运维和产品两大方面的考量因素
- 从运维的角度讲,任何一次上线都是有风险的,或者有一些步骤的遗漏,流程的不规范,或者有一些隐藏的代码 bug 都会导致线上的不稳定。
- 从产品的角度讲,有一些产品设计,交互,界面展现形式都不是坐在办公室里拍桌子就可以定出最佳实践的。
- 系统要求
- 精确的流量分发控制
- 监控系统的支撑
- 灵活的发布系统
五十度灰之石墨
- 使用
「Cookie」
让部分小部分用户体验到新的产品功能,根据反馈逐步灰度至全量。 - 根据特定的
「用户 ID」
或「用户组 ID」
进行产品新功能的灰度,根据反馈逐步灰度至全量。 - 对
同一功能的某一部分
进行后端服务的灰度,根据反馈逐步灰度至全量。 - 对服务进程进行灰度部署,根据反馈逐步灰度至全量。使用先
「双写」
数据,然后「迁移」
旧的数据,再进行「服务灰度」
的方式,根据反馈逐步灰度至全量。
浅谈分桶测试
- 分桶方式
- 基于用户的分桶(User-based bucket):这样的桶,是一个随机选定用户的集合。一种简单的方式是,使用一个 hash 函数,为每个 user id 生成一个 hash 值,选择一个特定的范围指向一个桶。例如:Ron Rivest 设计的 md5。
- 基于请求的分桶(Request-based bucket):这样的桶,是一个随机选择的请求的集合。常用的做法是,为每个请求生成一个随机数,然后将对应指定范围的请求随机数指定到某个桶内。注意,在这样的桶中,在实验期间,同一个用户不同的访问,有可能属于不同的分桶。
- 对于不同的测试,最好使用独立的各不相同的 hash 函数,以保持正交性
携程机票的 ABTest 实践
- 试想一下如果没有 ABTest,那新项目上线后的收益如何排除季节因素、市场环境因素的影响,而且一个页面上如果同时做多处改动,如何评判是哪个改动造成的收益或损失?这对一个理性思维的人是不可接受的。
- 实验正交性:AA 与 AB
你所应该知道的 A/B 测试基础
- 按用户(流量)划分控制组和实验组
- 按页面划分控制组和实验组
关于AB测试那些事儿
- 规避样本量不足
- 试验设计时预估进入试验的样本量,做分流规划时避免分配给测试集的样本量过少
- 除了进行 AB 测试外增加关于数据有效性考量的 AA 测试,将原始版本的流量中分出两个和测试版本相同的流量也进入测试
- 如果参与测试新版本已经分配了很大的流量比例,但是仍然存在样本量不足的情况,这时就只能通过拉长试验时间的方式来累积足够的样本量进行比较了
- 试验分层
关于 A/B 测试,这里有你想知道的一切
移动 App A/B 测试中的5种常见错误
以上。