我們一起聊聊維運知識的呈現需要個人化嗎？

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

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

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

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

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

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

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

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

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

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

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