互联 产品的灰度发布

在传统软件产品发布过程中（例如微软的Windows 7的发布过程中），一般都会经历Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等几个阶段（参考Software release life cycle）。可以看出传统软件的发布阶段是从公司内部->外部小范围测试>外部大范围测试->正式发布，涉及的用户数也是逐步放量的过程。

    在互联 产品的发布过程中也较多采用此种发布方式：产品的发布过程不是一蹴而就，而是逐步扩大使用用户的范围，从公司内部用户->忠诚度较高的种子用户->更大范围的活跃用户->所有用户。在此过程中，产品团队根据用户的反馈及时完善产品相关功能。此种发布方式，按照中国特色的叫法被冠以”灰度发布“、”灰度放量“、”分流发布“。

A/B测试也是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B反应良好，那么逐步扩大范围，把所有用户都迁移到B上面来。现在比较通行的实践方法，是在用户登录 站完成认证后，根据用户ID Hash后均衡地重定向（Redirect）到A服务器和B服务器。

复杂的后台系统在上线，需要由开发部门向运维部门移安装部署手册，不然运维部门有足够的理由拒绝接手。我们对用到的系统和应用软件都做了统一的rpm包和配置管理工具。系统工程师根据部署手册中配置定义的描述和安装步骤，按要求进行服务器安装，全程不需要开发工程师干预。对于前端PHP代码上线，使用统一的上线系统进行上线管理。开发工程师通过svn提交的代码统一由上线系统复制到线上的PHP服务器群，保证所有服务器上代码的一致性。后端JBoss服务器应用war包的更新，也由测试人员提交到svn服务器，运维人员使用脚本进行系统更新和重启。

Facebook逐步发布&暗启动

Facebook有一个系统，他们称之为“门卫”。该系统可以针对不同种类的用户运行不同的代码。（它简单介绍了代码库中的不同条件。）该系统让Facebook逐步发布新特性、A/B测试、激活仅针对Facebook员工的特性 等等。

门卫系统也让Facebook做些“暗启动”的事情。比如，在某一特性上线之前，可以激活该特性背后的元件。另外，它还可以做模拟压力测试，发现瓶颈和潜在的问题。默默启动一般都是在正式启动之前的2周完成。

1、灰度发布的作用

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

2、灰度发布的步骤

  1）、定义目标

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

  3）、筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等

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

  5）、发布总结：用户行为分析 告、用户问卷调查、 会化媒体意见收集、形成产品功能改进列表

  6）、产品完善

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

3、常见问题

  3.1）、以偏概全

         1)、问题特征：

              a、选择的样本不具有代表性；

              b、样本具有代表性，但选择样本用户使用习惯并没有涵盖所有核心功能 
         2）、解决方案：

              样本选择要多样化，样本的组合涵盖大部分核心功能

  3.2）、知识的诅咒

        ”知识的诅咒“的说法来自《粘住》中实验，具体可以自己搜索一下。我们自己对于自己开发的产品极为熟悉，于是乎想当然认为用户也应当能够理解产品的设计思路、产品的功能使用。

         1）、问题特征：

               a、结果没有量化手段；

               b、只依赖于用户问卷调查；

               c、没有web analytics系统；

               d、运营数据不全面，只有核心业务指标（例如交易量），没有用户体验指标

               e、对结果分析，只选择对发布有利的信息，对其他视而不见 
          2）、解决方案： 
               a、产品设计考虑产品量化指标 
               b、结果分析依据量化指标而不是感觉

  3.3）、发布没有回头路可走

        1）、问题特征：

              a、新旧系统用户使用习惯差异太大，没有兼容原有功能

              b、新旧系统由于功能差异太大，无法并行运行，只能强制升级

              c、新系统只是实现了旧系统部分功能，用户要完整使用所有功能，要在 在新旧系统切换

              d、新旧系统数据库数据结构差异太大，无法并行运行

         2）、解决方案：

              前期产品策划重点考虑这些问题，包括：

                  回滚方案、 新旧系统兼容方案、用户体验的一致性、用户使用习惯的延续性、新旧系统数据模型兼容性

  3.4）、用户参与度不够

         1）、问题特征：

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

4、灰度发布  VS.  A/B测试

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

    灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量

    A/B测试重点是在几种方案中选择最优方案

   关于A/B测试可以参考这篇文章：A/B测试终极指南

5、灰度发布引擎

   对于一般的小系统并不需要单独的灰度发布引擎，可以参考A/B测试中做法，在页面javascript或服务器端实现分流的规则即可。但对于大型的互联 应用而言，单独的用于管理用户分流的发布引擎就很有必要了。“钱掌柜”分流发布模式 提到了原来阿里软件所使用的灰度发布引擎，设计思路具有普遍性，可以供参考

6、参考文档

  “钱掌柜”分流发布模式：  http://www.kuqin.com/software-engineer/20100908/87787.html

   百度百科：灰度发布

   A/B testing

   A/B测试终极指南