今天一位同學給我打**，說是重啟了客戶機房裡的一台伺服器a，重啟之後此台伺服器不能與b伺服器通訊了，要命的是a臺伺服器上有關鍵資料需要與b伺服器進行通訊互動。客戶大發雷霆，同學的老闆也發火一再催促要盡快完工此次專案把錢收回來，做為專案經理的同學陷入到了嚴重的焦慮當中，一方面因為耽誤了客戶的業務感到愧疚，更一方面害怕公司的名譽受損，影響接下來的合作。這位同學已經一天一夜沒有休息了，他們公司的工程師也來了兩位依然沒有查到原因，無奈下向我求助，我能體會到這位同學進退兩難的境地，透過**能感受到他低落的情緒，不親身經歷的人永遠無法體會這種感覺。我決定試一試幫他解決。
問題聽起來並不複雜，就是a伺服器因重啟之後無法連線web伺服器了，於是我收集了a伺服器的網路資訊，如下：
[root@a~]# ifconfig | egrep "hwaddr|inet addr"eth0 link encap:ethernet hwaddr 00:0c:29:ec:9c:70
inet addr:192.168.80.124 bcast:192.168.80.255 mask:255.255.255.0
eth1 link encap:ethernet hwaddr 00:0c:29:ec:9c:84
inet addr:192.168.90.31 bcast:192.168.90.255 mask:255.255.255.0
eth2 link encap:ethernet hwaddr 00:0c:29:ec:9c:7a
inet addr:192.168.100.31 bcast:192.168.100.255 mask:255.255.255.0
inet addr:127.0.0.1 mask:255.0.0.0
[root@a ~]# route | grep default
default 192.168.80.254 0.0.0.0 ug 0 0 0 eth0
[root@b~]# ifconfig | grep "inet addr"在這個環境當中，a伺服器的三個網絡卡都與b伺服器的網絡卡不在同乙個網段，正常情況下，如果a想與b進行通訊必須先將資料報交付給閘道器（192.168.80.254）進行**，於是我在a伺服器ping了一下閘道器，發現a伺服器與閘道器是可以通的，但無法與b通訊，請求一直是超時，難道是閘道器沒有把包給**出去？或者是icmp-request包到達了b伺服器之後被iptables的input鏈給drop掉了，亦或者是icmp-replay包到達了b伺服器之後被iptables的output鏈給drop掉了？造成這個現象的原因有好多，我又不在現場，能排查的地方實在有限，我感覺自己已經走進了死胡同，難道這次幫忙要以失敗告終？我不甘心。inet addr:192.168.10.9 bcast:192.168.10.255 mask:255.255.255.0
在螢幕前面發呆了一會兒，我拿出a4紙，把造成這個現象所有的、我能想到的原因全部列了出來，列出來之後我發現我所列出的原因都是集中在資料報離開a伺服器之後所經過的節點裝置和b伺服器上，卻沒有列出a伺服器本身的原因，這時大腦當中忽然莫名奇妙的「蹦」出來一句話與這事不相干的話：「行有不得，反求諸已」，我好像抓住了什麼！我有種強烈的預感，問題就是出在這裡，a伺服器與閘道器的通訊已經能確認沒問題，但是a伺服器與b伺服器通訊的資料報真的從a伺服器正常發出去了嗎？這個我不確定，怎樣才能驗證一下呢？真是一波三折，正當發愁時，看到工作列上的wireshark軟體，對呀！通過wireshark可以確認a伺服器與b伺服器通訊情況，趕緊試一下。
於是我在a伺服器ping b伺服器時，在a伺服器的三個網絡卡都抓了包，結果發現eth0網絡卡竟然乙個icmp包都沒有發，這不應該，a伺服器與b伺服器通訊時，要通過eth0網絡卡才能將資料報交給閘道器，因為a的eth0與閘道器是處在同乙個子網，但是現在卻乙個包都沒有。我又開啟在eth1網絡卡上抓的包，結果驚訝的發現竟然有查詢b伺服器的arp廣播包！！！如下所示：
這說明什麼問題呢？這說明a上存在乙個符合192.168.10.9的路由表項，使得a通過eth1直接與b通訊，而沒有匹配到預設路由。我趕緊一條條的仔細檢查路由表，果然發現有這麼一條！如下所示：
[root@a ~]# route -n | egrep "dest|192.168.10.0"因為192.168.10.9預設也屬於192.168.10.9/24表項，所以預設就會走這條路由，而不同子網所配置的vlan也不同，所以這些arp請求包根本無法到達b伺服器，ping包就更不用說了，我讓同學將這條路由刪除之後a伺服器就與b伺服器恢復通訊了，同學和我都如釋重負，高興的不得了，同學說是回來一定要請我吃飯，我當然欣然答應了。我得到了同學的感謝，還得到了自己的認可，心中充滿了歡喜，真的像是打贏了一場硬仗，但我知道，我得到的遠不止這些……destination gateway genmask flags metric ref use iface
192.168.10.0 0.0.0.0 255.255.255.0 u 0 0 0 eth1
同學知道了原因之後，確定這次事故錯不在他，便理直氣壯的質問客戶：為什麼a伺服器重啟之後多了這條莫名其妙的路由呢？根據客戶回憶，他們以前的確配置過該條路由，後來刪除了，這個刪除僅是刪除記憶體裡面的路由條目，而配置檔案的路由條目依然存在，這次重啟伺服器，恰好給了伺服器重讀配置檔案的機會，所以這條路由又出來了。
我們從這個案例當中可以學到什麼呢？最直接的啟示就是拿上簡歷，投奔甲方去，這樣就在搞砸系統的時候，理直氣壯要求乙方解決了。假如你依然還想繼續當己方的話，那麼就必須要好好學習wireshark了，因為wireshark實乃網路工程師居家必備的「甩鍋利器」。再有經驗的工程師也有犯迷糊的時候，而whireshar從來不會，它隨時隨地都能告訴你真相，不偏不倚。
線上故障處理
於 2016 年 12 月 09 日 處理流程 故障後處理 前段時間在團隊內整理了乙份線上事故處理的流程，修改後在這裡分享。1.1 系統 業務報警 這個是獲取故障最常用的手段。一般的系統正常運營過程中都會有一定的指標監控。如 在系統層面某種報錯出現的次數，系統常規指標，如可用記憶體，jvm gc，連...
RAC 故障處理
rac的故障定位 比單節點資料庫更複雜 日誌的儲存位置更多 日誌的資訊量更大 故障更複雜 rac的核心程序，cssd,crsd 這兩個程序出現問題，那麼 rac就宕了。rac比單例項資料庫程序要複雜的多。rac日誌存放的位置也多，種類也多，相對於單例項。對於單例項資料庫，所有的關於資料庫的資訊幾乎都...
shell處理故障
以下是shell處理故障的一點積累,將來可能有用，先mark一下 1 匯出userid不為空，且下單日在2014 01 03日 含 以後的訂單 mysql u h p3307 p e use set names utf8 select distinct user id,user name from ...