大家都需要什么样的数据库运维工具

今天的文章是一个讨论话题，希望朋友们不吝赐教，让我们也了解一下各位DBA，各个企业对数据库运维工具的需求，从而让给我们今年启动的D-SMART 3.0的开发工作一些参考。本来这篇文章是2号准备一上班就发的，不过还有些问题没有思考清楚，因此写了一半就搁置了。昨天和一个朋友聊了聊关于运维工具的事情，把一些问题重新思考了一下，今天写出来和大家一起探讨一下。

做数据库运维工具已经五年了，我一直在用“运维知识自动化”的理念做一套数据库运维工具，把运维知识作为工具的核心，因此从指标采集，到各种模型再到各种诊断工具都是围绕运维知识开展的，想让DBA能利用这个工具自动化完成以前靠人手工完成的一些监控，诊断，分析，巡检工作。一方面降低DBA的工作强度，一方面让一些专家的思想能够固化下来，帮助DBA完成一些分析工作。之前DBA都会收集一些比较有价值的脚本和工具，在自己的运维工作中做辅助，我们希望把这项工作也帮助DBA做好了。

如果仅仅是用于数据库监控，遇到问题后的大部分分析诊断工作依然主要依靠人来完成，那么普罗米修斯、ZABBIX这样的开源工具就已经够用了。对于绝大多数大企业来说，他们目前的数据库运维模式就是这样的，他们也有足够的资金来雇佣或者外包大量的DBA来保障系统的运行。

知识自动化的能力对他们来说可能会有需求，但是针对不同的人群也可能存在一定的差异化的想法。作为一线DBA来说，可能他们需要一些比较好的工具来辅助工作，而对于二线、三线专家来说，他们可能会怕这些工具影响到自己的价值，因此可能会有些抵触。

因此我一直有一种想法，就是构建一个运维知识自动化的协作生态。让大家以我们的这个工具为平台，共享运维知识，共同积累运维工具。2021年的8月份，我们发布了社区版。一年多过去了，社区版的下载激活量已经超过了600套，商用版用户也在不断增加。不过运维知识自动化的协作生态工作进展缓慢。

而我的感觉是，运维知识自动化工具想要获得最终的成功，协作生态是关键。只有大量的用户愿意分享运维案例，分享运维知识与工具，这个社区才算真正地活起来了，这个运维工具才能真正发展好。如果仅仅依靠我们公司的这个研发小团队，是很难做好的。一方面我们没有那么多的工具开发工程师快速的开发大量的运维工具，一方面我们甚至不清楚一线运维人员到底需要什么样的工具。

如何把运维知识自动化的协作生态搞好，一直是我在思考的问题。不过在社区运营方面，我并不擅长。这方面也十分需要朋友们给予指点。我们在2022年底推出了全功能免费版的D-SMART OCEANBASE专版，这个版本比2021年推出的社区版更加开放，我们免费开放了所有的功能，并且开放了所有的定制及开发接口。用户可以在此基础上完全自主定制，扩展工具集、巡检报告等功能。

不过我对此举是否能够促进知识自动化社区协作依然心里没底，DBA们似乎不是特别愿意分享工具和运维案例，因此我们还需要采用一些其他的手段来推动这项工作的进行，不知道怎么样才能让工具与运维知识分享变得活跃起来。

也有朋友建议我们彻底开源D-SMART，这方面我以前也考虑过，不过一直不敢下决心。开源D-SMART是否能够促进知识自动化社区协作这个问题一直也困扰着我。如果D-SMART开源后只是让一些搞商用运维自动化工具的厂商拿去改进他们的产品了，社区知识共享工作似乎也很难从中受益。另外一方面我们也没有运营开源项目的经验，不知道其商业价值如何兑现，因为公司的这个产品线至少要能保持收支平衡。我们不是大型互联网公司，企业无法长期支撑一个完全不挣钱的业务，因此开源后这个产品线能否长期发展下去，我们心里还是没底。如果有朋友对此有经验，也可以多多赐教！

不管怎么样，我们还是会沿着心中的梦想走下去，D-SMART社区版上开放自定义工具、自定义基线、自定义故障模型、健康模型等已经在我们的考虑中，甚至全功能社区版也在我的考虑之中，也许不久后大家可以在3.0的社区版中体验到。

今年我们的版本将会升级到3.0，在3.0中我们会融合大语言模型，我们的目标是在一块16G或者24G的显卡上可以运行这个功能。我们会发布基于可独立部署的基于国产大模型的LLMSERVER，用于辅助故障定位、报告生成等任务。当系统捕获到一些故障隐患的时候，自动通过LLMSERVER做推理分析，并调度自动化诊断工具去做分析，最终把分析结果汇总后由LLMSERVER自动生成分析报告，存储在系统中供DBA使用，配置了企业微信告警的用户就可以在微信群里自动收到分析报告了。

今天这篇文章的最终目的是向大家请教，本文的留言只有我可见，不会因为观点不同而 产生争吵，仅仅是你我之间的讨论。大家有什么想法都可以留言，我会认真阅读每一个消息的。多谢了！