從問題的處理方式感悟學習方法

有時候當你碰到一些問題一籌莫展的時候，如果能夠看到某個帖子的問題和你碰到的剛好一致，那種欣喜的感覺真是難以形容。
但是有些問題儘管發生的錯誤一致，處理的方式卻不同，舉一個例子。
客戶反饋某個應用報出了連線錯誤。
對於這個問題，我們可以調侃一下，從幾個不同的層面來分析一下。
   step1:問題一般都會反饋到開發這一層面
   step2:開發經過分析，發現報錯是資料連線問題，簡單修改配置就能夠解決。如果沒有發現更多的資訊，就會向中介軟體部分求助。
   step3:問題到了中介軟體這一層，透過調節連線池等等問題就解決了，如果沒有解決就會反饋到資料庫層面
   step4:問題就直接到了資料庫層面，dba檢視資料庫中的session情況，發現是由於Linux核心引數設定不當導致的，
   step5:問題就這樣到了unix team這一層,最後發現這些核心引數需要重啟資料庫
   step6:問題就這樣反饋到了管理層，領導綜合評估決定這個問題的影響範圍不足以重啟伺服器，對業務造成重大影響，決定臨時停掉相關的應用或者禁用
   step7:問題就這樣到了開發層面。。。。
所以同樣一個問題總是會有各種不同的可能性，當被一個看似很簡單的問題搞的精疲力盡的時候，最後發現可能解決的方式會很簡單，甚至很讓人無奈。
當你碰到了同樣的問題的時候，從各種渠道檢視問題的相關資訊的時候，確實需要一定的耐心和自己的判斷來和自己碰到的問題來聯絡，是不是相關，問題就是這樣反反覆覆。
我們把問題再細化一下，就聚焦在第4步 "問題就直接到了資料庫層面，dba檢視資料庫中的session情況，發現是由於Linux核心引數設定不當導致的，"
dba收到郵件分析問題的時候，就可能有以下幾種方式。
   可能會求助同事或者小組領導來幫助分析。
   檢視資料庫日誌
    檢視資料庫負載
   同時可能也會忙不迭的去各大網站，論壇，部落格關聯搜尋這個錯誤。
   可能透過qq去求救技術圈的朋友。
   可能透過電話直接求救。
   去metalink上去查查相關的技術文章
所以一個簡單的問題就能引申出這麼多的章節和流程來，如果流程出現了問題，問題的解決效率就會大打折扣。
自己花了不少的功夫從一個簡單的連線問題來說明了這麼多，就是想說明問題的處理流程和方式是如何重要。
這些東西都很難從論壇，部落格中得到最直接的幫助資訊，每個人碰到的問題可能都是冰山一角，問題發生在自己身上的時候，那種無形的壓力只有自己知道，如果能夠從流程上大家都能夠有條不紊的開展工作。可能就不會把有些問題拖很久。
我的感悟就是
形成自己的一套知識體系，
很多問題都是特定的場景中發生的，如果在事後來看待問題處理的每一步，就會發現或多或少都走了不少的彎路。如果有自己的一套知識體系，問題處理就會得心應手。
比如你自己可以根據工作的實際情況來編寫一些方便工作的指令碼，這些沒有人來要求你強迫你，但是對你自己有益。只要能夠實際解決問題才是真的好。
比如你可以對一些問題的處理進行郵件整理，保留一些關鍵部分的郵件，在問題再次發生的時候，這封郵件就能讓大家都免去很多的無用功。
拋棄一些細緻末節，這樣可能不會讓你偏離方向
很多人總是感覺學得不夠深，時間也花了不少，也喜歡研究一些看似高大上的東西。給我們上課的老師曾經說過一句話，自己感觸很深，他說學習oracle就是一個過程，如果你花了大把大把的時間去鑽研某一個版本中的某一個bug,或者特定環境中的某一個問題，這對自己的個人成長其實沒有太大的好處，如果你能夠花同樣的時間來分析一個比較通用的問題，是基於資料庫的理論體系之中的，那麼你的所得要更多。這個可以舉個例子來說明。
在10gR2的早期版本中搭建RAC的時候，在建立好clusterware之後需要在各個節點中執行一套指令碼，但是在10g這個版本中總是會報一些奇怪的錯誤，我花了大把大把的時間，認真分析了指令碼的執行情況，最後才得知是有一個bug，在後續已經做了修復。等到我自己實際安裝11g RAC的時候，發現11g中的RAC架構已經和10g有了很大的不同。這個時候回味起老師的那句話覺得確實有道理。
最後花了些時間來分析一下資料庫的體系結構，分析sql調優中的細緻末節，自己也寫了一些指令碼，在10g，11g中都是通用的，我相信在12c版本中也差不離。
所以學習一種技術或者學問對我們每個人都是很有限的，說這麼多大概意思就是拋棄一些細緻末節，這樣可能不會讓你偏離方向。
和別人分享
在技術圈中的人都是單純的，我也時不時會接到朋友的電話求助，qq求助，部落格求助等等，幫別人解決問題是一種很好的學習方式，這比自己漫無目的的看書學習效果要好。