一大早，公司砸開了鍋，紛紛說公司所有的伺服器都出現登入出現延遲。我連忙遠端了一下，用ssh -v debug了一下，發現遠端連接配接并未出現什麼問題。但登入不到幾秒鐘，滑鼠就不動了。這還了得，根本無法幹活嘛！我陸續查了防火牆的負載，日志，cpu,session等都未發現什麼異常。公司的遠端工具也設定了反空閑。
我繼續用ping,tracert工具發現到聯通的節點就無法通路。很顯然tracert沒到公司的防火牆位址就不行了。我初步判斷是機房的網絡有問題。與機房協調溝通，并無半點收獲。人家說他們網絡正常，其他客戶都沒出現問題。從機房的流量監控看也沒發現流量異常。
我不得已親自去一趟機房，登上伺服器一看，未出現任何問題，通路外網也正常。ssh配置檔案沒有問題。用機房的内網遠端通路我們的伺服器，依舊是時斷時續。用了tcpdump抓包工具，發現一台伺服器的發出的udp包過多，我開啟了udp flood防護功能，但并未出現改觀。
在機房用機房的内網遠端我們的伺服器也是時段時續。在機房tracert我們的伺服器和在公司一樣，機房這才答應和機房的網絡提供商聯通聯系。事後機房也未承認是機房的網絡問題。隔幾天遠端竟然奇迹般的恢複正常。
到底是哪裡出現了問題呢，真是一個詭異的故障經曆。雖然沒有搞清楚問題出在哪裡，記錄下來，以作參考，也希望高人們能提出意見，不甚感激。
事後兩個月，這篇文章有了下文。
詭異的情況再次出現，從cacti監控圖可以看見一台伺服器的網卡流量較高，登上這台伺服器，用iftop -n檢視網卡流量發現有很多udp包，用lsof -i udp,發現發包的罪魁禍首是webservice,這是開發人員部署的一種分布式服務，把服務的部署人員協商，停止了這個服務，幾分鐘以後，ssh卡頓現象瞬間消失。上次已經發現了udp包過多的問題，隻是做了一些政策，并未停止服務。至于這個服務為什麼會有那麼大的破壞力，我也不得而知。事情總算過去了，至此ssh詭異事件也劃上了句點。