AIOPS的概念已经火了好几年了，确实目前AIOPS的应用已经在很多领域普及了，有些算法已经融入了DBA的日常工作中，因此这些年AIOPS似乎已经不那么热了。凡是新技术，大家都在谈论的时候往往是技术不太成熟的初始阶段，概念很热，但是实际上还不怎么能落地。过一阵子，一些场景已经落地了，一些场景大家也看明白了，无法真正落地。于是这个概念就没那么热了，但是比较容易落地的场景慢慢也推广起来了。
AIOPS做数据库根因分析是前些年特别热的概念，也有大量的企业在参与其中。某些场景确实能落地，不过数据库是超级复杂的软件系统，大量的具有挑战性和高价值的场景依然缺乏落地的能力。前些年有位朋友和我讨论一个概念，那就是“根因分析无法实现，运维中的大多数场景也不需要根因分析”。这个观点有些正确的地方，不过也过于偏颇了。他认为的根因分析是从唯物主义的角度出发的，我们看到的，认知的都是表象而不是事实，我们可以无限接近根因，但是无法达到。实际上这个观点从哲学上讲是没问题的，不过从运维实践上来看，是一个无用的正确观点。
在运维中我们只需要达到能够干预的根因，就可以实现在生产环境中消缺，因此运维工作中所说的根因，不需要找到哲学上的源头，只需要达到我们可认知，可处置的地方就可以了。比如说某个IO延时过大，可以从优化SQL来解决，也可以从提高存储性能来解决，根因分析只要找到了解决问题的方法，就算是成功的了，在某个时期，也就足以支撑好运维工作了。
大多数场景中不需要根因分析，这个观点也是部分正确的。既然是大多数场景不需要，那么就会有少量的场景需要根因分析。而这少量的场景不一定是不重要的场景，甚至很多情况下还是十分重要的场景。对于这些场景的根因分析还是十分必要的。比如某个SQL的执行时长抖动，对于一些关键交易系统来说十分重要，找出抖动的原因就十分关键。是并发量过大，还是执行计划变化，还是数据发生变化，亦或是数据库或者操作系统的某些配置存在问题。对于这个问题，我们需要尽可能远地找到其根因，找到确保能够消除大多数抖动的问题的时候，根因分析才能停止。
既然根因分析还是需要的，那么怎么做根因分析就是另外一个重要的话题了。被寄以厚望的AIOPS在根因分析这个领域的实际效果如何呢？经过几年的实践，结果还是挺令人失望的。在数据库根因分析领域，最起码现在在一些AIOPS的演讲中举的例子大多数还是几年前所举的那些场景。数据库中比较容易做根因分析的场景实际上不借助AIOPS也是很容易定位的，AIOPS在其中发挥的作用并没有比专家规则高明多少。
而在一些复杂的领域，专家也需要经过复杂的分析才能有所收获的领域，AIOPS目前能做的事情还不够多。AIOPS擅长发现异常，但是缺乏归纳推理复杂故障的能力，这些能力是专家的能力。专家的能力是基于数据库理论和大量的实践经验积累出来的高超的推理能力。传统的AIOPS算法无法达到这一点，近年来十分流行的大语言模型在这方面表现出了超过原有机器学习、深度学习的能力。通过大语言模型去训练数据库基础原理，专家积累的运维经验和海量的故障案例可能可以取得良好的效果，这一点我持乐观态度，不过其成本也是巨大的，目前似乎也还没有单一的企业有能力做这样的事情。
AIOPS单打独斗想要做数据库根因分析比较困难，其最主要的是AIOPS虽然有强大的异常检测能力，但是缺乏专家的综合推理能力。那么专家+AIOPS的组合就是当下比较好的选择了。福尔摩斯有句名言：“排除所有的不可能后，剩下的就一定是真相了”。AIOPS可以快速帮助专家排除不可能，找出可能，这是目前数据库运维中 AIOPS最具价值的功能。
目前我们还无法让AIOPS从一组可能与不可能中准确地推理出根因，那么不如把这个工作交给专家去做。AIOPS只要能够正确地排除掉不可能的因素，并且找出大多数可能的疑点，并给出一些力所能及的推理建议。那么剩下的工作交给专家去做就可以了，这样的组合能够大大提高专家的工作效率，缩短根因定位的时间。在实际生产案例中，采用这样的方法，我们成功地把一个原本专家单独分析需要两三个小时的场景成功地缩短到5-10分钟。
在目前阶段，DBA和专家还是运维工作的主体，AIOPS只是作为工具存在。不过我想在未来数年中，随着专业大模型及真正的AIGC的快速发展，AIOPS能够承担越来越多甚至是大多数场景中进行根因推理的那一天也不远了。不过到了那一天，专家和高水平的DBA依然是有存在的价值的，因为大多数并不等于所有，少数并不等于不重要。
