基於報警處理的補充

晚上在琢磨怎麼把報警的處理實現自動化的功能，想來想去，發現其實很多內容都是相通，在紙上寫寫畫畫，簡單理了理自己的思緒。
人嘛，有時候不逼著自己，只會更加懶惰，而一旦邁開了步子，可能就停不下來了，問題也有輕重緩急，我們來理一理。


我的一個簡單總結，問題分為三類，當前問題，潛在問題，歷史問題。
當前問題是實時抓取的狀態資訊，在這個基礎上需要去做一些及時的響應和處理，這個過程也就會涉及到精細化運維的部分
潛在問題需要提前發現，提前預警，這個涉及到半自動化運維，自動化運維
歷史問題，遺留問題，解決起來難度較大，需要資料分析，通過資料的視覺化，或者只能分析來達到目標。
而當前絕大多數的系統來說，問題的處理都是基於報警資訊，也就是基於問題處理問題，所以基於報警資訊的處理，大部分解決的是當前碰到的具體問題。


對於當前的具體問題，分為了幾個層面，
資源使用方面，有下面的一些類別。

這些也是在報警資訊中基本都覆蓋到的一些問題。都從各個層面反應出資料庫，系統，應用的諸多問題。
而基於等待事件，也就是非常流行的OWI，這種方式本身很有說服性，但是經驗論，方法論涉及的成分較多，單純去分析等待事件可能收效不大。
而在此需要額外注意的就是基於DB time的方式，分為兩種，一種是實時的DB time，一種是基於快照的方式，兩種各有優劣，基於實時的DB time計算會基於上一次的快照資料得出一個遞增的動態值，而基於快照的方式得到的是一個靜態值，而且從得到的資料來看，基於快照是後知後覺。報警系統中的很多問題基於DB time可能會引刃而解。但是這種方式有點兒值得推敲的地方，一個就是實時的DB time，可能有一些突發的抖動，可能業務上的需求等，如果溝通不夠充分，可能這類問題基本就是發現問題，分析問題，確認問題，忽略問題這樣的套路。還有一類問題是反反覆覆出現，可能本身影響不算大，比如設定DB time的閾值為400%，結果2分鐘內DB time到了450%，而後迅速跌倒了200%，這種方式如果反反覆覆就會出現大量的報警和報警恢復資訊，這類問題其實還是比較糾結的。
而基於快照的DB time則是一種後知後覺的方式，對於整體的系統負載和問題的基本定位還是大有裨益，但是解決很多突發性的問題可能資訊量不夠。
最後一類是基於併發和鎖，這種問題一旦出現，可能需要立即響應。這種影響的範圍也是全域性性的。
這些資訊如果在Oracle中和優化工具結合起來，如果使用得當，那就是一塊瑰寶，能夠很容易實現精細化運維，半自動化，自動化運維的內容。這些內容現在還在盤算，已經有了一些思路了。相信最近也會逐步理順，付諸實踐。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-2123359/，如需轉載，請註明出處，否則將追究法律責任。