本文是對2018年8月9日公司郵件系統郵件流故障的故障發現、故障處理和故障修復過程的一個記錄和總結反思。幫助自己總結經驗，吸取教訓，同時也作為一個反面供其他運維或管理員學習的教材。

故障排除

昨天下午 18:50 左右完成了團隊的培訓分享會后，我收到了同事的反饋，他們有幾個無法接收外部電子郵件（上圖）。好的，但無法接收外部郵件。

因為公司的郵件系統是公司自己搭建的，所以需要自己運營和管理。測試了幾個外部郵箱后，發現確實無法接收外部郵件。這些外部郵箱包括網易、阿里企業郵箱和微軟郵箱。

因為郵件服務是企業的核心服務之一，有同事反映遇到了問題，這個故障應該是重要的緊急故障，必須盡快排除才能恢復服務。

注1：問題嚴重或有應急處理流程的，應向上級報告，并按流程下達通知。

注2：以下是個人觀點和經驗總結，如有錯誤請指出。

故障排除

面對故障，最重要的是盡快通過排除法進行故障排除，以最快的速度恢復服務。所以首先要做的是排除故障。由于已經是下班時間，事故雖然嚴重，但尚未造成重大影響。

特別是由于缺乏親身的運維經驗，憑經驗不能一下子發現問題服務器運維，只能根據以往的經驗和結合一一檢查。

經初步測試，內部郵件收發正常，內部到外部郵件正常，但接收異常。于是開始下面的調查。

在進行故障排除之前，有必要了解最近的更改，例如軟件配置以及導致更改的操作，尤其是當兩個或多個管理員共同管理時。因此，服務器由一個人管理，最近沒有進行任何更改。是突然出現的問題，所以我直接開始排查：

檢查域名解析，查看mx記錄是否有問題。使用該命令在多個外部服務器上測試 MX 記錄，以及相關的 A 記錄和 CNAME 記錄。

注1：服務器可以使用-q=直接查詢，Linux命令需要交互查詢，即先執行再setq=mx或=mx，再查詢

注2：查詢mx記錄時，只需要查詢郵件服務器fqdn域名的上級域名即可。例如，您只需要查詢 mx 記錄。

經排查，排除域名解析問題。

檢查外部和內部通信問題，檢查防火墻阻塞和防火墻與服務器之間的網絡鏈接問題。使用25命令檢查25端口的開放情況，經測試排除防火墻問題。

注1：25端口是約定的接收外部郵件的端口

注2：如果25端口正常，目標是郵件服務器，應該提示“,:43:58+0800”。

要確認它不是防火墻或網絡設備錯誤，請重新啟動防火墻或網絡設備。通常，沒有軟關機和重啟功能的防火墻需要斷電或切換電源狀態10s以上。檢查后不是網絡設備問題。

以上3個步驟排除后，應該確定問題出在郵件服務器上。啟動郵件服務器本身的故障排除：

由于郵件服務器收發正常，直接登錄郵件服務器，查看其他可能影響郵件服務器的因素。

首先檢查服務器負載，包括CPU、內存、磁盤空間、IO和網絡負載。通常主要影響的是 CPU 和內存，其次是磁盤空間和 IO。查了一下磁盤空間不足（已經不足5%了，但是還有3GB的空閑空間，由于經驗不足，沒有判斷這個問題可能造成的影響，內網郵件正常，所以是沒有優先考慮，最后發現是這個原因造成的）。

接下來，您應該檢查服務器系統日志。首先檢查日志或首先檢查負載只是一個習慣問題。系統日志通常會為管理員提供足夠的信息。事件管理器雖然不是特別好用，但在日志方面還是相當良心的，一般大大小小的事件都有記錄。

除了檢查系統日志外，一般還提供其他診斷工具。比如“隊列查看器”，由于隊列查看器可以用來排查郵件流問題，在隊列查看器中也會有一些郵件無法投遞的提示。

查看系統日志和隊列查看器后，發現問題是由于資源不足。系統有兩個明顯的提示：

1.隊列查看器指出最后一個錯誤是“4524.3.”。查詢后，這通常意味著磁盤空間不足或內存空間不足。

2.事件查看器中的“來源”報告說：

（1）警告：資源壓力已從正常增加到中等。

（2）錯誤：傳輸服務拒絕了郵件提交，因為可用磁盤空間已低于配置的閾值。

故障排除和維修

已確定為由磁盤空間問題觸發的“背壓”保護策略。通過釋放磁盤空間來解決。解決方案解決后，通知上級領導及相關人員。

知識點

關于“背壓”。以下是文檔庫的摘錄——了解背壓。

背壓是存在于集線器傳輸服務器和邊緣傳輸服務器上的傳輸服務的系統資源監控功能。 可以檢測可用硬盤空間和內存等重要資源何時受到壓力，并采取措施嘗試防止服務不可用。

背壓可防止過度使用系統資源并嘗試傳遞現有消息。當系統資源使用恢復到正常水平時，服務器可以逐漸恢復正常運行。

其中，當集線器傳輸服務器或邊緣傳輸服務器處于資源壓力之下時，它會拒絕傳入連接。在 中，傳入連接被接受，但通過這些連接傳入的郵件以較慢的速度被接受或拒絕。當 SMTP 主機嘗試連接到背壓下的集線器傳輸或邊緣傳輸服務器時，連接成功，但當主機發出命令提交郵件時，根據壓力下的資源，可能會延遲確認命令或拒絕訂單。

以下摘錄來自事件查看器：

傳輸服務拒絕了郵件提交，因為可用磁盤空間已低于配置的閾值。

以下資源面臨壓力：隊列數據庫日志記錄路徑("C:\\V14\dataQueue")=95%[][=93%=95%high=97%]

背壓導致以下組件被禁用： 從集線器傳輸服務器提交入站郵件

提交來自的入站郵件

從選擇器目錄提交郵件

從重播目錄提交郵件

從郵箱服務器提交郵件

將郵件投遞到遠程域

從隊列數據庫加載電子郵件（如果可用）

以下資源處于正常狀態：Queue path("C:\\V14\dataQueuemail.que")=95%[][=95%=97%high=99% ]

版本桶=0[正常][正常=80中=120高=200]

私有字節=0%[正常][正常=71%中=73%高=75%]

物理內存負載 = 11% [限制為 94% 以啟動郵件凍結。]

批處理點=0[正常][正常=1000中級=2000高級=4000]

提交隊列=0[正常][正常=1000中=2000高=4000]

注意：其實Linux中也有類似的保護機制，比如oom，磁盤預留5%。遇到此類知識時，應從其他事實中推論，類推。

故障反映與總結

遇到故障或問題時，應保持頭腦冷靜，不要驚慌，不要搞砸自己。很多運維或者管理員遇到問題，首先想到的是如何解決，嘗試了各種解決方法都無濟于事后，為了節省時間想到了回滾，這是不正確的。作為一名合格的運維人員，應該了解事情的來龍去脈和問題的根源。在排查問題時，首先要考慮的是通過日志排查問題。在調查過程中，調查要盡可能全面，不要遺漏任何可能引起問題的細節。

部署必須符合標準，必須標準化。從這次事故來看，這臺服務器包含三個數據庫，其中一個存儲在C盤，其他盤不存在。久而久之，這個數據庫占用了大量磁盤空間，導致磁盤空間不足，從而觸發了“背壓”機制。從標準和規范的實踐來看，這個數據庫應該從 C 盤移動到其他大容量磁盤。并在部署之初計算容量。

注意警察。該服務器配置了監控告警，已經檢測到故障并發出告警。故障是由于處理不及時造成的。

就算要接手，也要改變過去。因為這臺郵件服務器是之前一個運維同事部署的，所以里面的一些問題被擱置了很久沒有解決（也有技術原因）。

保持學習。雖然有時有些事情會偏離自己的方向，但應該深入研究公司的核心 IT 系統（如郵件服務器）。只有理解和理解，才能在遇到問題時更快地解決問題。

每次失敗后總結經驗，吸取教訓。記錄知識和經驗，安頓下來。比如經過這個總結，遇到這個故障時服務器運維，你可能會突然想到磁盤空間不足會觸發背壓，導致無法接收外部郵件。

如果你想在這個行業工作，但你沒有基礎，可以先去培訓，也可以少走彎路。Linux培訓費用不貴，投資非常必要。