週六中午12點突然接到同事訊息，公司APP內的訂餐功能無法訪問，訊息無法傳送附件。

此時的我正在地鐵上，公司規模較小，週末並沒有人專職值班。

開啟手機，通過遠端控制軟體連線可用環境，檢查服務和埠一切正常。

服務正常的情況下，功能不正常，會不會是某個常見的問題（一直沒找到根本原因），其常用的處理方式是重啟服務。

於是把對應的服務重啟了一遍：

重啟應用服務，重啟訊息服務，重啟移動端服務。

重新嘗試訪問，仍然無效。

聯絡供應商，供應商的值班技術排查了一遍，沒找到問題，認為是移動端的問題，又聯絡移動端的同事排查一遍，仍然沒找到問題。

記錄一下排查思路：

首先是常規的netstat檢視埠的服務情況，然後是檢視移動端的請求日誌，發現請求日誌中大量的請求應用端80埠服務失敗。

開始檢查應用端80埠提供的服務，一切正常。

netstat -an|grep :80發現80埠主動拒絕了來自移動端的請求。

太詭異了，所有的服務都正常，但是就是無法訪問。

先暫停了解決該問題，準備去檢視檔案無法傳輸的問題，就在此時，基本定位了問題。

檔案傳輸失敗，我首先去檢查的是伺服器的磁碟空間

登入伺服器，df -h，發現此命令卡住了，ctrl+c中斷，df -l，發現磁碟的使用率只有一半。

此時的我，並不知道 df -h，df -l有什麼區別。

但是觀察df -l的時候，我發現了一個細節，本來應該掛載此伺服器上的一塊5T的磁碟不見了。

一番百度，發現了df -l只是列出本地磁碟，df -h是列出所有磁碟，包括網路磁碟。

df -l ###只檢視本地掛載的磁碟檔案

df -hT###檢視本地及遠端掛載的磁碟檔案

mount | column -t###檢視mount掛載檔案詳情

於是執行：

strace df -h

發現的確是在nfs磁碟位置卡住了。

同時，又找到了以下資料：

在設定了防火牆的環境中使用NFS，需要在防火牆上開啟如下埠：

1. portmap 埠 111 udp/tcp；
2. nfsd 埠 2049 udp/tcp；
3. mountd 埠 "xxx" udp/tcp
系統 RPC服務在 nfs服務啟動時預設會為 mountd動態選取一個隨機埠（32768--65535）來進行通訊，我們可以通過編輯/etc/services 檔案為 mountd指定一個固定埠。

的確我們的應用和檔案伺服器之間有一層防火牆。

我嘗試了ping和telnet對應的埠，所有的埠通訊沒有問題，這就很詭異了。

於是分享給了我另外一位管網路的同事，他告訴我一個重要訊息，防火牆在10點鐘進行過一次升級，而檔案傳輸失敗的問題，恰好發生在這個時間之後。

我們基本把問題定位到了防火牆層面。

經過一番檢查，防火牆策略並沒有變更，所有埠可以正常訪問，應用和檔案伺服器之間是做的any埠的策略。

但是我們相識還是防火牆做了這個升級引起的，於是聯絡防火牆供應商。

溝通第二天早上9點做一個三方溝通。

第二天早上9點之後，供應商檢查之後，做了相應的設定，檔案服務成功恢復，mobile成功登入。

關於本次問題的反思：

0.對於企業內部的所有服務之間的連線方式及介面，應該非常；

1.基礎設施的升級，儘可能一定要告知相關方；

2.基礎設施升級後，一定要做應用訪問是否正常的檢查，本次做了應用檢查，但是沒有做檔案服務的檢查。