我自己写了一个灰度小工具

什么是灰度发布？

概念

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以***保证整体系统的稳定***，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。

作用

1. 及早获得用户的意见反馈，完善产品功能，提升产品质量 让用户参与产品测试，加强与用户互动 降低产品升级所影响的用户范围
2. 保证系统的稳定性，安全性。假如直接全量发布，如果有bug，那么将会影响到全量用户，而如果采用灰度发布，即使新上线的内容有bug，对用户的影响面也是可控的。

步骤

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

测试方法

灰度发布与互联网公司常用A/B测试似乎比较类似，国外互联网公司似乎并没有所谓的灰度发布的概念。按照wikipedia中对A/B测试的定义，A/B测试又叫：A/B/N Testing、Multivariate Testing，因此本质上灰度测试可以算作A/B测试的一种特例。只不过为了术语上不至于等同搞混淆，谈谈自己理解的两者的差异。

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

灰度发布引擎

对于一般的小系统并不需要单独的灰度发布引擎，可以参考A/B测试中做法，在页面JavaScript或服务器端实现分流的规则即可。但对于大型的互联网应用而言，单独的用于管理用户分流的发布引擎就很有必要了。

常见问题

以偏概全

1）问题特征：
a选择的样本不具有代表性；
b样本具有代表性，但选择样本用户使用习惯并没有涵盖所有核心功能
2）解决方案：
样本选择要多样化，样本的组合涵盖大部分核心功能

知识的诅咒

“知识的诅咒”的说法来自《粘住》中实验，具体可以自己搜索一下。我们自己对于自己开发的产品极为熟悉，于是乎想当然认为用户也应当能够理解产品的设计思路、产品的功能使用，但其实用户与开发的想法可能是完全不同的
1）问题特征：
a结果没有量化手段；
b只依赖于用户问卷调查；
c没有web analytics系统；
d运营数据不全面，只有核心业务指标（例如交易量），没有用户体验指标
e对结果分析，只选择对发布有利的信息，对其他视而不见
2）解决方案：
a产品设计考虑产品量化指标
b结果分析依据量化指标而不是感觉

发布没有回头路可走

1）问题特征：
a新旧系统用户使用习惯差异太大，没有兼容原有功能
b新旧系统由于功能差异太大，无法并行运行，只能强制升级
c新系统只是实现了旧系统部分功能，用户要完整使用所有功能，要在新旧系统切换
d新旧系统数据库数据结构差异太大，无法并行运行
2）解决方案：
前期产品策划重点考虑这些问题，包括：
回滚方案、 新旧系统兼容方案、用户体验的一致性、用户使用习惯的延续性、新旧系统数据模型兼容性

用户参与度不够

1）问题特征：
a指望用户自己去挖掘所有功能。对于一个产品，大部分用户经常只使用部分功能，用户大部分也很懒惰，不会主动去挖掘产品功能
b互动渠道单一
c陷入“知识的诅咒”，不尊重参与用户意见
2）解决方案：
a善待吃螃蟹的样本用户，包括给予参与测试的用户小奖励（例如MS给参与Win7测试用户正版License）、给用户冠以title
b通过邮件、论坛、社区、Blog、Twitter等新媒体与用户形成互动
c提供产品功能向导。在hotmail最近的升级后的功能tip，gmail的tip都有类似的产品功能导向。在产品中会提示类似于：你知道吗，xx还提供xx功能，通过它你可以xx 。

灰度发布例子

***Gmail Labs***是一个新特性橱窗，用户可以自己选择一些未正式发布的新特性进行体验，不喜欢可以关闭，在这个过程中，吃了螃蟹，也当了Google的小白鼠。
这个做法比传统的灰度要高明很多，更加尊重用户：
1、它没有强加用户，用户是否愿意当小白鼠完全自愿
2、新特性不是打包在一起的一个大版本，可以选择某几个喜欢的螃蟹尝尝
3、螃蟹不好吃可以扔掉，不用硬吃进肚子里引发肠胃炎
当然这些好处也是有代价的：
1、要开发一个labs平台实现新特性上架、独立尝试的功能，这可能要改动Gmail的前后台架构
2、新特性要按照一定规范来写，才能发布到这个平台上，可能会增加一些工作量
3、小白鼠用户增多之后，对系统的压力可能会有一定提升，因为每一位用户调用的界面都不一样了
既然Gmail Labs能够顺利发布，那么说明对Google来说，以上这些问题都不算问题。另外，现在展示的新特性，都注明了开发者的名字，那么，Gmail Labs可能会开放这个平台让外部开发者也能提交特性？这倒是很开放的一种开发模式，非常适合Google的web app产品线。
互联网产品有一个特点，就是不停的升级、升级、再升级。
为了避免这些风险，很多产品都采用了灰度发布的策略，其主要思想就是把影响集中到一个点，然后再发散到一个面，出现意外情况后很容易就回退。

QZone是另外一个采用灰度发布的例子。大家都知道，QZone在过去的一年中改进是巨大的，从以前慢悠悠的老爷爷变成了一个充满青春活力的小伙子。其中经历了大小无数次的发布，他们的发布也都是采用了灰度发布的策略，用户数据的升级并不是大面积的一次性升级，而是通过一个用户升级标志服务器，如果用户数据没有升级，后台会把此用户的数据逐步迁移到新版本上&