http://djt.qq.com/article/view/16
其主要思想就是把影响集中到一个点，然后再发散到一个面，出现意外情况后很容易就回退。
Gmail Labs是一个新特性橱窗，用户可以自己选择一些未正式发布的新特性进行体验，不喜欢可以关闭，在这个过程中，吃了螃蟹，也当了Google的小白鼠。
这个做法比传统的灰度要高明很多，更加尊重用户：
1、它没有强X用户，用户是否愿意当小白鼠完全自愿
2、新特性不是打包在一起的一个大版本，可以选择某几个喜欢的螃蟹尝尝
3、螃蟹不好吃可以扔掉，不用硬吃进肚子里引发肠胃炎
当然这些好处也是有代价的：
1、要开发一个labs平台实现新特性上架、独立尝试的功能，这可能要改动Gmail的前后台架构
2、新特性要按照一定规范来写，才能发布到这个平台上，可能会增加一些工作量
3、小白鼠用户增多之后，对系统的压力可能会有一定提升，因为没有用户调用的界面都不一样了
既然Gmail Labs能够顺利发布，那么说明对Google来说，以上这些问题都不算问题。另外，现在展示的新特性，都注明了开发者的名字，那么，Gmail Labs可能会开放这个平台让外部开发者也能提交特性？这倒是很open的一种开发模式，非常适合Google的web app产品线。
互联网产品有一个特点，就是不停的升级，升级，再升级。我所在的项目组，基本上保持每周一次的发布频率，系统升级总是伴随着风险，新旧版本兼容的风险，用户使用习惯突然改变而造成用户流失的风险，系统down机的风险..... 为了避免这些风险，很多产品都采用了灰度发布的策略，其主要思想就是把影响集中到一个点，然后再发散到一个面，出现意外情况后很容易就回退。