本文是對2023年8月9日公司exchange郵件系統郵件流故障的故障發現、故障處理和故障修復的過程記錄和總結反思。幫助自己總結經驗和吸取教訓，同時也作為一次反面教材讓其他運維或管理員吸取教訓。
故障發現
昨天下午18點50左右結束團隊內培訓分享會後，收到同事的反饋，說他們幾個人都無法收到外部郵件（internet上的郵件），故障現象為：exchange伺服器內網收發郵件正常，外網傳送正常，但無法收到外部郵件。
因為公司的郵件系統是公司自建的exchange server 2010，因此需要運維自己去管理。經過多個外部郵箱的測試發現，的確無法收到外部郵件，這些外部郵箱包括網易、阿里企業郵箱和微軟outlook郵箱。
因為郵件服務是企業核心服務之一，加之已經有同事反饋遇到問題，因此此故障應該是重要緊急故障，必須盡快排除以恢復服務。
注1：如果問題比較嚴重或者有緊急事件處理流程規定，應該按照流程匯報上級領導和發出通告。
注2：以下是個人看法和經驗總結，如有錯誤敬請指出。
故障處理
面臨故障最重要的就是盡快通過排除法進行故障排除以實現服務的最快恢復。因此首先要做的故障排除。由於已經是下班時間，事故雖然重大，但還尚未造成重大影響。
因為在windows特別是exchange的運維上個人經驗比較欠缺，不能憑經驗一下子發現問題，因此只能先根據以往經驗，結合google等逐個排查。
經過初步測試，內部郵件收發正常，內部向外部傳送郵件正常，但接收異常。於是開始以下排查。
在排查之前應該先需要搞清楚最近發生的變更，如軟體配置，導致變更的操作，特別是兩個及以上的管理員共同管理時。因此伺服器由一人管理，且最近沒有進行過任何更改，是突然出現的問題，因此直接開始排查：
檢查網域名稱解析，排查mx記錄等是否存在問題。使用nslookup命令在多個外網伺服器上測試mx記錄、以及相關的a記錄和cname記錄。
注1：windows伺服器可以使用nslookup -q=mx ***.com直接查詢，linux命令需要互動式查詢，即先執行nslookup再set q=mx或set type=mx，再查詢
注2：在查詢mx記錄時，只需要查詢郵件伺服器fqdn網域名稱的上級網域名稱即可。如mail.qq.com，則只需要查詢qq.com的mx記錄即可。
經過排查，排除網域名稱解析問題。
檢查外部與內部的通訊問題，檢查防火牆攔截情況和防火牆到伺服器中間的網路鏈路問題。使用telnet mail.***.com 25命令檢查25埠的開啟情況，經過測試排除防火牆問題。
注1：25埠是接收外部郵件的約定埠
注2：如果25埠正常且目標為exchange郵件伺服器，應該提示類似「220 mail.***.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查詢，這通常意味著要麼磁碟空間不足要麼記憶體空間不足。
（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--
記一次伺服器事故
mysql資料庫報錯 can t create write to file tmp sql 6ccc 0.myi 在開始刪除之後，所有服務就已經恢復正常執行了，接下來就是優化那個session了，哎又是埋坑.最後附上inode擴容的方法 但是需要注意，手動擴inode，一般是新建分割槽時設定的，該操...
記一次伺服器專案遷移
今天被分配了伺服器專案遷移的任務,現在還在傳輸,閒著沒事就寫下總結,也算是一種學習 開啟虛擬機器,訪問需要遷移的伺服器 賬號密碼請向領導或運維索要 找到需要遷移的專案,一般在home 公司名 專案名,例如我所在的公司服務放置在home che tomcat epc 10100複製專案 訪問被遷移到的...
記一次伺服器timewait事件
首先說下網路架構 nginx和jetty都在同乙個伺服器，nginx http流量至多個jetty應用，基本情況就是這樣 首先我們來看下，為什麼會有timewait的狀態 客戶端主動關閉連線時，會傳送最後乙個ack後，然後會進入time wait狀態，再停留2個msl時間，進入closed狀態。也就...