以前虽然Oracle运维起来难度大一些，不过关键系统数量有限，人还是干得过来的。现在的国产、开源数据库虽然比Oracle简单多了，不过原来运维Oracle的模式似乎也不大灵光了。平时不出问题的时候人工去监控也没多大价值，出了问题，人工去处理似乎也经常发挥不出啥作用。再加上面对如此庞大的数量，总是觉得力不从心。
确实如此，Oracle时代行之有效的运维模式到了现在国产、开源数据库时代似乎不大好使了。转变思路，转变工作模式迫在眉睫。实际上既然业务都在数字化转型，IT运维也应该数字化转型了。今天我们就来讨论一下数据库的数字化运维能力是如何构建出来的。
图片
数据库的数字化能力来源是数据库产品自身的可观测性接口。通用数据库的可观测性接口一般来说还是比较丰富的，一些开源的专用数据库（比如clickhouse、mongodb等）相对少一些。一般来说，面对场景的复杂性和多样性越多的数据库产品就需要越多的可观测性能力来支撑其运维。上面的图中左侧是数据库需要对外提供的可观测性能力，右侧是IT部门需要构建的数字化运维能力。可观测性是数据库提供给运维的基础数据，数字化运维能力是IT部门建设的自动化分析与处置能力。
IT部门对于数字化运维能力的终极目标是自动化处置与故障自愈，不过这个要求很高，可以在一个组织内部，通过对自己运维对象与运维流程的深入理解不断的演进与完善。不过个性化定制的工程量很大，极难做成通用产品去销售。前阵子和蚂蚁的同学做了一次深入的交流，观看了他们支付宝的运维管理平台，他们的业务自动限流、SQL自动优化、故障自动隔离等方面的能力已经做得很强大了。我当时看得十分眼馋，问他们这部分能力能不能开放到OCP里。他们很坦诚的告诉我，这些能力都是基于对他们的系统充分了解的基础上构建起来的，甚至和他们的关键业务系统的代码都是关联的，想要开放成通用功能是有一定难度的。
虽然构建高级目标是需要长时间积累的，不过饭可以一口一口的吃，先把基础能力构建起来还是可以做的。不过要想构建基础的数字化运维能力也还是有一定的基础条件的。数据库的可观测性接口的能力强弱限制了数字化运维能力的建设。传统的数据库监控是网管理念的监控，数据库的几个关键指标合理，不宕机就行了，因为判断系统是否存在问题主要还是靠人。数字化运维是要考算法来判断系统是否存在问题 ，那么所需要的监控指标就复杂多了。
举个例子，哪怕是最简单的配置信息，如果是人工运维时代，那么很多配置信息记录在系统里或者保存在文档里还问题不大，大不了人工去检查。而如果要数字化运维，那么数据库的备份策略，备份作业的完成情况等配置信息都必须要数字化了。这方面Oracle数据库的完备程度是十分高的，值得国产数据库去学习。通过系统视图，我们可以知道大量的数据库运行于配置变更的细节，这对于数字化运维和最终实现数据库自治十分重要。
活跃会话历史（ASH）是数据库数字化运维高级阶段不可缺少的数据支撑。精准的故障预警和根因分析都需要ASH数据的支持才能实现。因此ASH也是很多数据库故障自愈能力构建的基础。数据库要提供ASH的能力并不简单，需要在数据库核心代码中能够将大量的会话活动数据转储出来，最终固化到系统表中。为了实现更精准的分析，ASH要求的采样频率一般是1秒钟，这对于数据库内核也是一个巨大的考验。目前应有一些国产数据库已经开始提供ASH数据了，比如openGauss、Polardb、KingbaseES等。
Top SQL的发现与分析是另外一种十分关键的可观测能力，在以人为核心的运维时代，对数据库的Top SQL可观测能力要求也不是很高。支持慢SQL输出就够用了。当系统出问题的时候，启动慢SQL日志输出，人工去看日志分析问题就行了。而如果要想实现自动化分析，那么就需要运维平台主动采集系统中的SQL语句。
仅仅分析“慢SQL”可能也不大够用，因为有很多问题并不是“慢SQL”引发的，一条平时执行时间10毫秒的SQL，突变为50毫秒也可能引发一场系统大灾难。而把“慢SQL”的门槛设定在50毫秒肯定是不合理的。
还是那句话，Oracle在Top SQL可观测性方面做得很好，而国产数据库在这方面还差强人意。很多数据库仅仅提供最近执行的SQL的采集接口（条数可以设定，不过设多大才够用呢？），有些数据库虽然在内存中保存着cursor的所有SQL语句，但是无法采集到的SQL的执行计划，而要自动做explain又因为参数或者绑定变量的问题而往往无法完成。无法自动采集到这些信息，就无法发现SQL存在的问题，做自愈也就无从谈起了。
本来今天还想多写一点，不过现在已经九点了，暂时先写到这里，明天再继续聊吧。
