北京
三十年期我們用Oracle數據庫的時候是盲目用，那時候用得就很不好，甚至把重啟數據庫都當成一件恐怖的事情來做。如果不是高手，都不敢輕易重啟數據庫，生怕數據庫重啟后起不來了。當時江湖中這種傳聞也是很多的，我有一次重啟了二十多分鐘還沒起來，只能眼巴巴地看著空空蕩蕩的日志，最后一次日志輸出還是十多分鐘之前。后來我對Oracle了解一些了，知道了每一行啟動日志的含義，也就知道了當時系統在清理臨時段，因為數據庫好幾年沒重啟過了，所以打掃工作很耗時。再后來了解了REDO和CHECKPOINT的原理，知道數據庫重啟時一個沒風險的活，就再也不怕去給客戶重啟數據庫了。
運維最大的恐懼來自于未知，你不理解數據庫的原理，沒有相關的運維經驗，那么使用數據庫還是一件十分恐怖的事情。最大的問題是心里沒底，當系統出問題的時候無法定位問題，解決問題。后來有了MOS，一切好了很多，大多數問題借助MOS都能搞定了。
前幾天我說我在標注國產數據庫的運維知識，怎么標注呢？實際上說簡單也簡單，說復雜也夠復雜。就像我標注的Oracle LOG_BUFFER參數這個案例，僅僅從官方文檔中把Oracle關于LOG_BUFFER的參數描述復制到這個地方是不夠用的，因為這里僅僅包含了“知識”，知識是正確而無法直接用于運維實踐中的東西。我們必須把“經驗”標注進去，才真正有用。“經驗”不一定百分百準確，甚至還可能有一定的局限性，遠沒有“知識”的準確性高，但是經驗能發揮的作用遠超“知識”。在關于LOG_BUFFER的標注中，不僅要列出官方的知識，還要把LOG_BUFFER與log buffer space 等待與每秒REDO生成量指標之間的關系講清楚，AI才能真正理解這個參數的定義與使用方法，才能在AI診斷中準確地對與此參數相關的問題分析清楚。
這是一個系統工程，Oracle數據庫的關鍵參數有200多個，指標有四五百個，等待事件有1500左右，如果能把這些知識都標注準確了，那么對Oracle數據庫的診斷分析能力也就相當高了，超越某些中等水平的專家應該還是可能的。如果只做Oracle還好，如果說還要做20多款國產數據庫，那么這個工作量就是很龐大了。目前我們標注過的實體節點已經超過6萬個，還沒有覆蓋所有的國產數據庫。
當然最后AIOPS的能力也受限于標注知識的團隊的整體能力，如果能力不足，最后做出來的產品能力也就有限了。這也是AI Machine Labs才不到50人，還沒推出任何產品，就能融到20億美金，估值一下子高達120億美金的主要原因。
目前在進行國產庫的知識圖譜的標注的時候，我們遇到了很多瓶頸，那就是國產數據庫的知識不透明，經驗積累極少，從基層運維案例中提煉知識和經驗的成本太高。等國產數據庫廠商搞出自己的MOS不知道要猴年馬月了，甚至我都看不到在未來的5-10年里，某個國產數據庫廠商能打造出一款水平達到20年前Oracle Metalink水準的知識庫。依托生態可能是一條更好的路子，去年這一年我也不斷在和各個數據庫廠商溝通，能不能一起來做這件事。雖然略有成果，但是還是太少。要想打造出與商業產品類似的知識庫，光憑我們這種合作是遠遠不夠的。在中國，缺乏這方面的戰略投資，因此在這個領域無法做得更好。
目前一切只能依托企業用戶自身和第三方合作伙伴，靠著企業用戶花錢來做這些事情了。但是地主家也沒有余糧的時候，想讓企業在這方面花大錢也是不現實的。前陣子一個客戶說他們手頭有某國產數據庫的1萬多個故障告警的案例，從中應該能夠提取出不少運維經驗，不過這個提取誰來做？誰出錢，做出來產權歸屬是什么？往下一深談，問題還是一堆。有朋友感嘆道：只能讓時間來解決了。我的觀點有些不同，沒有錢，光耗時間，是解決不了這個問題的。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
