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

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

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

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

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

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

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

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

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

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

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

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