数年前，AIOPS强势崛起的时候，大家认为AIOPS是替代专家运维的最 佳实现途径。当时的愿景是无需专家知识，无需十分精准的可观测性分析，仅仅利用现象和规律，利用AI算法就能够解决困扰运维工作数十年的难题。

　　数年过去了，曾经狂热于AIOPS的我有所感悟，现在我觉得当前的数据库 AIOPS顶多算是智能辅助运维，无法称之为真正的智能运维，主要是数据库运维的场景太复杂了，很多场景专家都很难定位问题，仅仅依靠没有专家知识的算法，就想有所突破，真的太难了。搞 AIOPS的朋友可能会不大服气，认为AI的能力已经足够了，完全可以胜任复杂的故障定位，并举出他们的案例来。有时候你列举的场景可能是OK的，但是泛化到其他的场景或者用户那边就不见得有效了。这也是很多上了AIOPS项目的客户抱怨当时做实验时候觉得效果还行，一实战就不行了。

　　对于一些互联网架构的系统，数据库本身不会出现复杂的故障，大部分故障都可以通过扩容、限流或者重启来完成。对于这样的场景，AIOPS的智能化程度是够用的。而对于一些传统行业场景，AI还是不堪一用的。

　　比如有一个案例，某天凌晨00:12-00:15，用户的一个业务系统出现了三分钟的卡顿，这个业务跑了很多年了，这几天业务变化也不大，那个时段发现sga_resize_ops中shared_pool有增长，能定位是sga resize导致了问题还是其他什么原因导致了问题？还是其他什么问题？如果是sga resize导致的问题，如何让此类问题不再发生呢？

　　从AWR报告上看，确实Mutex X等待十分严重，SGA RESIZE HANG导致3分钟的卡顿的可能性很大，但是并非唯一的可能性。这需要看卡顿起始时间与SGA RESIZE在时间上的先后顺序。本案例最后分析结果是卡顿先于SGA RESIZE数秒钟，因此SGA RESIZE只是结果而已。哪怕SGA RESIZE先于卡顿，引发SGA不足的原因还是更接近于根源的原因。要想找出共享池使用量突然增大的原因才是根本性解决问题的关键。

　　如果仅仅从上面的数据上看，每秒5.2W+的执行可能是个疑点，不过从历史上看，这套系统的每秒执行数一直就这么高。通过历史数据的比对分析，找出异常与正常的关键点是深入解析此类问题的关键。基于大模型或者小模型算法想要解决此类问题目前能力还不足。

　　事实上，要想通过自动化工具分析出此类问题的原因，需要对历史的指标数据有十分精准和周全地采集。不过仅有历史数据还是不够的，虽然我们能够通过算法发现某些指标是正常的，某些指标是异常的，并且能够对异常按照时间序列去排序，但是我们还是缺乏足够的知识库，从这些异常中直接定位问题。有经验的运维专家可以发现一些问题，并且逐步排除一些可能性，从而让问题收敛，而AI算法在这方面的能力依然不足。

　　刚开始的时候我发现了这些异常，解析后0次之行的SQL，很可能是这些SQL存在语法问题。后来用户那边确认是自己的应用框架存在BUG，此类问题一直存在，在没有卡顿的时段里也会存在这样的情况。

　　要定位此类问题，如果是专家进行分析，还会考虑一种排除方法，那就是找出当天可以确定的异常情况。比如当天是否有特殊的操作，发生问题的时间是1号，因此我们也怀疑是否因为新的表分区缺乏统计数据引起了动态采样。或者说有一些新的分区创建操作等。这些问题也被一一排除了。

　　最后我还是把焦点定位在1号这个疑点上，让用户检查之前几个月1号的应用日志，发现虽然前几个月没有触发应用告警，但是在类似的时点应用都出现了类似的卡顿现象。通过这个疑点，我怀疑卡顿来自于一个周期性的任务，但是在定期任务中确实找不到相关的定时任务。而且卡顿出现的时点又不是严格意义上的0点，而是0点之后的数秒到数十秒内，时间并不一致。于是分析只能从数据库基本原理入手，最终发现了一个疑点，就是分区表的延时段创建。因为分区表延时段创建导致的CURSOR失效引发了一系列的共享池相关的问题，最终导致了卡顿。

　　对于如此复杂的故障场景，专家要排除大量的非关联因素，需要与现场的DBA进行充分的沟通才能达成目标，因为很多现象并没有被指标化，因此也无法通过自动化采集形成指标，更不要说去做自动化分析了。在缺乏基础数据的基础上，AIOPS根本无法捕获到与此类理论相关的知识点和数据，因此怎么可能将分析指向此诊断路径？

　　从上面的那个案例来看，目前AIOPS的理论基础是有的，无论是小模型还是大模型，都是能够辅助专家进行分析的。其中最为缺乏的还是高质量的专家知识，对于此类问题，需要由专家参与才能构建出来。专家需要构建出一系列的图谱，才能让知识数字化，利用这些数字化的知识，才能知道想要走通这些图谱需要什么样的数据，然后我们才能把数据库的现象数字化表示出来，这样AI算法才能覆盖这个场景。

　　比如上面的一个关于direct path read temp/direct path write temp过多引发系统问题的知识就需要理解Oracle直接路径读写原理的专家经过梳理才能够比较清晰地呈现出来。有了这张图，才能够编制出有价值的算法来分析此类问题，虽然说这张图还只是很初级，还只是把一些常见的问题包含在内。在构建算法之前，首先要把分析要素都指标化了，否则算法也是巧妇难为无米之炊。

　　在数据库领域，AIOPS是未来必然的方向，不过在实现的路径上，还有很多争议，我觉得，任何智能背后都必然有更为艰苦的人工，想要绕过专家，绕过知识去构建AIOPS，只能是空中楼阁。