运营商去O之我见（下）
关注科技杂谈，洞析科技大事
中国通信行业影响力最大的自媒体
订阅请直接搜索公众号：keji_zatan
现在，科技杂谈已开辟【今日话题】栏目，每天发布一个最受关注的热点主题，欢迎感兴趣的朋友参与讨论，或提供您的观点文章。
每天的讨论内容与投稿，都将筛取精华，在第二天的科技杂谈分享给大家。
今日话题：腾讯新东方牵手
明日话题：4G手机大战
近期千元4G手机和五模手机的推进速度，都远超去年的各方预期，一场惨烈的大战将至，2014年将有哪些手机厂商处境危险？
如您有兴趣参与讨论，请添加我的微信：ennwangyunhui，以便添加入相关的讨论群组。
如您只是希望表述自己观点，或推荐优秀文章，可直接回复公众号，或回复邮件到ennwangyunhui@vip.163.com。
文 / 王晓征，作者为浙江移动业务支撑中心副主任，新浪微博：@酒剑仙007
上篇分析了运营商环境下去O的各种因素，那么我们究竟该如何是好呢？
我考虑了以下一些对策。
一，没有金刚钻，别揽瓷器活，去O有风险，同志需谨慎。
不能被互联网的人云山雾罩地一吹就晕，简单照搬互联网公司的做法，简单粗暴地快速全面去O，那样很容易搬起石头砸自己的脚。
这里没有对互联网公司的兄弟不敬的意思，个人以为，他们很多人都是中国人的骄傲，也在干着很有意义的事业。
只是，大家场景不同，还是要实事求是，因地制宜，不能脱离实际去搞大跃进。
听说，某次某传统行业技术交流，当着很多老专家的面，某著名互联网公司的一位仁兄放言：“你们不去O就是民族的罪人”，这种话就别拿出来忽悠了，大家当笑话听听就好。
二，如果一定要在运营商环境下去O咋办？
别怕，知彼知己，百战不殆，实事求是因地制宜，去O有办法。
首先，在运营商环境下，去O不能简单理解成去O的产品，而应该理解成去O的服务。
为什么？
请参考第一篇的内容，你懂的。【注：如您没有看过该文章，可关注微信公众号科技杂谈（keji_zatan）并查看历史消息】
我们应该把精力，花在局方和第三方Oracle技术支持力量的培养上。
当年，某运营商培养出了亚太第一批Ocm，那么，为什么今天，我们就不能在技术人员培养和激励机制上再创辉煌，再培养一批？
市场上有那么多专业的第三方合作伙伴，我们为什么一定要把服务吊死在原厂团队上？
全国一盘棋，是否能在技术支援体制上做文章，改变现有的各省烟囱式技术团队的现状，运营商内部好的甲乙方技术力量，是否可以复用创造更大的效益？
我们有那么好的管理机制，某些运营商集团，每层面、每年都有实实在在搞应急容灾演练，我们的容灾切换整体水平，难道在业界真拿不出手？
这一点，我估计至少部分运营商，目前整体水平要高于互联网行业！
甚至我在想，能不能充分利用几个大省较强大的技术力量，基础技术平台可以全国大区集中化管理……
只要以上几点做到位了，我相信Oracle原厂的服务，不会成为我们的什么瓶颈，根本不必拿出来说事。
如果我们做不到位的话，去O换成任何一种数据库，我们都要面临同样的技术保障问题，而且只会更加严重。
逆水行舟，不进则退啊。
三，抛开服务去O之路不论，继续深入谈产品去O。
如果确实要这么干，那么，应该从对数据的强一致性，数据库的可扩展性，安全性要求相对不高的系统入手，逐渐积累经验，锻炼队伍，逐步深入。
或许有那么一天，我们能把产品去O的手，伸进我们的核心系统，但这一天应该不会马上到来。
要知道，技术掌控力远强于我们的阿里，目前真正涉及到钱的支付宝核心系统，仍然在Oracle上！
或许明年吧，阿里真能实现支付宝去O，但可以看到阿里的去O进程，也是由浅入深，由外向内的。
这一点值得我们借鉴。
四，产品去O，产品本身应该如何选择。
很多人觉得奇怪，这还有什么可以选择的吗？
难道去O不是直接上mysql吗？
个人以为，错！
产品的选择不是儿戏，不能简单抄袭，还是那句话，环境不同，别人适合的东西不一定你适合，反之亦然。
此外，选择产品本身也可能涉及到技术路线的选择，这是个很大的事情！
现在，我来深入解释一下这一点。
大家知道，mysql和Oracle相比功能要简单得多，很多复杂查询不支持，数据结构很多需要转换，sql语法也差别较大。
也就是说，如果把程序从Oracle割接到mysql，数据倒换代价不说，代码基本上兼容性较低，是可以肯定的，需要重写的部分占比应该会很高。
而现实情况是，运营商对业务连续性的要求是很变态的，但技术掌控力又不如阿里。
这种情况下，想象一下我们的系统去O会面临什么样的挑战？
我们很可能要做到灰度割接（举个例子：我的一个系统按地市分成四个库，我先去掉一个库，后面逐步再去，以此类推……）两种数据库在一个系统内部，有较长时间的并存用，以观察系统的状态。
而且，就算割接上去，我们的体制文化下，谁敢保证用新的数据库就不会长时间宕库或者丢数据？
说句实话，就算合作伙伴胸脯拍肿，我们都不敢。
所以，必须要做到割接上去还有回头路，这一点，我们和互联网公司比，还是有一些差别的。
要解决以上风险，只有三种方法：
1，长期编写发布两套代码；2，在应用层实现对数据库特点的屏蔽；3，数据库层实现与Oracle的异构容灾。
第一种，阿里吃得消我们吃不消，体制问题，不多说。
第二种，阿里或多或少实现了，他们用的mysql，据传已经可以基于binlOg和Oracle做复制，据说还要做到支持更多种类的数据库，细节不详，拭目以待吧。
不过，这又是和他们自主研发的体制挂钩，他们可以自己发明轮子，我们得靠开发商发明轮子，而且这样做，基本等于我们和开发商进一步绑定，和我们现在加强自主掌控，减少对开发商的依赖的思路不符。
而且，我们的开发商在这个领域，现在还没有阿里那样的技术积累，干这个很有些难度和风险，当然，技术上可能性还是有的，或许可以用一下 类似hibernate那样的组件……
第三种，mysql理论上也有工具，但是没有大的应用案例，还有待于进一步研究。
此外，可以考虑一下国产数据库，很多人说国产库很烂，但是我想说的是，我们是国企，我们在体制内，走国产库的路一方面符合体制特点。
至少，目前国产库与Oracle代码纸面上的兼容性，远强于mysql，而且不同程度支持与Oracle的异构容灾。
再说了，当年中国人自己的3G技术某运营商扛了，现在不是发展得也挺大，扛个国产库，我想也不是完全没有可能。
没准，我们的国产数据库厂家也能成下一个华为呢？
五，很多人一谈到国产库就鄙视，很多也是玩mysql的人，我说一句，真的不要，真的没必要。
现在，国货或许还不行，但我们可以实话实说，可以不用，但是不要随意谩骂。
自己的孩子丑，父母不能直接就扔了，还是要努力培养，让他尽可能茁壮成长。
总之，去O数据库产品的选择，本质是在我们的环境下，不同技术路线的选择。
我目前对任何一种路线都没有倾向性，只是指出在现有体制和环境下，如果要去O，可能的选择和需要考虑的问题，具体的选择必，须要在做过详细测试拿到数据后才能谈。
除此之外，西药立竿见影，中药固本陪源，说了这么多，归根结底是还是咱们的技术力量不行，对人家互联网公司，甚至银行的技术力量不能不服啊！
什么时候，移动也能学学人家的先进经验，真正给体制内技术力量的培养，给点正能量呢？
吐槽几句，在体制内，搞技术的肯定不如搞业务的会写ppt的，可是体制内往往就吃这一套，咋办？
如果实在培养不起自己的技术力量，至少可以培养一下第三方技术力量，对原厂和开发商至少也是一种平衡。
最后强调一下，我并没有否定去O，我只是不认同简单化的全盘否定。
只要正确理解，有机吸取互联网行业的先进技术思路，结合运营商的现实环境情况，开拓思维，勇于创新，我们一定能走出一条我们自己的有运营商特色的去O之路来！
以上就是我对运营商去O的一点拙见。
本人见识有限，可能很多观点不一定妥当，权当抛砖引玉，希望能引起大家的讨论，众人拾柴火焰高，能研讨出更合适的路线。
最后再强调一下，对走在国内技术前沿的互联网公司的技术专家们表示敬意。
大家的观点是不是一致，这可以讨论，但如果没有你们，这个话题都不会有。
感谢你们！
【独乐乐不如众乐乐，好文章就要大家分享！欢迎大家投稿或推荐优秀文章（推荐方法：请转发链接给本公众号或邮箱：ennwangyunhui@vip.163.com，并注明推荐人身份、推荐理由与推荐来源）科技杂谈强调版权保护，我们将与作者进行联系取得授权后转载】
本文仅代表作者观点，科技杂谈授权刊登。
转载必须注明作者与科技杂谈，侵权必究。
科技杂谈文章，均同步发布于犀牛财经网。
已入驻搜狐新闻客户端，网易阅读客户端。
点击下方“阅读原文”直达犀牛财经网