中国移动 去“IOE”与核心能力掌控之路
先说一说去“IOE”：最近，去IOE炒得火热，各方高手争先恐后，抛头露面，作为一个运营商搞IT技术的人，基于移动的现状，我也发表几句不成熟的想法，希望通过我的一点思考，推动大家来更实事求是地看待问题，特别如果让很多在传统行业内掌握决策权的领导掌握更客观全面的情况，也听一听其他视角的声音，我就没白忙活了。此外，去IOE特别是去O有很多技术可以谈，不过对于运营商这样的传统企业（其实任何企业都一样），去IOE绝不可能仅仅是单纯的技术问题。所以今天我是结合技术和管理一起谈，不是纯粹谈技术，和大家说明一下。
再说一说核心能力掌控的问题：今天，在我们大谈去IOE的时候，尽管我想出了各种各样的现实应对之策，但归根到底，自身技术力量的发展最后是绕不过去的，这就涉及到运营商与合作伙伴的关系问题，我认为运营商与合作伙伴应该是互相促进共同发展的关系，绝不应该形成对供应商的过度依赖，这也是运营商核心能力掌控应该达到的及格线。所以，必须找出运营商特色的核心能力掌控之道，换句话说的直白点就是如何加强对开发商的管控能力！
今天的介绍只是个人看法，本人传统行业呆的时间长，很多群里的兄弟经验一定更丰富，本人看法放在这里算抛砖引玉，希望大家提出宝贵意见，批评指正。
去IOE的说法起源于互联网行业，由阿里巴巴公司于2010年最先发起。到2012年底，淘宝已经彻底完成去IOE。2013年五月，支付宝完成去IE。近期，据说支付宝已经完成部分去O。阿里的PR天团对去IOE的宣传力度一如既往的大。有个段子是据说最夸张的时候，某销售曾经把去IOE提搞到是否爱国的高度。姑且不论对错，但客观上这种论调对去IOE的概念形成了炒作效应，对舆论导向性起到了很大影响。
银监会曾经有个著名的39号文，所以可以说金融行业似乎已经首当其冲收到了去IOE潮流的冲击。 运营商方面对去IOE，没有金融界压力大，但应该说在内部也是一个热门话题。那么，如果不把去IOE分析清楚，传统行业小伙伴们看来很难愉快地玩耍下去了，这也是我编写本文的一个驱动。
1、特点：基于向上扩展(Scale-up)技术的高端设备以及围绕着它们开发的专有硬件、大型数据库和商业中间件；
2、难点：最核心是去Oracle数据库，由于其与业务关联密切；
3、本质：“分布式+开源架构” 替代 “集中式+封闭架构”，变成彻底的云计算服务模式，即“Scale-out架构+开源软件” 对 “Scale-up架构+私有软件”的取代。
中国移动早在2011年10月即开展UNIX应用迁移研究工作。2012年4月-12月，结合研究成果，部分省公司开展UNIX应用迁移试点工作，完善并更新Unix应用迁移建议及迁移实施方法，初步形成了Unix应用迁移中云计算技术的引入策略及方法。
近年来，中国移动开展第三代业务支撑系统架构演进，推动业务进行基于X86的软硬件架构改造，要求从小型机架构向X86架构演进，严格控制小型机和磁盘阵列的扩容，部分省份已提前完成。浙江移动部分核心系统2011年完成去IE，预计2015年内全面完成核心系统去IE。浙江移动部分系统已经迁移到开源数据库，预计2015年内实现部分核心系统迁移到开源数据库。
2013年中国联通在北京、黑龙江、浙江、重庆四个省份布置了Hadoop分布式体系，代替IOE架构。2013年度，中国电信集团公司信息化部提出“去IOE”，有些省份已先行开端履行，如江苏电信对其电子途径运营中心提的要求是：“从IOE向LAMP转变”。2013年度，中国电信广西公司IT系统基础架构采用云资源池和分布式云计算平台，先易后难地开展核心系统的“去IOE化”。针对用户反映强烈的计费清单查询慢问题，启动计费清单查询/存储云化改造。针对CRM和OSS系统大量历史工单占用生产系统存储空间的情况，启动CRM和OSS历史工单云化存储/查询改造。重庆电信2013年年底发布了“系统硬件云化应用系统分布式计算”的IT平台去IOE去电信化演进策略，计划用3~5年时间完成对现有基础架构平台去IOE的升级改造。
去IE本质上的技术挑战主要是：
系统云化程度的提升，把小云做成中云就结了（不解释，具体参见我的运营商云计算那篇文章）。此外对数据存储安全性，业务连续性和灾备体系，还有对运营商原有的过度电信化的保障思路，维保购买等级和成本有一定冲击。
实际上，这些都不是什么太大的问题。举个例子，一些部门一提到降低硬件维保级别，节省维保成本就如临大敌，为什么如此？当然，我很理解运维部门的维稳压力，但是维稳和创新其实是辩证统一的。合理创新其实长远来看恰恰是为了更好地提升系统的稳定性，并节省TCO。其实只要你的系统架构真正实现了那么一点点真正的云化，你的技术团队又能驾驭这些技术进步，硬件维保级别的降低并不是那么可怕的。我们实现维保体制改革当然要在厂家服务质量管理体系和商务模式上做文章，但真正的杀手锏是技术体系和运维体系对云化的支撑力度！这方面只要投入一些资源，硬件维保水平降低又有何妨呢？另外，我估算过，你在前者投入一元，后者降低不止一元没问题，这才是去IE真正的TCO节省之王道！
近年来运营商内部的一些项目，包括我们自己做的一些技术创新，都基本证明了，在运营商生态环境下，去I和去E这两件事情，都没有大的技术难点。但重点在于去O。
为什么不能直接照抄阿里?这个问题估计传统行业不少技术人员思考过？或被问过，先给大家看个案例吧
这玩意是个二战奇葩。本质上这个故事和小马过河差不多。P39飞蛇，这玩意机动性，火力特强。问题是太灵活也就是难开，容易坠机，跳伞还特麻烦，所以飞行员容易挂。老美财大气粗，怕出人命，马上当垃圾处理，送给了斯大林。俄罗斯老毛子，个个亡命之徒，讲不怕死，起飞就没想着活着降落，他们自己的飞机设计本身就是特难跳伞（估计设计师就没准备让飞行员真能跳伞），所以P39在他们眼里缺点都不是缺点了，那就只剩下优点了。
给我们的启示是：开放的心态拿来主义的精神；橘生南为橘，生北为枳-企业DNA影响不容忽视；知己知彼，量力而行-没有最好的技术只有最适合自己的技术。从技术角度，没有什么是绝对不能做的，只是看代价多少，以及是否合适比如，当年阿里还没去IOE时候，运营商不少系统中就在用MySQL了…… MySQL不是天使，Oracle也不是妖魔，关键还是要看你的技术场景，你的技术管理机制。适合你的，你搞得定的，就是好的。
二、技术能力储备和管理体系分析
先看看互联网公司，比如阿里巴巴。它们自己掌握开发人员，自己掌握架构，含应用架构，技术架构，数据架构。阿里巴巴的技术团队的薪酬管理体系，很能体现技术人员的价值，适合技术人员是生存发展。在这种环境下，开源数据库的缺点，可以靠自己培养的、国内少见的代码级专家来解决，开源数据库与应用可以做到高度融合。
运营商的情况却完全不同。由于开发长期完全外包，自己几乎没有研发技术人员，体制内也缺乏技术人员发展环境（这个大家都懂的，不展开）。这导致，十多年前培养起来的，真正具备动手能力的少量第一代技术骨干，正随着时间流逝雨打风吹去；新生力量又顶不上来。现状是，运营商对核心能力的掌控非常有限。相对来说，技术架构的掌控还相对得力，但应用架构和数据架构已经成为现实的重灾区！在局方培育机会，没有哪怕非代码级的高端技术支持专家，市场上也找不到拥有代码级技术专家的合作伙伴。最终，在运营商生态环境中，像阿里那样对mysql可以进行代码级掌控的元素已基本缺失。
去了O，用MySQL也好，PG也罢，后面的对纯数据库层的监控运维根本就是小CASE，麻烦远远不在于此。 真正的麻烦（或者说机遇）是：开发DBA团队的春天到了！必须有DBA从平台层走出来，走到数据架构管控层去！O是个大平台，应用写烂一点还能扛住，去了O无论用什么都是小平台，应用代码，表结构设计等必须严控！否则死路一条。所以说，真正的麻烦在数据架构。 阿里去O，开发DBA起了很大作用。
没想明白上面这点，悍然去O属于自杀行为。阿里的运维DBA团队很强，对MySQL运维得很好，这样很不容易了，但光这样也不行。必须看到开发DBA团队是很强悍的，没有这支团队，阿里去O绝对是不可想象的。此外，阿里还有自己的数据库研发团队，自己写OceanBase，自己修MySQL BUG。以上三方面团队加起来，我相信：TCO投入可能远超过购买O记服务的费用。
三、去O的应用驱动分析
阿里做去IOE有其业务发展上的原因。阿里云的目标，是为对于互联网和传统企业来讲，最终都得为用户服务，希望尽量减少收费和依赖，变成一个尽量廉价的公共服务平台，而在这个平台上则可以滋生出体验更好的服务。而运营商的应用场景目前来看，比较明确的还是私有云，并且希望通过去O加强自身核心能力的建设，减少对合作伙伴的依赖，剑指亚联华为这样的开发商和oracle这样的平台提供商。
而所谓阿里去O的技术原因，是oracle不能满足互联网业务的可扩展性需求，这个理论可能是站不住脚的。充分利用闪存混合架构，mysql的单库容量都能提高，更何况oracle？更何况，还有exadata？海量数据的处理，直接上hadoop，nosql就得了，本来就和去o这种oldsql，newsql的使用场合的议题扯不到一起。
结论：双方去IOE的真正原因，无论是商务和业务原因，都并不一致，甚至可以说是大相径庭。
四、去O的技术难点简析
简单说几个问题：1. 数据一致性（看业务需求，但运营商核心系统往往有强一致性要求）；2. 复杂查询支持；3. 单机的Scalability；4.Optimizer的成熟度。这几个问题，会显著增加业务开发的复杂度, 因为必须将这部分功能的需求，在应用层实现。对于技术储备一般的公司来讲, 这个就是非常高的门槛了。而运营商，在这几方面也正好中枪。
1.运营商没有阿里那种SUPER PR。其实我们蛮羡慕阿里的，比如说最近支付宝挂了，马上就被危机公关宣布成一次国军成功转进，这不，技术保障日都出来了，这么给力的PR，运营商XDJM们羡慕呀。
2.运营商是被盯上的，这个不解释，在线诸位估计心里巴不得运营商倒霉的不在少数吧？其实说多了都是泪呀。咱公司特别在乎用户投诉，不管有理没理，只要客户够没底线够没素质，够凶，敢投诉，敢骂人，基本都是可以得到赔钱的。本质上运营商在客户面前就是个弱势群体，不解释。
结论，种种综合因素，传统企业如金融和运营商不敢承担数据不一致乃至数据丢失的风险，但互联网公司说实话承受力大得多呀，这也是大实话。
五、重复发明轮子
上面说到了，去O就必须把部分原本已经在数据库层实现的很好的功能去掉，交给应用来做。这种重复发明轮子的浪费，对于阿里来说，由于业务原因，是值得投入的，但对运营商来说，完全可能是自找麻烦。运营商最好的办法，是学阿里改革，创造机制自己培养技术人员。如果做不到，那在数据库这种核心平台相关的架构上，与其用亚联华为这种国内开发商的轮子，或许，还真不如用国际大公司生产的轮子。
六、技术生态环境分析
以浙江移动为例，对Oracle的掌控程度较高：局方4人持有Oracle最高等级认证（OCM）。在对Oracle能力能掌握的情况下，浙江公司率先开始进行去O的服务，已终止购买Oracle数据库的原厂技术保障服务。浙江移动在数据库方面的积累在运营商内部我有信心说是综合能力领先的，但这样是不是就可以轻松去O了？
O的生态环境决定了最容易掌控，掌控不了O，换成其他任何数据库，只会更依赖，去O应该从去O的服务开始。不可否认的是，Oracle的数据库产品确实牛，特别是在较为传统的OLTP和OLAP场景下（如果考虑exadata因素，更加如此）。 事实上，开放和封闭的差别，不仅仅存在于代码环节，还存在于技术支持环节。而在运营商环境下，后者比前者更加重要。说实话，代码再开放，你也得有看得懂，改得了的人啊。Oracle数据库有非常开放的技术文档，带来了极度繁荣的。独一无二的第三方技术支持市场。再说句糙话，如果在如此丰富的技术江湖上，还不能培养起足以替代或者控制Oracle原厂的甲方和第三方技术力量，每天还在拿Oracle服务不好说事，甚至拿这个做理由去O，那么，首先需要反思的，是自身的技术管理思路出了问题。如果连Oracle这么好掌控的东西都对付不了，还指望能对付其他数据库吗？
有一些传统行业的领导开口闭口Oracle垄断，Oracle市场份额高是高，但光用垄断这个词形容Oracle是不完整的。Oracle市场份额是高，可是它却很注意培养生态环境，它的技术文档很多，资料很全，生态最好。这是一个垄断能涵盖的吗？ 好嘛，十八摸数据库没Oracle垄断，国产数据库没Oracle垄断，可是你从市场上能买到这些产品的靠谱的第三方技术支持服务吗？你能很容易招到这方面的DBA吗？
去O的技术难点决定了去O很可能必须开发一个类似阿里TDDL那样的数据访问层在开发外包的前提下，Oracle和山寨TDDL，谁的生态环境更开放？ Oracle和开发商，被谁绑架更可怕？
去O就必须把部分原本已经在数据库层实现的很好的功能去掉，交给应用来做。这种重复发明轮子的浪费，对于阿里来说，由于业务原因，是值得投入的，但对运营商或传统企业来说，完全可能是自找麻烦。简单去O,会降低数据库供应商的依赖，但核心能力将更加向开发商倾斜。对于传统企业来说，如果没有养自己的开源数据库研发级团队的能力（实际上传统企业的机制决定了这个基本。。。。不靠谱），那么首先至少可以在服务上尝试去O，这还是传统企业可以去拼一下的。其次，直接上纯开源也太危险，毕竟是数据库不是中间件，数据丢了不是开玩笑的，所以开源商业版是你能奢望一下的，至少出了事还有个念想吧。
那么，运营商去O之路该如何走？
首先，请记住我的话，我认为，在运营商环境下，去o不能简单理解成去o的产品，而应该理解成去o的服务。运营商应该把精力花在局方和第三方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之路来！
过度外包导致IT核心能力丧失，数据架构才是我们运营商IT架构的阿基里斯之踝！国有传统企业自身体制和机制的限制，是导致问题出现的直接原因。简而言之，内部重业务轻技术，重项目轻运营，重汇报轻实干，重管控轻创新的机制终于还是占了统治地位。
当年某动刚成立的时候，机制一度有市场化的雏形，有些激励机制今天看来仍然不过时，有些做法现在看起来很怀念！这是最好的时代，这也是最坏的时代！这句话我在最近我们内部一篇大数据培训的材料中看到过，我觉得用在十来年前世纪交替之际的运营商也是蛮贴切的。那个时代遗留下来的一些好的遗产，一直给我们提供正能量到今天。
举个例子，那时候我们一度自己开发软件，一度拥有技术人员的培养和技术支援的机制，可惜最终由于种种原因，没有坚持发展下去，中道崩殂了。当年也有过所谓的大H技术通道，但是搞得不彻底，沿用了管理干部竞聘那套做法，真正的技术人员对那套充斥着管理思路，业务思路和PPT文化的技术通道很不感冒，最终还是演变成了资深员工和退居二线干部的通道，应该说这个机制对企业的发展仍然是有正能量的，但对设立它的初衷就大相径庭了。当年考虑的开发外包，也不能说就是错误的，在当时，在当年，不失为一个实事求是的，快速上手的，抓大放小的创新方式，问题在于后面没有持续演化下去！
今天我们IT部门的员工比当年多了几倍，但是我们大多数员工的工作重心都是业务，管理和日常性事物，典型的例子是万恶的PPT，这个大家都懂的......在技术上面的投入实质上非常有限，这直接导致了后继无人的危险！现在遗留下来的硕果仅存的技术骨干和一批懂技术的干部，大多数是那个时代的遗产。运营商最后技术力量，就像沙漠里面的小草，就像突破三道封锁线走过草地雪山的红军，很多人离开了这个战线，人数锐减，剩下的人大浪淘沙，几经起伏，几度风雨，到今天仍然顽强地生存着。
但就像我在前两篇里面说的，目前我们自身的力量并不强大，太多的人流失了，今天我们在技术架构方面相对还有一点力量，但数据架构和应用架构（具体说是逻辑架构）则成了阿基里斯之踝！再说具体点，我们运营商可以自己不生产服务器和数据库，不开发应用，但是不能不掌握架构，不应该出现对任何一个层面的供应商出现过度依赖乃至近乎垄断的情况！从这个角度说，应用开发商是运营商IT技术方面最大的管理痛点，我们今天可以换网络设备厂家，换服务器厂家，甚至连适度去O也不是完全没有可能，但谁敢说我已经能够在核心应用开发的合作伙伴方面形成真正的竞争？全运营商行业我看都没有！(如果哪家运营商省级以上单位已经完全具备此能力，我一定虚心学习先进经验）运营商与合作伙伴应该是互相促进共同发展的关系，绝不应该形成对供应商的过度依赖，这也是运营商核心能力掌控应该达到的及格线。不幸的是至少在部分领域并没有达标。
我看过银行的架构管控思路，银行的看法就是掌握架构不等于不用进口用国产，简单地使用国内的软硬件产品并不能达到自主可控的目标，特别是在当前市场化和资本运作的大环境下，企业的国内外资本性质转换很快，所谓的国内和国外都是相对的，这方面市场上已经有了很多实际的案例。
银行提出的是“自主可控”研发，在满足甲方自身信息系统整体体系架构的前提下，自主研发核心和关键信息系统，并分层异构使用外部产品，实现对信息科技风险的可监控、可管理、过程可审计。简而言之，八个字，自主可控，分层异构。这个我以为很值得我们运营商的技术管理人去思考和借鉴。
今天，在我们大谈去IOE的时候，尽管我想出了各种各样的现实应对之策，但归根到底，自身技术力量的发展最后是绕不过去的，所以，必须找出运营商特色的核心能力掌控之道，换句话说的直白点就是如何加强对开发商的管控能力！我提出两手抓，两手都要硬的应对思路。
首先，必须从现在开始，总结得失，采取有效措施，奋起直追，培养积聚运营商自己的技术力量。这个我想来想去还是觉得是绕不过去。运营商之大，难道真的容不下技术人员的一张办公桌？不信，不甘心，要推动！此外，移动互联网时代，技术发展很快。传统的IOE技术架构正在逐渐演化为新一代以X86，闪存，开源应用平台，数据平台等技术为基础的新一代技术架构，站更高一点看，传统的IT正在向DT演进，在半个月之前，阿里巴巴董事局主席马云在内部邮件中提出，要在未来十年建立DT数据时代中国商业发展的基础设施。有的时候昨天的好就是今天的短，反之亦然。今天大家在一个起跑线上。IT和DT之间，不仅仅是一个技术的变革，而是思想意识的变革，IT主要是为我服务，用我来更好的控制和管理，DT是激活生产力，让别人活得比你好，DT的思想是相信别人比你聪明，IT的思想是我比你有能力，因为我掌握信息，你不掌握。
所以，我们在这个时代，几乎大家是同一起跑线。所以，昨天运营商技术团队落后了，但今天我们有机会大破大立，创造后发优势。而且，运营商根本不需要去过度创新，不要去做第一名。木秀于林风必催之，做技术老大代价是很高的，运营商只要跟在互联网行业后面，学习吸收，批判接收就可以了，而这是很有利的发展条件。当然，我希望我们现在就行动，不要再拖下去拖到技术团队衰弱到连学习抄袭的能力都丧失了，那样就太可悲了。
一、培养文化，尊重技术
在一些领导和管理部门或业务部门的员工看来，技术人员往往像是生活在另一个世界的科学怪人，他们不善言辞，脾气古怪，每次交流都是语言不详，每次汇报就是叫苦加要资源。而技术人员反过来看也是一样，我辛辛苦苦加班加点，你又未必懂我的专业你知道我有多苦吗？你知道我的价值吗？你听得懂我在说什么吗？于是，沟通不畅开始了，抱怨开始了，信息不对称开始了，甚至人才流失开始了。尤其是在运营商这种体制下，业务性型人员提拔的概率远大于技术型人员，再加上技术通道的不畅，造成技术人员价值和成就感得到满足的概率不高(有些技术人的心态是我不求工资有多高，但求被认可、被尊重总不过分吧 )，进一步加剧了这种情况的蔓延。
首先还是呼吁一下，请各级领导，管理部门和业务部门的员工尊重技术人员。请至少能够尝试去倾听他们，去理解他们，不要轻易对他们呼来喝去，指手画脚。只要这么去做了，就算仅仅是一个形式，技术人员也会感到温暖。知道吗，据说某位运营商员工去阿里的真正原因还真不一定是为了钱，而是感到业务部门的员工往往只知道做二传手，一个业务需求看都不看就往他手里扔，态度稍有怠慢就去领导那里投诉，这种得不到尊重得不到理解的感觉对技术人员的打击才是非常致命的。看上去这段很虚，但我还是要放在第一点来提。
要改进这一点其实真没什么投入，一方面只要省公司以上领导发言的时候有关尊重技术的话多说几句，多说几次就可以了，第二点就是要把中央八项规定落到实处，尤其是第二，第三条。我在这里抄录一下：第二条、要精简会议活动，切实改进会风，提高会议实效，开短会、讲短话，力戒空话、套话。第三条、要精简文件简报，切实改进文风，没有实质内容、可发可不发的文件、简报一律不发。第三点针对运营商还要加上一条，去PPT！对于运营商来说，去PPT比去IOE重要多了。当然我这个去不是说机械地不准用，而是不要滥用PPT，一切以效率出发，能脱稿的尽量脱稿，能用word的尽量不用PPT。让我们的员工从文山会海中脱离出来，把时间，把生命都燃烧在真正产生价值的事情中去，找回世纪之交那种高效务实的作风来！
二、反思自己，创造价值
一个巴掌拍不响，运营商的技术人自己也要反思。难道技术人就没有责任了？甲午战争大家都在反思清政府腐败，难道海军就可以免责了？说到底战争胜负还是一线官兵打出来的。韩国足球队再买通裁判，也得自己过硬，中国队就算有了裁判，就能进世界杯四强了？扯远了，打住......
运营商的技术人能否提升自身水平，能否以业务价值的视角来看问题，能否在日常工作中找到自己新的定位，新的地位?互联网公司也不是在技术线上白白烧钱，人家也要看到价值的。技术人员们请扪心自问，如果公司现在给技术线加大投入，技术线能给出什么样的面向业务价值的KPI？其实不要去叫苦，环境现在确实不给力，但是我希望要么闭嘴，要么走人，要么推动，三者必居其一，叫苦不是一个可以接受的选项，必须奋进，必须提升自身能力，改变形象，必须有为公司创造出价值的决心和意识。
下面简单举几个例子。
价值一：业务价值。大数据时代了，通过什么样的技术创新，技术团队能够像互联网企业那样，为公司的决策提供有效支持，为公司的营销提供高效低成本的方案?我们的线上渠道什么时候可以取代实体渠道，成为公司营销的主力?这些方面，我们的技术人能做什么?
价值二：管理价值。我们的系统能不能真正提高生产者的效能，成为公司使用我们的it系统的员工工作上的大杀器?互联网企业提把客户感知做到极致，我们能不能多少也提一点?也做到一点?这些方面，运营商的技术团队能做什么?
价值三：经济价值。我们的支撑，网络，ICT系统大量使用传统的IOE架构，投资和成本居高不下，在技术架构演讲，为公司节省投资和成本方面，运营商的技术团队能做什么?
三、创造机制，培养队伍
终于谈到最关键的一点，运营商需要有能留住技术人才的机制，运营商的人力资源管理体系必须改革!上面谈到过现行的大H体系名存实亡的现实，但是相信运营商的高层已经认识到了问题，相信运营商的人力资源管理部门不乏有识之士，只要有相关领导和部门的理解支持，这个问题一定能够解决，至少能够缓解。
我建议注意几点。首先，必须有一个大H的准入范围管理，不能什么都往里面装，否则又走上老路了。必须限制范围，真正聚焦到那些真正的稀缺岗位，高价值岗位，专业性岗位。其次，必须考虑一个合理的评价机制。现在的技术通道竞聘，评委大多是非技术部门中层和公司高层，加上真正的技术人员往往拙于言辞和PPT,在这种面试中脱颖而出的往往是适合M线的人。建议在形式上做出优化，增加客观分的比例，增加与其真正接触的员工领导的打分比重。此外，建议加强人力资源部门的团队建设，运营商的人力资源部应该真正成为公司最重要的部门，具备对各类人才包括技术人才全面的评估能力。短期内，可以采取与技术部门合作的方式来治标，可以出具临时性的技术人才评定和激励方案，中期可以引入第三方专业的咨询公司，阿里就是这么做的，也就几十万上百万，只要真正做好方案，这点成本算的了什么?远期就是看人力资源部自身建设了......
四、找准方向，重点突破
应用架构和数据架构是目前运营商核心能力掌控最大的拦路虎。应用架构（以及逻辑架构）关注系统总体功能和业务逻辑设计、系统内部和系统之间的接口设计；数据架构关注元数据、数据存储、数据分布、数据模型、数据质量、数据生命周期、数据资产、数据同步等。只要在这两点上入手，必会收到满意的效果。这个前面多次提到了，不多说了。这两个方向就是我们的重点突破口！
如何去做呢？如何才能重拾旧山河，加强开发商管控，培养运营商自己的技术力量呢？
我先打个比方，讲个故事。从前有个老皇帝，他一手打下江山，能力超强，他可以每天工作十几个小时，他可以不要宰相，事必躬亲，于是朝政一片清明。很多年后老皇帝退了，新皇帝继位，新皇帝的能力远不如老皇帝，于是新皇帝设立了宰相，帮他管理朝政。一开始，一切太平，可是随着时间的推移，由于宰相才是天天接触日常具体政务的人，宰相权威日盛，新皇帝每天工作是轻松，但是渐渐觉得驾驭不了宰相，朝政有失控的风险。皇上急了，他贬斥了宰相，自己来抓朝政，可是宰相一休息，没打过江山的新皇上每天面对堆积如山的公文，几天就形容枯槁，几近奔溃了，没法子，又把宰相请回来，于是宰相上班了，朝政正常了，宰相地位更高了。这该咋办啊。事实上，宰相仅仅是文官集团的代言人，皇帝想以一己之力对付整个文官集团，除非是打江山的老皇上，新皇上确实是力有不逮啊！终于有一天，皇上灵机一动，终于想出来办法。
对策一，釜底抽薪。皇帝最不缺的就是太监。给太监学文化，以文化太监队伍为基础，组建内廷，组建东厂。从此，外廷宰相和文官集团的公文，必须有內廷太监的确认才能执行，外廷和内廷互相钳制，东厂还时不时对文官集团的内部情况进行勘察汇报，皇上耳清目明，消息灵通，居中协调，倍感轻松。
对策二，分而治之。你宰相不是能吗，你文官集团不是铁板一块吗？皇上自从有了内廷和东厂，对文官集团的影响力大了，于是进一步推进了官职改革，把原来宰相自己设计的铁板一块的官职，改成了标准化规范化的三省六部，各省各部之间职责清楚，分工配合，但各自又自成一系，于是，宰相就更不能一手遮天了。同时，皇上还委派自己的皇室青年子弟，成立锦衣卫与东厂一起工作，这样的体制成立之后，新皇帝终于可以稳坐江山了。
大家可能看出来了，老皇帝和新皇帝就是不同阶段的运营商IT部门，宰相就是核心应用开发商，文官集团就是应用架构，内廷和东厂就是独立第三方合作伙伴，皇室青年子弟掌管的锦衣卫就是局方自己的新一代技术人员，公文就是数据架构。
局方现状是技术团队实力凋零，对开发商依赖严重，暂时自己的技术力量还需要慢慢培养，暂时还不堪大用。因此，我们完全可以投入自己的局方人员，可以以老带新，力量不足的话再加第三方合作伙伴人员，通过SOA架构体系的建设，逐步理清应用之间的接口，相信掌控接口只是时间问题。等到瓜熟蒂落，水到渠成的那一天，我们真正地掌握了接口，把核心系统进行合理的拆分，至少要把现在动不动就是CRm、BOSS这样的巨无霸系统大卸八块。任何系统拆细了还能翻起什么浪花来啊？
此外，数据架构是另一条独立战线，套路也差不多。通过有实力的第三方合作伙伴，我们完全可以从数据架构审核入手，逐步推进，逐步培养，逐步延伸到数据架构设计。在这个过程中，局方可以逐步培养出自己新一代的数据架构技术人才。具体工作开展可以以先核心系统后外围系统，先审核后设计，先流程后工具，先表明后深入为原则逐步推进。这样也就达到了初步的核心能力掌控的目的，对开发商也就具备了初具规模的掌控能力。
通过以上措施，运营商完全可能挽狂澜于既倒，一方面迅速形成生产力，一方面逐步推进，一方面逐步培育出自己的新一代技术力量。这就是堂堂正正的阳谋，正大光明，稳健而坚定。当然，和一些兄弟研讨后，我觉得，以上方案有几个地方也可能是有一定的局限性的。
首先，对合作伙伴的管理是需要成本的，运营商现在的合作伙伴数量已经不少了，再引入新的合作伙伴对运营商的管理能力是一个挑战。其次，运营商现在没有明确清晰统一的的业务架构和产品架构管理体系，很多职能都分散在各个业务部门，业务部门之间的沟通和信息交互机制也有值得提升之处，俗话说，上梁不正下梁歪，业务和产品没管清楚一定害了需求开发，需求开发出了漏洞一定影响到运行运维......这给it部门构成了很大的压力，其中首当其冲的就是IT部门的需求管理员。现在的需求管理员对外要成为使能者，多少要帮助业务部门做好业务、需求，产品的梳理，需求实现的必要性和效能的分析，对内要做好需求分析和设计，压力是非常大的，在目前的体制下也缺乏有效的激励机制，对这个团队的发展造成了一定的困扰。而对于这个团队，很多工作都是难以找到也不适合交给第三方合作伙伴的。
所以上述思路中对于独立第三方合作伙伴使用的适用范围是有一定的限制的，只能在技术架构和部分的数据架构、应用架构、逻辑架构的范围内起到一定的作用，不能面面俱到包治百病。如果这样，或许可以这样搞：抽调精锐部队，集中兵力打歼灭战。抽调局方精干力量到需求管理员团队，把这块工作先顶起来，确保顶层建设不走偏。其他各条战线，还是走我上文中的路线，独立第三方+局方新生力量两手抓，互相配合，共同发展。或许如此可行?
我们搞技术的，不要忘记了科学精神。什么是科学精神？看片子，我以为最关键就是八个字：实事求是，开拓创新。我的大学历史老师告诉我，你到浙大来，我不希望你成为一个工匠，希望你成为一个知识分子。知识分子是社会良知，有独立思考的能力，有价值观，他相信真理和民主，他不屈服于权威，上级，传统文化糟粕和任何主题思想。
阿里去O，打破了Oracle不可替代的生活，意义很大，但如果不考虑前因后果，简单粗暴抄袭，把它神话掉，就恰恰走向了事物的反面。要实事求是地去看待它。
开放的心态很重要，对于我们传统行业尤其要注意这点，封闭自大是没有出路的，会变成下图那个样子。阿里对去IOE尽管宣传过头，但毕竟包含了很多科学遗产，要虚心批判性地接受。
以上谈的都是在现有体制和环境下如何去IOE。强调一下，我并没有否定去O，我只是不认同简单化的全盘否定。
只要正确理解，有机吸取互联网行业的先进技术思路，结合运营商的现实环境情况，开拓思维，勇于创新，我们一定能走出一条我们自己的有运营商特色的去O之路来！
本文章源自三墩IT人、高效运维订阅号，经作者同意由DBA+社群进行合并整理。
作者介绍：王晓征
2016中国数据资产管理峰会特邀演讲嘉宾
中国移动浙江有限公司信息技术部副总经理
中国移动业务支撑高级技术专家
Oracle 9I OCM（2003年）
1997年中国足球乙级联赛注册球员
关于DAMS中国数据资产管理峰会：
中国数据资产管理峰会主题是行业顶级“数据”峰会，覆盖大数据与数据资产管理、架构、数据安全、云、运维及跨界数据应用等，预计2016年7月15-16日2天在上海，1主场9分场1500人规模，指导单位上海经信委，联合主办：上海云计算产业中心、DBA+社群，目前已经邀请到来自腾讯、阿里、蚂蚁金服、京东、小米、创大、浙江移动、壳牌等重量级演讲嘉宾，目标听众：CIO、CTO、架构师、大数据工程师、数据分析师、DBA等。
春节优惠大放送，现在购买门票享受折上八折优惠哦，快快点击阅读原文购票吧！