這些年數據庫運維工具的領域各種概念層出不窮，每個用戶好像都有自己的特殊情況，他們需要的運維工具的功能也千差萬別，搞的有時候讓我都感到有些弄不明白用戶到底需要什么樣的產品了。有些運維工具是企業的剛需，是高頻使用的功能，比如說數據庫的安裝部署、自動打補丁升級，批量修改數據庫配置等。隨著企業私有云的建設，這些功能會逐步納入到云平臺管理的范圍之中。

而對于運維監控、系統預警、系統巡檢等方面的功能，大家的需求就千差萬別了。我們是做運維知識自動化系統的，目的是通過將運維知識數字化幫助DBA進行運維監控、故障預警、根因分析、系統巡檢、SQL審計、容量管理、安全管理等工作，通過數字化的運維知識直接輔助DBA工作，從而降低人工運維的成本。

我們的產品在某些用戶那邊很受歡迎，覺得工具確實對他們很有幫助。而對于某些用戶來說，他們覺得還是更相信DBA的判斷，還是需要依靠以前的模式來監控和管理數據庫系統。還有一些企業有十分嚴格的管控，通過什么方式來監控系統，甚至使用什么命令，都有十分嚴格的要求，如果沒有按照規程操作，系統出了問題，責任是很大的。

作為D-SMART產品實際上的產品經理，我也經常從運維人員的角度在思考問題，“運維知識自動化”如何才能給一線運維人員更多的幫助。前兩天的一次與客戶的線上交流給了我很大的啟示，雖然這只是某一個用戶的需求表達，不過我感覺可能他們遇到的問題還是有一定代表性的。首先他們對“運維知識自動化”這個概念十分認可，他們覺得以前買過很多數據庫運維工具，但是買來的都只是工具，并沒有買來運維數據庫的知識，因此這些工具在他們那里使用效果都不太好，大部分買過來半年后就沒人用了，我們這個工具是他們覺得可以長期使用的。

不過雖然我們的工具理念和他們比較吻合，但是我們的工具目前還無法覆蓋他們日常運維監控工作的全部，一些他們日常的監控功能還沒有覆蓋。后來我和他們交流了一些他們日常工作的內容。我發現實際上我們的工具中的一些功能基本上能夠替代他們以前的一些監控行為。因為我們之間的一些運維理念存在差異，某些我們覺得可以通過日檢來解決的問題，他們需要每天定時去做一些檢查。某些我們可以通過其他方式來進行評估的風險，他們習慣于用自己的方法去分析。    

其實大家都在使用自己的“運維知識”來進行日常的運維工作，不過運維知識體系是十分復雜的，大家日常所依靠的運維知識雖然從理論基礎上看是不矛盾的，不過在實際工作中，人們更習慣于按照自己的習慣去監控和管理數據庫系統。這些習慣的差異還是會為運維人員帶來很多困擾。

比如說有個客戶在他們的運維手冊里要求定期到服務器上采集listener的狀態，我們的工具里并沒有listener探活的指標，而是通過真實連接去探活數據庫的可用性。其實我們的探活包含了對監聽的探活，能夠真正連接數據庫，肯定監聽是工作正常的，否則我們會采集到監聽失敗的消息。對于這個問題我們可以通過說服用戶去接受我們的指標，不過對于用戶來說，最佳的使用體驗是能夠直接看到監聽狀態的指標數據，這樣的話，就完全不需要改變他們的運維習慣了。

作為運維工具的開發商，我們不能只是從工具的角度去考慮問題，讓用戶來適應工具的特性，甚至我還聽說過某位工具廠商的朋友說要對用戶的運維習慣進行教育，讓他們的運維能力得到提升。對于某些用戶，可能能夠完全接受一種全新的監控工作模式，不過對于一些用戶來說，并不一定能夠做到如此。在十多年的運維工作中，他們已經積累下了一些被證明有效的運維經驗，完全丟棄也是一種浪費。

大語言模型在運維領域受到追捧的一個十分重要的原因也是如此，因為它可以用你所習慣 的知識語言體系來回答你的問題，讓你不需要做任何知識體系轉換。這種特性也是運維工具廠商需要去學習的。通過簡單的配置實現運維知識的個性化呈現，盡可能地讓工具貼近用戶現有的運維習慣，既可以讓用戶更快更好地使用工具，也可以最大限度地發揮工具的作用。    

我欣然接受了客戶的要求，表示一定全力配合他們，盡可能把他們所有的日常運維工具的能力都納入到系統中去，盡可能不改變他們現有運維習慣的前提下提升他們的監控預警與故障分析能力。通過交流，雙方都覺得通過這個合作，利用現有平臺的基礎能力，可以實現絕大多數日常運維工作的白屏化，進一步再實現部分操作的無屏化。

要實現這一點，首先需要將他們的所有日常監控、巡檢操作都實現自動化采集，并通過一個集成界面讓他們便捷查看。然后逐步結合一些分析算法，對這些狀態和數據進行自動化分析，形成可預警的故障模型，當系統出現某類異常的時候進行自動預警。經過一段時間的磨合后，運維人員可以對系統的預警產生一定的信賴，那么運維人員今后就不一定需要定期去查看監控屏幕了，運維工作也可以逐步從白屏化向無屏化演進了。