昨天我談了一個健康管理項目組的案例，現(xiàn)場DBA認(rèn)為已經(jīng)找到了解決這個小問題的關(guān)鍵，而實際上隱藏在這個小問題背后還有更大的問題。當(dāng)時分析這個問題的時候，因為holadata存在一個BUG，無法從企業(yè)版D-SMART的分布式模式下下載數(shù)據(jù)，因此當(dāng)時的分析僅僅依靠了現(xiàn)場DBA發(fā)來的幾份問題診斷報告，而并沒有全面地去分析數(shù)據(jù)。缺乏完整數(shù)據(jù)的情況下，分析問題和發(fā)現(xiàn)問題依靠的更多是經(jīng)驗，我對Oracle LOGON過程以及LOGON AUDIT過程的準(zhǔn)確理解是我能夠在不經(jīng)意間發(fā)現(xiàn)這個隱患的關(guān)鍵。

昨天也有朋友給我留言說，通過監(jiān)控，完全可以發(fā)現(xiàn)IO鏈路抖動的問題。實際上也并不一定是如此的。因為很有可能某個故障發(fā)生的持續(xù)時間只有1-2分鐘，而且故障發(fā)生的頻率也不高，而監(jiān)控往往都是采樣而不是持續(xù)性的，持續(xù)性的采樣只能從內(nèi)核來實現(xiàn)，成本太高，已經(jīng)不屬于監(jiān)控范疇而屬于TRACE了。TRACE的成本是極高的，不大可能在一般系統(tǒng)中開啟。而基于采樣的監(jiān)控，對于低頻發(fā)生問題的發(fā)現(xiàn)是存在一定概率的逃逸的，因此低頻問題的監(jiān)控，我們需要從多個側(cè)面來進行問題發(fā)現(xiàn)。從該問題可能影響以及帶來的多種跡象中，只要能夠抓住一種，觸發(fā)告警，從而促進問題的發(fā)現(xiàn)，就達(dá)到監(jiān)控的目的了，并不一定要追求直接命中問題。

從holadata發(fā)來的數(shù)據(jù)看，在11號7點左右故障發(fā)生期間，基線告警是存在幾次db file parallel write延時過高的告警的，不過并不嚴(yán)重。因為安全管控問題，最近系統(tǒng)調(diào)整了權(quán)限，關(guān)閉了所有OS采集的權(quán)限，因此系統(tǒng)沒有采集操作系統(tǒng)IO延時情況，也沒有采集操作系統(tǒng)的日志，所以僅憑這個告警還是無法定位問題的。而且基線告警的數(shù)量龐大，作為告警來使用，那么運維人員每天就不用干別的，所有時間都來看告警，十來個DBA也干不過來。因此此類的無效告警實際上對運維是沒有太大價值的。我們一般都只關(guān)注故障模型的告警。

從9號到現(xiàn)在的數(shù)據(jù)來看，系統(tǒng)產(chǎn)生的嚴(yán)重告警數(shù)量并不多，和鏈路故障有關(guān)的告警主要有“運維對象連接失敗”、“LOG FILE SYNC延時過高”、“非正常狀態(tài)進程數(shù)量過多”這幾個告警了。

從診斷結(jié)果上看，確實是進程會出現(xiàn)D狀態(tài)的進程，這是IO子系統(tǒng)存在問題的另外一個側(cè)面的表現(xiàn)。

今天談了半天，都是談的系統(tǒng)如何監(jiān)控，如何從不同的角度去發(fā)現(xiàn)系統(tǒng)可能存在的問題。似乎有點跑題了，今天的題目是“從IPHONE手機誤報車禍說起”，實際上這個話題也來自于近期IT界比較熱門的一個話題。蘋果手機里有十分強大的傳感器，借助蘋果ICLOUD強大的算法能力，可以為手機使用者提供很強大的功能。車禍自動報警就是其中一個十分實用的功能。當(dāng)車禍發(fā)生時，如果能夠及時報警，重度車禍人員被救活的幾率要高出很多，如果車禍第一時間沒有人告警，等到有目擊者告警的時候往往就錯過了最佳的拯救時間。因此很多人把車禍告警這個功能，一旦出現(xiàn)車禍，能夠第一時間獲得救治。

不過問題來了，蘋果的算法再強大，也只是基于數(shù)據(jù)的一個模型計算而已，其中就有一定的出錯概率。如果某個城市很多人都開啟了這個功能，對于如此巨大的基數(shù)，再小的概率都會產(chǎn)生巨大的告警量，城市公共資源因此就不堪重負(fù)了。昨天我看到的一個案例就是因為一個哥們玩過山車忘記關(guān)閉車禍告警，玩得很嗨的時候發(fā)現(xiàn)下面開來了警察救護車。

IPHONE車禍告警的這個案例實際上和我們的IT監(jiān)控告警十分類似，我們在IT運維監(jiān)控時也面臨類似的困境，某些情況是否要把告警推送到告警臺上，如果狼來了的事情太多了，警察還會不會把IPHONE車禍告警當(dāng)回事，真的狼來了怎么辦？

更精準(zhǔn)的告警是運維監(jiān)控一直在追求的目標(biāo)，告警收斂也是精準(zhǔn)告警算法的關(guān)鍵技術(shù)。在這方面要想做好也不易。IPHONE的車禍告警功能開發(fā)團隊有可能考慮到了越野穿越的場景，而根本沒想到還有一個坐過山車這種與車禍?zhǔn)诸愃频膱鼍埃圆艑?dǎo)致了各種烏龍告警的頻發(fā)，隨著此類事件的不斷出現(xiàn)，車禍告警的準(zhǔn)確性會越來越高，最終越來越實用。

幾年前我拜訪一個客戶的時候，他十分頭疼的告訴我，他的數(shù)據(jù)中心有30多萬臺服務(wù)器，各種數(shù)據(jù)庫3000多實例。哪怕告警系統(tǒng)已經(jīng)通過算法收斂了90%的告警信息，他的手機上每天接收的基線告警和日志告警就有數(shù)萬條。以前發(fā)短信的時候，他的手機經(jīng)常半天就沒電了?，F(xiàn)在他們把告警信息發(fā)到微信群，而且把告警信息分類，把一些不重要的發(fā)到一個告警群，重要的發(fā)到一個嚴(yán)重告警群。不過每天收到的嚴(yán)重告警還是有數(shù)千條之多，還是看不過來。

正好這個時候收到了一條“不重要”的告警消息，他拿給我看，我一眼就看出來，這條并不是不重要的短信，而是很重要的。他收到的是一條ORA-1555的告警，如果是Oracle DBA，可能對這個經(jīng)典錯誤告警已經(jīng)很熟悉了，大多數(shù)DBA遇到此類告警，也會放在一邊的。不過我當(dāng)時就看出問題了。ORA-1555有五六種常見的場景，其中一種是因為某個索引的itl因為Oracle的一個BUG出現(xiàn)了錯誤，指向了錯誤的UNDO RECORD，此類錯誤實際上是一個索引數(shù)據(jù)邏輯損壞，一旦訪問到這條記錄，SQL馬上就會報ORA-1555，如果索引不重建，此類SQL會永遠(yuǎn)報錯。丟棄這樣的告警，實際上是一個錯誤的做法。

很多朋友都覺得精準(zhǔn)告警需要通過算法來實現(xiàn)，因為依靠傳統(tǒng)的經(jīng)驗與知識，做了幾十年也沒做好。不過我覺得運維知識還是實現(xiàn)精準(zhǔn)告警的關(guān)鍵，而依靠現(xiàn)在越來越強大的算法與算力，運維經(jīng)驗應(yīng)該能夠發(fā)揮出更大的效能。而目前對于經(jīng)驗的發(fā)現(xiàn)來說，某個企業(yè)或者群體還不足夠，只有社區(qū)的力量才能做得更好。對于蘋果這樣的TOC產(chǎn)品，廣大的用戶群體可以為蘋果積累巨大的案例庫，而對于運維監(jiān)控系統(tǒng)這種TOB的業(yè)務(wù)，想要達(dá)到TOC的效果，搞好社區(qū)是關(guān)鍵。這也是我們堅持做DBAIOPS社區(qū)的主要原因。