关于ab测试:基于-Feature-Flag-的下一代开发模式

面向疾速迭代，如何升高上线危险？字节跳动 DataTester 团队找到危险与迭代的平衡点——渐进式公布。

渐进式公布 (Progressive Delivery) 被认为是继续公布（Continous Delivery）的下一代状态，其专一于加强公布过程管制与升高公布危险，最终进步整体收益。国内科技巨头比方 Amazon、Google 和 Netflix 等公司每天通过渐进式公布的形式将数千次的性能更新、bug 修复等更新到用户环境。

疾速迭代的同时，防止不了引入一些预期之外的 bug。因而须要如何采纳适合的工具，在危险与收益之间找到一个很好的平衡点就显得尤为重要。目前继续公布（CD）可能通过一些用户数据、系统监控或者一些外围指标对部署的性能进行监控，当发现问题及时回滚，以此造成一个继续迭代闭环。然而当用户体量十分大的时候，一个小的问题可能会造成难以掂量的损失，这是不可承受的。

为了找到危险与迭代的平衡点，渐进式公布的形式慢慢被提出并且深受器重。

什么是渐进式公布

渐进式公布有两个特点：公布进度管制和公布阶段受权。

其中公布进度管制即按肯定的节奏将新的软件或者性能向用户推送，公布节奏能够是间断的也能够是分步骤的，以此管制每次失效的范畴。这种做法建设在继续交付的外围准则之上，行将“代码部署”与“性能公布”离开。

公布阶段受权是指在不同的阶段将性能的操作权限受权给不同的团队，比方将性能的所有权缓缓从工程转移到产品，而后从产品治理转移到营销等等。

公布进度管制和公布阶段受权并用，升高了继续交付相干的危险，并赋予团队在整个公布周期中更多的控制权。

继续公布与渐进式公布区别

继续集成与继续公布（CI/CD）中强调骨干分支的代码须要时刻放弃在可部署的状态，这须要一直地将 feature 开发分支与骨干分支进行合并，而不是期待一周甚至几周的工夫，待所有性能开发完并通过残缺的测试再合并到骨干分支。CI/CD 的目标就是为了放慢软件的开发与部署速度与效率，将新的性能尽快部署上线，同时尽可能升高危险。

尽管 CI/CD 可能减速软件与性能的交付速度，然而与之而来的危险并没有很好打消。当所有性能一次上线到生产环境后，如果蕴含比较严重的 bug 但不能及时发现，后果将很难意料。尽管 CI/CD 模型中的金丝雀公布（canary release）可能管制 bug 影响的范畴，然而须要依赖比较复杂的控制系统。因而目前大部分场景下的 CI/CD 零碎并不是严格意义上的继续集成与继续交付，大部分状况还是基于 feature 分支进行开发，而后在适合的机会合并到骨干分支一并进行上线。

而渐进式公布的形式将新的性能暗藏在一个 feature flag 中，并能够通过可视化界面对公布的过程进行灵便管制，这是渐进式公布与目前 CI/CD 状态的一个比拟要害的区别，其示意图。此外还有一键敞开、紧急失效参数、流量管制与监控等性能，当呈现问题时不须要重新部署代码，通过按键即可进行性能的回滚，进而尽可能减少故障时的影响范畴。能够说渐进式公布就是为解决公布问题、进步公布稳定性而生的公布理念。

那么渐进式公布有那么多的长处，想要独立开发一套控制系统又非常复杂，有没有简略易用的平台能够应用呢？答案是必定的，火山引擎 A/B 测试中 FeatureFlag 智能公布专一于打磨公布平台，并实现与 A/B 测试的全方位联动，将是一个不错的抉择。

FeatureFlag 智能公布平台是什么

Feature Flag 即 Feature Toggle，顾名思义其本质是一个暗藏在业务代码外面的一个管制逻辑。尽管看似简略的 if else 逻辑，但在公布畛域有着十分弱小的性能，能够实现生产环境中性能的动态控制而不须要要重新部署代码；此外还可能实现对失效流量、指标受众的灵便管制。

火山引擎 A / B 测试 FeatureFlag 性能基于先进的智能公布引擎和一站式配置托管平台，满足业务灰度发版、A/B 测试、定向差异化公布等不同利用场景。帮忙开发、产品、运维人员在低危险环境下迭代新 Feature、修复 bug，实现精益麻利开发。其外围指标在于保障利用迭代品质、助力精益开发效率、反对精细化业务场景与产品矩阵赋能。

如何基于 FeatureFlag 实现渐进式公布

一个好的平台想要做到易用肯定要在性能复杂性与交互简洁性之间寻找平衡点。因而为了升高应用门槛，目前 Feature Flag 性能的配置只须要四步即可实现所需参数的配置，上面将对配置过程简要介绍。

01 – 根本信息配置

根本信息中的必须参数有 Feature 名称、Feature 对应的 key（也即某个性能对应的开关）和端类型。其中服务端与客户端只有在集成的时候稍有差异，然而在平台上应用的时候操作统一。所以只须要简略填写几个必须参数，第一步就实现了。

何为变体呢？其实能够简略了解 Feature Key 用于标识性能，而变体的值即为 Feature Key 对应的值，对应到代码外面这个值就是管制 if else 逻辑的数据。目前 Feature Flag 反对四种类型的参数配置，能够按需应用。

公布受众顾名思义用来管制以后配置的失效范畴，其分为三个局部。受众白名单即为优先级最高的受众条件，如果为某个用户开明了白名单，那么该用户会优先失效变体对应的值。自定义受众规定则能够灵便依据用户属性进行指标受众的圈选，这些参数和用户上报的属性相干，比方截图中即为渠道为 app store 且浏览器为 chrome 的用户会失效变体 2。均不合乎以上条件的用户则会失效默认最终规定变体 1。

目前如果开明了 APM Insight 性能，那么是能够在监控指标这里抉择一些预约义的性能指标作为监控，能够依据公布状态实时监控当火线上用户的状况，呈现问题能够及时回滚。比方下图即为 JS 错误率的监控和聚合后的报警事件后果。

02 – 公布进度管制

为了实现渐进式公布中对公布进度的灵便管制，目前反对了手动公布、定时公布、主动下线、一键敞开、定向公布与随机公布等性能。现别离介绍如下。

手动增量公布

用户能够手动对以后的公布流量进行调节，进而实现对公布范畴的管制。

实用场景

• 新性能上线，须要审慎管制失效范畴与成果
• 性能的公布节奏无奈通过工夫管制

定时主动公布

定时主动公布中能够提前按工夫线设置流量的失效状况，到工夫后将会主动失效对特定流量范畴的用户失效。

实用场景

• 节日流动，须要在特定工夫失效相干配置

一键敞开

Feature Flag 可能帮忙用户在生产环境测试新的 feature 成果，并能够通过开关疾速的管制新 feature 的状态，以最大化的升高因新 feature 呈现问题对线上环境的影响。传统状况下，上线新性能后发现问题的批改往往须要对代码的批改与服务的重新部署，进而会导致服务在一段时间内不可用，而这个过程往往比开关的管制更为简单。该技术的背地是应用不同的逻辑分支，当 Feature Flag 开启的时候开启某些性能，反之敞开某些性能。

例如某个界面对一个看板进行了优化，那么能够通过配置 feature key 的形式，让一部分用户先体验新的看板性能，另一部分用户维持原样，这样一来能够依据线上成果判断这个性能对系统稳定性带来影响，也能够防止新看板存在的 bug 影响到整体的用户。在代码中你可能须要提前应用如下的代码：

if (isFeatureEnabled(‘new_dashboard’)) { // true or false ​
    showNewDashboard();                               ​} else { ​
    showExistingDashboard();                                        ​}                         

定向公布

定向公布即只对指定用户失效特定新性能。Feature flag 能够通过用户分群或主动以指标受众的形式，管制新性能只对小范畴用户失效。

例如，新上线的看板只对开明渠道为 app store 的用户失效。其代码如下：

if (isFeatureEnabled(‘channel’，’app store‘)) { // true or false 
    showNewDashboard();} else {showExistingDashboard();                                        
}       

实用场景

• 比方某些用户曾经是老粉了，而且偏向于尽早体验到产品的新性能，那么能够据此创立内测用户分群，新性能优先向这些用户推送。内测用户往往可能尽早为新性能提供反馈，进而及时做出性能调整。
• 国际化公司，在不同国家上线性能，能够通过国家圈选不同用户，进而为不同区域定制性能开发。
• 新的性能能够应用收费用户进行测试，查看性能的成果。

随机公布

随机公布即从线上所有用户抽取一部分流量做验证，如下图所示。

实用场景

• 新性能逐渐上线，较指定日期全量上线，大大减小危险，即便出问题也只会影响一小部分用户，可能及时回滚。

危险较大的变更上线（例如基础设施迁徙，数据迁徙，大型重构或基础架构更改），根本不会对您的产品或业务产生负面影响。

提前裸露性能等问题，通过一部分流量的数据能够预测将来服务性能的变动，而不至于新性能的上线导致服务不可用。

03 – 公布阶段受权

公布阶段性受权是渐进式公布的另一个特点，那么 FeatureFlag 中同样也是反对的。具体的公布阶段受权次要包含两局部：权限治理和工作流程治理。

权限治理

联合账号体系，能够对每个 feature 按角色和用户设置权限。如果一个 feature 还在测试晚期那么能够只为角色为研发的用户开明权限，以此类推。缓缓的将权限的管制移交给售前或者经营，实现性能上线与失效的拆散。

工作流程治理

工作流程治理能够对公布过程进行管制，在不同的公布阶段能够引入不同的角色或者用户进行审核，灵便调整每个公布阶段的受权范畴，确保公布过程的可控性。

FeatureFlag 智能公布有哪些利用场景

FeatureFlag 的利用场景十分多，基于其提供的渐进式公布能力，能够减速产品迭代过程，晋升服务稳定性。上面从几个方面介绍下常见的利用场景。

01 – 新性能灰度公布

新性能发版可逐渐灰度扩量，先让小局部用户体验新性能，察看用户反馈和数据体现，再初步扩量，潜藏问题及时发现疾速止损，如下图所示。

• Step1 白名单测试 + 内测 + 众测
  新性能上线前，先用白名单测试，并让外部用户和内部众测用户参加验证运行一段时间保障稳定性。
• Step2 公布审核内测通过后，邀请组内其他人参加 Review，通过后再进行后续的灰度。
• Step3 流量灰度 + 增量公布
  优先选择 1% 小流量，没问题逐渐调整流量比例，灰度放量。在小流量过程发现了问题，咱们及时回滚了配置，让旧版本配置失效。修复后再逐渐放量新版本。
  
  

02 – FeatureFlag 与 A/B 测试买通

与 A/B 测试买通是火山引擎 FeatureFlag 性能的一大特色，两者的珠联璧合将会大大放慢产品的迭代速度与效率。具体场景可分为以下三个局部：

• A/B 试验产生优胜版本后，可间接将试验固化为 feature，实现 A/B 试验的疾速全量，并可采纳灰度公布更加持重全量。
• 在 FeatureFlag 智能公布创立 feature 后，可间接由 feature 开启 A/B 试验，快捷实现试验的开启和后续的治理。
• A/B 试验的参数可固化为 feature，放在 FeatureFlag 智能公布对立治理，产品可全局查看 feature 版本与试验的关系。

那么 A/B 测试与 FeatureFlag 两者间能够互相转化，他们之间的关系是怎么样的以及应用场景应该如何抉择？

A/B 测试是成果测试（个别用来验证某个想法是否合乎预期），同一时间有多个版本性能对外提供服务，这些性能都是通过足够测试，达到了上线规范的服务，有差别然而没有新旧之分。它关注的是不同版本性能的实际效果，比如说转化率、留存等。其目标是为了验证产品的迭代方向是否正确。

Feature Flag 强调的是公布策略，指标是确保新上线的零碎稳固，关注的是新零碎的 BUG、性能隐患及稳定性，强调在公布过程中可能较早发现问题的存在。

Feature Flag 与 A/B 测试的抉择流程能够参考下图。

03 – 异样监控智能告警

目前 FeatureFlag 智能公布曾经和 APM 利用性能监控买通，可实现从利用—>Feature—>Flag 级别的监控。当某个监听的技术指标出现异常时主动触发报警，疾速发现线上异样问题。后续对服务端技术指标的反对。

• 指标灵便组合，让监控更加便捷。
• 报警事件聚合，让监控更加欠缺
• 有效性验证 +ACK，让监控更无效。
  

04 – 千人千面 - 人群差异化公布

基于 FeatureFlag 中灵便的自定义指标受众条件，能够实现不同用户下发不同的配置参数，真正实现千人千面，灵便公布。

1. 能够依据不同人群特点展现性能，比方安卓用户举荐 QQ 登录，IOS 用户举荐微信登录，晋升不同人群的个性化体验。
2. 经营流动时，可针对不同地区、人群采纳差异化的经营策略，实现细分人群的精细化经营。
3. 自定义指标受众参数，满足业务定制化的定向公布需要。
   

05 – 加强继续集成与继续部署能力

CI/CD 使得开发者能够疾速开发、迭代与公布新性能。继续部署(合乎企业软件实际，它是欠缺继续集成准则的天然演变。但继续集成与部署案例却十分常见，其中起因可能是须要简单的治理以及放心部署失败而影响零碎的可用性。

目前在开发过程中，开发者会从 develop 分支 checkout 新的分支进来开发本人的新性能，在充沛测试实现后再合并到骨干分支，这样骨干分支可能保障在任意时刻都是能够上线的状态。然而这种开发方式存在一些问题，比方分支分进来工夫越长往往代码合并难度越大。一旦代码库中存在了分支，也就不再是真正的继续集成了。当然你能够给每个分支建设一个对应的 CI，但它只能测试以后分支的正确性。如果在一个分支中批改了函数性能，然而在另一个分支还是依照原来的假如在应用，在合并的时候会引入 bug，须要大量的工夫来修复这些 bug。

而基于 Feature Flag 的 CI 过程则如下图所示。开发实现的代码能够在任意时刻合到骨干分支中，并通过 Feature Flag 开关管制未开发实现的性能对用户不可见；新的个性能够提前上线，产品或者经营等角色可通过开关管制何时与什么范畴失效新的 Feature；对线上问题的修复，能够通过管制公布范畴，应用线上流量进行验证。

1. 进一步放慢 CI/CD 过程，骨干分支随时能够部署，进步迭代效率。
2. 性能上线与代码部署的拆散，通过 flag 将新性能暗藏，一方面不便线上小流量测试，另一方面产品或者经营能够按需开启性能，不须要再问研发要排期，进步合作效率。
   

总结

继续公布在古代软件公司的倒退过程中施展了比拟重要的作用，然而继续公布时不减少必要的管制是十分危险的。渐进式公布形式在整个公布过程中退出了足够的管制，并且交融了公布阶段受权，能够大大降低继续部署时可能导致的问题。

FeatureFlag 智能公布可能更加不便帮忙用户实现渐进式公布，并缩小产品迭代过程中引入的问题和上线危险，最终在升高危险的前提下进步迭代速度。疾速迭代、保障平安和实时控制，这就是火山引擎 A/B 测试的 FeatureFlag 智能公布性能。

** 性能体验传送门：火山引擎 FeatureFlag

** 理解更多请戳：火山引擎 Feature 智能公布帮忙核心

火山引擎 A/B 测试

A/B 测试，解脱猜想，用迷信的试验掂量决策收益，打造更好的产品，让业务的每一步都通往增长。

以后，火山引擎首度公布增长助推「火种打算」，火山引擎 A/B 测试作为「火种打算」产品之一，将为您收费提 2 亿事件量和 5 万 MAU，以及高达 12 个月的使用权。体验传送门

欢送关注 “字节跳动数据平台” 同名公众号