AI加持后能自动化运维吗?

首先介绍一下IF CLUB社区

这里要说一下这个社区我也是联合发起人，我发现大家现在都希望听一些日常的问题，而不是歌功颂德的说产品好。我本人多年前参会看到的大厂的经验，开了眼界。不过随着时间长了，我觉得这些要看，但是不能只有这些。阿里、腾讯这样做，我们能用吗？

TDSQL打榜1650台机器，Polardb花了20亿做到的极 致，我都承认。只是我用不上。绝大多数用户都不用上。用大家自己企业的那种SQL上去，我个人认为以上的数据库都崩溃，这是我们的常态。所以估计很多人都想开拓眼界的同时看看别人的问题有没有借鉴经验。

北京上海有密密麻麻的地铁和高架，还是拥堵。而有些城市没有地铁和高架都不怎么堵车，而这些才是我国绝大部分的区县的现状。大家想看看朴素的问题，重点是问题。躲避坑以及自己的问题是不是可以得到解决。目前国内很少有这样的平台，所以我希望更多不怕说问题的人和事情来帮助大家。

AI加持后能自动化运维吗？

可能少部分场景可以，比如在云时代就有的云计算的弹性扩缩容这些在AI上可能发挥的更好。
但是我觉得还有不少场景下做不到。或者说能解决表明现象，无法替代人工。

如果不能是因为数据不准确吗？

上周在IF CLUB首场线下活动上。徐老师主题是AI和自动化运维，他提出了一个我非常赞同的观点。即AI的前提是数据准确。事实证明了，再厉害的算法，遇到基础数据不准的情况，最终都会给出错误的答案。我就借这个这个来说说我遇到的问题和想法。

我的观点是有很多时候即使数据都准确，甚至把运维知识和运维经验加进去都无法自动化。

例如我遇到过的事update t set where id=？就这样的场景，锁了。而id我可以告诉你是主键。
想必大家都能猜到就是事务还没有提交。

那么为什么没有提交？我也可以告诉你，是微服务和中台的不合理架构，让长流程跨了多个数据库和服务。为了保障一致性，就是慢。（什么分开提交？那遇到了不一致的你来改这错综复杂的业务流程来解决？）

这表明问题是事务提交问题，根因就是不适合微服务和中台的业务场景用了不适合的架构。这都分析到这个地步了，可以把这些作为语料给大模型训练了吧？（说的直白点，把这些写在word中上传到deepseek了吧）

那么请问下次出现锁了，AI能不经过确认就去杀会话吗？几乎没人同意这样做吧？

那么AI能改变这个架构吗？伤筋动骨了，貌似也不能。也就是说只能接受这种问题存在。

即使采集数据都准确，即使AI判断100%准确，还是需要人工去确认。有的时候是等等，还是一定要人工干预。因为这种操作还需要有善后处理。

所以还是会出现：今天出这个问题，过几天还是会出这个问题。即使给AI做够的授权，做出来AI智能体，他也是按照规则去救火，无法从根本上解决。至于杀会话后的一致性问题，他是管杀不管埋了。

以上只是简单的例子，AI可以解决这些表面问题。但是深层次的问题还是需要专家的。