周末我花了个把小时，写了两个分析工具

白鳝的洞穴 2025-05-13

123

我们在用数据库运维工具的时候，经常发现工具的使用习惯不太符合自己的工作思路。这是因为大多数运维工具都是专家提出想法，开发人员根据从专家侧获得的需求去开发的。很多运维专家不擅长写程序，而很多开发运维工具的研发人员并不懂运维，这是目前运维管理系统总是让运维人员觉得用起来别扭的主要原因。

特别是一些深度运维工具，哪怕是一个技术难度不高的容量预测工具，要想写好着实不易。运维专家可以面对客户花样百出的实际情况，利用自己的知识体系去做分析，做出十分准确的判断来。但是专家要把他的工作思路变成一个工具是不容易的。先要把想法表述给产品经理或者直接交给具体的研发人员，这中间就会不断丢失细节，研发人员也无法一下子理解完整。很多这样的工具必须到用户现场，经过数十个上百个客户的实际案例，发现程序中存在的思维盲区，去不断修正，把各种情况都纳入进来，才能把工具做好。我们以前在开发运维工具的时候也遇到过类似情况，哪怕是一个十分简单的Oracle表空间容量分析与预测，就十分难缠。因为数据文件有可能是自动扩展的，有可能是BIG FILE，有可能22位的BLOCK ID会让8K文件哪怕设置为自动扩展也会受限于32GB，还有一次我们遇到一个用户，其中一个表空间用了非DEFAULT的32K的块大小，我们的工具就误报了。

最近经常有人和我探讨大模型对数据库运维会带来什么，其实很多人还在一些基础概念上纠结，不过我深深地感到了大模型会给未来的行业带来的影响。3月初的时候，我和一个数据库厂商交流，这个厂商在我眼里一直是比较正统常规的，没想到他们的40%的前端研发工作量都已经交给AI自动生成了，前端研发的工作效率提升近30%。

在数据库运维工具领域也将会如此，社区的小伙伴开发了一个工具开发框架，于是我这个以前只是简单了解PYTHON，对系统整体了解不多的老家伙也可以自己独立开发诊断分析工具了。写程序的过程不再是复杂的条件逻辑判断，仅仅是把自己脑子里的东西用语言文字描述出来。在这种情况下，不再有中间商赚差价，运维专家可以很方便地把自己的知识积累直接变成工具，这是AI对我们最大的馈赠。

这个周末其实我也很忙，不过晚上没事的时候，坐在电脑前尝试着写“代码”，不到半个小时，我就已经调通了kes表空间容量分析的工具，这个工具里对数据增量的计算甚至连孤儿文件都已经考虑进去了。用传统的方法来写工具，首先我要把这些变成思维导图，然后配上文字，交给开发人员，开发人员不见得一下子能理解，或者我自己的算法写得不见得完善，第一版肯定效果很差，然后经过几天的来回沟通，大概能出一个凑活可以用的版本，到用户侧又会发现很多没有考虑到的特殊情况。而现在，我一个人花了不到半小时，工具写完，初步调试也完成，可以到用户那去试用了。哪怕有些小毛病，修改起来也就是加几句话，改几句话的事情，大多数情况下，用户在我的指导下自己改一下脚本就完成了。

这种效率上的提升是革命性的，我周边的很多DBA朋友们对AI还是持审慎的态度，当然AI不是万能的，不能解决数据库运维中的所有疑难问题，但是AI辅助带来的成本上的优化，是肉眼可见的。我想未来一两年，AI也逐渐会办成你身边的水和空气，在默默帮助你，但是你可能都不会感知它的存在了。

人工智能数据库表空间

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

周末我花了个把小时，写了两个分析工具

评论