文章转载自"ToB行业头条"
tyle="visibility: hidden; opacity: 0; ">
—
建立国产数据库的应急响应流程,培养自己的数据库运维人才,定期主动和数据库厂商沟通以获得最新的产品资讯等,都是亟待解决的问题!
来源 / 数据最前线 (ID:data_battlefield)
作者 / 数据最前线
周末现场支持客户的核心系统及周边部分应用投产上线,当天晚上各项工作进行的都很顺利,凌晨三点上线基本完成,大家都松了一口气,拖着疲惫的身躯回去休息。不出意外,这次上线和以往的很多次成功上线一样,不会掀起任何波澜。第二天早上10点,业务突然发现有部分表查不到数据,接下来又发现第二张第三张表有类似的问题。在接下来的分析过程中,又发现一些奇怪的现象。比如,查询某个字段有数据但是查询所有字段没数据,带条件查询没数据但是不带条件查询所有字段有数据。突然间原本安静的操作间喧闹了起来,开发运维部门的领导也赶到了现场,大家七嘴八舌的讨论各种可能的原因。好在是前一天晚上重大变更,客户安排了工程师保障,很快厂商技术人员从酒店赶到了现场。但是对于复杂的情况,支持工程师也没有处理过类似的问题,只能是将故障现象和相关日志反馈给研发。下午3点左右,研发给出反馈,确认是优化器上的已知Bug导致本次问题的发生。解决方案有两个,1是升级数据库到新版本,2是重启所有的数据库节点。下午5点左右,客户开始滚动重启数据库集群节点,半小时后完成,系统恢复正常,而这时已经距离故障发生近8小时!事后复盘,这次救援现场,暴露了国产数据库使用过程中的种种隐患。首先,质量保证体系不完善。本次故障最终确定的原因是数据库的Bug,其后台研发早已经知道存在这样的问题,但是并没有及时主动通知到客户,甚至现场的支持工程师也不清楚。对于客户来说,没有任何针对这个问题的处理手段和应急预案,出现问题只能抓瞎。
其次,售后服务体系不健全。国产数据库厂商大多数规模不大,售后网点的覆盖也不全。比如这次现场工程师不能及时定位问题,客户要求研发到场,需要南方总部派人,11点左右提的要求要到晚上6~7点才能赶到现场,真要是大故障,黄花菜都凉了!
第三,运维支持工程师能起到的作用有限。受限于产品的受众数量,以及厂商在生态建设上的投入,掌握国产数据库的工程师相对较少,尤其是一些小众的产品更是如此。即便对于原厂工程师,大多数的产品问题,也只能研发通过源代码的分析检查才能定位和修正,支持工程师能力强的可以协助定位问题,能力不强的只能干瞪眼。虽然在现场承受着客户的巨大压力,却也无能为力,发挥不了太大的作用。
因此对于最终客户来说,建立国产数据库的应急响应流程,培养自己的数据库运维人才,定期主动和数据库厂商沟通以获得最新的产品资讯等,都是亟待解决的问题!开源生态的繁荣大大降低了数据库行业的准入门槛,XC政策的加持下国产数据库行业的“百花齐放”,截止到今年7月,墨天轮上收录的国产数据库多达288种。海量的数据库产品严重割裂了市场,大多数国产数据库厂商生存并不容易,为了拿到项目彼此之间相互攻击的现象非常普遍,同时也给客户的选择带来很大的困难,PPT上讲的都很好,只有真正经历过的才能深刻体会其中的酸甜苦辣!大家在使用数据库的过程中有哪些心得感想呢,欢迎关注留言,一起来唠唠!