隨著數字化的不斷深入，數據庫爆炸式增長已經是一個現實了。如此數量眾多，種類繁雜，還包含大量國產數據庫的中小型數據庫如何運維，是未來擺在每個企業IT部門面前的一道難題。傳統的企業IT運維都是抓大放小，關鍵、核心系統花大價錢招人或者請第三方服務商駐場服務，一些不重要的，小型的的數據庫就放任不管，出了問題再去解決。不過隨著數字化轉型的不斷深入，大量的不能放任不管的中小系統又擺在運維人員面前了。再加上以前一套Oracle數據庫干的事情，現在可能需要分解為多套國產數據庫來干。
以前雖然Oracle運維起來難度大一些，不過關鍵系統數量有限，人還是干得過來的。現在的國產、開源數據庫雖然比Oracle簡單多了，不過原來運維Oracle的模式似乎也不大靈光了。平時不出問題的時候人工去監控也沒多大價值，出了問題，人工去處理似乎也經常發揮不出啥作用。再加上面對如此龐大的數量，總是覺得力不從心。
確實如此，Oracle時代行之有效的運維模式到了現在國產、開源數據庫時代似乎不大好使了。轉變思路，轉變工作模式迫在眉睫。實際上既然業務都在數字化轉型，IT運維也應該數字化轉型了。今天我們就來討論一下數據庫的數字化運維能力是如何構建出來的。
圖片
數據庫的數字化能力來源是數據庫產品自身的可觀測性接口。通用數據庫的可觀測性接口一般來說還是比較豐富的，一些開源的專用數據庫（比如clickhouse、mongodb等）相對少一些。一般來說，面對場景的復雜性和多樣性越多的數據庫產品就需要越多的可觀測性能力來支撐其運維。上面的圖中左側是數據庫需要對外提供的可觀測性能力，右側是IT部門需要構建的數字化運維能力。可觀測性是數據庫提供給運維的基礎數據，數字化運維能力是IT部門建設的自動化分析與處置能力。
IT部門對于數字化運維能力的終極目標是自動化處置與故障自愈，不過這個要求很高，可以在一個組織內部，通過對自己運維對象與運維流程的深入理解不斷的演進與完善。不過個性化定制的工程量很大，極難做成通用產品去銷售。前陣子和螞蟻的同學做了一次深入的交流，觀看了他們支付寶的運維管理平臺，他們的業務自動限流、SQL自動優化、故障自動隔離等方面的能力已經做得很強大了。我當時看得十分眼饞，問他們這部分能力能不能開放到OCP里。他們很坦誠的告訴我，這些能力都是基于對他們的系統充分了解的基礎上構建起來的，甚至和他們的關鍵業務系統的代碼都是關聯的，想要開放成通用功能是有一定難度的。
雖然構建高級目標是需要長時間積累的，不過飯可以一口一口的吃，先把基礎能力構建起來還是可以做的。不過要想構建基礎的數字化運維能力也還是有一定的基礎條件的。數據庫的可觀測性接口的能力強弱限制了數字化運維能力的建設。傳統的數據庫監控是網管理念的監控，數據庫的幾個關鍵指標合理，不宕機就行了，因為判斷系統是否存在問題主要還是靠人。數字化運維是要考算法來判斷系統是否存在問題 ，那么所需要的監控指標就復雜多了。
舉個例子，哪怕是最簡單的配置信息，如果是人工運維時代，那么很多配置信息記錄在系統里或者保存在文檔里還問題不大，大不了人工去檢查。而如果要數字化運維，那么數據庫的備份策略，備份作業的完成情況等配置信息都必須要數字化了。這方面Oracle數據庫的完備程度是十分高的，值得國產數據庫去學習。通過系統視圖，我們可以知道大量的數據庫運行于配置變更的細節，這對于數字化運維和最終實現數據庫自治十分重要。
活躍會話歷史（ASH）是數據庫數字化運維高級階段不可缺少的數據支撐。精準的故障預警和根因分析都需要ASH數據的支持才能實現。因此ASH也是很多數據庫故障自愈能力構建的基礎。數據庫要提供ASH的能力并不簡單，需要在數據庫核心代碼中能夠將大量的會話活動數據轉儲出來，最終固化到系統表中。為了實現更精準的分析，ASH要求的采樣頻率一般是1秒鐘，這對于數據庫內核也是一個巨大的考驗。目前應有一些國產數據庫已經開始提供ASH數據了，比如openGauss、Polardb、KingbaseES等。
Top SQL的發現與分析是另外一種十分關鍵的可觀測能力，在以人為核心的運維時代，對數據庫的Top SQL可觀測能力要求也不是很高。支持慢SQL輸出就夠用了。當系統出問題的時候，啟動慢SQL日志輸出，人工去看日志分析問題就行了。而如果要想實現自動化分析，那么就需要運維平臺主動采集系統中的SQL語句。
僅僅分析“慢SQL”可能也不大夠用，因為有很多問題并不是“慢SQL”引發的，一條平時執行時間10毫秒的SQL，突變為50毫秒也可能引發一場系統大災難。而把“慢SQL”的門檻設定在50毫秒肯定是不合理的。
還是那句話，Oracle在Top SQL可觀測性方面做得很好，而國產數據庫在這方面還差強人意。很多數據庫僅僅提供最近執行的SQL的采集接口（條數可以設定，不過設多大才夠用呢？），有些數據庫雖然在內存中保存著cursor的所有SQL語句，但是無法采集到的SQL的執行計劃，而要自動做explAIn又因為參數或者綁定變量的問題而往往無法完成。無法自動采集到這些信息，就無法發現SQL存在的問題，做自愈也就無從談起了。
本來今天還想多寫一點，不過現在已經九點了，暫時先寫到這里，明天再繼續聊吧。
