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个营业厅，让他们先感受新系统，接受新系统，后续的割接应该会顺畅很多。即使是新系统有问题，一两家营业厅、几个台席的失败，对地市公司都是可以承受的。所以，灰度发布看似一个加长系统升级的过程，其实是一个有效减低风险，加快割接进度的好策略呢。


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