灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式,让一部用户继续用A,一部分用户开始用B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面 来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。
Gmail Labs是一个新特性橱窗,用户可以自己选择一些未正式发布的新特性进行体验,不喜欢可以关闭,在这个过程中,吃了螃蟹,也当了Google的小白鼠。
这个做法比传统的灰度要高明很多,更加尊重用户:
1、它没有强X用户,用户是否愿意当小白鼠完全自愿
2、新特性不是打包在一起的一个大版本,可以选择某几个喜欢的螃蟹尝尝
3、螃蟹不好吃可以扔掉,不用硬吃进肚子里引发肠胃炎
当然这些好处也是有代价的:
1、要开发一个labs平台实现新特性上架、独立尝试的功能,这可能要改动Gmail的前后台架构
2、新特性要按照一定规范来写,才能发布到这个平台上,可能会增加一些工作量
3、小白鼠用户增多之后,对系统的压力可能会有一定提升,因为每个用户调用的界面都不一样了
既然Gmail Labs能够顺利发布,那么说明对Google来说,以上这些问题都不算问题。另外,现在展示的新特性,都注明了开发者的名字,那么,Gmail Labs可能会开放这个平台让外部开发者也能提交特性?这倒是很open的一种开发模式,非常适合Google的web app产品线。
互联网产品有一个特点,就是不停的升级,升级,再升级。我所在的项目组,基本上保持每周一次的发布频率,系统升级总是伴随着风险,新旧版本兼容的风险,用户使用习惯突然改变而造成用户流失的风险,系统down机的风险..... 为了避免这些风险,很多产品都采用了灰度发布的策略,其主要思想就是把影响集中到一个点,然后再发散到一个面,出现意外情况后很容易就回退。
很长时间,我们都一直在改进搜索引擎的排序算法,尽量让最好的商品出现在搜索结果的第一屏。我 们尝试了很多中算法,不断调整各个排序因子所占的比重。但是我们无法确信我们的排序结果能满足所有用户的需求。所以我们采用了灰度发布,选取几个一级商品 类目,在其中应用不同的排序算法,比如在女装类目中,我们把卖家信用所占的比率调整到60%,在珠宝类目中,我们把销售量所占的比率调整到60%.. 然后发布出去,收集用户反馈,最终选择一种大部分人认为好的算法。
QZone是另外一个采用灰度发布的例子。大家都知道,QZone在过去的一年中改进是巨大 的,从以前慢悠悠的老爷爷变成了一个充满青春活力的小伙子。其中经历了大小无数次的发布,他们的发布也都是采用了灰度发布的策略,用户数据的升级并不是大 面积的一次性升级,而是通过一个用户升级标志服务器,如果用户数据没有升级,后台会把此用户的数据逐步迁移到新版本上,然后将升级标志位置1,升级过程 中,用户仍然可以访问旧的数据,升级完成后的访问都将转发给新的版本。
Gmail Labs是一个新特性橱窗,用户可以自己选择一些未正式发布的新特性进行体验,不喜欢可以关闭,在这个过程中,吃了螃蟹,也当了Google的小白鼠。
这个做法比传统的灰度要高明很多,更加尊重用户:
1、它没有强X用户,用户是否愿意当小白鼠完全自愿
2、新特性不是打包在一起的一个大版本,可以选择某几个喜欢的螃蟹尝尝
3、螃蟹不好吃可以扔掉,不用硬吃进肚子里引发肠胃炎
当然这些好处也是有代价的:
1、要开发一个labs平台实现新特性上架、独立尝试的功能,这可能要改动Gmail的前后台架构
2、新特性要按照一定规范来写,才能发布到这个平台上,可能会增加一些工作量
3、小白鼠用户增多之后,对系统的压力可能会有一定提升,因为每个用户调用的界面都不一样了
既然Gmail Labs能够顺利发布,那么说明对Google来说,以上这些问题都不算问题。另外,现在展示的新特性,都注明了开发者的名字,那么,Gmail Labs可能会开放这个平台让外部开发者也能提交特性?这倒是很open的一种开发模式,非常适合Google的web app产品线。
互联网产品有一个特点,就是不停的升级,升级,再升级。我所在的项目组,基本上保持每周一次的发布频率,系统升级总是伴随着风险,新旧版本兼容的风险,用户使用习惯突然改变而造成用户流失的风险,系统down机的风险..... 为了避免这些风险,很多产品都采用了灰度发布的策略,其主要思想就是把影响集中到一个点,然后再发散到一个面,出现意外情况后很容易就回退。
很长时间,我们都一直在改进搜索引擎的排序算法,尽量让最好的商品出现在搜索结果的第一屏。我 们尝试了很多中算法,不断调整各个排序因子所占的比重。但是我们无法确信我们的排序结果能满足所有用户的需求。所以我们采用了灰度发布,选取几个一级商品 类目,在其中应用不同的排序算法,比如在女装类目中,我们把卖家信用所占的比率调整到60%,在珠宝类目中,我们把销售量所占的比率调整到60%.. 然后发布出去,收集用户反馈,最终选择一种大部分人认为好的算法。
QZone是另外一个采用灰度发布的例子。大家都知道,QZone在过去的一年中改进是巨大 的,从以前慢悠悠的老爷爷变成了一个充满青春活力的小伙子。其中经历了大小无数次的发布,他们的发布也都是采用了灰度发布的策略,用户数据的升级并不是大 面积的一次性升级,而是通过一个用户升级标志服务器,如果用户数据没有升级,后台会把此用户的数据逐步迁移到新版本上,然后将升级标志位置1,升级过程 中,用户仍然可以访问旧的数据,升级完成后的访问都将转发给新的版本。
QQ的很多产品发布都采用灰度发布,有些是抽取部分QQ号段升级成新系统,然后根据用户反馈再大范围升级。我们的产品大部分也是采用灰度发布。
灰度发布引擎
对于一般的小系统并不需要单独的灰度发布引擎,可以参考A/B测试中做法,在页面javascript或服务器端实现分流的规则即可。但对于大型的互联网应用而言,单独的用于管理用户分流的发布引擎就很有必要了。“钱掌柜”分流发布模式 提到了原来阿里软件所使用的灰度发布引擎,设计思路具有普遍性,可以供参考