谈到AIOPS，我们往往会把目标定的过高，总觉得如果不一步到位，让AI解决所有的问题，那还不如不做。实际上信息技术发展了几十年，任何技术都不是一步到位的，随着某个技术的发展，会越来越好用，能够解决更多的问题，而某项技术刚刚成熟的时候，能够解决的问题是有限的，不过也不妨碍我们在技术发展早期就开始使用这项技术，当年的关系型数据库技术就是如此。

技术的发展让我们可以更高效的去完成我们的工作，所有的技术发展都是渐进式的，不可能一蹴而就直达终点。AI技术也是如此，我们在谈AI技术的时候，往往有两种极端的观点：一种观点是AI无所不能，另外一种是AI存在各种缺陷，所以AI目前还不堪大用。实际上在运维领域，目前AI已经能够帮我们做很多事情了。AI的意图识别能力是目前能够帮助我们提升运维能力的重要助手。我们在做运维工作的时候，都是围绕意图来展开的，传统的模式是我们有了意图以后由人工思考并完成这些工作。

目前在绝大多数企业里都有很多专用的、片段式的工具，用于完成一个特定的工作以前大家十分头痛的是如何管理这些工具，并且让这些工具更好地发挥作用，很多企业开发了复杂的管理工具想实现这个目标，不过效果不佳。AI的意图识别能力可以更好地管理这些工具，让他们能够在运维中有更大的价值。如果把这些工具略加改造，成为MCP工具，那么基于大模型的意图识别+MCP SERVER就可以更好地管理这些工具，让这些工具能够通过编排完成更复杂的分析任务。利用AI的意图识别来管理MCP改造过的工具技术实现的可行性很高，不过改造工具还是需要投入的，制定企业级的MCP工具的规范可能是更加重要的事情。

第二个误区是关于NL2SQL的，我和很多客户交流过关于数据库的AIOPS问题，绝大多数领导对这个话题都很感兴趣，他们谈到AIOPS的时候，和我聊的第一个技术就是NL2SQL，似乎AIOPS的核心就是NL2SQL。确实，NL2SQL很重要，是AIOPS未来深入发展的核心技术之一。不过在企业做数据库的AIOPS的前期，并非必须的能力。NL2SQL实际上是一种基于语义理解去做SQL自动编程的能力，这个概念目前在AI应用领域目前十分火热，在数据应用领域，NL2SQL还有一个霸气的名字-“AI问数”。

数据库运维不是一种泛泛的SQL编程，核心价值来自于企业或者DBA积累的运维知识，利用这些知识去解决数据库的运维问题的时候，和数据应用领域的“问数”还是有较大区别的。

在数据库运维领域，一些复杂的数据分析往往不只是数据的查找，还包含很多分析经验，如果用NL2SQL来实现，其效率不高。而且数据库运维领域的数据查询是相对固定的，利用预先准备好的脚本工具来“问数”才是比较有效的方式。因此NL2SQL技术在数据库运维领域的作用与在数据应用领域相比，重要性没有那么大，甚至没有NL2SQL的能力，也不妨碍数据库AIOPS能力的建设。

当然，当未来NL2SQL技术相当成熟的时候，AI有了全面的自主编写SQL的能力，在一些复杂的故障场景分析中能够发挥更大的作用，不过这是未来的事情了，现在在数据库运维领域，不用过多关注。

第三个误区是有了智能化，就可以跳过数字化了。目前绝大多数企业在数据库运维领域可能刚刚进入制度化的阶段，离自动化、数字化还很远。不过这样也不妨碍领导想做智能化。很多领导甚至认为有了智能化技术，就可以跳过以前他们一直没有做的数字化，直接弯道超车了。实际上“数字化”是智能化的基础，想要做好智能化，就必须先把数字化的课补上，否则你搞出来的智能化不是真正的智能化，而只是一种智能化幻觉。

第四个误区是AIOPS的目的是替代人，所以对DBA是不友好的。AIOPS部分替代人，未来是一定的，AI会重塑很多行业，DBA行业也是如此。很多技术都可以帮助我们提高效率，降低人力开销，哪怕没有AIOPS。在经过数据库国产化替代之后，DBA这个行业就已经被重构了。AIOPS在目前阶段只会赋能DBA，让DBA在现阶段通过AI赋能能够去弥补目前能力上的不足。运维的主体责任人是DBA，DBA作为责任主体，目前而言还是不可替代的。不过随着AI技术的发展，DBA的工作效率得到了提升，那么可能企业不再需要招聘更多的DBA了，这是不远的未来DBA面临的最重大的挑战。拥有AI赋能的DBA在这个挑战到来时会有更大的竞争力，因此DBA不应该回避AI，讨厌AI，而要更主动地去拥抱AI。