運維知識是怎麼構建起來的

DBA都比較羨慕那些老鳥，他們看看日誌檔案，查幾個指標，看兩份AWR報告就能大致推斷出資料庫的問題到底出在什麼地方。心嚮往之的同時，也在想我什麼時候也能達到這樣的水平，我需要怎麼學習才能達到這樣的水平。實際上這世上並無捷徑，每個老鳥都是從菜鳥開始成長起來的 。每一次故障處置，每一次去現場的機會，每一次在網上和別人討論一個案例，都是向老鳥前進一步的機會。如果你半夜接到老闆的電話，讓你去現場處置一個緊急故障，你覺得不公平，為啥叫我去，不讓其他人去，那麼你很可能就失去了一次鍛鍊自己的機會。年輕人吃點苦不怕，怕的就是到了30多歲才發現自己這些年太荒廢了。大多數成功的老鳥都是比較勤奮的，在這年裡，我還沒有遇到過平時很懶，但是水平極高的高手。

勤奮只是一個必要條件，並不代表充分條件，僅僅勤奮是不夠的，善於總結更為重要。有可能你已經半夜加了不少班了，但是你不去總結，僅僅是機械的重複老鳥教給你的那幾招技巧，那麼你很難有大的長進。運維知識的積累往往和總結密不可分，如果你只是不斷的幹苦活累活，並沒有去做必要的總結，也沒有人指點你如何去總結。那麼可能你幹了一輩子還是在一個較低的水平上徘徊。

你看到上面的等待事件會意識到什麼?你需要怎麼去進一步分析問題。要想分析這些問題，你需要在自己的腦子裡構建出Oracle等待事件的知識圖譜，大概每個等待事件的含義是什麼，可能受什麼影響，可能會影響到下游的哪些方面，產生什麼樣的後果。這個例子中，我們可以得到以下的結論：

佔比最高的是direct path read temp/direct path write temp,這兩個等待事件應該是關聯的;

CPU TIME大致是SQL執行的開銷，這個系統中CPU使用率很高，不過CPU TIME很小，大機率是SQL都比較小，沒有複雜的消耗很大SQL;

log file sync和REDO的併發量有關，本系統中的事務併發量不大，REDO量也不大，延時有點高，可能配置上存在一些問題，不過不是主要問題;

latch：cache buffer chains等待與DB CACHE爭用或者熱塊爭用有關。佔比不高，可能和熱塊衝突有關。

有經驗的DBA對於常見的等待事件在腦子裡會有一個類似知識圖譜的東西，比如上游什麼事件會引發下游什麼事件。比如對於排名最靠前的等待事件direct path read temp/direct path write temp,腦子裡的這個區域性的知識圖譜是這樣的：

如果上游的圖譜識別得不完整，只看到了HASH JOIN和SMJ，沒有SORT，那麼分析下去就有可能出現偏差。如果識別錯了，把direct path read和direct path read temp搞混了，那就更麻煩了。

這是一個十分容易出現的認知偏差，有時候一馬虎就忽略了temp這個詞了，有些人對這個知識點了解得一知半解，也會存在錯誤認知，從而在分析問題的起點就發生偏差，最終導致無法準確定位問題。

如果我們使用了正確的知識圖譜，那麼下面就很容易找到驗證問題的方法，看看臨時表空間訪問的效率，看看PGA命中率是不是很低，看看M-PASS排序都是什麼樣的大小。

這時候可能有點經驗的DBA都能看出，這個問題應該是PGA引數設定不合理導致的。對於有經驗的DBA來說，定位這個問題耗時幾分鐘就可以完成了，因為在腦子裡有這個知識圖譜存在。如果腦子裡沒有知識圖譜，那麼定位這個問題就需要去MOS上找相關案例，然後進行比對才能完成。

完成這個思考的圖譜如上，實際上這張圖可能更大，如果問題表現不同，可能會涉及更為廣泛的知識圖譜。大家可以看出，這種圖是畫不完的，因為知識體系十分龐大，甚至超過人腦可記憶思考的範圍。人的腦子裡的知識圖譜也不是這麼構造的，是透過長時間一點一滴積累的。是人的大腦自動把這些支離破碎的知識拼湊在一起的。有些時候這些知識點都在人的腦子裡存在，只是沒能把這些知識點之間的關係構建起來，那麼在思考問題的時候，就無法十分流暢地進行推理了。

因此積累點狀知識的同時，也要注意對知識的理解和梳理，只有打通了任督二脈，才能讓真氣運用自如。知識不能運用自如，就會像段譽使用六脈神劍一樣時有時無，思路順暢的時候行雲流水，而下一回好像遇到了堰塞湖。這種情況一般都是因為你沒有打通一些知識點之間的聯絡，沒有把知識圖譜梳理清晰。

梳理知識的比較好的方法是定時整理，而寫文章是最好的整理方式，特別是寫給別人看的文章，那麼在寫的過程中往往還要去做知識驗證，否則寫錯了，就會貽笑大方了。因此寫文章發部落格、公眾號是更好地梳理知識的方法。公眾的監督會讓你把這件事做得更好，因此我一般會建議年輕人多寫寫文章。在《DBA的思想天空》的序言中我也曾寫過，我真正的梳理Oracle的知識是從想模仿《DELPHI深度歷險》寫一本名字叫《Oracle深度歷險》的書，最後因為那時候對Oracle的理解還比較粗淺，書寫得不成功，但是透過寫書，把Oracle知識的任督二脈打通了。

雖然知識體系是一個龐大的網路，因此我偏好用知識圖譜來描述。不過我們無法直接構建一張大而全的知識圖譜來描述這些知識，只能以點狀來學習和記錄知識。龐大的知識圖譜對於人來說也很難駕馭，思考問題的時候雖然會自動使用這些知識，但是人的算力總是有限的，而計算機系統在圖處理方面的能力要遠高於人腦，因此把這些知識放到圖資料庫裡，透過圖演算法來處理這些知識會有更高的效率。這也是這些年我把手頭的工作全部放下，全身心投入到運維知識圖譜的構建工作中的主要原因。

不過這項工作並不好做，個人的能力總有窮時，必須集大家之智來做這件事才更為靠譜，不過目前我並沒有找到一個更好的辦法來集眾之力，完成這一工作，只能先做起來再說了。