今天的文章是一個討論話題，希望朋友們不吝賜教，讓我們也了解一下各位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使用，配置了企業微信告警的用戶就可以在微信群里自動收到分析報告了。