三週前剛從上家公司換到新的公司,這家公司與上家公司相比對阿里雲的雲計算環境更加的依賴,使用的ECS實例和其餘服務如SLB、RDS、OSS等更多了一個數量級。這篇文章的背景就是爲了解決阿里雲ECS雲主機SSH鏈接的一個問題,從故障發現到故障排除到最後反思的一個詳細過程。文章比較長,圖片衆多,建議有時間仔細閱讀,沒時間就閱讀文末的「總結和反思」部分便可。安全
故障發現:服務器
2017-05-23 下午17:00點前同事報告稱GitLab所在的服務器訪問出現異常。經查發如今公司內沒法正常經過SSH鏈接GitLab服務器。通過測試後發現問題確實存在。網絡
用戶(運維)自查過程:運維
SSH鏈接公網IP地址失敗,ping正常,該服務器上的業務訪問正常,所以判斷不是服務器宕機;tcp
鏈接到在阿里雲剛搭建好的Open×××服務器,SSH鏈接內網IP地址,發現能夠正常鏈接,排除SSH服務問題;ide
通過查詢ECS雲主機上的日誌,/etc/hosts.*,防火牆、SELinux以及ECS安全組,發現公司的IP根本沒有任何鏈接ECS雲主機的日誌記錄和存在配置不當的問題;工具
所以初步判斷問題不在ECS雲主機和公司網絡上,懷疑多是阿里雲安全組出了問題或者公網出口的防火牆對咱們公司的IP地址進行了攔截,認真核對了安全組設置和肯定雲主機以及運行環境沒有問題後,果斷向阿里雲提工單支持。測試
阿里雲工單支持過程:阿里雲
說明:雲計算
(1)爲了方便編輯和閱讀,全部內容均爲原始截圖(在新標籤頁中打開圖片查看原始圖片),IP等敏感信息也不作隱藏處理,請你們不要惡意***,若是發現漏洞歡迎留言和進一步交流;
(2)溝通記錄後面的圖片是溝通記錄中按次序出現的圖片,供你們查閱;
(3)工做任務比較繁重,時間倉促,若有問題請批評指正和多多諒解;
1.用戶報告問題,售後工程師給出初步診斷
2.雙方互相協助排查
3.進一步測試問題
4.及時跟進進度,進一步診斷問題
5.進一步分析和確認緣由
6.找到緣由,解決問題
7.售後工程師給出問題結論,用戶評價,完成工單
問題和解決方案總結:
[ 問題現象 ] ECS雲主機的公網IP地址沒法經過SSH鏈接,提示「Connection reset by peer」,內網地址鏈接正常
[ 解決方案 ] 排查發現是該客戶端IP掃描服務端多個敏感端口致使被雲盾攔截,若是確認沒有問題,您能夠經過以下路徑設置白名單放行:雲盾控制檯--》DDOS防禦--》基礎防禦--》點擊具體的實例--》掃描攔截--》白名單設置--》添加源地址 124.129.14.90
總結和反思:
1.阿里雲的產品的確爲用戶提供了很大的便利,但用戶也須要了解用戶本身使用的阿里雲產品的技術棧和相關知識,用戶須要有本身專業的運維支持
2.提交問題時,用戶要儘量的爲問題診斷人員提供儘量的多的信息,這樣才能幫助問題診斷人員在較短的時間內定位問題
3.在工單過程當中,用戶要儘量的提供圖片,保留問題證據,爲後期糾紛和索賠作好準備
4.利用排除法縮小問題範圍,判斷問題的種類和使用恰當的工具很重要,好比這個例子中:SSH沒法鏈接-->排除其餘問題定位到是網絡問題-->網絡問題的工具:tcpdump+Wireshark抓包排查-->判斷不是xxx的問題-->最終得出結論:雲盾攔截
5.當售後工程師幫助咱們解決問題時,本身也要多動腦思考,並非一勞永逸提交過工單說明狀況就完結了,須要用戶在此過程當中多作配合及時跟進問題,瞭解工單進展
6.問題解決過程當中,用戶和售後要互相諒解,互幫互助,以解決問題爲要
7.事故的責任問題,此事故不能說徹底是用戶的問題,阿里雲的雲盾確實存在缺陷,假設用戶辦公網絡內真的存在惡意掃描,雲盾在檢測到***後應該及時告知用戶,例如給出***威脅通知,在攔截並加入黑名單後,應該及時通知用戶
8.對於這位售後工程師的評價:其實他很不容易。但經過縱覽解決問題的全過程,能夠發現這位工程師在解決問題的能力上和在爲用戶解決問題的態度上仍是有必定問題的。若是在溝經過程中能更主動一些,解決問題的思路上更靈活一些應該能在更短的時間內解決問題
9.本身的反思:
(1)做爲運維人員來講,經驗要不斷積累,技能要不斷提高,這須要保持一個良好的心態和麪對問題時的態度;
(2)在面臨問題時要考慮全面,把全部可能的問題因素都找出來,逐個排除最終解決問題;
(3)解決問題時工具和思路都很重要,平時運維過程當中不只須要經驗知識積累也須要關注針對某一部分問題的完整解決方案的積累,能靈活運用恰當的工具快速解決問題
(4)…… ……
時間有限,先到此爲止,後期再慢慢整理和反思。
--end--