这一次我们阅读和翻译关于分层实验平台的来自Google的论文Overlapping experiment infrastructure: more, better, faster experimentation （没有找到特别官方的链接，学术搜索能搜到）。
Google也大量需要在线的对照实验来做决策，几乎所有的微小的改变，都需要通过实验决定。相比众多的实验，流量的数量已经成为了瓶颈。为了更高效、更准确地做更多的实验，这篇文章设计了分层实验平台。同一份流量可以同时做多个实验。
更多、更好、更快
实验平台不仅能同时运行多个实验，也要具有灵活性：不同的实验可以使用不同的配置、不同的流量大小。不正确的实验不应当被允许运行，正确但影响很差的实验应当被迅速发现并中止。实验的设置和进行应当容易并迅速，即使不是工程师也可以做（不需要写代码）。实验指标应当实时可用，这样实验就可以被迅速评估。简单的重复实验应当很容易做，最理想情况下，实验平台可以用做灰度发布（gradually ramping up）。
发展到这一步，不仅需要工程上的架构设计，也需要相应的工具和对使用流程的控制。
背景
这里说的分层实验平台只用在Web互联网服务上，不包括Google Apps、Chrome等（我们可以想象一下，实际上，非Web服务也可以做对照实验，但是如果要做重叠的实验则有一定的困难）。
与之前在（一）中提到的对照实验系统一样，做对照实验完全由参数来控制。使用参数使得实验容易创建，因为他们可以是易读的文字，不是代码。同样，数据文件比程序文件更容易快速部署。
在最初，Google使用了一种可以称作“单层实验平台”的架构。一个流量只能做一个实验。首先分配基于Cookie划分流量的实验，然后再划分基于随机分配流量的实验。这种架构不足以支持足够多的实验。
分层架构
我们将参数划分为若干个子集，每个子集之内的参数是可能互相影响的，也就是说不能同时做实验的；子集之间的参数则是不会互相影响的（正交的）。这种划分可以来自于检查，也可以来自于过往实验的结果。用每一个子集对应一个抽象的“层”的概念。同时，把对流量的每一个划分抽取对应一个抽象的“领域”（domain）的概念。一个领域里可以有多层，一个层里也可以有多个领域。如图。而这个图也可以看做最宏观上Google Web的层和领域的划分。
虽然看起来有点复杂，但这个划分有很多好处。一个非重叠实验领域，可以方便地做影响非常大的实验（可能实验的参数跨遍各层，只能在这个领域做）；它允许在两个领域中对相同的参数做不同的划分；我们也可以比较容易地把一个参数从一层中移到另一层中（如果发现这样更有利于流量的利用）。
注意到图(c)中增加了发布层Lanuch Layer。Lanuch Layer是一种特殊的层，它们必须运行着100%的流量（它们所在的领域称default domain，不能与其他domain纵向切分），同一个参数最多出现在一个Launch层中，同时最多出现在一个普通层中。Launch中参数的取值，可以被下面普通实验层中进行的实验的参数取值所覆盖。
发布层的典型应用是，每一个待发布的参数版本，新建一个发布层，而当它稳定后，删掉这个发布层。由于发布层在default domain中，因此它可以用来最终验证实验间的相互影响。
流量的划分不仅有基于cookie、random的，也会根据实验的要求有更灵活的其他方式，比如userid，query-string等。而不同的划分方式可能会在领域与层之间造成饥饿和有偏的问
题，为此，需要给每个领域和层指定流量划分方式，对已经被上层抽取造成的有偏的流量要加以标识，排除掉它们以避免有偏。
分层实验框架的工程架构基本就是如此，而这篇论文的后半部分还用了很大的篇幅讨论前面说到的”工具和使用流程控制”，我们在下一篇阅读笔记中讨论。
Codingstory 