这是一个创建于 999 天前的主题，其中的信息可能已经有所发展或是发生改变。
A/B 实验、以功能粒度发布的管理平台
主要使用场景如下：
1. 『功能粒度』灰度发布: 每个功能独立灰度发布给用户。可迅速关闭受 BUG 影响的功能，同时不影响其他正常功能的使用。
2. 降低测试环境搭建成本: 节约测试环境搭建和线下测试时间成本。利用线上环境小流量测试，环境真实同时影响可控。
3. 降低故障恢复时间:故障发生时通过降级策略调整服务行为，保障用户主路径不受影响。
4. 简化研发协同方式: 用功能开关替代传统分支开发的团队协同模式。真正实现主干开发、持续部署。减少分支合并冲突，显著加快迭代速度。
5. 统一的配置管理中心: 通过用户友好的操作页面，统一操作线上配置，实时修改功能参数，让运营活动生效更简单。
GitHub 地址： https://github.com/FeatureProbe/FeatureProbe
文档地址： http://docs.featureprobe.io
体验环境地址： https://featureprobe.io/
欢迎 star 和提 issue/pr,如果能得到大家小小的鼓励和认可，是我的荣幸!
 | 1 ryan4yin 2023-02-17 10:14:01 +08:00  1 看着不错，企业会比较需要这种 |
 | 2 FeatureProbe OP @ryan4yin 欢迎使用，如有任何建议或问题的话，可以提 issue/pr ，也可以找我哦。 |
 | 3 gangbinfo123 2023-02-17 11:56:04 +08:00 感觉发现了新大陆，使用一段时间，上线风险降低好多啊 |
 | 4 shibo501c 2023-02-17 11:58:01 +08:00 via Android 紧急情况关闭一些功能还挺好用，配置系统还是太偏向研发人员了，这种平台其他角色也可以用，国外还有 launchdarkly, growthbook 什么的，国内少一点 |
 | 5 millken 2023-02-17 12:38:27 +08:00 带侵入的方案企业一般不敢用，A/B testing 大多数 gateway 已经支持了，当然你这个属于定制行非常强，在非常熟悉 SDK 的情况下且有复杂场景需求的可以考虑使用。 |
 | 7 gohaian 2023-02-24 11:47:45 +08:00 体验了，非常不错，期待开源更多功能。 |
 | 8 lessMonologue 2023-03-01 17:23:49 +08:00 DIDI 的 apollo ？ |
| 9 FeatureProbe OP @gohaian 这周上线了指标分析功能，欢迎使用，有任何问题和建议欢迎提 issue |
 | 10 zhaoyta 2023-03-01 17:39:37 +08:00 携程的 apollo ？ |
 | 11 dnsjia 2023-03-01 18:17:21 +08:00 |
| 12 FeatureProbe OP @zhaoyta 携程的 apollo 是配置中心，FeatureProbe 主要是功能粒度去管理和发布功能，之前写了一篇文章讲了二者的区别，有兴趣可以看一下 https://juejin.cn/post/7187598169730416701 |
| 13 FeatureProbe OP @lessMonologue 欢迎使用 |
| 14 shibo501c 2023-03-02 11:34:46 +08:00 @lessMonologue 难道是老橘子 |
 | 15 OpenSea 2023-03-02 13:54:53 +08:00 呀，在 V 站看到了，之前提了不少 issue |
 | 16 opentrade 2023-03-02 13:55:28 +08:00 有米置顶 |
 | 17 99yuying 2023-03-02 14:19:32 +08:00 文档写的很全面 |
 | 18 kingterrors 2023-03-02 14:41:16 +08:00 看起来就很厉害，向大佬学习！ |
 | 19 jiangzm 2023-03-02 14:47:17 +08:00 跟 DIDI 有个开源项目很像， 另外字体是不是有点小感觉不太协调。 |
| /td> | 20 jiangzm 2023-03-02 15:00:13 +08:00 |
 | 21 daguozi 2023-03-02 15:33:53 +08:00 via iPhone 小白看了非常感兴趣，想请教楼主对于 AB 测试如何做的 randomization? 在有 gradularity 时，如何确定用户 A 在 10%的 roll out 呢？每次 rollout 时，A 永远在 10%还是每次都不一样呢？ |
| 22 shibo501c 2023-03-02 16:16:54 +08:00 2 @daguozi 好像比较常见的做法是不同的 AB 实验，用不同的 salt 进行 hash ，也有提前分不同的 zone 的。10% 的 roll out 也分稳定的还是不稳定的，只要用户有唯一的 key ，hash 出来就可以是稳定的。 |
| 23 daguozi 2023-03-02 16:53:32 +08:00 @shibo501c 谢谢解释！我比较感兴趣的是 如果 10% rollout 然后 roll back 10%，再 rollout 10% 以后是否是稳定的。还没有仔细看 doc ，也许我说的是错的，但感觉看起来 hash 是根据 project 的 unique identifier 进行 salt 的？那只要是一个 project 下的 rollout ，就是稳定的。但如果 new 了一个 project ，那新的 project 下的 10%可能应该就是 reshuffle 了 |
| 24 jiangzm 2023-03-02 17:09:41 +08:00 1 @daguozi 是的，灰度流量不能总是让同一批人当小白鼠。用 user_id 加上 exp_no hash 算出流量区间，或者基于 session_id 来计算，这样能保证实验的独立性。 |
| 25 shibo501c 2023-03-02 17:18:18 +08:00 1 @daguozi 是的，所以如果是想让全新用户进组的话，有很多办法，比如可以让业务代码上记录下属性，FeatureProbe 目前支持用户代码传入一个 user 的属性，初始化时候，传入用户时候看过上一个版本，在 toggle 的规则中排除掉，比如过滤掉 user["feature_v1_viewed"] == true 的用户。 |
| 26 daguozi 2023-03-02 18:06:07 +08:00 @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 里拿的。。。想请教这里的顺序问题。。。 |
| 27 shibo501c 2023-03-02 18:38:42 +08:00 @daguozi 好问题，目前我们开源的版本是会出现 2 和 3 组都会有一部分用户进入组 1 ，是有方案做到只从 2 组拿用户出来的，但是实现要复杂一些。 比如目前是分 100 个桶，第一次按照流量分前 20 是组 1 ，中间 40 是组 2 ，最后 40 是组 3 ，调整后，找减少最多的组中多余桶，再进行 hash 分给增加的组，直到桶分完。 |
| 28 shibo501c 2023-03-02 19:15:18 +08:00 1 补充下，因为 3 组 40%没变，所以目前的一层 hash 实现只会从 2 组挪动 10%到 1 组。 如果是变成 30%，40%，30%，则会让 组 2 的一部分去组 1 ， 组 3 一部分去组 2 。 两层 hash 的话，可以只让 3 组的进入组 1 ，组 2 不动。 |
| 29 daguozi 2023-03-02 19:22:26 +08:00 @shibo501c 谢谢作者的解释，明白了，看来这种 edge case 应该不是 best practice 的 use case 。感觉 binary 的 flag rollout 就没有问题哈。 |
 | 30 szzadkk 2023-03-03 10:59:52 +08:00 A/B 实验的话，应该还需要互斥组这个东西，做流量的复用和隔离 |
| 31 FeatureProbe OP @szzadkk 赞，这个已经在我们的规划中了，每个 release note 都会发布在 github 上，欢迎关注 |
 | 32 wuchangming89 2023-03-03 13:21:52 +08:00 不错，点个赞 |
 | 33 mikeying 2023-03-07 14:53:04 +08:00 1 赞，已经开始用了，期待你们的上线更多的功能！ |
 | 34 TomVista 2023-03-07 19:46:07 +08:00 这个帖子花了不少钱啊... |
 | 35 40EaE5uJO3Xt1VVa 2023-03-07 19:49:13 +08:00 |
| 36 shibo501c 2023-03-07 20:46:55 +08:00 @yanzhiling2001 其实热度还可以，很多 V2EX 的朋友给我们点 star ，导致我们周末还短暂的在 github 的 trending 上待了两天。 |
 | 37 mistygg 356 天前 大佬，gitee 的微信群二维码过期了，可以更新一下吗？ 另外，我尝试在一个 2 核 4G 的云服务器上 docker 部署，但是报错了，说内存不够，请问有办法解决吗？ |
Select Language