国产化替代进入第六个年头，很多核心系统已经切换到国产数据库，期间也或多或少发生过一系列的故障。前阵子就某银行的故障和移动的一位老专家探讨了一番，他们对这个故障进行了模拟推演，最后的结论是，如果他们遇到了类似的因为国产数据库引发的未知故障，故障恢复时间不会低于2小时，如果运气不好，业务中断半天的概率也极大。他个人感觉，2000年左右在Oracle上吃过的苦，是不是在数据库国产化的今天还要再吃一遍?

　　我和那位专家是同龄人，也经历过90年代末的那场以银行、运营商为代表的企业信息化大潮。当年运营商使用的Oracle数据库大多数还是8.0、8i和后来略微成熟一些的9i，银行则大多数在使用Informix和DB2。那时候的Oracle还没有在中国的大型核心业务系统上磨练过，软件开发商也对如何在大型核心系统上把数据库用好缺乏经验，数据库出现故障，导致核心业务停业也是常见的事情，于是DBA成为了那个时代的英雄。但凡对数据库技术有点追求的人，在那个时代都能得到极大的锻炼。其实锻炼这个词十分形象，现在这个词被90后、00后形象地称为“虐”。

　　经过二十年的不断发展，Oracle在企业信息系统中变得十分“丝滑”了，实际上这些年成长起来的DBA是比较幸福的，Oracle变得极其好用了，Oracle的相关生态也相当繁荣。

　　不过随着数据库国产化替代的开始，似乎一切又要回到20多年前了。国产数据库产品与关键业务系统的磨合还需要几年时间，国产数据库相关的知识也如25年前的Oracle一样欠缺，但是经历了Oracle“丝滑”时代制定下的“规矩”已经不像25年前那么随意了，那时候数据库故障了，业务就停了，30分钟到1小时左右能恢复，业务部门也大多数能认可。用户的要求也比较低，知道“电脑坏了”，大家就会静静地等着电脑好起来。现在的人对IT系统的依赖程度极高，某个公共服务停半小时，甚至十分钟都可能意味着巨大的经济损失，哪怕是不会有经济损失的个体闲人，也会觉得极大的不爽，认为自己为之付费后获得的服务打了折扣。

　　目前我们把应用系统从一个十分成熟的数据库迁移到了一个不够成熟的数据库上，可靠性下降，出现某些故障可能是必然的事情。但是在数字化浪潮下，我们的IT系统的依赖度又远高于二十五年前，这样就出现了考核体系与必然的客观规律之间的矛盾。我们必须要求关键公共服务的系统不出故障，从而保障经济和生活不受干扰，但是客观规律又决定了这些系统很难达到这个要求。这个课题就摆在了系统开发商、数据库厂商、用户、第三方服务商的面前。随着时间的推移，以及不断磨合，大家吃点苦，扛上一段时间，会慢慢有所改善的。关键是企业的考核制度，是不是给大家一条活路呢?面对出现的故障是不是能更大地宽容呢?