關於OOM故障覆盤

故障背景

在業務高峰時期，出現io告警和記憶體告警，應用程式掛掉，從而導致業務中斷。

業務中斷如何定義？對於現在的應用來說，都是高可用的，那麼意味著掛了乙個其實沒什麼關係，就像人員的主備，好像暫時還沒出現人員的雙活情況，雙活可能導致的問題就是心跳不同步，資訊不到位，從而導致腦裂。

業務中斷的定義：請求的成功數量/總的請求的數量，從而定義乙個服務水平。或許服務水平也可以這樣來定義，一定不要滿足客戶百分百的請求，因為很多都是無理的請求，當然，這樣導致的後果就是。。。死的很慘。。。追求完美，不可能的。。

故障處理過程

1 描述故障，發布通告

在故障發生的那一刻，驚慌失措是正常的，但是這個時候，依舊要描述目前的影響範圍，並且描述清楚目前出現的各種現象，可能這個現象是對的，可能這個現象是錯誤的。

在故障發生的那一刻，技術人員的本能是什麼？檢視日誌，追蹤服務報錯，檢視報警看看**有問題，一頭扎入各種問題的細節之處，等到發現無法解決的時候，時間已經過去了一半。

在關鍵時刻，抵制本能。。。人的生活也是這樣，在出現煩心事的時候，第一時間就開始抱怨，忍住，不要浪。。。

我們要做的是，發布故障，聯絡相關團隊加入，在每個團隊加入的時候，告訴他們故障的現象，可能存在什麼樣的問題，他們負責哪一塊的問題。。。明確每個人需要協助的方面。

如果不停的有團隊加入，加入的時候資訊不同步，那麼新加入的人肯定一頭霧水，wtf，我來幹啥？我能做啥？需要我幫你幹啥。。。弄啥嘞

2 排除故障的方法

故障可能出現在每乙個方面，如果我們不曾測試過。。。如果測試過，那麼很多故障能提前避免。

關聯性的故障是最難排查的，因為出現的問題是千絲萬縷的。

排除故障的方法一般就幾種：

a 統計法

應用程式平穩執行了幾個月，突然之間掛掉，檢視監控，將時間週期放長，看看這一段時間是否有業務峰值。

從不同的角度來檢視監控，檢視伺服器的cpu，記憶體，io，網路流量，有的時候只有單一的因素，有的時候則有各種相關的同時發生，例如出現oom的時候，同時出現了io和記憶體的告警，從而可以從這兩個方向進行排查。

b 對比法

對於應用程式來說，一般都有兩個後端，後端都是負載均衡的，所以如果是乙個掛了的話，那麼就可以使用對比法，對比兩個伺服器的使用的資源消耗，從而看看哪個方面的資料不正常。

c 查日誌

從應用程式角度檢視應用的日誌，看看是否出現相關的報錯，看看是否出現記憶體劇增，看看是否出現oom的日誌。

從作業系統層面，檢視系統日誌message，檢視核心日誌dmesg，檢視top看看效能，查查history看看是否有相關的審計。

從應用程式的鏈路檢視相關日誌，這個服務正常，下游的服務呢，服務的追蹤鏈條，就像有乙個人錯了，從而導致這一條線全錯了。

d 查原理

如果是記憶體oom了，那麼哪些程序使用了超級多的記憶體？為什麼使用了那麼多的記憶體？如果記憶體消耗都是正常，那麼是否應該考慮擴容，本身的資源不足導致的？

io出現告警，為什麼會出現io告警？是因為應用的業務高峰，導致瘋狂的讀寫檔案導致？還是因為在讀取遠端的檔案，而導致io在進行排隊請求？

e 查操作

在出現的問題的那一刻，所有的操作都值得查證，是因為一些平時看起來沒問題的操作導致的？因量變而導致的質變，例如平時開啟乙個檔案沒啥關係，開啟乙個10g的檔案實施；還是程式裡面開啟了乙個檔案，平時檔案很小的時候沒出現問題，當開啟乙個10g的檔案的時候，oom了？

此時此刻，誰在幹什麼，程式在幹什麼。。。我是誰，我在**，我在幹什麼。

f 查爭搶

無論在做什麼，總是會出現爭搶，畢竟底層的資源是有限的，一台物理機上面執行了10個虛擬機器，乙個物理機上面執行了100個容器，乙個人喝了好幾杯奶茶。

乙個池子，乙個人搗蛋，那麼所有在這個池子裡面的都會受到影響。。。想一想一台物理機上執行10個mysql的例項，乙個mysql的sql不規範，全域性都受到影響

3 改進措施

a 運維不規範，行人兩行淚。。。內部同步運維規範，用處不是很大，因為故障報告沒有存檔，沒有人闡述整體的背景經過，新來乙個，依舊會踩坑。。。每個人都很忙，誰有那麼多時間。。。新手模擬故障，處理故障，運維規範。

b 故障描述清楚，聯絡合適的人處理合適的問題，無論是開發，運維，管理，故障公升級，是一種共同責任。。。一條線上的螞蟻

c 當不知道問題出在哪兒的時候，全部上來查，先證明自己負責的沒問題。。。同步排查，有資訊進行同步，減少故障的處理時長。

4 記憶體相關