重大疑難故障分析日誌（已經解決）

故障現象：

三個不同的應用，每個應用都是N台伺服器的叢集。從兩周前出現一個非常奇怪的現象，每天從11：20開始，

到下面的幾個點的20分，如12:20,13:20,14:20,15點20.一直到某個點結束，每個點的20分都是會發生資料庫

串連暴漲,把有資料庫請求的方法進行攔截，很多方法竟然執行20多秒，最後逾時退出（正常的100ms以內）。

不過這樣的情況僅持續很短時，不超過一分鐘就恢複正常。

分析過程：

我是參與這個故障分析，不是主導。

1.首先懷疑資料庫本身是否有定時任務或時間觸發器在做什麼工作影響了外部的請求，但是資料庫方面的排查

一切正常。全國資料庫排名前十的其中六人在我們集團，他們對資料庫是否異常的認識我們還是相信的。

2.應用本身，如果有定時任務，那麼就應該是針對不同應用的定時任務。這樣的定時任務一定是受管的，但排

查所有配置，未發現問題。

3.既然不同應用同時發生問題，那麼最可能的原因應該來自外部一個全域的環境。網路，共同的資料庫或

memcached等。資料庫未發現問題，那麼網路方面分析，流量分布一切正常。路由，防火牆策略等均發現異常。

我們是和國內其它電訊廠商平行的主幹網，維護水平應該比電信級的更進階一些（因為他們是公家的），所以網

絡方面原因排查結果也是可信的。

4.分析業務日誌，是否有瞬間的攻擊，或者特殊的請求比如構造一個32K的字串讓你的資料庫查詢。日誌我們

細分到每分種，請求數也基本和沒有發生問題的時間斷平均值一致。請求參數也沒有異常。

5.在沒有其它路徑可走的情況下，只能隔離分析（線上環境，不到萬不得已不走這樣的險招）。首先資料庫執行個體

本身我們認為是可靠的。但是它和應用間的串連品質是否可靠？於是在昨天晚上把資料庫所在的小型機的網卡

進行切換，今天11點開始觀察。（11點之前一切正常）

11：20，每天如約而至的連結暴漲沒有了，方法調用超過500ms的沒有了（原來有大量的超過20s）.

故障現象已經消失，定位於連結到資料庫的網路振蕩。已經接近真相的99％。

今天繼續分析引起振蕩的原因: 1.物理網卡？2.交換器口？3.bond software?

如果是1或2，什麼樣的物理故障竟然導致定時性的振蕩？

最終定位於交換面的上聯口buffer被打死，每秒1G多的流量同步流量。硬體BUG，目前無解，解決方案是每個應用的

資料同步分開做，不走統一的通道。