灰度发布
灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
1）定义目标
2）选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
3）筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
4）部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
5）发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
6）产品完善
7）新一轮灰度发布或完整发布
以偏概全
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 。
链接：http://www.zhihu.com/question/20584476/answer/15558660
我所理解的灰度发布系统，主要任务是从产品用户群中按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的显式反馈（论坛、微博）或隐式反馈（应用自身统计数据），对新版本应用的功能、性能、稳定性等指标进行评判，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。
从上述描述可以得出灰度发布系统需要具备的一些要素：
用户标识
用于区分用户，辅助数据统计，保证灰度发布过程中用户体验的连贯性（避免用户在新旧版本中跳变，匿名Web应用比较容易有这个问题）。匿名Web应用可采用IP、Cookie等，需登录的应用可直接采用应用的帐号体系。
目标用户选取策略
即选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择，最好能够提供让用户自主回滚至旧版本的渠道。
对于客户端应用，可以考虑类似Chrome的多channel升级策略，让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。
数据反馈
用户数据反馈：在得到用户允许的前提下，收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比，决策后续是继续扩大新版本投放范围还是回滚。
服务端数据反馈：新版本服务端性能、服务端稳定性等，作用与用户数据反馈类似。
新版本回滚策略
当新版本灰度发布表现不佳时，应回滚至旧版本。对于纯粹的Web应用而言，回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用，如果期待用户自行卸载新版本另行安装旧版本，成本和流失率都太高。可以考虑通过快速另行发布新版本，利用升级来“回滚”，覆盖上次灰度发布的修改。
对于移动客户端，新版本发布成本较高，需要Appstore、Market审核。本人没有移动客户端产品的经验，不太确定移动客户端产品如何处理灰度发布及回滚。但尽量将客户端打造成Web App，会更有利于升级和回滚。（不过苹果对纯Web App类的App有较强的限制，好像已经不允许在Appstore上发布这类应用了？）
新版本公关运营支持
对于改版级别的大型升级，需要配合公关运营支持，用于及时处理用户在微博、博客等渠道给出的“显式反馈”。对比通过隐式数据反馈得到的结论后，综合考虑应对策略。
从上述描述可以得出灰度发布系统需要具备的一些要素：
用户标识
用于区分用户，辅助数据统计，保证灰度发布过程中用户体验的连贯性（避免用户在新旧版本中跳变，匿名Web应用比较容易有这个问题）。匿名Web应用可采用IP、Cookie等，需登录的应用可直接采用应用的帐号体系。
目标用户选取策略
即选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择，最好能够提供让用户自主回滚至旧版本的渠道。
对于客户端应用，可以考虑类似Chrome的多channel升级策略，让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。
数据反馈
用户数据反馈：在得到用户允许的前提下，收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比，决策后续是继续扩大新版本投放范围还是回滚。
服务端数据反馈：新版本服务端性能、服务端稳定性等，作用与用户数据反馈类似。
新版本回滚策略
当新版本灰度发布表现不佳时，应回滚至旧版本。对于纯粹的Web应用而言，回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用，如果期待用户自行卸载新版本另行安装旧版本，成本和流失率都太高。可以考虑通过快速另行发布新版本，利用升级来“回滚”，覆盖上次灰度发布的修改。
对于移动客户端，新版本发布成本较高，需要Appstore、Market审核。本人没有移动客户端产品的经验，不太确定移动客户端产品如何处理灰度发布及回滚。但尽量将客户端打造成Web App，会更有利于升级和回滚。（不过苹果对纯Web App类的App有较强的限制，好像已经不允许在Appstore上发布这类应用了？）
新版本公关运营支持
对于改版级别的大型升级，需要配合公关运营支持，用于及时处理用户在微博、博客等渠道给出的“显式反馈”。对比通过隐式数据反馈得到的结论后，综合考虑应对策略。
具体软件方面：
海外应用用optimizely，国内应用可以考虑AppAdhoc，AppAdhoc简单够用，optimizely相当强大，尤其在native app A/B测试这块，具体自己用用就知道了。