我开源了一个 A/B 实验、功能发布管理平台项目

[FeatureProbe]

A/B 实验、以功能粒度发布的管理平台

主要使用场景如下：

1. 『功能粒度』灰度发布: 每个功能独立灰度发布给用户。可迅速关闭受 BUG 影响的功能，同时不影响其他正常功能的使用。

2. 降低测试环境搭建成本: 节约测试环境搭建和线下测试时间成本。利用线上环境小流量测试，环境真实同时影响可控。

3. 降低故障恢复时间:故障发生时通过降级策略调整服务行为，保障用户主路径不受影响。

4. 简化研发协同方式: 用功能开关替代传统分支开发的团队协同模式。真正实现主干开发、持续部署。减少分支合并冲突，显著加快迭代速度。

5. 统一的配置管理中心: 通过用户友好的操作页面，统一操作线上配置，实时修改功能参数，让运营活动生效更简单。

GitHub 地址： https://github.com/FeatureProbe/FeatureProbe

文档地址： http://docs.featureprobe.io

体验环境地址： https://featureprobe.io/

欢迎 star 和提 issue/pr,如果能得到大家小小的鼓励和认可，是我的荣幸!

[ryan4yin]

看着不错，企业会比较需要这种

[FeatureProbe]

@ryan4yin 欢迎使用，如有任何建议或问题的话，可以提 issue/pr ，也可以找我哦。

[gangbinfo123]

感觉发现了新大陆，使用一段时间，上线风险降低好多啊

[shibo501c]

紧急情况关闭一些功能还挺好用，配置系统还是太偏向研发人员了，这种平台其他角色也可以用，国外还有 launchdarkly, growthbook 什么的，国内少一点

[millken]

带侵入的方案企业一般不敢用，A/B testing 大多数 gateway 已经支持了，当然你这个属于定制行非常强，在非常熟悉 SDK 的情况下且有复杂场景需求的可以考虑使用。

[shibo501c]

@millken 是的，后端其实方案比较多，主要还是移动端要发版，上应用商店，能够快速关闭个功能，还是挺有用的

[gohaian]

体验了，非常不错，期待开源更多功能。

[lessMonologue]

DIDI 的 apollo ？

[FeatureProbe]

@gohaian 这周上线了指标分析功能，欢迎使用，有任何问题和建议欢迎提 issue

[zhaoyta]

携程的 apollo ？

[dnsjia]

https://github.com/dnsjia/luban

[FeatureProbe]

@zhaoyta 携程的 apollo 是配置中心，FeatureProbe 主要是功能粒度去管理和发布功能，之前写了一篇文章讲了二者的区别，有兴趣可以看一下 https://juejin.cn/post/7187598169730416701

[FeatureProbe]

@lessMonologue 欢迎使用

[shibo501c]

@lessMonologue 难道是老橘子

[OpenSea]

呀，在 V 站看到了，之前提了不少 issue

[opentrade]

有米置顶

[99yuying]

文档写的很全面👍

[kingterrors]

看起来就很厉害，向大佬学习！

[jiangzm]

跟 DIDI 有个开源项目很像， 另外字体是不是有点小感觉不太协调。

[jiangzm]

@zhaoyta
@lessMonologue
@FeatureProbe
对的配置中心一般给开发人员用的，A/B 实验一般是产品基于用户画像来实验新功能的。

[daguozi]

小白看了非常感兴趣，想请教楼主对于 AB 测试如何做的 randomization? 在有 gradularity 时，如何确定用户 A 在 10%的 roll out 呢？每次 rollout 时，A 永远在 10%还是每次都不一样呢？

[shibo501c]

@daguozi 好像比较常见的做法是不同的 AB 实验，用不同的 salt 进行 hash ，也有提前分不同的 zone 的。10% 的 roll out 也分稳定的还是不稳定的，只要用户有唯一的 key ，hash 出来就可以是稳定的。

[daguozi]

@shibo501c 谢谢解释！我比较感兴趣的是 如果 10% rollout 然后 roll back 10%，再 rollout 10% 以后是否是稳定的。还没有仔细看 doc ，也许我说的是错的，但感觉看起来 hash 是根据 project 的 unique identifier 进行 salt 的？那只要是一个 project 下的 rollout ，就是稳定的。但如果 new 了一个 project ，那新的 project 下的 10%可能应该就是 reshuffle 了

[jiangzm]

@daguozi 是的，灰度流量不能总是让同一批人当小白鼠。用 user_id 加上 exp_no hash 算出流量区间，或者基于 session_id 来计算，这样能保证实验的独立性。

[shibo501c]

@daguozi 是的，所以如果是想让全新用户进组的话，有很多办法，比如可以让业务代码上记录下属性，FeatureProbe 目前支持用户代码传入一个 user 的属性，初始化时候，传入用户时候看过上一个版本，在 toggle 的规则中排除掉，比如过滤掉 user["feature_v1_viewed"] == true 的用户。

[daguozi]

@shibo501c @jiangzm 啊是这个是个好方法哈哈！有意思，感觉应该是灰度到了每个 variant 了。感觉是 project 下有 concurrent toggles ，然后 每个 toggle map 100% user base 。突然有这么个问题。。。如果有其中 toggle 里 1 ，2 ，3 三个 enum flag rollout 。rollout 20% 1 ，40% 2 ，40% 3. 那么 stable 情况下，第二次 rollout 30% 1 ，30% 2 ，40% 3. 那么这次 1 多出来的 10% 是从 2 拿的呢还是说 2 + 3 里拿的。。。想请教这里的顺序问题。。。

[shibo501c]

@daguozi 好问题，目前我们开源的版本是会出现 2 和 3 组都会有一部分用户进入组 1 ，是有方案做到只从 2 组拿用户出来的，但是实现要复杂一些。

比如目前是分 100 个桶，第一次按照流量分前 20 是组 1 ，中间 40 是组 2 ，最后 40 是组 3 ，调整后，找减少最多的组中多余桶，再进行 hash 分给增加的组，直到桶分完。

[shibo501c]

补充下，因为 3 组 40%没变，所以目前的一层 hash 实现只会从 2 组挪动 10%到 1 组。
如果是变成 30%，40%，30%，则会让 组 2 的一部分去组 1 ， 组 3 一部分去组 2 。
两层 hash 的话，可以只让 3 组的进入组 1 ，组 2 不动。

[daguozi]

@shibo501c 谢谢作者的解释，明白了，看来这种 edge case 应该不是 best practice 的 use case 。感觉 binary 的 flag rollout 就没有问题哈。

[szzadkk]

A/B 实验的话，应该还需要互斥组这个东西，做流量的复用和隔离

[FeatureProbe]

@szzadkk 赞，这个已经在我们的规划中了，每个 release note 都会发布在 github 上，欢迎关注

[wuchangming89]

不错，点个赞

[mikeying]

赞，已经开始用了，期待你们的上线更多的功能！

[TomVista]

这个帖子花了不少钱啊...

[yanzhiling2001]

@TomVista

原谅我粗浅，我没看懂楼主这个项目干什么的。这样应该算正常。

不过诡异的是 这个帖子没有什么热度，缺有 21 个赞，被顶在首页。

[shibo501c]

@yanzhiling2001 其实热度还可以，很多 V2EX 的朋友给我们点 star ，导致我们周末还短暂的在 github 的 trending 上待了两天。