信创下的数据库运维与服务
这个周末比较巧，好几个以前的老客户老朋友打电话来咨询数据库的事情，无一例外都是和信创相关的。他们的上级集团公司要求他们近期上报信创数据库的方案，不过对于方案之外的数据库运维才是他们为关注的。这几个都是我十多年二十年前服务过的Oracle用户，IT规模不算很大，运维能力也较弱。他们以前用的是Oracle数据库，每年的运维经费也捉襟见肘。他们刚刚问我的时候，我还开玩笑说，准备多点钱，就不怕没人给你提供服务。他们认为，虽然自己的IT经费不太充裕，不过实在没办法的时候，也只能向上面要求增加经费预算了，这个问题反而好解决，不好解决的是以后采用什么样的运维模式，以及谁能给他们提供服务的问题。经过交流我发现他们这样的例子还很多，仅仅他们的集团公司旗下就有几十家类似的企业面临类似的问题。他都是在2000初开始引入Oracle数据库的，目前的版本还停留在11.2上，不过近这十年他们基本上也都没怎么变更了，系统运行也较为平稳，平时在数据库上的运维费用不高，而更换数据库之后，他们面临着巨大的运维压力。首先是自己的人肯定没有一个人懂国产数据库，以前他们用的比较熟悉的工具大部分也将会被淘汰。新的工具是否有这么丰富，用起来是否习惯压根不清楚。大的问题还是服务，以前用Oracle的时候，他们就用不起原厂服务，不过好在第三方服务价格还能接受，质量也还可以，因此他们希望更换国产数据库之后，服务价格可以贵一些，但是服务质量能够有保障。对这一点，我建议他们做好思想准备，做好基本上没有服务的前提下先让IT系统能够正常运转，做好各种应急预案，先把主备高可用搞好，把故障切换预案做好，而不要把运行保障依托在服务厂商身上。同时在应用迁移上多预留一些费用，一旦有些问题数据库解决不了，那么就从应用角度先绕过去。对于他们这种IT规模的企业，数据库原厂服务的覆盖肯定是不好的，而第三方服务在国产数据库的覆盖上也很差，因此想要获得质量较好的第三方服务也十分困难。在明年国产数据库的起步阶段，这一些都必然是客观存在的，既然国产化替代工作必须要做，那么这个阶段就只能挺过去。实际上，数据库国产化替代这件事因为目前的国际形势，变得势在必行，这一点不是某些人觉得怎么样就能改变的，而顺应这种改变，也是必须要去考虑的问题。这可能会影响到很多做Oracle数据库服务的厂商以及很多Oracle DBA。对于这些厂商来说，这件事肯定会带来较大的冲击，不过也面临着巨大的机遇。根据我和一些客户的沟通，在未来的五年内，这些要做数据库国产化替代的企业，在数据库采购、应用迁移、数据库运维服务等方面都预算了比以往更多的资金。国产数据库厂商的服务能力存在较大的缺口，因此第三方服务的机会肯定是很多的。只不过国产数据库的DBA培养是一个比较大的难题，一个的DBA不可能是在自己的实验室环境中培养出来的，必须有大量的实战案例才能培养出真正的高手。因此在数据库国产化替代的初期阶段，数据库服务支撑能力不足肯定会存在一段时间。要想用好国产数据库，就必须缩短这个服务空窗期，尽快培养出一大片国产数据库的运维支撑人员出来，这对于构建国产数据库生态十分关键，实际上目前打造这个服务生态的关键还在于国产数据库厂商。不幸的是，我们的国产数据库厂商并没有把这件事当成一件十分重要的事情来做，他们的工作重点还是在一些比较大的客户身上，这些客户一般会花较多的钱来购买许可证，并会大量购买现场支持服务。如果数据库国产化工作仅仅限于一些大企业，这种做法是无可厚非的，只不过在目前的国际国内大形势下，大量的中小型企业也会加入到这个行列中来。我们的国产数据库厂商也需要考虑一下这些企业使用了自己产品后的服务问题了。一方面需要加速服务团队的建设，以满足不断增长的用户数量的需求；另外一方面也要加强售后服务生态的建设。不要认为某些第三方服务厂商抢了你们几个运维服务的单子就不爽，如果他们能把服务工作大多数都接过去，让你们能够专心把数据库产品做好不是更好的一件事情吗？我们的数据库厂商应该为广大第三方服务厂商与DBA提供好服务，搞好文档、学习教材、知识库等基础的运维支撑材料，广泛地开展免费的DBA培训，加快第三方服务能力的建设，实际上是国产数据库发展的必要支撑。现在很多国产数据库厂商的市场还没做起来，不过也学起了Oracle，搞起了了各种收费的专家、大师培训。实际上Oracle也是已经实现了在全球市场占有率超过50%后才开始这种增值业务的，我们的数据库厂商学的有点早了，有时候免费的生意也是很赚钱的买卖。也有些朋友和我聊天的时候在抱怨，Oracle用的好好的，折腾这些干什么？实际上他们忽略了两点。首先他们决定Oracle用的好好的，因为他们用的都是盗版Oracle，如果每套Oracle都要求他们按照实际上使用情况付费，哪怕给他们半价，可能也是用不起的。在法治越来越健全的今天，总是用盗版数据库产品，对企业来说也不见得是件好事。第二个问题是，目前的国际形势并不是单方面的问题，而是一个短时间内无法解决的问题，因此去掉Oracle这个问题实际上已经是必须做的事情了，对于必须做的事情，再去分析为啥要去做，就没有任何意义了，只有想办法怎么用小的代价去做好。在每次危机之中，危中必然有机。对于数据库服务厂商和DBA来说，现在执拗的说去Oracle是有病，是劳民伤财，那实际上只是在错失这个危机中的“机”，终获得的只能是“危”。顺应潮流，自己快速地完成调整，做出必要的改变是解决这个危机的好的办法。在这个转变之中，社区应该是一个十分重要的力量，当一个人的力量太弱的时候，借助社区的集体力量，共同积累国产数据库的运维知识，共享国产数据库运维案例，形成共同共享的工具与经验，可以让大家的学习与转型成本都得到有效的下降。我想国内比较活跃的IT社区今后也将会扮演更为重要的角色，当年Oracle的第三方服务能力也是依托了itpub、csdn等社区才快速发展起来的。