灰度发布
1.1、灰度发布的由来

在大型软件产品发布过程中(例如微软的Windows 7的发布过程中),为慎重起见, 一般都会经历Pre-Alpha、Alpha、Beta、RC(Release Candidate)、RTM、GA (General availability or General Acceptance)等几个阶段。 产品的发布过程不是一蹴而就,而是逐步扩大使用用户的范围。

可以看出,对于大型软件的发布是分阶段的。 一般是从团队内部 → 部门内部 → 公司内部 → 外部小范围测试 → 外部大范围测试 → 正式发布, 涉及的用户数也是逐步放量的过程。

在大型互联网产品的发布过程中,也较多采用此种发布方式: 从公司内部用户 → 忠诚度较高的种子用户 → 更大范围的活跃用户 → 所有用户。 在此过程中,产品团队根据用户的反馈及时完善产品相关功能。

此种发布方式,按照中国特色的叫法被冠以“灰度发布”、“灰度放量”、“分流发布”。 在众多的叫法中,“分流发布”这个名字直白的说明了发布原理。而“灰色发布”这个名字最为优雅,所以“灰色发布”这个名字最受欢迎。

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

灰度发布实际上就是从不发布,然后逐渐过渡到正式发布的一个过程。

灰度发布是一种试探性发布。因为他不确定新版本会对用户造成什么影响,所以选择让一部分用户使用新服务, 如果发现用户好评如潮,就逐渐扩大用户升级规模,最后让全部用户升级到新服务。

灰度发布对海量用户的App发布非常有效。

1.2、灰度发布的作用
  • 及早获得用户的意见反馈,完善产品功能,提升产品质量。
  • 让用户参与产品测试,加强与用户互动。
  • 降低产品升级所影响的用户范围。
1.3、灰度发布的步骤
  1. 定义目标
  2. 选定策略:包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
  3. 筛选用户:包括用户特征、用户数量、用户常用功能、用户范围等
  4. 部署新系统、部署用户行为分析系统
  5. 调整分流规则
  6. 跟踪发布结果:用户行为分析报告、用户问卷调查、社会化媒体意见收集
  7. 形成产品功能改进列表
  8. 产品完善
  9. 新一轮灰度发布或完整发布
1.4、灰度发布过程中的常见问题
1.4.1、以偏概全

问题特征:

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

解决方案:

  • 样本选择要多样化,样本的组合涵盖大部分核心功能。
1.4.2、知识的诅咒

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

问题特征:

  • 结果没有量化手段
  • 只依赖于用户问卷调查,没有web analytics系统
  • 运营数据不全面,只有核心业务指标(例如交易量),没有用户体验指标
  • 对结果分析,只选择对发布有利的信息,对其他视而不见

解决方案:

  • 产品设计考虑产品量化指标
  • 结果分析依据量化指标而不是感觉
1.4.3、发布没有回头路可走

问题特征:

  • 新旧系统用户使用习惯差异太大,没有兼容原有功能
  • 新旧系统由于功能差异太大,无法并行运行,只能强制升级
  • 新系统只是实现了旧系统部分功能,用户要完整使用所有功能,要在新旧系统之间来回切换
  • 新旧系统数据库数据结构差异太大,无法并行运行

解决方案:

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

问题特征:

  • 指望用户自己去挖掘所有功能。对于一个产品,大部分用户经常只使用部分功能,用户大部分也很懒惰,不会主动去挖掘产品功能
  • 互动渠道单一
  • 不尊重参与用户意见

解决方案:

  • 善待吃螃蟹的样本用户,包括给予参与测试的用户小奖励(例如MS给参与Win7测试用户正版License)、给用户冠以title
  • 通过论坛、QQ群、微博、微信公众号等新媒体与用户形成互动
  • 提供产品功能向导。在hotmail最近的升级后的功能tip,gmail的tip都有类似的产品功能导向。在产品中会提示类似于:你知道吗,xx还提供xx功能,通过它你可以xx
1.5、灰度发布 vs. A/B Test

灰度发布与A/B Test看起来比较类似,国内很多人常常将灰度发布与A/B Test等耳视之。老外也并没有所谓的灰度发布的概念。 实际上,灰度发布是中国人从A/B Test引申而来的,所以灰度发布是A/B Test的一种特殊用途,用来发布产品的。

A/B Test最重要的是大数据分析,以提供决策,没有大数据分析,就不能称为A/B Test

1.6、分流引擎

分流是反向代理和负载均衡的原理基础。而灰度发布也是基于分流的。

对于一般的小系统并不需要单独的灰度发布引擎,在页面javascript或服务器端实现分流的规则即可。

对于大型的互联网应用而言,单独的用于管理用户分流的发布引擎就很有必要了。 “钱掌柜”分流发布模式提到了原来阿里软件所使用的灰度发布引擎,设计思路具有普遍性,可以供参考:

1.7、灰度发布的一个示例

1、假设我们的App现在市场上的版本是1.0.0,我们的版本规划是,下个发布版本是2.0.0,现在的布署图如下:

2、现在我们2.0.0版本已经开发完成,测试和iOS审核过程中的布署图如下:

在这个时候,我们一定要确保,只有用户的操作系统是iOS和客户端版本是2.0.0的请求才能访问2.0.0服务。

这时候,我们的1.0.0版本的服务仍然在运行,市面上的用户仍然使用1.0.0的服务, 但是iOS审核人员用的是我们提交的2.0.0版本,他用的服务就是新的2.0.0的服务,并且只有他用的是这个新服务。

3、当iOS审核通过后,一部分iOS用户更新了App,我们的布署图如下:

这时候,我们通过修改Ngnix的配置文件,让具有某种特征的用户使用2.0.0新服务, 让另外一些用户依然使用1.0.0版本的服务。

我们要做的就是:不断根据用户反馈进行统计分析,了解这部分使用了2.0.0新服务的用户的对新服务的使用满意度,根据满意度决定, 是让更多的用户使用新服务还是关闭新服务。