灰度发布

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。

在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

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

作用

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

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

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

步骤

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产品线。

互联网产品有一个特点，就是不停的升级、升级、再升级：我所在的项目组，基本上保持每周一次的发布频率，系统升级总是伴随着风险，新旧版本兼容的风险，用户使用习惯突然改变而造成用户流失的风险，系统down机的风险…..

为了避免这些风险，很多产品都采用了灰度发布的策略，其主要思想就是把影响集中到一个点，然后再发散到一个面，出现意外情况后很容易就回退。

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

QZone是另外一个采用灰度发布的例子。

大家都知道，QZone在过去的一年中改进是巨大的，从以前慢悠悠的老爷爷变成了一个充满青春活力的小伙子。

其中经历了大小无数次的发布，他们的发布也都是采用了灰度发布的策略，用户数据的升级并不是大面积的一次性升级，而是通过一个用户升级标志服务器，如果用户数据没有升级，后台会把此用户的数据逐步迁移到新版本上，然后将升级标志位置1，升级过程中，用户仍然可以访问旧的数据，升级完成后的访问都将转发给新的版本。

QQ的很多产品发布都采用灰度发布，有些是抽取部分QQ号段升级成新系统，然后根据用户反馈再大范围升级。

在传统软件产品发布过程中（例如微软的Windows 7的发布过程中），一般都会经历Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等几个阶段（参考Software release life cycle）。

可以看出传统软件的发布阶段是从公司内部->外部小范围测试>外部大范围测试->正式发布，涉及的用户数也是逐步放量的过程。

在互联网产品的发布过程中也较多采用此种发布方式：产品的发布过程不是一蹴而就，而是逐步扩大使用用户的范围，从公司内部用户->忠诚度较高的种子用户->更大范围的活跃用户->所有用户。

在此过程中，产品团队根据用户的反馈及时完善产品相关功能。此种发布方式，按照中国特色的叫法被冠以”灰度发布“、”灰度放量“、”分流发布“。

关于“灰度发布”叫法的来源无从考察。

只不过按照中国传统哲学的说法来看，很符合中国人中庸的思维模式：自然界所有的事物总是以对称、互补、和谐的形式存在，例如黑与白、阴与阳、正与负、福与祸。

在二元对立的元素间存在相互过渡的阶段，所谓”祸兮福所倚，福兮祸所伏“。

具体到黑与白，在非黑即白中间还有中间色——灰色。

于是出现了很多关于灰色的说法：灰盒测试，灰色管理（极力推荐 任正非：管理的灰度），灰色收入，灰色地带等等。

因此灰度发布实际上就是从未发布逐渐过渡到正式发布的一个过程。

大厂常用的几种灰度发布方案

灰度发布的划分

灰度发布如果按照端来分的话，可以分为web前端、客户端、服务端灰度。

无论是哪种灰度，一般需要满足以下2点要求：

  1. 需要一个放量配置，给产品/运营等工作人员配置放量策略；

  2. 需要做到同一个用户始终访问的是同一个版本的代码，如果同个用户上个请求访问的是A版本，下个请求访问的是B版本，就可能会出问题。

1. web 前端灰度

假设我们的前端资源存放在CDN上面：我们每次发布一个新版本，就把资源增量式地上传到CDN，然后给它分配一个唯一的版本号，再把所有的版本号存储起来。

当处理请求时，根据动态配置的分流策略来决定用户使用哪个版本。

比如分流策略是放量10%，即新版本随机放量给10%的用户使用，当用户首次命中资源版本号时，需要把用户id和版本号的映射关系存储起来（可存到cookie），这样就能保证同个用户上次请求和下次请求访问到的都是同个版本的代码。

那如果线上有紧急bug需要修复，又要重新发布新版本，该如何处理当前灰度的状态？

是赶紧结束上一个灰度然后全量发布还是一起发上去同时灰度？

一般来说，再有新版本发布或者放量策略发生变化时，应该重新分流灰度。

2. 服务端灰度

服务端灰度分为兼容变更灰度和不兼容变更灰度。

1）兼容变更

兼容变更又可分为物理灰度和逻辑灰度。

物理灰度：物理灰度比较简单，根据机器维度进行灰度，直接部署新老版本在不同机器，流量均匀地打在新老版本上面。这种方式虽然简单，但不适用于不兼容变更；

逻辑灰度：逻辑灰度就是根据更精确的流量策略来控制流量，这种灰度一般要写一定的灰度代码。这种方式能比较精确地控制流量，但是增加了一定的灰度代码，灰度完成后要删除相关灰度代码，有点麻烦。

2）不兼容变更

不兼容变更指的是更改了当前功能，即接口逻辑跟之前版本发生很大变化，必须要前后端同时发布，否则会有一段时间服务不可用。

一般的做法是引入接口版本号，新老版本接口并存，比如 /v1/api 和 /v2/api。

前端使用/v2/api版本，当过去一段稳定期后（可以是登录态时间失效后），就可下掉/v1/api版本。

3. 客户端灰度

web前端和服务端灰度发布可以在客户无感知的情况下平滑进行，遇到问题也可以快速回滚，但是移动客户端涉及到用户的主动安装行为，所以上述的方式已经不适用。

如果一个带有bug的安装包全量发布出去，一旦有问题，我们只能快速定位问题来提醒用户安装新版本，是否安装取决于用户，所以客户端灰度发布是非常有必要的。

客户端在启动时，会向灰度系统发起请求，灰度系统根据客户端传过来的参数和当前的放量策略来决定是否要给客户端升级提醒。

一般会根据以下几种策略来决定给予用户升级提醒：

  1. 根据用户设备的系统和应用版本；

  2. 根据渠道：发布到不同应用市场的app都会被打上渠道标签，所以可以根据渠道来区分用户；

  3. 根据设备ID和用户ID。

  4. 通过设备ID主要是为了控制提醒频率，用户ID主要是为了区分出特性用户，比如对活跃用户发送提醒。

二、灰度放量策略

流量策略一般分为以下几种：

1. 按流量百分比

先到先得的方式比如限制10%的用户体验的是新版本，90%的用户体验的是老版本。

先访问网站的用户就优先命中新版本，直到流量用完为止。

2. 按人群划分

按用户id、用户ip、设备类型比如可通过平时的埋点上报数据得知用户的pv、uv、页面平均访问时长等数据，根据用户活跃度来让用户优先体验新版本，进而快速观察使用效果。

按地域、性别、年龄等用户画像比如可通过用户的性别、年龄等做下新老版本的对比效果来看看目标用户在新版本的使用年龄段，性别范围是多少。

3. 按渠道划分

比如根据用户的注册来源来放量。

三、灰度发布的代价

通过上面的讲解，可以看到一个完整的灰度发布，包括前端、后台都需要额外的代码量去实现，如果只有几万的用户，要去实现这样一套灰度发布，代价是比较高的。

但如果是百万～亿级用户，灰度发布是很值得的，它不仅能降低新版本bug的风险，还能通过版本对比，推出最好效果的版本应用。

参考资料

百科

https://help.aliyun.com/document_detail/181383.html

https://blog.csdn.net/xing7290/article/details/121250082

https://baijiahao.baidu.com/s?id=1692367749356717047&wfr=spider&for=pc