有一次我和一个分布式数据库厂商的内核研发人员谈到他们的产品的可观测性方面存在不足。他的观点是,分布式数据库太复杂了,不能按照运维Oracle那样去运维它。他们搞数据库内核的人的目标是让数据库完全自治,数据库内部的自愈机制会自动发挥作用,无需运维人员介入分析。因为他们的产品太复杂了,运维人员对于大多数复杂一些的故障是束手无策的。
他的观点在某个角度上看是有道理的,分布式数据库的复杂度太高了,依靠运维监控发现问题,想要快速定位问题是比较困难的。最近一些大系统发生故障后,恢复的时间都相当长,也从侧面说明了这个问题。据说某金融系统故障,仅仅定位一个看似并不复杂的问题,花了近2个小时。对于金融机构要求的1-5-10,一分钟发现,五分钟定位,十分钟恢复,简直就是云泥之别。在这些业务场景中,依靠运维是不靠谱的,依靠数据库的健壮性才能彻底解决问题。
但是又有哪个数据库是100%可靠的呢?数据库内核开发人员水平再高,也不可能考虑到成千上万的用户场景,也不可能在设计中能够针对任意场景都游刃有余,数百人的研发队伍里也不可能不写出一个BUG。在一些国产分布式数据库的大型运营故障中,大多数分为两类,一类是产品对的BUG,另外一类是一些非预期的负载行为引发了某个资源不足。
实际上无论你数据库产品的复杂度如何,技术水平如何,想要用好还是离不开可观测性的。希望数据库运行不依赖于运维,而通过数据库内核来提供保障,这个理想是不错的,但是现在很难做到,未来也不见得能够真正实现。数据库自治能力与可观测性其实不是对立的两极,数据库自制能力也高度依赖数据库的可观测性。数据库内核想要实现高度自治,自己感知数据库内核的问题,也必须要依赖于自身的可观测性。
在不断提升数据库自治能力的同时,通过提升数据库的可观测性,让运维人员可以随时感知数据库内核中存在的隐患,既可以针对数据库的缺陷做提前的优化,又可以在系统故障时更快速地定位问题。这条Oracle以前走得不错的路子,现今依然有参考价值。