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

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

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

從9號到現在的數據來看，系統產生的嚴重告警數量并不多，和鏈路故障有關的告警主要有“運維對象連接失敗”、“LOG FILE SYNC延時過高”、“非正常狀態進程數量過多”這幾個告警了。

從診斷結果上看，確實是進程會出現D狀態的進程，這是IO子系統存在問題的另外一個側面的表現。

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

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

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

更精準的告警是運維監控一直在追求的目標，告警收斂也是精準告警算法的關鍵技術。在這方面要想做好也不易。IPHONE的車禍告警功能開發團隊有可能考慮到了越野穿越的場景，而根本沒想到還有一個坐過山車這種與車禍十分類似的場景，所以才導致了各種烏龍告警的頻發，隨著此類事件的不斷出現，車禍告警的準確性會越來越高，最終越來越實用。

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

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

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