反思一次Exchange服務器運維故障
故障發現
昨天下午18點50左右結束團隊內培訓分享會後，收到同事的反饋，說他們幾個人都無法收到外部郵件（Internet上的郵件），故障現象為：Exchange服務器內網收發郵件正常，外網發送正常，但無法收到外部郵件。
因為公司的郵件系統是公司自建的Exchange Server 2010，因此需要運維自己去管理。經過多個外部郵箱的測試發現，的確無法收到外部郵件，這些外部郵箱包括網易、阿裏企業郵箱和微軟Outlook郵箱。
因為郵件服務是企業核心服務之一，加之已經有同事反饋遇到問題，因此此故障應該是重要緊急故障，必須盡快排除以恢復服務。
註1：如果問題比較嚴重或者有緊急事件處理流程規定，應該按照流程匯報上級領導和發出通告。
註2：以下是個人看法和經驗總結，如有錯誤敬請指出。
故障處理
面臨故障最重要的就是盡快通過排除法進行故障排除以實現服務的最快恢復。因此首先要做的故障排除。由於已經是下班時間，事故雖然重大，但還尚未造成重大影響。
因為在Windows特別是Exchange的運維上個人經驗比較欠缺，不能憑經驗一下子發現問題，因此只能先根據以往經驗，結合Google等逐個排查。
經過初步測試，內部郵件收發正常，內部向外部發送郵件正常，但接收異常。於是開始以下排查。
在排查之前應該先需要搞清楚最近發生的變更，如軟件配置，導致變更的操作，特別是兩個及以上的管理員共同管理時。因此服務器由一人管理，且最近沒有進行過任何更改，是突然出現的問題，因此直接開始排查：
檢查域名解析，排查mx記錄等是否存在問題。使用nslookup命令在多個外網服務器上測試MX記錄、以及相關的A記錄和CNAME記錄。
註1：Windows服務器可以使用nslookup -q=mx xxx.com直接查詢，Linux命令需要交互式查詢，即先執行nslookup再set q=mx或set type=mx，再查詢
註2：在查詢mx記錄時，只需要查詢郵件服務器fqdn域名的上級域名即可。如mail.qq.com，則只需要查詢qq.com的mx記錄即可。
經過排查，排除域名解析問題。
檢查外部與內部的通信問題，檢查防火墻攔截情況和防火墻到服務器中間的網絡鏈路問題。使用telnet mail.xxx.com 25命令檢查25端口的打開情況，經過測試排除防火墻問題。
註1：25端口是接收外部郵件的約定端口
註2：如果25端口正常且目標為Exchange郵件服務器，應該提示類似“220 mail.xxx.com Microsoft ESMTP MAIL Service ready at Fri, 10 Aug 2018 10:43:58 +0800”字樣。
為了確認不是防火墻或網絡設備bug問題，重啟防火墻或網絡設備。通常無軟關閉和重啟功能的防火墻需要斷電或切換電源狀態10s以上。經過檢查不是網絡設備問題。
以上3個步驟排除後，應該確定問題是出在郵件服務器身上。開始郵件服務器自身的排查：
因為是郵件服務器內部收發正常，因此直接登錄郵件服務器，檢查郵件服務器的其他可能影響因素
首先檢查服務器負載，包括CPU、內存、磁盤空間、IO和網絡等負載情況。通常影響Exchange的主要是CPU和內存，其次磁盤空間和IO。經過檢查磁盤空間不足（已經低於5%，但尚有3GB可用空間，由於經驗不足，沒有判斷出此問題可能造成的影響，加之內網郵件正常，因此沒有優先處理，最後發現是此原因造成）。
其次應該檢查服務器系統日誌。關於先檢查日誌還是先檢查負載情況，只是習慣問題。系統日誌一般會給與管理員足夠的信息。雖然Windows的事件管理器並不是特別好用，但是Exchange在日誌方面還是比較良心，一般大小事件均記錄在內。
除了檢查系統日誌之外，Exchange一般提供了其他診斷工具。比如“隊列查看器”，因為隊列查看器可用於解決郵件流問題，因此隊列查看器裏面也會有一些關於郵件無法傳輸的問題的提示。
經過查看系統日誌和隊列查看器後，發現問題是由於資源不足引起。系統有兩處明顯的提示：
1.隊列查看器提示上一個錯誤為“452 4.3.1 Insufficient system resources”。經過Google查詢，這通常意味著要麽磁盤空間不足要麽內存空間不足。
2.事件查看器中來源自“MSExchangeTransport”報告稱：
（1）警告：資源壓力已從 普通 增至 中。
（2）錯誤：Microsoft Exchange 傳輸服務拒絕郵件提交，因為可用磁盤空間已降至配置的閾值之下。
故障確認和修復
已經確認為磁盤空間問題導致的觸發Exchange的“反壓”保護策略。通過釋放磁盤空間解決。解決後通告給上級領導和相關人員。
知識點
關於“反壓”。以下摘錄Microsoft文檔庫--了解反壓。
反壓是存在於 Microsoft Exchange Server 2010 集線器傳輸服務器和邊緣傳輸服務器上的 Microsoft Exchange 傳輸服務的一種系統資源監視功能。Exchange 傳輸可以檢測重要資源（例如可用硬盤空間和內存）何時具有壓力，並采取操作以嘗試阻止服務不可用性。
反壓可以防止過多地使用系統資源，並且 Exchange 會嘗試傳遞現有郵件。當系統資源使用率恢復到正常級別後，Exchange 服務器就可以逐漸恢復正常運行。
在 Exchange Server 2007 中，當集線器傳輸服務器或邊緣傳輸服務器具有資源壓力時，它會拒絕傳入連接。在 Exchange 2010 中，會接受傳入連接，但是會以更慢的速度接受或拒絕通過這些連接傳入的郵件。SMTP 主機嘗試連接到處於反壓下的集線器傳輸服務器或邊緣傳輸服務器時，連接會成功，但是該主機何時發出 MAIL FROM 命令來提交郵件，則取決於具有壓力的資源，Exchange 可能會延遲確認 MAIL FROM 命令或拒絕該命令。
以下摘錄自事件查看器：
Microsoft Exchange 傳輸服務拒絕郵件提交，因為可用磁盤空間已降至配置的閾值之下。
以下資源處於壓力之下: 隊列數據庫日誌記錄路徑(“C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\”) = 95% [中] [正常=93% 中=95% 高=97%]
反壓力導致禁用了以下組件: 從集線器傳輸服務器提交入站郵件
從 Internet 提交入站郵件
從分揀目錄提交郵件
從重播目錄提交郵件
從郵箱服務器提交郵件
向遠程域傳遞郵件
正在從隊列數據庫加載電子郵件(如果可用)
以下資源處於正常狀態: 隊列數據庫路徑(“C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\mail.que”) = 95% [普通] [正常=95% 中=97% 高=99%]
版本存儲桶 = 0 [普通] [正常=80 中=120 高=200]
專用字節 = 0% [普通] [正常=71% 中=73% 高=75%]
物理內存負載 = 11% [開始郵件凍結的限制為 94%。]
批處理點 = 0 [普通] [正常=1000 中級=2000 高級=4000]
提交隊列 = 0 [普通] [一般=1000 中=2000 高=4000]
註：其實Linux中也有類似的保護機制，如oom，磁盤保留5%，遇到此類知識應該舉一反三，觸類旁通。
故障反思和總結
遇到故障或問題應該保持頭腦冷靜，切莫慌亂，不能自身亂了陣腳。很多運維或者管理員在遇到問題時首先想到是如何解決，而嘗試各種辦法解決無果後為了節約時間就想到回滾，這是不正確的。作為一個合格的運維應該弄清事情的來龍去脈和問題的根本原因。在排查問題時首先想到通過日誌去排查問題。在排查時應當盡可能全面的排查，不要漏掉任何一個可能導致問題的細節。
部署必須遵從標準，必須規範。從這次事故來看，此Exchange服務器中含有三個數據庫，其中一個數據庫存放在C盤沒有在其他盤。隨著時間的增長，這個數據庫占用了大量的磁盤空間，導致磁盤空間不足，從而觸發了“反壓”機制。從標準和規範的做法來看，應該將此數據庫從C盤移動到其他容量大的磁盤。並且在部署最開始時計算好容量。
重視報警。此服務器是配置了Zabbix監控報警的，而且Zabbix已經監測到故障並發送報警，由於沒有及時的處理才導致本次故障的發生。
就算是接盤也要痛改前非。因為此郵件服務器是之前運維同事部署的，因此裏面有些問題一直擱置而遲遲沒有解決（也有技術上的原因），從長遠角度上看，即使需要付出一定的代價也需亡羊補牢。
保持學習。雖然有些時候，某些東西偏離了自己的發展方向，但像郵件服務器這樣的公司的核心IT系統應該去深入的學習。只有了解和懂得才能遇到問題時更快的解決問題。
每次故障後總結經驗和吸取教訓。將知識和經驗記錄下來，沈澱下來。比如此次總結後，在遇到此故障可能一下子就想到了磁盤空間不足會導致Exchange觸發反壓，從而導致無法收到外部郵件。
--end--
反思一次Exchange服務器運維故障