diff --git a/overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md b/overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md
index b76000a..fd4fa89 100644
--- a/overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md
+++ b/overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md
@@ -46,9 +46,9 @@
 * **更好**：不合理的实验是不应该让它在线上流量进行的。合理的但是很差的实验（比如，有`Bug`的实验或是无意中产生的很差的实验结果）都应该能很快的被捕获并且停止它的进行。标准化的标价指标可以让所有的实验进行公平的比较：比如在计算`CTR`指标的时间，两个实验应该用相同的过滤器去掉爬虫流量。
 * **更快**：能够很容易并且很快地建立一个实验。容易到非工程师不需要写代码就可以创建一个实验。评价指标应该很快的被统计出来，以便分析。简单的迭代可以很快速地进行。理想状态是，实验系统不仅支持实验，并且可以控制放量，比如，以一种系统的和容易理解的方式对实验进行放量。
 
-为了达到这些设计的目标，我们不仅需要实验架构来进行更多的实验，并且需要一些工具和指导过程来支持更多和更快的实验。
+为了达到这些设计的目标，我们不仅需要实验设施来进行更多的实验，并且需要一些工具和指导过程来支持更多和更快的实验。
 
-对于实验架构，有两个很明显的选择，或是要支持单层实验或是要支持多因素实验。单层实验意味着每个请求最多只会通过一个实验，单层实验是很容易使用的，并且也具有灵活性，但是扩展性不足。多因素实验在统计学上进行了大量的讨论，多因素实验中每个参数（因素）都可以被独立地实验，在实验中每个参数（因素）都可以独立地被实验，每个实验中只测试一个参数，这个参数会覆盖所有其它实验中的其它参数。每个查询可以同时在 <img src="http://chart.googleapis.com/chart?cht=tx&chl=N" style="border:none;" alt="N" /> 个实验中，其中 <img src="http://chart.googleapis.com/chart?cht=tx&chl=N" style="border:none;" alt="N" /> 是参数的个数。虽然这种方法进行了多年的研究和实践，但对于`Google`的系统却不适用，因为`Google`有几千个参数，并且不能被独立的分析。例如：要对两个参数进行分析，一个参数是`Web`页面的背景色，另一个是文字的颜色，虽然『蓝色』对两个参数都是合法值，但是如果两个参数都取『蓝色』，那么页面是不可读的。
+对于实验设施，有两个很明显的选择，或是要支持单层实验或是要支持多因素实验。单层实验意味着每个请求最多只会通过一个实验，单层实验是很容易使用的，并且也具有灵活性，但是扩展性不足。多因素实验在统计学上进行了大量的讨论，多因素实验中每个参数（因素）都可以被独立地实验，在实验中每个参数（因素）都可以独立地被实验，每个实验中只测试一个参数，这个参数会覆盖所有其它实验中的其它参数。每个查询可以同时在 <img src="http://chart.googleapis.com/chart?cht=tx&chl=N" style="border:none;" alt="N" /> 个实验中，其中 <img src="http://chart.googleapis.com/chart?cht=tx&chl=N" style="border:none;" alt="N" /> 是参数的个数。虽然这种方法进行了多年的研究和实践，但对于`Google`的系统却不适用，因为`Google`有几千个参数，并且不能被独立的分析。例如：要对两个参数进行分析，一个参数是`Web`页面的背景色，另一个是文字的颜色，虽然『蓝色』对两个参数都是合法值，但是如果两个参数都取『蓝色』，那么页面是不可读的。
 
 本文提出的解决方案是将参数分成子集，每个参数子集包含相互不能独立修改的参数。一个参数子集会与一个包含实验的层相关联，不同层的实验的流量是正交的。每个`query`可以在 <img src="http://chart.googleapis.com/chart?cht=tx&chl=N" style="border:none;" alt="N" /> 个实验中，其中 <img src="http://chart.googleapis.com/chart?cht=tx&chl=N" style="border:none;" alt="N" /> 是层的数量。
 
@@ -56,7 +56,7 @@
 
 # 3. 背景
 
-在讨论`Google`的实验之前，我们先描述一下我们实验架构所处的环境，这样能更清楚的理解我们实验架构所要设计的目标和所受到的限制。
+在讨论`Google`的实验之前，我们先描述一下我们实验设施所处的环境，这样能更清楚的理解我们实验设施所要设计的目标和所受到的限制。
 
 宏观上看，用户通过它们浏览器发送请求与`Google`交互。请求进入`Google`的服务系统后，会先后被多个服务处理（运行在服务器上的程序），然后产生面向用户的结果页。比如，可能有一个服务决定与查询最相关的原生搜索结果，另一个服务决定与查询最相关的广告，还有一个服务将原生搜索结果和广告结果组织到结果页，返回给用户。见图1。一方面，这种模块化可以让我们降低延时（不相互依赖的过程可以并行），显然，原生的搜索过程与广告搜索过程是相互独立的，并能更快速的试验（每个服务都可以独立地进行，并且模块化的测试可以进行更快速的发布）。另一方面，如果要求每个请求最多只进入一个实验，那么模块化就需要更精心地设计。可能存在的问题有流量饥饿（上游模块的实验可能优先处理了所有请求，导致下游模块的实验没有请求），和偏置（`bias`）（比如，上游模块的实验处理了所有英语的请求，导致下游模块的实验就只有非英语请求）。
 
@@ -73,7 +73,7 @@
 
 在数据文件中配置实验，可以让实验更快更方便地创建：数据文件是可读的，并容易手工编辑，不需要进行代码变更，并可以由非工程师进行创建，而且配置数据的推动会比二进制程序的发布更加频繁，它使创建仅包含已有参数的实验更加方便快捷。
 
-在开发我们的实验架构之前，我们使用一个简单的单层实验设施，在这个架构中，每个请求最多进行一种实验。先分配`Cookie`取模的流量的实验，再分配随机流量的实验。上游服务会优先分配流量，所以如果上游（即`Cookie`取模的实验）进行了很多实验，那么下游可能会得不到足够的流量，即流量饥饿问题。除了这些问题之外（包括前面提到的流量饥饿和偏置问题），单层实验可以满足我们设计目标中的易用和相对的灵活性。但是在`Google`数据驱动的文件中，单层的方法没有足够的可扩展性：我们无法快速地进行足够多的实验。
+在开发我们的实验设施之前，我们使用一个简单的单层实验设施，在这个设施中，每个请求最多进行一种实验。先分配`Cookie`取模的流量的实验，再分配随机流量的实验。上游服务会优先分配流量，所以如果上游（即`Cookie`取模的实验）进行了很多实验，那么下游可能会得不到足够的流量，即流量饥饿问题。除了这些问题之外（包括前面提到的流量饥饿和偏置问题），单层实验可以满足我们设计目标中的易用和相对的灵活性。但是在`Google`数据驱动的文件中，单层的方法没有足够的可扩展性：我们无法快速地进行足够多的实验。
 
 # 4. 重叠实验基础设施
 
@@ -127,7 +127,7 @@
 
 图3中展示了一个请求分配给域，层和实验的逻辑。这些逻辑都以动态库的方式实现，编译链接到二进制之中，所以任何修改（比如，新的分配类型，新的分配条件，等等）都会在日常的二进制推送时集成到系统中去，动态库保证了在整个系统内的一致性，并且从动态库中自动可以获取到最新的功能。
 
-在这个架构下，一个特性的评估和发布过程是类似如下过程的：
+在这个设施下，一个特性的评估和发布过程是类似如下过程的：
 
 * 在合适的模块中，实现新的特性（包括`code review`，二进制推送，设置默认参数等等，如标准的工程实践一样）。
 * 创建一个灰度实验（通过数据推送方式），以保证特性可以正常工作，如果不能正常工作，那么可能就要重写代码修复这个问题。
@@ -137,7 +137,7 @@
 
 # 5. 工具与流程
 
-虽然重叠架构是有能力运行更多的实验，更快速地进行实验，并能同步优化实验效果，但只依靠架构还是不够的。我们还需要工具、研究、和教导过程来支持更快速的实验。在本节，我们讨论几个关键的工具和过程，以及它们如何帮助我们扩展的。
+虽然重叠实验设施是有能力运行更多的实验，更快速地进行实验，并能同步优化实验效果，但只依靠设施还是不够的。我们还需要工具、研究、和教导过程来支持更快速的实验。在本节，我们讨论几个关键的工具和过程，以及它们如何帮助我们扩展的。
 
 ## 5.1 工具
 
@@ -164,7 +164,7 @@
 
 _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http://chart.googleapis.com/chart?cht=tx&chl=%5Ctext%7Bqueries%7D_%7B%5Ctext%7Bexperiment%7D%7D%3D2N" style="border:none;" alt="\text{queries}_{\text{experiment}}=2N" /> ，那么必须 <img src="http://chart.googleapis.com/chart?cht=tx&chl=2N" style="border:none;" alt="2N" /> 大于等于 <img src="http://chart.googleapis.com/chart?cht=tx&chl=16(s%2F%5Ctheta)%5E2" style="border:none;" alt="16(s/\theta)^2" /> 才能满足最小变化检测需求，16这个值是由置信度（ <img src="http://chart.googleapis.com/chart?cht=tx&chl=1-%5Calpha" style="border:none;" alt="1-\alpha" /> ，通常为95%）和期望的统计功效（ <img src="http://chart.googleapis.com/chart?cht=tx&chl=1-%5Cbeta" style="border:none;" alt="1-\beta" /> ，通常为80%）决定的。
 
-我们的重叠架构的其一优点是我们可以在每一层创建一个大的比照实验，这样它可以被多个实验共享，如果共享的对照实验规模比实验大的多（ <img src="http://chart.googleapis.com/chart?cht=tx&chl=1%2F%5Ctext%7Bqueries%7D_%7B%5Ctext%7Bcontrol%7D%7D%2B1%2F%5Ctext%7Bqueries%7D_%7B%5Ctext%7Bexperiment%7D%7D%20%5Capprox%201%2F%5Ctext%7Bqueries%7D_%7B%5Ctext%7Bexperiment%7D%7D%0A" style="border:none;" alt="1/\text{queries}_{\text{control}}+1/\text{queries}_{\text{experiment}} \approx 1/\text{queries}_{\text{experiment}}" /> ），那么我们可以用 <img src="http://chart.googleapis.com/chart?cht=tx&chl=%5Ctext%7Bqueries%7D_%7B%5Ctext%7Bexperiment%7D%7D%3DN%0A" style="border:none;" alt="\text{queries}_{\text{experiment}}=N" /> 而不是 <img src="http://chart.googleapis.com/chart?cht=tx&chl=2N%0A" style="border:none;" alt="2N" /> ，这样虽然样本量变小为 <img src="http://chart.googleapis.com/chart?cht=tx&chl=%5Ctext%7Bqueries%7D_%7B%5Ctext%7Bexperiment%7D%7D%3DN%20%5Cge%2010.5(s%2F%5Ctheta)%5E2" style="border:none;" alt="\text{queries}_{\text{experiment}}=N \ge 10.5(s/\theta)^2" /> ，却有着90%的统计功效（ <img src="http://chart.googleapis.com/chart?cht=tx&chl=1-%5Cbeta" style="border:none;" alt="1-\beta" /> ）。
+我们这套重叠做法的一个优点是我们可以在每一层创建一个大的比照实验，这样它可以被多个实验共享，如果共享的对照实验规模比实验大的多（ <img src="http://chart.googleapis.com/chart?cht=tx&chl=1%2F%5Ctext%7Bqueries%7D_%7B%5Ctext%7Bcontrol%7D%7D%2B1%2F%5Ctext%7Bqueries%7D_%7B%5Ctext%7Bexperiment%7D%7D%20%5Capprox%201%2F%5Ctext%7Bqueries%7D_%7B%5Ctext%7Bexperiment%7D%7D%0A" style="border:none;" alt="1/\text{queries}_{\text{control}}+1/\text{queries}_{\text{experiment}} \approx 1/\text{queries}_{\text{experiment}}" /> ），那么我们可以用 <img src="http://chart.googleapis.com/chart?cht=tx&chl=%5Ctext%7Bqueries%7D_%7B%5Ctext%7Bexperiment%7D%7D%3DN%0A" style="border:none;" alt="\text{queries}_{\text{experiment}}=N" /> 而不是 <img src="http://chart.googleapis.com/chart?cht=tx&chl=2N%0A" style="border:none;" alt="2N" /> ，这样虽然样本量变小为 <img src="http://chart.googleapis.com/chart?cht=tx&chl=%5Ctext%7Bqueries%7D_%7B%5Ctext%7Bexperiment%7D%7D%3DN%20%5Cge%2010.5(s%2F%5Ctheta)%5E2" style="border:none;" alt="\text{queries}_{\text{experiment}}=N \ge 10.5(s/\theta)^2" /> ，却有着90%的统计功效（ <img src="http://chart.googleapis.com/chart?cht=tx&chl=1-%5Cbeta" style="border:none;" alt="1-\beta" /> ）。
 
 在确定实验规模的过程中，更重要的问题是如何估计标准误差 <img src="http://chart.googleapis.com/chart?cht=tx&chl=s" style="border:none;" alt="s" /> ，特别是当我们使用很多比率指标 <img src="http://chart.googleapis.com/chart?cht=tx&chl=y%2Fz" style="border:none;" alt="y/z" /> 时（比如，覆盖率，有多少查询是返回广告的（有广告返回的查询/全部查询量））。问题产生于是实验的单元与分析的单元不一致时，比如，对于覆盖率，分析的单元是一个查询，但对于`cookie`取模的实验而言，实验的单元是一个`cookie`（一系列查询），并且我们无法假设来来自同一用户或`cookie`的请求之间是相互独立的，我们的方法是计算 <img src="http://chart.googleapis.com/chart?cht=tx&chl=s'" style="border:none;" alt="s'" /> ，即每个实验的标准误差，然后以 <img src="http://chart.googleapis.com/chart?cht=tx&chl=s'" style="border:none;" alt="s'" /> 来表示 <img src="http://chart.googleapis.com/chart?cht=tx&chl=s" style="border:none;" alt="s" /> ，在上例中， <img src="http://chart.googleapis.com/chart?cht=tx&chl=s'" style="border:none;" alt="s'" /> 是每个`cookie`取模的标准误差，且 <img src="http://chart.googleapis.com/chart?cht=tx&chl=s%3Ds'%5Csqrt%7B%5Ctext%7Bavg%20queries%20per%20cookie%20mod%7D%7D" style="border:none;" alt="s=s'\sqrt{\text{avg queries per cookie mod}}" /> 。对于比率指标，我们用`delta`方法计算  <img src="http://chart.googleapis.com/chart?cht=tx&chl=s'" style="border:none;" alt="s'" />  [11]。
 
@@ -189,7 +189,7 @@ _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http:/
 
 ## 5.3 快速的分析（`Fast Analytics`）
 
-虽然前面提到的架构，可以同时进行许多实验，并快速地运行一个实验，但没有实验分析工具，一个真正的实验进程是无法在本质上快速进行的。对实验工具完整的讨论已经超出了本文的范围，但这里我们讨论一个重要的设计目的。
+虽然前面提到的设施，可以同时进行许多实验，并快速地运行一个实验，但没有实验分析工具，一个真正的实验进程是无法在本质上快速进行的。对实验工具完整的讨论已经超出了本文的范围，但这里我们讨论一个重要的设计目的。
 
 分析工具最重要的目标是提供实验者要衡量它们的实验的指标。在`Google`，我们并不将好多个实验指标合成一个目标函数，而是查看多个指标，以更彻底地理解用户的体验是如何改进的（比如，用户可以多快解析这个页面，点击按钮应如何移动，等等），注意，实时流量只能衡量发生了什么，而无法看到改变的原因。
 
@@ -204,7 +204,7 @@ _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http:/
 
 ## 5.4 教导（`Education`）
 
-现在我们有了重叠架构和相关工具，实验设计已经完成了进行更多、更快、更好的技术方面的要求。我们还是要讨论一下人的因素。教导在促进健壮的实验目标中是同样重要的。在`Google`，有两个过程来保证实验是良好设计的，并且一个实验的结果是能被理解和传播的。
+现在我们有了重叠设实验施和相关工具，实验设计已经完成了进行更多、更快、更好的技术方面的要求。我们还是要讨论一下人的因素。教导在促进健壮的实验目标中是同样重要的。在`Google`，有两个过程来保证实验是良好设计的，并且一个实验的结果是能被理解和传播的。
 
 ### 5.4.1 实验委员会（`Experiment council`）
 
@@ -223,7 +223,7 @@ _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http:/
 
 另一个过程是讨论会，实验者们带着他们的实验结果与专家进行讨论，讨论的目标是：
 
-* 保证实验的结果是有效的。在有些时候，即使有实验委员会，但在实际的实验上出错了，或是有一些意外发生，在这些情况中，讨论会中的讨论就像是一个调试（`debugging`）的过程，有完整的开发，日志，实验架构，指标，分析工具的专家集合是解决问题的关键。
+* 保证实验的结果是有效的。在有些时候，即使有实验委员会，但在实际的实验上出错了，或是有一些意外发生，在这些情况中，讨论会中的讨论就像是一个调试（`debugging`）的过程，有完整的开发，日志，实验设施，指标，分析工具的专家集合是解决问题的关键。
 * 有了有效的结果后，要保证对指标集合做整体的观察，以理解实验结果到底如何，其它划分数据的方法或是改变指标也许可以更进一步理解实验的影响。一些实验很复杂，需要实验者追踪地进行几次。
 * 有了完整的结果集合，讨论并决定整个实验是一个正影响或负影响的用户体验，有了决定后，决策者可用这个数据（结合策略和战略信息）来决定是否要发布这个实验，或提出可能的改进建议，或是放弃。
 
@@ -231,11 +231,11 @@ _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http:/
 
 # 6. 成果
 
-我们在2007年3月部署了我们的重叠实验架构（以有很多工具和处理预时期和后时期的架构发布），最终衡量我们整个系统成功的指标是我们在运行更多的实验，更好地运行，更快得到结果的能力。
+我们在2007年3月部署了我们的重叠实验设施（以有很多工具和处理前期和后期的设施发布），最终衡量我们整个系统成功的指标是我们在运行更多的实验，更好地运行，更快得到结果的能力。
 
 ## 6.1 更多
 
-我们可以用几个标准来判断我们是否成功地运行更多的实验，在一个时期上一共运行了多少实验，这些实验中有多少发布了，有多少不同的实验在运行实验（见图5）。要说明的是实验的数目包含了对照实验的数目。对于运行实验人数，一些实验是有多个拥有者的（比如，如果某人离开城市或发生了事），或是将团队邮件列表中的成员也认为拥有者。不幸的是，我们无法轻松地知道有多少拥有者是非工程师，但有意思的是，非工程师的数据是在增加的，对分布层的数量，我们只计算了使用重叠架构的发布层的数量。在重叠实验之前，我们用其他的一些机制发布实验，但它们的频率在下降。在所有的图中，y轴上的数据出于保密的原因隐去了（它们是线性比例），但从趋势上可以明显地看出，我们系统支持了指数级增加的实验，发布，实验者。
+我们可以用几个标准来判断我们是否成功地运行更多的实验，在一个时期上一共运行了多少实验，这些实验中有多少发布了，有多少不同的实验在运行实验（见图5）。要说明的是实验的数目包含了对照实验的数目。对于运行实验人数，一些实验是有多个拥有者的（比如，如果某人离开城市或发生了事），或是将团队邮件列表中的成员也认为拥有者。不幸的是，我们无法轻松地知道有多少拥有者是非工程师，但有意思的是，非工程师的数据是在增加的，对分布层的数量，我们只计算了使用重叠实验的发布层的数量。在重叠实验之前，我们用其他的一些机制发布实验，但它们的频率在下降。在所有的图中，y轴上的数据出于保密的原因隐去了（它们是线性比例），但从趋势上可以明显地看出，我们系统支持了指数级增加的实验，发布，实验者。
 
 <img src="figure-05-1.jpg" width="290"><img src="figure-05-2.jpg" width="290"><img src="figure-05-3.jpg" width="290">  
 **图5**：实验，拥有者，发布数量在时间上的趋势图
@@ -264,9 +264,9 @@ _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http:/
 
 # 7. 结论与工作展望
 
-在本文中，我们描述了重叠实验架构、相关工具和教导过程来以进行更多实验，更好且更健壮的实验，和更快的实验。我们并给出了实践中我们的工作的结果：更多实验，更多实验者，更多发布，并更快速且有更小的错误了。虽然实际的实现是针对`Google`，但关于设计的讨论对于任何想收集统计数据评估变化的公司都是适用的。
+在本文中，我们描述了重叠实验设施、相关工具和教导过程来以进行更多实验，更好且更健壮的实验，和更快的实验。我们并给出了实践中我们的工作的结果：更多实验，更多实验者，更多发布，并更快速且有更小的错误了。虽然实际的实现是针对`Google`，但关于设计的讨论对于任何想收集统计数据评估变化的公司都是适用的。
 
-下面是几个我们要继续改进我们实验架构的方向，包括：
+下面是几个我们要继续改进我们实设设施的方向，包括：
 
 * 提供加速实验新特性的方法和推动一些特别的实验（不是通过参数表达的实验）。
 * 突破一个实验参数被限制到一个层的规定。特别是，对于数值参数，我们添加了运算操作（比如，乘、加），它们是可传递的，也就是可组合的。有了这些操作符，我们可以在多个层用同一参数，只要实验都只是指定对默认值的操作，而不是覆盖默认值。