灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。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，升级过程 中，用户仍然可以访问旧的数据，升级完成后的访问都将转发给新的版本。
　　QQ的很多产品发布都采用灰度发布，有些是抽取部分QQ号段升级成新系统，然后根据用户反馈再大范围升级。我们的产品大部分也是采用灰度发布。
本文来自 http://enki-ding-yeah-net.iteye.com/blog/1114565

聊聊灰度发布http://bbs.c114.net/thread-730772-1-1.html

再发一篇攒人品，早点突破新兵的限制。上一篇《运营商要向互联网学什么》

2011年底，浙江公司分管支撑的杨剑宇副总在支撑内部召集了一次头脑风暴，要求部门里各位主管和骨干轮流发言，不讲成绩，只讲问题和思路，一圈人一个一个轮流讲过来：

l  负责开发的主管说现在业务部门的需求经常考虑不清楚，而上线的时间压力很大，风险也很大，匆忙上线很容易把现有的业务弄乱，同时，上线后往往要在业务规则、操作便捷性上做多次修改，形成了很多不必要的二次开发，因此要求业务部门和需求管理员加大需求分析的力度，尽早明确需求，降低上线风险，减少二次开发。

2  负责产品配置的同事说新增产品现在只能在测试环境上进行验证，发布后即为生产环境，很难分析新产品上线带来的影响，以及评估对现有产品模型、资费体系的冲击。建议增加一套类生产的环境，进行全量模拟验证。

3  负责测试发布的同事说目前回归测试案例集不全，有些前台功能使用的场景只有一线营业员才知晓，一旦在上线前的回归测试有遗漏，上线后2个小时的核心功能回归并不能保证系统正常。要求加强自动化测试范围，完善回归测试案例集。

4  负责投诉处理的同事说上线后的功能不稳定导致的前台保障、批量客户投诉对日常的运维工作的冲击很大。要求提高需求分析和上线质量，避免故障和批量差错的发生。

那为什么会有这么多的事情呢，这一切都是因为2011年浙江移动新版本的CRM割接上线后各类事件、问题非常多，对于割接前已经稳定了很多年的开发、运维体系造成了极大的冲击。

割接，是一场战争

割接，尤其是核心系统的割接，对支撑，对前台，就是一场战争，因为每一次的系统割接，基本就等同于第二天系统无法使用、或者用户的批量投诉。

先来回顾一下什么是割接。2003年刚毕业，我就赶上了浙江移动第一次全省集中BOSS系统的割接。我和同批进公司的朱骏一起问当时的BOSS项目经理罗文模（现福建移动支撑的副总）：什么是割接，他说：割接，就是把老系统割下来，把新系统接上去，哈哈，非常形象吧。后来，百度了一下“割接”，发现这是一个从网络专业延伸到支撑网的名词：传统的割接是指使用一种新的事物替换原有旧的事物，也指将一种业务或流量从一个网中移植到另一外网络中。现在，凡是以新的系统替换旧的系统的行为都称为割接。

在通信行业，割接是一件很慎重的事情，凡是割接，都是在晚上进行，要求进行周密的测试、数据的备份、以及失败紧急回退方案演练等等，不管是正向，还是反向，都要有充足的准备和演练，才能保证割接的成功。同时，一般在临晨5、6点前要求割接完毕，完成业务验证，不能影响第二天的运营，因此，留给真正开始割接的时间并不多，对各配合方要求都非常高。浙江移动CRM割接步骤当时专门印发成了一本小册子，A4的打印纸，100多页，详细到每一个人、每一个时间点、每一个步骤、每一个命令。

割接方案中，最难的就是涉及数据模型升级的地方了。现在的割接方案都是先把老的数据模型在系统升级前，通过批量操作方式，“一次性转换”成新版本的数据模型。我们做过软件开发的朋友们都很清楚，做正向的升级比逆向的降级要简单，就好像连微软等这些传统的大软件开发商都没有提供这样的服务：我们把OFFICE软件从2003升级到2010，用了一段觉得不爽，不用卸载而直接回退到2003再使用。从正向考虑把老的模型升级到新模型，大家都认为是理所当然要做的事情，从项目建设之初就考虑的很清楚，在准备割接脚本时也很充分。但反过来，从新模型降级回老模型，绝大部分开发人员都是从内心拒绝这个事情的，人的思维中总是存在侥幸心理，万一不成功才用到的脚本，为了这个“万一”值得么，有这功夫还不如好好想想怎么确保成功呢，所以，最容易出问题的地方往往就在这些回退的脚本上。而且，因为都是批量操作，极易出错，且要消耗大量的时间，这样，把本来就很紧张的升级时间压缩的更短，因为割接计划中还要预留出足够的回退时间。

灰度，是一种策略

这里打断一下，最近这几年您听说过淘宝升级么？如果没有记错，最近的一次淘宝发公告要暂停业务进行系统升级是2008年，之后再也没有听说过淘宝通过半夜停业务的方式来做系统升级的事情了。您听说过QQ升级么，事实上QQ从最开始的只能有500个好友到现在支持上亿的好友，经历过大大小小上千次的升级，从来没有停业务这一说法，为什么啊？因为互联网产品有一个特点，为了减少甚至避免系统升级对用户使用造成影响，在升级的过程中都采用了灰度发布的策略。

什么是灰度发布，这里引用一下百度百科的内容。

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

哦，原来灰度发布就是保持两份不同的版本，让一小撮用户先在新版本上尝鲜，等这部分小白鼠用户稳定了，在把绝大部分的用户迁移到新版本上来。别的先不说，就针对之前我们部门那么多领导提出来的问题，一一解答下：

n  灰度发布后：上线前需要明确业务主线，如果业务规则、操作上存在纰漏，出问题的范围也可控。而且，现在市场部门做推业务前，采用的也是先挑一个中等营业厅先操作试点，整理出业务规范，确定没问题再大规模推广，灰度发布正好就能适应这种节奏和方式。

n  灰度发布后：可以控制在灰度环境上验证新产品的准确性，验证各种订购、计费、查询等场景。

n  灰度发布后：在灰度环境上观察、收集营业员的操作，并录制成自动化测试的脚本，可以快速提高自动化测试的比例。

n  灰度发布后：前台的影响范围可控，也就是几个台席、百十个客户，完全可以避免上线故障和批量差错的产生。

这么一圈分析下来，灰度发布真是个令人激动的好东西啊！接下来，部门内针对灰度发布的事情组织一拨人讨论，论证我们的CRM系统是否适合做灰度发布。

当前系统典型的分层架构都是三层结构，在WEB层、APP层做灰度发布很容易，只需要搭建两套不同版本的生产环境，然后从WEB层控制访问的源头即可。但是服务总要收敛到数据层，因为客户的数据只能保留一个版本才能保证最小粒度（单客户级）的对外服务一致性，所以，一旦要在这个层上做灰度，不但要保留两个不同版本的数据，而且在程序控制、代码逻辑上会非常困难。

最后的结论是如果只有WEB层的功能上线，做灰度是合适的，但我们每次上线都涉及都后台表的变化，无法承担两份数据的差异，所以无法实施灰度发布。

这事就一直搁置在这里了。

是不是在运营商里，真的就不适合用灰度呢？

灰度，更是一种思想

如果真的能通过在WEB层、APP层的灰度发布控制影响的话，为什么一定要提前批量把数据转换过去呢，为什么不能在客户访问到系统，要用到数据的时候，才把客户数据从老模型转换成新模型呢？

也就是说，除了系统层面、数据层面能做灰度这种选择，我们在过程上为什么不能同样采用灰度呢？

具体的说，就是把以前批量的数据割接和回退的脚本“单元化”，封装成一个个针对单独数据来源的小脚本。不管你做没做过DBA，我想这类针对单客户的数据迁移，您一定会使用到索引，执行效率非常高，这样，单个数据迁移完成后再调用新版本的服务，对客户感知基本没有什么影响。

这样，前端的灰度发布，加上后端数据的即时转换，我们就能做到每次升级后的版本至开放到一两家营业厅、几个台席，控制较少量的用户使用，同时，采取动态数据迁移的方式，把这些台席上受理的客户数据动态升级到新的数据模型，前台只要加上个“数据转换中，请等待”的提示，前台人员一定能够理解，对这些“小白鼠”客户持续跟踪，等系统稳定了再逐步放开台席，放开试点数量，这不就是一个完整的灰度发布么？

事情就是这样，只要你持续在一个问题上深入想下去，总会有解决的办法。2013年初去广东公司交流的时候，他们正在做CRM系统的割接，因为地市公司担心割接带来的业务影响，配合意愿不强，而且在第一次割接的时候确实是因为系统问题产生了一些影响，被地市公司把问题放大，给了支撑很大的压力。如果广东公司能考虑下灰度的策略，在地市只挑1、2个营业厅，让他们先感受新系统，接受新系统，后续的割接应该会顺畅很多。即使是新系统有问题，一两家营业厅、几个台席的失败，对地市公司都是可以承受的。所以，灰度发布看似一个加长系统升级的过程，其实是一个有效减低风险，加快割接进度的好策略呢。

灰度部署典型的框架如下图，供参考：

小结

2011年亚信在浙江割接，2012年在上海、北京、辽宁割接，亚信的余鹏武总还计划写一本移动CRM割接的书，说要把这些经历和痛苦都写出来，虽然我相信这本书里一定有很多的内容和趣闻，但我个人还是不赞成这种宣扬靠人堆、靠硬干蛮干的工作方法。

真心希望移动公司以后的上线不再有“割接”这样的词，而都是采用“灰度”的方式，大家轻装上阵，不用提心吊胆、不用熬夜干活，大家白天里轻轻松松就把事情做掉了。

割接前先再搭一套新系统，只有WEB和应用部分新建，数据部分先搭个空库。数据部分做成脚本，按照规则预设，来的用户属于规则的，就触发脚本，把旧数据库的用户数据升级填充到新的空库里面。