我们将大数据处理按处理时间的跨度要求分为以下几类

    基于实时数据流的处理，通常的时间跨度在数百毫秒到数秒之间

    基于历史数据的交互式查询，通常时间跨度在数十秒到数分钟之间

    复杂的批量数据处理，通常的时间跨度在几分钟到数小时之间

1.流处理

流是一种数据传送技术，它把客户端数据变成一个稳定的流。正是由于数据传送呈现连续不停的形态，所以流引擎需要连续不断处理数据

流处理的主要应用场景：金融领域和电信领域

1.1 Stom

Storm是一个免费开源、分布式、高容错的实时计算系统。

Storm主要分为两种组件Nimbus和Supervisor。这两种组件都是快速失败的，没有状态。任务状态和心跳信息等都保存在Zookeeper上的，提交的代码资源都在本地机器的硬盘上。
1）Nimbus负责在集群里面发送代码，分配工作给机器，并且监控状态。全局只有一个。
2）Supervisor会监听分配给它那台机器的工作，根据需要启动/关闭工作进程Worker。每一个要运行Storm的机器上都要部署一个，并且，按照机器的配置设定上面分配的槽位数。
3）Zookeeper是Storm重点依赖的外部资源。Nimbus和Supervisor甚至实际运行的Worker都是把心跳保存在Zookeeper上的。Nimbus也是根据Zookeerper上的心跳和任务运行状况，进行调度和任务分配的。
4）Storm提交运行的程序称为Topology。
5）Topology处理的最小的消息单位是一个Tuple，也就是一个任意对象的数组。
Topology由Spout和Bolt构成。Spout是发出Tuple的结点。Bolt可以随意订阅某个Spout或者Bolt发出的Tuple。Spout和Bolt都统称为component。

1.2 Spark Streaming

Spark Streaming是一种构建在Spark上的实时计算框架，它扩展了Spark处理大规模流式数据的能力。

Spark Streaming的基本原理是将输入数据流以时间片（秒级）为单位进行拆分，然后以类似批处理的方式处理每个时间片数据

2.交互式查询（Adhoc Query）

在商业智能领域少量更新和大量扫描分析场景，目前是Impala+Kudu/Hive/Spark SQL/Greenplum Mpp数据库在混战。

3.批处理技术

3.1 MapReduce（Hadoop）

MapReduce模式的主要思想是自动将一个大的计算拆解成Map和Reduce

3.2 Spark

Spark的中间数据放到内存中，对于迭代运算效率更高。
Spark更适合于迭代运算比较多的ML和DM运算。因为在Spark里面，有RDD的抽象概念。
Spark比Hadoop更通用
Spark提供的数据集操作类型有很多种，不像Hadoop只提供了Map和Reduce两种操作。比如map, filter, flatMap, sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort,partionBy等多种操作类型，Spark把这些操作称为Transformations。同时还提供Count, collect, reduce, lookup, save等多种actions操作。

尝试解决使用jupyter绘图无法交互的问题

---

问题描述

在练习《python数据手册》中matplotlib部分时，书中提到的魔术方法

//  在notebook中启动交互式图形
% matplotlib notebook

无法使用并报错，以下是尝试解决的步骤，在此记录以防忘记。

一、升级jupyter lab

首先，我在conda中的jupyter notebook版本为6.1.4，但是jupyter lab版本只有1.2.6，而lab的许多拓展必须在2以上的版本才能使用，必须首先升级lab的版本，使用

conda update jupyterlab

升级发现报错“PackageNotInstalledError: Package is not installed in prefix.”但是，相同方法升级notebook就没有任何问题，可能是版本实在太低，于是使用

pip install --upgrade jupyterlab

完成lab的升级

二、安装jupyterlab拓展

由于使用交互绘图模式报错“Javascript Error: IPython is not defined”，查询错误原因，知道可以在conda中使用如下命令解决:
[原文链接: link.]

conda install -c conda-forge ipympl

# If using JupyterLab
conda install nodejs
jupyter labextension install @jupyter-widgets/jupyterlab-manager
jupyter lab build

# Later, if updating a previous Lab install:
conda install ipympl
jupyter lab build

其中，jupyter labextension install 命令还遇到了WinError5的权限问题，右键管理员权限运行anaconda powershell prompt即可解决。

随后发现必须按照链接原文评论区中所说，补充一条命令以激活拓展：

jupyter nbextension enable --py widgetsnbextension

重启jupyter，此时交互式绘图模式已经可以正常使用，不论使用%maytplotlib notebook还是 %matplotlib widget均可以进入交互式绘图模式。效果如下图所示，笔者可以旋转图中莫比乌斯带的3d图像，而在inline模式下3d图的查看是非常不便的：

---

本文章，百度+论坛+知乎等处查询，了解灰度测试，方便学习。本文章只限学习。文章可能内容多，我进行了网上查询终结，还需细看整理，如有重复内容请见谅，我也正在了解，方便手机携带查看。

灰度测试就是指如果软件要在不久的将来推出一个全新的功能，或者做一次比较重大的改版的话，要先进行一个小范围的尝试工作，然后再慢慢放量，直到这个全新的功能覆盖到所有的系统用户，也就是说在新功能上线的黑白之间有一个灰，所以这种方法也通常被称为灰度测试。类似于我们通常所说的内测。

灰度测试就是将自己的产品首先拿出来给一部分目标人群使用，通过她们的使用结果和反馈来修改产品的一些不足，做到查漏补缺，完善产品的功能，使产品的质量得到提高。这样产品尽早的与用户接触能为以后产品的正式发布打下基础。

定义：灰度测试，就是在某项产品或应用正式发布前，选择特定人群试用，逐步扩大其试用者数量，以便及时发现和纠正其中的问题。

灰度期：灰度测试开始到结束期间的这一段时间，称为灰度期。

目前，灰度测试存在两种方式：

1、软件系统内自带灰度测试发布系统

2、使用第三方工具来辅助进行

这两种方法都是可行的。

灰度测试这种方法可以帮助研究团队快速试验并发现问题并在大规模推向用户之前及时把问题修正过来，很大成度上减少了不少风险的产生，所以灰度测试是很有必要的。要知道只有不断创意并完善的软件才能在激烈的市场竞争中立于不败之地，当有创意的时候，小规模的灰度测试是非常有必要的。不但满足了一部分人抢先体验的愿望同时也可以发展研发团队不容易发现的各种问题，还能收集到真正的用户体验，这些对于优化全新的系统内容都是非常有帮助的，如果没有灰度测试的话，其实和闭门造车的感觉是差不多了，在增加灰度测试以后才能真正把其推向用户。

灰度测试存在的意义是什么呢？

现在的许多互联网产品的用户规模都是非常大的，版本更新也比较频繁，每当有新版本进行更新或者上线的时候，新的版本都是要承受非常大的压力，而灰度测试则可以很好的规避这种存在可能性非常大的风险问题。

灰度发布能及早获得用户的意见反馈，完善产品功能，提升产品质量，让用户参与产品测试，加强与用户互动，降低产品升级所影响的用户范围。

灰度测试的具体步骤

第一、确定自己的目标

既然选用了灰度发布这个方法，就首先要确定自己的目标是什么，比如通过让一部门用户先使用产品，从而通过试用结果和用户的反馈来找出产品的不足，从而想办法来提升产品的品质，还有的除了这个目的之外可能还想要借此机会来推广自己的产品。

第二、选择策略

定好目标之后，就要选择策略了，要根据自己产品的规模和功能的多样性来确定互联网灰度发布试用用户的规模和发布的频率，这样才可以提高用户的参与度，全方位的试用产品，这样才能反馈出一个比较全面的结果。包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等

第三、对用户进行筛选

然后就是要对这些用户进行筛选，用户的选择一定要具有代表性，要选择一部分的新用户和一部分的老用户来交替使用产品，还有就是选择的用户要具有敢问好问的精神，善于发现才能发现问题。选择完用户就是产品系统的部署，然后就是对用户参与的结果进行数据分析，找出产品存在的问题。对用户的筛选包括用户特征、用户数量、用户常用功能、用户范围等

第四、部署系统

部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调

第五、发布总结

用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表

第六、产品完善

第七、新一轮灰度发布或完整发布

在上述步骤全都完成之后，互联网产品的灰度发布就基本上是完成了，后续最重要的事情就是全身心的投入对产品的改进中，对产品的不足进行完善，如果产品的漏洞比较大，可以进行再一轮的灰度发布，如果只是一些小问题，那么在修改之后就可以正式的发布了。

什么是灰度发布？
灰度发布，又名金丝雀发布，或者灰度测试，是指在黑与白之间能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。
灰度发布的意义
灰度发布能及早获得用户的意见反馈，完善产品功能，提升产品质量，让用户参与产品测试，加强与用户互动，降低产品升级所影响的用户范围。
灰度发布步骤

1. 定义目标
2. 选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
3. 筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
4. 部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
5. 发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
6. 产品完善
7. 新一轮灰度发布或完整发布

灰度测试环境就是生产环境，生产数据，所影响的也是生产环境，只是范围比测试环境更广，更真实。其实就是小范围的生产环境。类似于游戏内测。

与现有国内一般的公司发布的做法相比，灰度发布的过程是一个渐进的过程，其实这才是一种正确规范安全的发布过程。正常一个产品开发过程中，会对其进行功能测试，用户体验测试，交互评估等。功能测试可以让产品尽量少的bug;用户体验测试与交互评估等可以在开发过程中，使产品尽可能的满足于用户的使用习惯，以及对功能的可接受程度。但这些都是少部分人的感觉与习惯所产生的结果，只是公司内部的测试+小范围外部测试。

在标准的软件产品的发布过程中，这充其量只是一个Alpha版本，而一般互联网产品的发布大多数是做到这里就直接上线，替换了原有的版本，这种跳跃式的发布是非常危险的，如果产品影响面大，对项目成员的压力是非常大的。

灰度发布可以在原有的Alpha版本之后增加了更大范围的外部测试，是一个不断的放量过程，通过这样的发布过程可以是产品的问题暴露出来，而不是影响到全部的用户，最终可以让产品最大程度稳定、适合用户。如果要使用灰度发布，与往常的项目过程不同的是，需要做好提升点的预准备，通过数据分析，日志分析找到改进点；也要考虑在出问题时可以快速的定位到问题，并切换到原有产品；当然放量也是可以有多种多样的，可以通过选取最能让产品改进的用户参与新版本的试用。

灰度发布可以从业务，功能，性能，用户体验很多方面使产品得以提升，并平滑上线。

传统软件产品发布过程（例如微软的windows7的发布过程）一般都会经历Pre-Alpha、Alpha、Beta、Release candidate(Rc)\RTM\General availability or General Acceptance(GA)等几个阶段（参考Software release life cycle）从范围来理解，即公式内部—>外部小范围测试->外部大范围测试->正式发布。

A/Btest其实属于灰度当中的一个小小的分支，做产品，运营数据的都必须要懂。这是国际前沿的产品发布和改版方式，而不是依靠主观去进行。

灰度测试定义

灰度测试指的是在同一个时间段内，存在两个不同的应用版本，一个版本叫做黑色版本，而另一个版本叫做白色版本。然后我们通过观测两个同时存在的版本的表现来调整黑色版本和白色版本的比例，如果一切顺利，渐渐地就把所有用户的应用从黑色版本过渡到白色版本。而这种通过共存黑白版本的手段进行测试的过程就叫做灰度测试或灰度发布。

灰度测试与A/B测试比较

灰度发布/灰度测试A/B测试 时间周期一般在新版本发布的早期。版本整个生命周期，都持续不断的做A/B测试。 目的验证新版本工程正确性，如功能特性、性能、可靠性、易用性等。为商业目的，优化用户体验相关的各方面特性。 用户人群一般对用户人群的属性和数量没有特殊要求。对用户人群的属性和数量有较高要求。 是否修改功能特性否，灰度测试过程中一般不修改新版本的功能特性。是，A/B测试是持续不断的修改版本的界面和流程，以便找到最优设计。 实施方法采集数据，分析是否有功能缺陷（bug）、性能问题、稳定性问题、易用性问题等。有规范的过程步骤：提出假设，设定目标，制作版本、分析结果等。有严格的数理统计算法，判断结果

灰度测试实现方式

通常情况下，有两种方式来实现灰度测试。第一种是修改代码，通过对代码的修改实现灰度测试的逻辑。修改代码的优点在于开发人员能够非常精细地控制不同版本的细节，无论多么复杂的需求都能够实现，能够较好地满足测试的需求。但是修改代码的方式会较深地侵入代码，同时不能够快速响应需求，开发人员实现需要的功能是需要时间的。

第二种方法就是通过负载均衡系统实现了，在负载均衡服务器上调整配置，使得用户在访问应用的时候能够自动被分配到不同的版本上去。这种方式的优点在于部署简单，不需要过多的改动。但是这样做就会增加运维人员的负担，改动负载均衡系统的配置具有一定的风险。

随着云眼A/B测试软件的广泛应用，人们开始利用AB测试软件进行灰度发布和灰度测试，这样不仅能够保证新版的工程正确性，也能保证新版本的商业目的得到科学、准确的验证，并且在整个生命周期里都可以持续不断的优化改进。

灰度测试指的是系统测试通过后，将测试版本发布到线上环境，替换部分的线上服务器代码进行预测试。当灰度测试结束后，线上版本实现会统一。本质上是上线前的测试，收集用户的反馈。

A/B测试指的是系统测试通过并发布后，同一个软件功能不同的用户会看到不同的实现方式，收集每个用户的反馈。本质上是上线后的测试，收集用户的反馈。

灰度测试

指没有限制的内测。但是还是会限制用户身份，即只有有资格的用户才可以获得内测软件。
这时一般就是最后一次测试了，然后就是公测版了，可能有较多的bug……

使用A/B 测试首先需要建立一个测试页面（variation page），这个页面可能在标题字体，背景颜色，措辞等方面与原有页面（control page）有所不同，然后将这两个页面以随机的方式同时推送给所有浏览用户。接下来分别统计两个页面的用户转化率，即可清晰的了解到两种设计的优劣。
传统的A/B测试，是一种把各组变量随机分配到特定的单变量处理水平，把一个或多个测试组的表现与控制组相比较，进行测试的方式。
新的A / B测试，不仅仅其范围限制在web分析方面，而是为其注入新生命，即移动设备端分析。Pathmapp联合创始人兼首席执行官亚当Ceresko表示，今天，开发人员需要大大提高优化工具的性能，移动分析已成为A/B测试增长最快的一个领域。

灰度测试是什么意思？如果您对互联网软件开发行业了解不多，您可能对这个词不太熟悉。事实上，灰度测试是指如果软件要在不久的将来推出新功能，或者进行重大修改，你必须首先做少量的试验工作，然后慢慢增加数量，直到这个新功能覆盖所有系统用户，即新功能上的黑白之间都有灰色，因此这种方法通常也称为灰度测试。

灰度测试又名金丝雀发布、灰度发布，一种在黑白之间发布平滑过渡的方式。可以对其执行A/B测试，也就是说，一些用户继续使用产品功能A，并且一些用户开始使用产品功能B，如果用户不反对B，则逐渐扩大范围并迁移所有用户到B来。灰度测试可以确保整个系统的稳定性，并且可以在初始灰度级找到并调整问题以确保其影响度。

灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。
 

灰度测试有什么作用？

灰度测试可以及早获得用户的反馈，改进产品功能，提高产品质量，允许用户参与产品测试，增强与用户的互动，并减少受产品升级影响的用户范围。

灰度测试步骤：

1、定义目标

2、选定的策略：包括用户规模，发布频率，功能覆盖，回滚策略，运营策略，新旧系统部署策略等。

3、过滤用户：包括用户特征，用户数，用户常用功能，用户范围等。

4、部署系统：部署新系统，部署用户行为分析系统（web analytics），设置流量规则，运营数据分析和微调流量规则

5、发布总结：用户行为分析报告，用户问卷，社交媒体意见收集和产品功能改进列表

6、产品完善

7、新一轮灰度测试或完整发布

测试方法

灰度测试似乎与互联网公司的常见A/B测试相似。外国人似乎没有灰度测试的概念。根据维基百科中A/B测试的定义，A/B测试也称为：A/B/N测试，多变量测试，因此实质上灰度测试可视为A/B测试的特例。只不过为了术语上不至于等同搞混淆，谈谈自己理解的两者的差异。

灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量。A/B测试重点是在几种方案中选择最优方案。

灰度测试的要点注意

1、精确的流量分发控制

这是一切的核心。从运行和维护风险控制的角度来看，有必要在一个精确的范围内控制受影响的流量。在上线前就知道哪部分用户会有问题，而不是真出问题谁受到影响都不知道。一个常见场景是新版本只允许公司内的员工访问它，然后推送到一个城市再到一个省。

从产品的角度做A/B测试，需要控制测试样本，其中用户是版本A，哪个用户是版本B，应该在发布后修复，而不是一会访问A，一会访问B。传统的负载均衡器策略只能实现粗略的比例分配，并且没有细粒度的流量规则控制。理想的灰度发布系统应具有非常细粒度的流量规则，例如匹配Android用户，匹配特定区域中的用户，甚至组合多个条件以匹配特定人员。

2、监控系统的支撑

准确的流量分配只是第一步，获得关键指标的多个版本更为重要。对于操作和维护，可能需要查看系统级指示器，例如错误率，吞吐量，延迟和CPU内存消耗这些系统层面指标。对于产品，可能是由于pv，uv等业务指标的变化。这些需要能够收集和显示数据，以方便后续决策：完全推送还是回滚？使用方案A或B？否则，灰度版本不会带来更多业务推广，也不能帮助您更好地了解业务状态和用户行为。

3、灵活的发布系统

从以上描述可以看出，灰度发布不是短暂的过程并且可能持续很长时间。例如，主要框架或系统更新可能会持续很长时间。有可能整个服务在几个月内都是新旧并存，甚至可能需要分别进行两个版本的迭代。从产品的角度来看，它可能更灵活。很可能在线上有五到六个程序来收集数据。每天有了一些新想法都要上一些小版本看效果，每个版本上线后可能都要再各自做优化调整观察效果。这种情况可能线上就永远不会有一个统一的版本灰度反而是个常态来应对不断变化的需求和挑战。

而发布系统也需要做相应的调整，不在把每个服务看成一个单一版本的运行体，只在更新的短时间内出现多版本共存，只允许全量推和回滚这种粗粒度策略。相反，多版本共存应被视为正常状态，允许迭代每个版本，并且可以在版本之间区分相应的监视日志信息，从而可以将灵活的发布系统与灵活的灰度策略相结合。

灰度使用黑色调表示物体。 每个灰度对象都具有从 0%（白色）到 灰度条

100%（黑色）的亮度值。 使用黑白或灰度扫描仪生成的图像通常以灰度显示。 使用灰度还可将彩色图稿转换为高质量黑白图稿。 在这种情况下，Adobe Illustrator 放弃原始图稿中的所有颜色信息；转换对象的灰色级别（阴影）表示原始对象的亮度。 将灰度对象转换为 RGB 时，每个对象的颜色值代表对象之前的灰度值。 也可以将灰度对象转换为 CMYK 对象。 自然界中的大部分物体平均灰度为18％。 在物体的边缘呈现灰度的不连续性，图像分割就是基于这个原理。灰度测试 就是测试亮度。

在一般情况下，升级服务器端应用，需要将应用源码或程序包上传到服务器，然后停止掉老版本服务，再启动新版本。但是这种简单的发布方式存在两个问题，一方面，在新版本升级过程中，服务是暂时中断的，另一方面，如果新版本有BUG，升级失败，回滚起来也非常麻烦，容易造成更长时间的服务不可用。

为了解决这些问题，人们研究出了多种发布策略，下面我们一一介绍。

蓝绿部署

所谓蓝绿部署，是指同时运行两个版本的应用，如上图所示，蓝绿部署的时候，并不停止掉老版本，而是直接部署一套新版本，等新版本运行起来后，再将流量切换到新版本上。但是蓝绿部署要求在升级过程中，同时运行两套程序，对硬件的要求就是日常所需的二倍，比如日常运行时，需要10台服务器支撑业务，那么使用蓝绿部署，你就需要购置二十台服务器。

滚动发布

所谓滚动升级，就是在升级过程中，并不一下子启动所有新版本，是先启动一台新版本，再停止一台老版本，然后再启动一台新版本，再停止一台老版本，直到升级完成，这样的话，如果日常需要10台服务器，那么升级过程中也就只需要11台就行了。

但是滚动升级有一个问题，在开始滚动升级后，流量会直接流向已经启动起来的新版本，但是这个时候，新版本是不一定可用的，比如需要进一步的测试才能确认。那么在滚动升级期间，整个系统就处于非常不稳定的状态，如果发现了问题，也比较难以确定是新版本还是老版本造成的问题。

为了解决这个问题，我们需要为滚动升级实现流量控制能力。

灰度发布

灰度发布也叫金丝雀发布，起源是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，如果金丝雀不叫了，就代表瓦斯浓度高。

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。

当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。

如果在灰度发布过程中（灰度期）发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。

################################################################

使用脉冲云轻松地实现灰度发布-查看视频

脉冲云的部署管理可以轻松实现上述的带有流量管理功能的灰度发布。正常编辑应用信息后点击保存，然后脉冲云会提示直接升级或灰度发布。

直接升级就是使用一般的滚动升级，点击灰度发布后可以人工干预升级过程，进行流量控制。

选择灰度发布后，就会呈现灰度发布控制面板。

在这个控制面板上，可以拖拉滑块，快速调整新旧版本的运行副本数量，同时也可以按百分比，将流量导入到新版本上。此外，还可以通过匹配HTTP Header，指定个别用户的流量到新版本上。

除了匹配用户流量的HTTP请求头，还可以直接指定匹配请求头中的Cookie信息，匹配规则支持精确匹配、包含、正则、前缀、后缀等，甚至还允许反向匹配。

当确认新版本运行无误后，就可以点击 完成升级 按钮，就会将流量全部切换到新版本上，并且销毁掉所有老版本应用。如果新版本出了问题，可以点击 取消升级 按钮，立即将流量切回老版本，并销毁掉新版本应用。

总结

在新版本应用发布时，为了服务器不停机升级，使用灰度发布策略，在灰度发布开始时，使用HTTP Header 匹配指定测试人员的流量到新版本上，然后当新版本内部测试通过后，可以再按百分比，将用户流量一点一点导入到新版本中，比如先导入10%观察一下运行情况，然后再导入20%，如此累加，直到将流量全部导入到新版本上，最后完成升级，如果期间发现问题，就立即取消升级，将流量切回到老版本。

运用灰度发布，就再也不需要加班到深夜进行停机升级了，在白天就可以放心大胆地、安全地发布新版本。

A/B测试与灰度发布的理论产品是多维度的，设计体验、交互体验、系统质量、运营支持等等，测试的目的是为了系统最终的交付，一套各方面都足够好的系统，而不是文档上定义的系统，系统是需要不断进化的。测试的质疑贯穿产品的设计到编码到最终的运营过程，并最终促使产品的改善，周而复始。符合互联网思维敏捷的本质。

1、A/B测试与灰度发布相关的一些术语

1.1 桶测试（Bucket Testing）：这个没有什么地方给出明确的定义，但是通常来说是国外用于测试游泳池是否存在漏水行为的一种比较测试。即将一桶水放到泳池中，分别标明内外水位，放置一段时间后，如果外部水位明显下降（超过XXX英寸），则证明水池漏水。这个和软件测试没有什么直接关系，但是他是一种两个方案之间的对比性测试，用于识别缺陷。

1.2 多变量测试（Multivariate Testing）：这个使用市场营销的一个术语，通常用于在多个变量的复杂环境下，对营销方案效果的比较技术。

1.3 A/B测试（A/B Testing）：Wikipedia的定义，“是Web设计（通常指用户体验）中用于区分两种网页设计对收益最大化目标（如点击率）效果支撑程度的一种试验手段”。主要用于比较两种设计的优劣程度。桶测试（Bucket Test）、多变量测试（Multivariate Testing）是A/B测试的变体，因为可能涉及到多种场景的比较。A/B测试还用于市场营销渠道的比较，这和定义是一致的，因为网页就是一种营销渠道。

1.4 灰度交付：“灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。”

2、A/B测试和灰度发布和传统的测试的不同点

2.1 可以有多个现成的产品来，实实在在的去测试（桶测试）

2.2 A/B测试是支持多变量测试的一种方式

2.3 A/B测试时一套系统，是灰度发布的一种实现方式

到此为止，测试与运维已经集成到一个过程当中了

3、A/B测试与灰度发布的运用

3.1 推荐系统之间不同算法的比较，不同变量的比较

3.2 设计方案中不同方案的比较

3.3 设计调整，方案调整

3.4 故障控制

如果你系统需要优化一些你自己无法预测和控制的领域的时候。

试试A/B测试吧，有利于控制未来的风险

数据是优化系统的重要依据 ，想要在哪方面做优化，就在哪方面积累数据。

后面再写点A/B测试与灰度发布系统实战

在淘宝仲明的一个访谈中第一次看到灰度测试这个词，其解释是灰度测试的专业说法是Bucket Test。这两个术语都可以互联网应用的测试扯上关系，但是含义还确实不同。

• A/B测试（A/B Testing）：Wikipedia的定义，“是Web设计（通常指用户体验）中用于区分两种网页设计对收益最大化目标（如点击率）效果支撑程度的一种试验手段”。主要用于比较两种设计的优劣程度。桶测试（Bucket Test）、多变量测试（Multivariate Testing）是A/B测试的变体，因为可能涉及到多种场景的比较。A/B测试还用于市场营销渠道的比较，这和定义是一致的，因为网页就是一种营销渠道。
• 多变量测试（Multivariate Testing）：这个使用市场营销的一个术语，通常用于在多个变量的复杂环境下，对营销方案效果的比较技术。
• 桶测试（Bucket Testing）：这个没有什么地方给出明确的定义，但是通常来说是国外用于测试游泳池是否存在漏水行为的一种比较测试。即将一桶水放到泳池中，分别标明内外水位，放置一段时间后，如果外部水位明显下降（超过XXX英寸），则证明水池漏水。这个和软件测试没有什么直接关系，但是他是一种两个方案之间的对比性测试，用于识别缺陷。
• 测试驱动开发（TDD）：Kent Beck在TDD一书中也提到了水桶和编程的关系，“设想把编程看成是转动曲柄从井里提一桶水上来的过程。如果水桶比较小，那么仅需一个能自由转动的曲柄就可以了。如果水桶比较大而且装满水，那么还没等水桶全部被提上来你就会很累了。你需要一个防倒转的装置，以保证每转一次可以休息一会儿。水桶越重，防倒转的棘齿相距越近。 测试驱动开发中的测试程序就是防倒转装置上的棘齿。一旦我们的某个测试程序能工作了，你就知道，它从现在开始并且以后永远都可以工作了。相比于测试程序没有通过，你距离让所有的测试程序都工作又近了一步。现在我们的工作是让下一个测试程序工作，然后再下一个，就这样一直进行。分析表明，要编程解决的问题越难，每次测试所覆盖的范围就应该越小”这个里面实际上和桶测试（Bucket Testing）没有任何关系，仅仅是一个类比，不用桶，用其他机械装置也是一样对比。
• 灰度交付：百度百科的定义，“灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。”

回到正题上，互联网应用在交付上线过程中（运维部门的职能），需要经过灰度交付和A/B测试两个环节，前者用于检验系统是否稳定可靠，满足上线要求，需要收集和分析性能数据来决定；后者用于检验到底新版本好还是旧版本好，需要收集和分析用户访问数据来决定。

因此结论是灰度交付和A/B测试（桶测试）有不同的目标和手段。

下图是阿里软件的发布引擎，支持灰度交付。

灰度测试是什么意思呢？如果对互联网软件研发行业不太了解的话，可能对这个词还是很陌生的，其实灰度测试就是指如果软件要在不久的将来推出一个全新的功能，或者做一次比较重大的改版的话，要先进行一个小范围的尝试工作，然后再慢慢放量，直到这个全新的功能覆盖到所有的系统用户，也就是说在新功能上线的黑白之间有一个灰，所以这种方法也通常被称为灰度测试。

从目前来看，灰度测试存在两种方式，一种是软件系统内自带灰度测试发布系统，另一种方式就是使用第三方工具来辅助进行，这两种方法都是可行的。

灰度测试这种方法可以帮助研究团队快速试验并发现问题并在大规模推向用户之前及时把问题修正过来，很大成度上减少了不少风险的产生，所以灰度测试是很有必要的。要知道只有不断创意并完善的软件才能在激烈的市场竞争中立于不败之地，当有创意的时候，小规模的灰度测试是非常有必要的。不但满足了一部分人抢先体验的愿望同时也可以发展研发团队不容易发现的各种问题，还能收集到真正的用户体验，这些对于优化全新的系统内容都是非常有帮助的，如果没有灰度测试的话，其实和闭门造车的感觉是差不多了，在增加灰度测试以后才能真正把其推向用户。

灰度测试存在的意义是什么呢？要知道现在很多互联网产品都存在用户规模非常大，版本更新过于频繁的问题，每当有新版本进行更新或者上线的时候，新的版本都是要承受非常大的压力的，而灰度测试的使用则可以很好的规避这种存在可能性非常大的风险问题。

例子：

摘要：滴滴开放灰度测试是什么情况？滴滴开放灰度测试具体怎么回事？据知情人士透露，滴滴顺风车上周在小范围内开放灰度测试。4月23日，有网友向记者反映，滴滴在内测新的拼车产品，用户需要预约15～30分钟之内出发的车辆，可选择乘车人数。该产品无论使用体验和价格都和原来的顺风车类似。

　　滴滴开放灰度测试是什么情况？滴滴开放灰度测试具体怎么回事？据知情人士透露，滴滴顺风车上周在小范围内开放灰度测试。4月23日，有网友向记者反映，滴滴在内测新的拼车产品，用户需要预约15～30分钟之内出发的车辆，可选择乘车人数。该产品无论使用体验和价格都和原来的顺风车类似。

　　根据界面新闻拿到的一张截图显示，上海用户已成功显示顺风车预约界面及价格。顺风车的入口位于公众评议右侧。而据滴滴官方表示，公众评议于去年11月2号正式上线，会不定期出现在滴滴的APP内。此前，滴滴内部员工向界面新闻记者透露，顺风车业务线的领导希望今年六月能上线，目前产品已经准备好，不过公司层面还没有做好决策。
　　延伸：滴滴顺风车
　　滴滴顺风车是北京小桔科技有限公司推出的一款拼车软件，继“滴滴打车”、“滴滴专车”、滴滴企业出行服务后在移动出行领域推出的第四款产品。
　　2018年8月24日，温州乐清发生滴滴顺风车司机强奸杀人案件，现嫌疑人已被警方控制。2018年8月25日下午，浙江省道路运输管理局紧急约谈滴滴平台浙江区负责人，鉴于滴滴平台顺风车业务存在重大安全隐患，浙江省道路运输管理局要求滴滴平台立即整改，整改期间暂停其在浙江区域的顺风车业务。
2：

灰度：使用黑色调表示物体，即用黑色为基准色，不同的饱和度的黑色来显示图像。 每个灰度对象都具有从0%（白色）到100%（黑色）的亮度值。（注意这个百分比是以纯黑为基准的百分比。与RGB正好相反，百分比越高颜色越偏黑，百分比越低颜色越偏白。科普一下：RGB即Red红色、Green绿色、Blue蓝色。RGB色彩模式是工业界的一种颜色标准，是通过红(R)、绿(G)、蓝(B)三个颜色通道的变化以及它们相互之间的叠加来得到各式各样的颜色的，这个标准几乎包括了人类视力所能感知的所有颜色。）

简而言之，灰度指不饱和的黑色。

自然界中的大部分物体平均灰度为18%。我们平常所说的黑白照片、黑白电视，实际上都应该称为灰度照片、灰度电视才确切。灰度色中不包含任何色相，即不存在红色、黄色这样的颜色。

以上可以认为是废话，转入今天的标题。

2015年5月31日，马化腾在香港大学李兆基会议中心大礼堂举办了一场创业演讲，演讲中爆了一个大料：微信的诞生史。

微信在诞生之前，在腾讯内部有三个团队在同时做微信，主要竞争者为张小龙的e-mail团队和手机QQ团队。做这个产品之前，腾讯内部并没有给这个产品定一个完整的基调，而是让公司内部形成一个激烈的竞争，通过观察用户对产品的喜好程度和产品的实际完成情况决定上线结果。

马化腾的灰度机制是这样的：很多公司在一开始做产品定义时，要么确定它是黑的，要么确定它是白的。但是马化腾发现，互联网产品的定义是有用户投票决定的。在一开始，我们不定义它是黑，还是白，有一个灰度的周期。在这个灰度周期里，让用户的口碑决定它是生是死，是白还是黑。

说的再直接点，这也是马化腾创新上的灰度机制：容忍失败，允许适度浪费，鼓励内部竞争内部试错。马化腾说过，在产品研发过程中，我们还会有一个困惑：自己做的这个产品万一失败了怎么办？“我的经验是，在面对创新的问题上，要允许适度的浪费。怎么理解？就是在资源许可的前提下，即使有一两个团队同时研发一款产品也是可以接受的，只要你认为这个项目是你在战略上必须做的。很多人都看到了微信的成功，但大家不知道，其实在腾讯内部，先后有几个团队都在同时研发基于手机的通讯软件，每个团队的设计理念和实现方式都不一样，最后微信受到了更多用户的青睐。你能说这是资源的浪费吗？我认为不是，没有竞争就意味着创新的死亡。即使最后有的团队在竞争中失败，但它依然是激发成功者灵感的源泉，可以把它理解为内部试错。”

总结一下，马化腾的“灰度机制”包括7个维度：

具体内容，请参考：《马化腾致信合作伙伴：灰度法则的七个维度》

1. 需求度：用户需求是产品核心，产品对需求的体现程度，就是企业被生态所需要的程度；
2. 速度：快速实现单点突破，角度、锐度尤其是速度，是产品在生态中存在发展的根本；
3. 灵活度：敏捷企业、快速迭代产品的关键是主动变化，主动变化比应变能力更重要；
4. 冗余度：容忍失败，允许适度浪费，鼓励内部竞争内部试错，不尝试失败就没有成功；
5. 开放协作度：最大程度地扩展协作，互联网很多恶性竞争都可以转向协作型创新；
6. 进化度：构建生物型组织，让企业组织本身在无控过程中拥有自进化、自组织能力；
7. 创新度：创新并非刻意为之，而是充满可能性、多样性的生物型组织的必然产物。

下面说说灰度上线

楼主在去哪儿工作时，发现自己和同事手机里的APP展示页面不同，于是就问什么情况，为什么没有自动更新。PM告诉我是ABtest，当时还不知道什么意思。

先来看看百度百科的定义：

灰度发布：是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

传统的产品研发模式大致可以分为：

产品调研-架构评估-产品启动-需求分析-产品设计-产品开发-产品发布

七大阶段。

实际情况中，你会发现，从产品调研到产品发布，总是一拖到底。这样的做法对于范围比较大，周期比较长的项目，尤其是用户体验类项目而言，存在较大的弊端：我们很可能在没有足够清楚用户需求的情况下，定制了过多的辅助功能，这样即拉长了项目周期，又无谓的投入了过多的人力。

灰度上线，简单点理解就是按产品需求优先级，抽出核心需求，在满足用户基本要求的情况下快速上线，并通过限制流量、白名单等机制进行产品试用，以此收集用户的意见，从而萃取出用户潜在的需求，形成后续更有针对性的设计方案。

和传统研发模式相比，这么做唯一的区别就在于将原先一锅粥式的需求和功能点进行了轻重缓急的排序，并以此将项目从原来的单长线作战转化为多迭代短线循环，让产品的生命周期不再昙花一现。

如此一来，需求分析阶段显得尤为关键，我们必须清晰的将需求按优先级归纳分类为几个序列，如：p1，p2，p3…核心功能和必备的体验在p1序列，辅助功能点和辅助型体验列在p2序列，争执不定的需求点可以放在p3序列。需求排序后，我们可以将项目发布点有序的分成（>2期），第一期只确保主要的核心功能和基础体验快速灰度上线，随后通过用户访谈、产品的tracker&session数据、业务数据等手段分析出用户对产品的真实反应，并以此调整二期需求，该加的加，该砍的砍，做到有的放矢。

下面是百度百科定义的灰度发布的步骤：

1. 定义目标；
2. 选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等；
3. 筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等；
4. 部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调；
5. 发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表；
6. 产品完善；
7. 新一轮灰度发布或完整发布。

虽然，灰度、灰度机制、灰度发布之间的概念完全不一致，但是都包含着从黑到白的过程。所以，瞎扯了一通。