互联网产品灰度发布

​原文链接：https://blog.csdn.net/boonya/article/details/51537674

1. 前言 

 互联网产品有一个特点，就是不停的升级，升级，再升级。一般采用敏捷开发的团队，基本上保持每周一次的发布频率，系统升级总是伴随着风险，新旧版本兼容的风险，用户使用习惯突然改变而造成用户流失的风险，系统down机的风险.....为了避免这些风险，很多产品都采用了灰度发布的策略，其主要思想就是把影响集中到一个点，然后再发散到一个面，出现意外情况后很容易就回退。

很长时间，我们都一直在改进搜索引擎的排序算法，尽量让最好的商品出现在 搜索结果的第一屏。我们尝试了很多种算法，不断调整各个排序因子所占的比重。但是我们无法确信我们的排序结果能满足所有用户的需求。所以我们采用了灰度发 布，选取几个一级商品类目，在其中应用不同的排序算法，比如在女装类目中，我们把卖家信用所占的比率调整到60%，在珠宝类目中，我们把销售量所占的比率 调整到60%.. 然后发布出去，收集用户反馈，最终选择一种大部分人认为好的算法。

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

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

  关于“灰度发布”叫法的来源无从考察。只不过按照中国传统哲学的说法来看，很符合中国人中庸的思维模式：自然界所有的事物总是以对称、互补、和谐的形式存 在，例如黑与白、阴与阳、正与负、福与祸。在二元对立的元素间存在相互过渡的阶段，所谓”祸兮福所倚，福兮祸所伏“。具体到黑与白，在非黑即白中间还有中 间色——灰色。于是出现了很多关于灰色的说法：灰盒测试，灰色管理（极力推荐 任正非：管理的灰度），灰色收入，灰色地带等等。因此对于灰度发布实际上就是从不发布，然后逐渐过渡到正式发布的一个过程。

 

 

2. 灰度发布定义

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

3. 灰度发布作用

a.及早获得用户的意见反馈，完善产品功能，提升产品质量

b.让用户参与产品测试，加强与用户互动

c.降低产品升级所影响的用户范围

d.规避一定的发布风险

e.避免停服发布给用户带来不便

f.具有容灾能力

4. 灰度发布步骤

  1）、定义目标

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

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

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

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

  6）、产品完善

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

 

5. 灰度发布测试方法

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

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

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

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

 

6. 灰度发布引擎

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

 

  

下面是一个灰度发布的架构示意图：

 

 

7. 灰度发布常见问题

7.1. 以偏概全

7.1.1. 问题特征：
a选择的样本不具有代表性；

b样本具有代表性，但选择样本用户使用习惯并没有涵盖所有核心功能

7.1.2. 解决方案：
样本选择要多样化，样本的组合涵盖大部分核心功能

7.2. 知识的诅咒

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

7.2.1. 问题特征：

a结果没有量化手段；

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

c没有web analytics系统；

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

e对结果分析，只选择对发布有利的信息，对其他视而不见

7.2.2. 解决方案：

a产品设计考虑产品量化指标

b结果分析依据量化指标而不是感觉

7.3. 发布没有回头路可走

7.3.1. 问题特征：

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

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

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

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

7.3.2. 解决方案：

    前期产品策划重点考虑这些问题，包括：回滚方案、 新旧系统兼容方案、用户体验的一致性、用户使用习惯的延续性、新旧系统数据模型兼容性

7.4. 用户参与度不够

7.4.1. 问题特征：

a指望用户自己去挖掘所有功能。对于一个产品，大部分用户经常只使用部分功能，用户大部分也很懒惰，不会主动去挖掘产品功能

b互动渠道单一

c陷入“知识的诅咒”，不尊重参与用户意见

7.4.2. 解决方案：

a善待吃螃蟹的样本用户，包括给予参与测试的用户小奖励（例如MS给参与Win7测试用户正版License）、给用户冠以title

b通过邮件、论坛、社区、Blog、Twitter等新媒体与用户形成互动

c提供产品功能向导。在hotmail最近的升级后的功能tip，gmail的tip都有类似的产品功能导向。在产品中会提示类似于：你知道吗，xx还提供xx功能，通过它你可以xx 。

8. 让产品具备灰度发布能力

8.1. 灰度机制的七个维度

8.1.1. 需求度

用户需求是产品核心，产品对需求的体现程度，就是企业被生态所需要的程度;

8.1.2. 速度

快速实现单点突破，角度、锐度尤其是速度，是产品在生态中存在发展的根本;

8.1.3. 灵活度

敏捷企业、快速迭代产品的关键是主动变化，主动变化比应变能力更重要;

8.1.4. 冗余度

容忍失败，允许适度浪费，鼓励内部竞争内部试错，不尝试失败就没有成功;

8.1.5. 开放协作度

最大程度地扩展协作，互联网很多恶性竞争都可以转向协作型创新;

8.1.6. 进化度

构建生物型组织，让企业组织本身在无控过程中拥有自进化、自组织能力;

8.1.7. 创新度

创新并非刻意为之，而是充满可能性、多样性的生物型组织的必然产物。

8.2. 灰度发布的策略要素

8.2.1. 易于发布到云平台

    一般采用灰度发布都是具有自主产品的平台模式发布，而不是在客户服务器端进行发布，具备自主研发产品和有一定硬件部署能力的企业可以考虑灰度发布。

灰度发布一般是基于云的需要，如负载均衡，用户隔离等机制。如大型的电商网站等都是采用的分布式部署方式，利用负载均衡实现服务器分发，将用户访问分配到不同的地区服务器访问，确保用户访问效率，提升用户体验。

之所以强调易于发布，就是公司要具备自己可操作的服务器设备（云服务设备），这样可以实现在用户不知情的情况下实现灰度发布。即，在用户无感知的情况下实现最优配置的测试部署，提升产品质量，实现产品快速迭代——频繁发布，实现具有意义的‘实时发布’策略。

注：需要开通云服务模式（有一定硬件和经济实力的公司可以考虑）。

 

8.2.2. 设置用户标识策略

用于区分用户，辅助数据统计，保证灰度发布过程中用户体验的连贯性（避免用户在新旧版本中跳变，匿名Web应用比较容易有这个问题）。匿名Web应用可采用IP、Cookie等，需登录的应用可直接采用应用的帐号体系。

8.2.3. 目标用户选取策略

即选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择，最好能够提供让用户自主回滚至旧版本的渠道。

对于客户端应用，可以考虑类似Chrome的多channel升级策略，让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。

8.2.4. 提供数据反馈入口

     用户数据反馈：在得到用户允许的前提下，收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比，决策后续是继续扩大新版本投放范围还是回滚。
     服务端数据反馈：新版本服务端性能、服务端稳定性等，作用与用户数据反馈类似。

8.2.5. 新版本回滚策略

当新版本灰度发布表现不佳时，应回滚至旧版本。对于纯粹的Web应用而言，回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用，如果期待用户自行卸载新版本另行安装旧版本，成本和流失率都太高。可以考虑通过快速另行发布新版本，利用升级来“回滚”，覆盖上次灰度发布的修改。

对于移动客户端，新版本发布成本较高，需要Appstore、Market审核。本人没有移动客户端产品的经验，不太确定移动客户端产品如何处理灰度发布及回滚。但尽量将客户端打造成Web App，会更有利于升级和回滚。（不过苹果对纯Web App类的App有较强的限制，好像已经不允许在Appstore上发布这类应用了？）

8.2.6. 新版本公关运营支持

对于改版级别的大型升级，需要配合公关运营支持，用于及时处理用户在微博、博客等渠道给出的“显式反馈”。对比通过隐式数据反馈得到的结论后，综合考虑应对策略。

8.3. 灰度发布的方案

灰度发布一般有三种方式 nginx+lua，nginx根据cookie分流，nginx 根据权重来分配：
     nginx+lua根据来访者ip地址区分，由于公司出口是一个ip地址，会出现访问网站要么都是老版，要么都是新版，采用这种方式并不适合nginx 根据权重来分配，实现很简单，也可以尝试nginx根据cookie分流，灰度发布基于用户才更合理。

 

Nginx+lua配置可以参考如下文章进行实践：

利用nginx+lua+memcache实现灰度发布

 

Nginx+Lua+Redis实例

 

nginx灰度方案---基于ip或者基于cookies

 

8.3.1. 方案一：代码逻辑控制

实现：

在代码中埋开关，做if-else判断，对于需要灰度的机器，设置开关为on，否则为off。每次版本发布都是有两个版本。

优点

· 快速回滚，不需要重新发布和重启系统。

缺点

· 对代码有倾入性。

· 分支逻辑，带来复杂性。

这种方式笔者曾经应用过，就是在阿里的时候把商品的数据库从Oracle切换到MySql，使用了一个状态变量进行控制。从而打到平滑迁移的效果。

 

8.3.2. 方案二：Alibaba预发机制

    其实这个不是真正意义上的灰度。因为这个预先发布机器是内部IP，没有对外服务的。需要绑定域名进行验证。但是数据是完全的线上。所以本质上是灰度 某些特定用户（可以访问灰度机器的用户，内部测试用户）的一种简单做法。其实API这边也有类似的做法，就是我们的Gamma环境，而且我们还提供了 Gamma机器的域名，方便外部合作用户配合测试。

优点

· 简单

缺点

· 浪费一台机器（这个可以预先发布完成之后投入正式环境，预发布的时候从nginx摘除，不过需要运维支持。）

· 不够灵活

· 只能针对接入层机器，IDL服务灰度需要另外考虑。

8.3.3. 方案三：SET部署

8.3.3.1. 按照业务隔离部署
    比如现在API Container的做法，部署的粒度可以到API级别，前端根据nginx进行转发。比如：

· 微购物 API Container: api.weigou.qq.com

· 拍拍 API Container：api.paipai.com

· 易迅 API Container: api.yixun.com

· 网购 API Container：api.buy.qq.com

    上面是大业务级别的隔离部署。还可以进一步细化到模块级别，比如虚拟服务电商的API，是挂在拍拍下面的一个子业务模块，但是由于他们接入微信之 后，访问量大增，为了避免影响拍拍其他业务，也为了避免受其他业务影响，API这里是给他们单独部署了两台机器，nginx配置一下就可以将针对虚拟的 API访问引流过来了：

虚拟API Container：http://api.paipai.com/v2/virbiz

这样，我们在发布一个版本的时候，可以先选择业务量最小的易迅进行发布，观察没有问题再全量其他平台。

8.3.3.2. 按照用户隔离部署
    这个对于开放平台来说不是很适合，不过对于SNS这种应用场景就很合适了。比如QQ系统，按照用户号码段分为若干个set，每个set包含连续1亿 个号码的用户。假设现在最新的QQ号码接近10亿，则总共有10个set（Set 1到Set 10）。这样每次可以选择其中一个SET进行发布，而且高位QQ往往是不是很重要的用户，所以会先发布SET10。

优点

· 隔离部署，各个业务线影响最小。自动支持灰度发布。

缺点

· 灰度的粒度取决于隔离部署的粒度，一般会偏大。

· 相对于集中部署比较浪费机器。

· 各个业务线版本可能不一致，不利于统一管理。

· 有一定的实现和部署成本

 

 

8.3.4. 方案四：动态路由

   采用一个可以灵活配置的灰度策略，影响Load Balance的行为，让其根据灰度策略，返回灰度服务的IP和端口。

适合与后台IDL的服务灰度。

优点

· 灵活，可控。

缺点

· 现在的配置中心和L5本身没有考虑指定路由策略，且不具有扩展性，需要在其外边开发。

· API的元数据来源比较分散，目前 API和IDL元数据，API等级和频率限制 分布在不同的数据源，现在需要增加一个 灰度路由 数据源。