字节跳动内部有着非常浓厚的数据文化和实验文化，数据中台已经成为研发流程中的新基建， A/B测试也基本上是整个研发链路上的必经一环。 那么如何将数据驱动有效应用在研发体系中呢？
本文基于字节的多年实践从“研发流程中无处不在的数据驱动”、“如何建立可持续的数据驱动文化”、“数据驱动的ROI”三个方面，剖析构建数据驱动的新型研发体系， 充分展现A/B测试如何“嵌入”技术研发的流程及其效果。
作者：韩云飞
字节跳动在整个研发流程中，数据驱动无处不在。首先，以火山引擎的AB测试为例，探究研发流程中数据驱动。
火山引擎A/B测试，由来已久。包括抖音、今日头条的名字都做过A/B测试，平台自建立之初至今，已经承载着500+业务线、150W+实验总量的能力，日新增实验2000+，同时运行试验3W+。
AB测试，究竟是怎样支撑这样海量的实验和这么多的并行度的呢？
首先在数据层是有SDK来采集端上的埋点和服务端的埋点，还包括用户进组的信息。在数据集成上，会有大量用户业务的数据和第三方的数据，内部通过数据集成的能力把它进入到系统中。
在功能层，它又分成几个模块。 首先是从整个实验的设计、实验的配置、调试、数据报告，包括这种出结论，以及上线发布，这些都归由实验管控的模块来负责。
做实验最重要的是要来评估报告，所以内部在实验报告里面提供了包括执行度的检验、统计的分布，包括实验数据的趋势，还有一些指标的配置。除此之外，还配套了一些比较好用的工具，包括比如说实验受众管理，因为内部做实验其实有时候会针对于特定的用户群体，比如新用户，某个城市的用户，甚至于有一些用户的画像。
在接入层提供了SDK以及分流，来给各种业务系统包括会话层的服务端、客户端，还有一些to B的其他的小程序做一些对接。
在应用层，这里提供了面向不同行业的解决方案，包括在泛互联网，这里泛互联网分得更细，包括有内容、电商、社交、工具等等。其次金融行业其实包括银行、证券、保险，也都会用到这样的能力。最后是大消费行业，比如包括家电、客户、汽车行业等等。
接下来，将会和大家探讨研发流程中要怎么使用数据驱动。
开发新功能的正确姿势是什么?
假设PM提了一个需求，如果要给抖音增加一个“熟人tab”，如果在数据驱动情况下，我们是怎么做这件事呢？
我们在产品评审的环节之后，会增加两个东西，一个叫做埋点的设计，一个叫做AB方案的设计。其实从前面开始，PRD的方案开始，就可以猜出来，它可能是提供了不只一种方案。tab，到底是加在顶部，还是加在底部？策略到底应该是什么样的？这是一个不确定的事。
草率的决定可能会对整个抖音大的生态有很大的影响。所以其实是需要来试验，先小规模、小流量的来试验。
所以可能就有这样一个方案。
比如有了V1组和V2组，把熟人tab加了进去。这时候通过验证各自的流程时长等指标得到最终的实验结论，发现V2组是比较好的，对社交价值有更为显著的提升，就把这个方案全量上线。
怎样才能做好一次复杂系统 重构 ?
今日头条是一个通用信息平台。头条早期的信息流服务是用一个Python的单体服务。随着业务发展迅猛，流量在爆发式增长，业务工程上的复杂度也在急剧升高。为了更好地长期支撑业务发展，信息流同学做了一次大规模的服务化重构：
语言选型从Python切换到了golang，从单体服务架构演变成了分层的微服务架构。以往大家做重构时更多关注质量、性能等技术上的指标，以为这样就够了，其实是对用户体验和业务目标的忽视。这样一次大规模重构，设计实现并没有太久，但需要保障重构的信息流服务在各种业务指标上是不能有损的，这就花了大半年的实验去做AB测试，通过几十次AB测试不断的灰度，分析业务指标影响，最终在大部分全局指标几乎没有影响，甚至有些关键指标正向的情况下完成了这个复杂系统大规模重构上线。
Bug fix 难道不是应该修复完就上线?
这是一个直播的场景，在一个精排的模型里用到了抖音的Universal Embedding，用到了一些特征，内部在召回阶段也用一下这些特征，能够让召回的模型学习到更多信息，提前做一些召回符合用户兴趣的一些内容，保持召回和精排在一致性的情况下，能够提升一些指标。
这个想法很好，但是由于配置的问题，导致文章的一些内容特征获取是失败的，这个功能没有成功上线。现在对这个功能做了fix，那是不是fix完就能直接上线呢？其实是未必的。这个bug它很隐蔽，它不会造成用户很明显的感知，但是用户的系统跟用户设想的是不一致的。所以团队还是采用了AB测试。
方法是分了新用户、老用户分别去测，发现对于新用户其实是没有什么实质性的影响，指标就是在波动。这是可以理解的，新用户可能本身就没有太多的特征可以用。对于老用户实验，团队发现在他的人均的展现上和人均的阅读上，都有0.3%左右的显著提高。这个数字可能不高，但是对于抖音的体量，提升这么多，其实已经是非常大的了。
上线发布如何更安全丝滑?
下面是上线发布的例子，在整个微服务中，上游服务对下游服务的调用过程中，很多流量直接打到各个机器上。在一些场景上，这么做会有一些问题。比如说新模型上线，模型需要机器来承载，在测试阶段的流量显然是远远不及真实上线时那么大。那么上线时能不能让流量直接打过来，以及上线过程中重启机器等等是否会带来一些不太好的影响，这都是需要做AB测试的。
所以团队针对于上线场景，把AB的能力开放给基础架构部门。首先根据预先的配置对目标服务进行切分，切分成不同的集群，比如说里面有AB的集群，还有基线版本的集群。集群切分之后，会调平台的OpenAPI来开启实验，实验里面配了一些环境参数，比如叫env。上游服务会通过RPC框架跟团队AB之间有一个交互，能读到环境参数具体是什么，然后它就能够把它的流量正确的调度到下游相应的集群。
这个过程中，需要多大流量，分配多少机器，开发人员可以通过OpenAPI是能够把这两件事关联起来的，可以得到恰当的处理。线上的整个升级包括重启机器等都可以非常平稳、非常丝滑。
SQL 优化让人秃头，怎么破?
再比如Spark SQL的优化，首先想做好优化，优化前需要知道mapper数、reducer数、excutor数等参数怎么设置，还要面料executor堆内内存不够、driver堆外内存不够、序列化结果过大等让人头大的错误。
其次，SQL运维优化会花费大量的人力，随着数据量的上升，其执行的环境也会变化。一次好的优化不一定永远都是对的，可能需要随着数据量上涨、需要随着环境的变化不停地去调，有可能未来也变得很差。
针对这件事怎么做更好呢？团队大数据的同学想到了AB测试。
在数据提交的阶段引入AB测试，在开启任务的时候能够开启一个优化列表，这个过程中团队开发了一个叫做DataOptimizer的优化引擎，会根据任务来不断优化，比如它历史跑的执行情况，环境数据等，最终会进行一些调优，调完之后看效果。最终团队发现，这套优化系统会比专家经验还要好5%。
AB测试作为研发全流程基础设施
因此，把刚才的案例串联起来，包括开发、上线、BugFix、优化、重构。团队发现在整个研发流程中，其实AB测试是可以像存储、计算、网络一样，作为一个基础设施来服务于整个研发流程。通过刚才的例子，大家应该会比较有体感，在整个研发的日常流程中，怎样去把它用于自己的工作实践，成为我们一个得力武器。
第二部分介绍一下基于大量的实践，团队总结出怎么样能够在一个公司内去建立一个可持续的数据驱动的文化。前文分享了很多案例，其实就是想让大家更深有体会，通过这样大量的实践，得出来一些小小的知识，怎么来建立可持续的数据驱动的文化。
字节跳动的数据驱动的文化是怎么建立的？
价值观：从企业基因上鼓励数据驱动
首先第一部分价值观，要从整个企业的基因上去鼓励大家去做数据驱动，这里截取下几个内部字节圈的截图。这个例子是说，上次去出差，遇到一个老大爷，非常关注互联网，喜欢刷抖音。他说了好多问题。但是他又提到，竞品的自动播放不用刷，但是冬天特别冷，可能没有暖气，可能会比较舒服。还有一些创作者也提出来这样的功能，公司比较鼓励大家提出想法，包括跟用户去交流。
大家直接就说，其实可以做一个AB测试，或者团队把这个反馈给相关的抖音的业务部门，让他们来做这样一个尝试，看是不是有收益的，或者能够对用户非常友好。所以内部其实是鼓励大家不同的想法去涌现的。
第二个例子，其实跟这个有点相似。抖音自动播放完毕之后，上滑的功能，其实跟上面这个需求是非常相似的。其实已经在做了，就有同学说，我希望能够加入到这个内测，先体验体验。
还有两个例子更生动有趣的例子。
字节在北京有很多工区，有一个互金的工区，有一天行政把马桶圈给换了，有同学就反馈说，好像很尴尬，非常麻烦。字节行政的同学就在下面回复，其实这件事是在做一件AB测试，是非常小的流量，只不过这个同学比较倒霉，刚好可能命中了实验组。字节的行政同学就跟进去解决。其实你会发现，到行政这样离研发流程非常远的序列都在积极参与，已经在尝试把数据驱动的理念用于他们的生产。
其次，还有大家已经形成了很多段子，比如大家在内网发“我要做可乐鸡翅，到底是应该放可口可乐还是放百事可乐”，其实这个问题猛然问到你，你可能也不一定能那么好的回答起来，到底哪个口味更好，这个就需要试，有同学就说你需要自己在家AB测试一下。
数据平台：从数据应用把门槛降到最低
刚才讲到价值观和企业文化，接着我们讲第二个要素：好用的工具。前面的分享讲了底层基建，怎么样把数据弄进来，大家直接可以看数据，怎么治理数据之类。到这里想和大家分享字节的特色是在数据应用层做了比较多的工作，去降低大家的使用门槛。
这里拿三个字节的数据应用层的工具举例。比如DataFinder，它是一个用户行为分析的工具，它有两个典型的功能在降低门槛。一个是场景模板，它会根据大家不同的业务场景，甚至于不同行业的需求，可能有40多个模板，企业来了之后，也许可能一开始不知道怎么样把看板搭起来，这个模板就给企业参考，告诉企业要做运营该怎么做，要做支付转化该怎么建看板。
其次DataFinder还提供了看板的洞察，这个数据假设有一些波动，DataFinder会告诉企业用户它可能真的是波动了，虽然每天都在波动，有一些集群点的偏离，DataFinder会帮企业用户分析出来，就相当于代替了一部分大家原来手动分析的功能。
其次DataTester就是AB测试的工具，里面也提供了可视化编辑的能力，在把SDK接入之后，用户的一些PM、运营同学可能直接就在网站上比如改变一下Slogan、改变一下按钮的文案、甚至一些颜色，能做一些所见即所得的AB测试。在运营触达上也是，DataTester接通了很多通道，运营、增长的同学来到DataTester平台上，可以直接测试一下不同的推送时机、不同的推送文案、不同的频次，想到的都可以去试。
最后一个是DataWind，它是一个BI的工具，它提供的就是可视化的拖拉拽分析，在有这个平台之前原来是写SQL非常多，但仍然还是会有更多人不会写SQL。团队通过把想要的数据，比如它的一些指标、维度通过拖拽建立一个数据集，直接就能去使用。这里面也提供了一些比较偏智能化的能力，比如自动归因，来帮用户发现整个数据集、数据看板中的一些增长/下降是什么维度上的变化引起的。
总之，这些能力都是在帮助大家降低门槛。
Launch Review：业务一号位的科学决策流程
Launch Review是字节的一个传统，公司业务线负责人会对大家做的事情进行科学决策，具体的流程流程如下。
每一周或双周，字节一些部门都会主持这样一个例会，大家会对做的一些算法迭代的实验或者产品的实验，来做一个总结分析。中间会有包括部门的负责人、业务方等很多人来听，大家会进行提问和互动。但最终是要部门的一号位来做出决策，确定是不是能上线。
整个过程体现了下面几个点。
复盘的文化： 复盘是需要天天做，日常每天都要做的，自己做这件事到底它的价值是什么？SWOT分别是什么？
保持信息透明： 一个功能要上线了，这件事是怎么做的，为什么做，大家要始终保持信息透明的。比如推荐系统有那么多工程师在改进，现在就是一个非常黑盒的系统，但是对于部门的一号位或者非常核心的负责人来说，他还是要非常清楚里面的一些关键的东西到底是怎么work的。
全局视角： 其实通过这个机制，就能保证大家每次上新的功能的时候，团队会思考这个东西对既有的系统的影响，整个系统是长什么样子，这样能够帮助业务一号位总揽全局，这样在新的改进加进来之后，才能做出更趋全局最优的决策。
经验沉淀： 通过这种比较开放的会议，鼓励让大家都能参与进来，互相借鉴，也许抖音做了一件什么改进，头条的人说我也可以拿去试试，这样大家的想法收益就能够无限的放大。
数据驱动VS 信仰判断 ： 正向的不一定能上，负向的也许可以上。数据驱动不是唯一，数据驱动要在业务价值信仰之间跟数据驱动之间做一个平衡和判断，它是来辅助人的科学决策。
前面讲了怎么建立数据驱动的文化，但是在降本增效的大背景下，如果要落地数据驱动，它的ROI应该是什么样的，是不是值得大家去做呢？
数据驱动的成本
首先有这样三件事：
第一，需要在企业文化上进行数智化转型，这里用了智能的“智”，而不是数字的“字”。这是有区别的，不能光是有数据的，还需要数据要真正驱动业务。数据如何跟业务结合，来辅助进行决策。
第二，需要在整个研发流程上做数智化转型。因为很多互联网企业、科技企业很重要的流程就是在做产品的研发、业务的研发，最终在最核心的流程中是否能够让数据被驱动，而不是让大家在一个错误的方向上越走越远，这也是非常重要的。
第三，为了完成以上两点的落地，需要搭建一个以数据驱动的基础设施，这里有两种方法，一个是自建，可以根据自身的实际情况来进行，再一个是外采，最终要能帮助业务来实现价值。
总结成一句话，需要让整个企业变成一家数字原生的企业，这就是付出的成本。当企业变得数智化原生，意味着企业进化得更好了，这本身也是一种收益。
数据驱动的收益
讲完成本，大家来看下收益。数据驱动的收益，一言以蔽之，“帮助业务团队低损耗地朝正确方向持续小跑！”
第一，数据驱动能激发创新，提升收益。只有大家对业务比较有Owner意识，才能去贡献自己的想法，才能激活这个企业的发展，大家才会有更多的创新涌现出来。
其次，数据驱动能够降低成本去试错，人效是提高的。比如通过AB测试要搞两个版本，好像听起来成本是增加的，其实是未必的。也许用户决定的那个版本压根儿没有用，甚至带来了比较大的负向，这个损失是更大的。
AB测试通过在非常小的范围去做这样的验证，反而是降低成本，提高人效的。这个对应的，可能有一定的损耗，它的损耗对应的收益是，你能持续一直做正确的决策，数据驱动是有损耗的，但它的损耗是可接受的必要成本。
再次，通过数据驱动是能够积累团队经验的，最终提升整个团队的决策力。上文刚才讲的Launch Review，它其实是让整个团队共同决策个通过数据驱动最终实现了一个决策的平民化和公平化。
最后，整个研发流程做的大部分事情，收益是可以被量化的，这样就知道什么改进对业务帮助更大，最终就能赋能给我们公司的管理团队，让大家在管理上有更好的科学的辅助。
产品介绍
火山引擎 A/B 测试，限时免费，立即申请！
A/B 测试，摆脱猜测，用科学的实验衡量决策收益，打造更好的产品，让业务的每一步都通往增长。火山引擎首度发布增长助推「火种计划」，火山引擎 A/B 测试作为「火种计划」产品之一，将为您免费提供 2 亿事件量和 5 万 MAU，以及高达 12 个月的使用权。后台回复数字“8”了解产品
--推荐阅读--