再发一篇攒人品，早点突破新兵的限制。上一篇《运营商要向互联网学什么》html
2011年末，浙江公司分管支撑的杨剑宇副总在支撑内部召集了一次头脑风暴，要求部门里各位主管和骨干轮流发言，不讲成绩，只讲问题和思路，一圈人一个一个轮流讲过来：前端
l 负责开发的主管说如今业务部门的需求常常考虑不清楚，而上线的时间压力很大，风险也很大，匆忙上线很容易把现有的业务弄乱，同时，上线后每每要在业务规则、操做便捷性上作屡次修改，造成了不少没必要要的二次开发，所以要求业务部门和需求管理员加大需求分析的力度，尽早明确需求，下降上线风险，减小二次开发。web
2 负责产品配置的同事说新增产品如今只能在测试环境上进行验证，发布后即为生产环境，很难分析新产品上线带来的影响，以及评估对现有产品模型、资费体系的冲击。建议增长一套类生产的环境，进行全量模拟验证。算法
3 负责测试发布的同事说目前回归测试案例集不全，有些前台功能使用的场景只有一线营业员才知晓，一旦在上线前的回归测试有遗漏，上线后2个小时的核心功能回归并不能保证系统正常。要求增强自动化测试范围，完善回归测试案例集。数据库
4 负责投诉处理的同事说上线后的功能不稳定致使的前台保障、批量客户投诉对平常的运维工做的冲击很大。要求提升需求分析和上线质量，避免故障和批量差错的发生。后端
那为何会有这么多的事情呢，这一切都是由于2011年浙江移动新版本的CRM割接上线后各种事件、问题很是多，对于割接前已经稳定了不少年的开发、运维体系形成了极大的冲击。服务器
割接，是一场战争网络
割接，尤为是核心系统的割接，对支撑，对前台，就是一场战争，由于每一次的系统割接，基本就等同于次日系统没法使用、或者用户的批量投诉。架构
先来回顾一下什么是割接。2003年刚毕业，我就遇上了浙江移动第一次全省集中BOSS系统的割接。我和同批进公司的朱骏一块儿问当时的BOSS项目经理罗文模（现福建移动支撑的副总）：什么是割接，他说：割接，就是把老系统割下来，把新系统接上去，哈哈，很是形象吧。后来，百度了一下“割接”，发现这是一个从网络专业延伸到支撑网的名词：传统的割接是指使用一种新的事物替换原有旧的事物，也指将一种业务或流量从一个网中移植到另外一外网络中。如今，凡是以新的系统替换旧的系统的行为都称为割接。app
在通讯行业，割接是一件很慎重的事情，凡是割接，都是在晚上进行，要求进行周密的测试、数据的备份、以及失败紧急回退方案演练等等，无论是正向，仍是反向，都要有充足的准备和演练，才能保证割接的成功。同时，通常在临晨五、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系统的割接，由于地市公司担忧割接带来的业务影响，配合意愿不强，并且在第一次割接的时候确实是由于系统问题产生了一些影响，被地市公司把问题放大，给了支撑很大的压力。若是广东公司能考虑下灰度的策略，在地市只挑一、2个营业厅，让他们先感觉新系统，接受新系统，后续的割接应该会顺畅不少。即便是新系统有问题，一两家营业厅、几个台席的失败，对地市公司都是能够承受的。因此，灰度发布看似一个加长系统升级的过程，实际上是一个有效减低风险，加快割接进度的好策略呢。
灰度部署典型的框架以下图，供参考：
小结
2011年亚信在浙江割接，2012年在上海、北京、辽宁割接，亚信的余鹏武总还计划写一本移动CRM割接的书，说要把这些经历和痛苦都写出来，虽然我相信这本书里必定有不少的内容和趣闻，但我我的仍是不同意这种宣扬靠人堆、靠硬干蛮干的工做方法。
真心但愿移动公司之后的上线再也不有“割接”这样的词，而都是采用“灰度”的方式，你们轻装上阵，不用提心吊胆、不用熬夜干活，你们白天里轻轻松松就把事情作掉了。
割接前先再搭一套新系统，只有WEB和应用部分新建，数据部分先搭个空库。数据部分作成脚本，按照规则预设，来的用户属于规则的，就触发脚本，把旧数据库的用户数据升级填充到新的空库里面。
