無論是傳統(tǒng)運(yùn)維還是智能運(yùn)維，最核心的都是經(jīng)驗(yàn)

　　三十年期我們用Oracle數(shù)據(jù)庫(kù)的時(shí)候是盲目用，那時(shí)候用得就很不好，甚至把重啟數(shù)據(jù)庫(kù)都當(dāng)成一件恐怖的事情來做。如果不是高手，都不敢輕易重啟數(shù)據(jù)庫(kù)，生怕數(shù)據(jù)庫(kù)重啟后起不來了。當(dāng)時(shí)江湖中這種傳聞也是很多的，我有一次重啟了二十多分鐘還沒起來，只能眼巴巴地看著空空蕩蕩的日志，最后一次日志輸出還是十多分鐘之前。后來我對(duì)Oracle了解一些了，知道了每一行啟動(dòng)日志的含義，也就知道了當(dāng)時(shí)系統(tǒng)在清理臨時(shí)段，因?yàn)閿?shù)據(jù)庫(kù)好幾年沒重啟過了，所以打掃工作很耗時(shí)。再后來了解了REDO和CHECKPOINT的原理，知道數(shù)據(jù)庫(kù)重啟時(shí)一個(gè)沒風(fēng)險(xiǎn)的活，就再也不怕去給客戶重啟數(shù)據(jù)庫(kù)了。

　　運(yùn)維最大的恐懼來自于未知，你不理解數(shù)據(jù)庫(kù)的原理，沒有相關(guān)的運(yùn)維經(jīng)驗(yàn)，那么使用數(shù)據(jù)庫(kù)還是一件十分恐怖的事情。最大的問題是心里沒底，當(dāng)系統(tǒng)出問題的時(shí)候無法定位問題，解決問題。后來有了MOS，一切好了很多，大多數(shù)問題借助MOS都能搞定了。

　　前幾天我說我在標(biāo)注國(guó)產(chǎn)數(shù)據(jù)庫(kù)的運(yùn)維知識(shí)，怎么標(biāo)注呢？實(shí)際上說簡(jiǎn)單也簡(jiǎn)單，說復(fù)雜也夠復(fù)雜。就像我標(biāo)注的Oracle LOG_BUFFER參數(shù)這個(gè)案例，僅僅從官方文檔中把Oracle關(guān)于LOG_BUFFER的參數(shù)描述復(fù)制到這個(gè)地方是不夠用的，因?yàn)檫@里僅僅包含了“知識(shí)”，知識(shí)是正確而無法直接用于運(yùn)維實(shí)踐中的東西。我們必須把“經(jīng)驗(yàn)”標(biāo)注進(jìn)去，才真正有用。“經(jīng)驗(yàn)”不一定百分百準(zhǔn)確，甚至還可能有一定的局限性，遠(yuǎn)沒有“知識(shí)”的準(zhǔn)確性高，但是經(jīng)驗(yàn)?zāi)馨l(fā)揮的作用遠(yuǎn)超“知識(shí)”。在關(guān)于LOG_BUFFER的標(biāo)注中，不僅要列出官方的知識(shí)，還要把LOG_BUFFER與log buffer space 等待與每秒REDO生成量指標(biāo)之間的關(guān)系講清楚，AI才能真正理解這個(gè)參數(shù)的定義與使用方法，才能在AI診斷中準(zhǔn)確地對(duì)與此參數(shù)相關(guān)的問題分析清楚。

　　這是一個(gè)系統(tǒng)工程，Oracle數(shù)據(jù)庫(kù)的關(guān)鍵參數(shù)有200多個(gè)，指標(biāo)有四五百個(gè)，等待事件有1500左右，如果能把這些知識(shí)都標(biāo)注準(zhǔn)確了，那么對(duì)Oracle數(shù)據(jù)庫(kù)的診斷分析能力也就相當(dāng)高了，超越某些中等水平的專家應(yīng)該還是可能的。如果只做Oracle還好，如果說還要做20多款國(guó)產(chǎn)數(shù)據(jù)庫(kù)，那么這個(gè)工作量就是很龐大了。目前我們標(biāo)注過的實(shí)體節(jié)點(diǎn)已經(jīng)超過6萬個(gè)，還沒有覆蓋所有的國(guó)產(chǎn)數(shù)據(jù)庫(kù)。

　　當(dāng)然最后AIOPS的能力也受限于標(biāo)注知識(shí)的團(tuán)隊(duì)的整體能力，如果能力不足，最后做出來的產(chǎn)品能力也就有限了。這也是AI Machine Labs才不到50人，還沒推出任何產(chǎn)品，就能融到20億美金，估值一下子高達(dá)120億美金的主要原因。

　　目前在進(jìn)行國(guó)產(chǎn)庫(kù)的知識(shí)圖譜的標(biāo)注的時(shí)候，我們遇到了很多瓶頸，那就是國(guó)產(chǎn)數(shù)據(jù)庫(kù)的知識(shí)不透明，經(jīng)驗(yàn)積累極少，從基層運(yùn)維案例中提煉知識(shí)和經(jīng)驗(yàn)的成本太高。等國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商搞出自己的MOS不知道要猴年馬月了，甚至我都看不到在未來的5-10年里，某個(gè)國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商能打造出一款水平達(dá)到20年前Oracle Metalink水準(zhǔn)的知識(shí)庫(kù)。依托生態(tài)可能是一條更好的路子，去年這一年我也不斷在和各個(gè)數(shù)據(jù)庫(kù)廠商溝通，能不能一起來做這件事。雖然略有成果，但是還是太少。要想打造出與商業(yè)產(chǎn)品類似的知識(shí)庫(kù)，光憑我們這種合作是遠(yuǎn)遠(yuǎn)不夠的。在中國(guó)，缺乏這方面的戰(zhàn)略投資，因此在這個(gè)領(lǐng)域無法做得更好。

　　目前一切只能依托企業(yè)用戶自身和第三方合作伙伴，靠著企業(yè)用戶花錢來做這些事情了。但是地主家也沒有余糧的時(shí)候，想讓企業(yè)在這方面花大錢也是不現(xiàn)實(shí)的。前陣子一個(gè)客戶說他們手頭有某國(guó)產(chǎn)數(shù)據(jù)庫(kù)的1萬多個(gè)故障告警的案例，從中應(yīng)該能夠提取出不少運(yùn)維經(jīng)驗(yàn)，不過這個(gè)提取誰來做？誰出錢，做出來產(chǎn)權(quán)歸屬是什么？往下一深談，問題還是一堆。有朋友感嘆道：只能讓時(shí)間來解決了。我的觀點(diǎn)有些不同，沒有錢，光耗時(shí)間，是解決不了這個(gè)問題的。