# Microsoft Outlook修復在流量下持續失敗

Published: 2026-11-13

Microsoft在11月12日至13日發生的電子郵件中斷，暴露了一個修復循環問題：恢復後的伺服器在流量下可能再次變得無回應。在香港時間11月13日11:04:50 UTC的批准截止時間，亞太地區部分地區的恢復工作取得了進展，但間歇性問題和在其他地區的工作仍然存在。本次跟進解釋了依賴關係和延遲郵件的保護措施。

Canonical: https://thedailydiff.dev/zh-HK/video/2026-11-13-microsoft-recovery-loop/

## 本影片涵蓋的內容

- 檢查每個操作的後端依賴關係：大多數核心Teams功能和直接的SharePoint檔案訪問仍然正常，而依賴於Exchange的功能則受損。
- Microsoft報告稱，恢復的伺服器在接收到流量後可能再次變得無回應；其關於健康處理組件的解釋仍處於假設階段。
- 延長的48小時電子郵件超時旨在在隊列和積壓處理期間保留延遲郵件。這並非修復截止日期或普遍的交付保證。
- 一般Graph節流指南建議在缺少Retry-After標頭時遵循它並採用指數退避；它無法診斷或修復此事件。

## 問題與解答

### 為什麼Microsoft恢復的郵件伺服器在流量下可能再次失敗？

Microsoft報告稱，恢復後的伺服器在接收到流量後可能再次變得無回應。其調查描述了超負荷的進程和處理伺服器健康狀況的組件可能存在的問題，但最初的觸發原因仍在等待最終事件報告。該事件概念性地說明了報告的恢復、工作和復發序列；它不聲稱已證明內部架構或最終根本原因。

### 為什麼Teams通話可以運作，而日曆功能卻失敗了？

根據Microsoft擴展的服務健康通知，大多數核心Teams通話、會議和聊天功能保持正常。日曆和排程場景依賴於Exchange Online，在服務中斷期間可能失敗。直接的SharePoint檔案訪問也保持正常。有用的應用程式級區別在於操作背後的依賴關係，而不是將產品標誌下的每個功能都視為共享相同的失敗狀態。

### 48小時的電子郵件超時是否設定了修復期限？

Microsoft延長了電子郵件超時窗口，以在優先處理隊列和積壓的同時，保留延遲的訊息。這為延遲的郵件在恢復期間爭取了更多時間。公開通知未提供48小時的修復期限，也未保證每封訊息都會到達其收件人。因此，在時間敏感的工作流程依賴於待處理或排隊的通知之前，需要進行實際的交付或結果檢查。

### Exchange中斷如何影響Microsoft Graph應用程式？

Microsoft表示，對Exchange Online郵件、日曆和聯絡人的請求可能會超時。應用程式在具有不同底層依賴關係的操作中可能會遇到不同的結果。該事件建議檢查操作的實際服務依賴關係。Microsoft單獨的常規節流文件討論了在缺少Retry-After標頭時遵循Retry-After和指數退避；這些策略無法確定此事件的原因或承諾恢復服務。

### The Daily Diff對Microsoft的恢復判斷為何？

The Daily Diff的結論是NEEDS REVIEW。Niko將恢復情況保持在審查中，因為Microsoft的更新描述了恢復的伺服器在流量下出現故障。有實際工作通過的持續服務是有效的恢復測試。在事件報導截止時，最初的原因仍未確定，Microsoft承諾在緩解措施後發布完整的事件報告和縱深防禦措施。

## 章節

- 0:00 為什麼恢復的伺服器再次失敗？
- 0:19 哪些功能依賴於Exchange？
- 1:03 容量不足如何導致服務過載？
- 1:34 Microsoft最初嘗試了什麼？
- 2:48 報告截止時已知了什麼？
- 3:17 為什麼一個Graph請求可能失敗？
- 4:05 48小時郵件窗口有何作用？
- 4:48 持續恢復需要證明什麼？

## 翻譯的文字記錄

從英文原文旁白翻譯。可用的音頻和字幕由 YouTube 控制。

### 為什麼恢復的伺服器再次失敗？

0:00 Microsoft將郵件伺服器恢復服務。 當流量返回時，它們可能再次停止回應。 以下是開發人員的跟進。 在這段影片中，為什麼恢復持續失敗？ 而你的應用程式哪些部分仍然正常運作？ Microsoft還給予延遲的電子郵件48小時的處理時間。 這實際上能為你帶來什麼？ 今天是11月13日星期五，這是The Daily Diff。

0:18 Exchange Online是Microsoft託管的電子郵件服務，而其他Microsoft 365

### 哪些功能依賴於Exchange？

0:22 功能都依賴於它。 這是Microsoft狀態頁面提供的一個有用區別。 Teams通話和群組聊天大部分運作正常。 日曆功能和郵箱數據請求可能會失敗。 檢查你的應用程式實際使用的依賴項。 這意味著即使日曆拒絕協作，會議仍然可以舉行。 直接訪問SharePoint中的檔案也保持正常運作， 而某些分享功能則受到影響。

0:42 窗口上的標誌很少能告訴你下一次點擊所需的後端。中斷始於星期四，Microsoft最初調查 美洲地區的郵箱訪問問題。 隨後證實任何地區的用戶都可能受到影響。 CNN報導了銀行、政府和法院面臨的問題。 一封遺失的電子郵件只會帶來不便，直到某人的實際工作依賴於它的 到達。Microsoft的早期解釋是可用伺服器數量減少。 這些機器本應處理的工作，卻讓剩餘的基礎設施不堪重負。

### 容量不足如何導致服務過載？

1:06 當服務容量消失時，即使是普通需求也可能導致服務過載。 隊列會變得更長，即使沒有人突然對發送電子郵件產生熱情。 隨後，公司調查了自動健康檢查機制。 這些檢查有助於判斷伺服器是否可以承擔工作。 Microsoft表示，處理伺服器健康的組件可能涉及其中。 這是一個仍在進行中的調查的假設。 我們沒有最終的事件報告來解釋為什麼這些伺服器最初會變得不可用。 更新讀起來就像值班人員對早餐的興趣越來越低。

1:29 暫停部署。轉移流量。 重啟伺服器。Microsoft驗證了一種替代健康檢查方法，使部分伺服器恢復，並準備自動系統來檢測和重啟無回應的機器。

### Microsoft最初嘗試了什麼？

1:37 每次更新都描述了恢復容量的嘗試。 然後是解釋恢復循環的那句話。 Microsoft表示，恢復服務的伺服器在接收到流量後可能再次變得無回應。 一台機器可能會恢復，接收實際工作，然後停止回應。 這一觀察結果比任何人在回覆中自信的理論都更有力。 想像一下同一個伺服器經歷這些狀態。 不可用。恢復服務。 正在處理流量。再次無回應。

1:59 這解釋了Microsoft的說法。 是什麼觸發了最後一次轉換，仍然沒有答案。 重啟可以產生暫時性的改進， 而導致伺服器失效的狀況仍未解決。 「關掉再打開」的建議開始收取加班費。 工程師必須檢查工作恢復後會發生什麼。 客戶需要服務在下一個請求和再下一個請求中保持運作。 Microsoft限制了某些流量到達受影響的基礎設施在某些位置。它還使用先前的配置重建了一部分伺服器，以測試它們是否會保持回應。

2:18 這些是報告的緩解實驗。 在恢復期間暫停部署，並不能證明星期五的部署導致了最初的服務中斷。 根據Microsoft在UTC時間11點04分的星期五更新， 亞太地區部分地區的恢復行動已完成。 流量逐漸恢復，郵箱訪問和延遲電子郵件處理有所改善。 部分用戶仍可能面臨間歇性問題， 其他地方的恢復仍在繼續。 這是我們的報導截止時間。

2:39 Microsoft表示沒有惡意活動的證據， 並承諾在緩解措施後發布完整的事件報告。 我會等到那份報告出來再指責誰是罪魁禍首。 網路偵探工作可以在你還沒刷新頁面之前，就給你一個罪犯。

### 報告截止時已知了什麼？

2:48 對於開發人員來說，Microsoft Graph讓依賴關係特別容易被忽略。 它對Exchange郵件、日曆和聯絡人的請求可能會超時。 您的應用程式可以成功呼叫Graph執行一項操作，卻在另一項操作中失敗。 一個成功的無關請求，對於您的用戶所需的郵箱操作是否會完成，幾乎沒有任何說明。 狀態頁面甚至需要自己的逃生路線。 Microsoft公開發布事件資訊，因為管理員可能無法載入管理中心以查看服務健康狀況。 當查詢問題的儀表板本身也依賴於出問題的部分時， 這個儀表板也加入了事件。

3:10 保持一個帶外狀態鏈接可用。 對於普通的Graph節流，Microsoft的指南建議在請求收到過多請求回應時， 遵守重試延遲， 並在缺少該標頭時使用指數退避。

### 為什麼一個Graph請求可能失敗？

3:20 該指南管理的是節流。 它無法診斷這次中斷，也不能保證重試能恢復服務。 現在是四十八小時。 Microsoft擴展的狀態頁面顯示，它優先處理隊列和積壓處理，並延長了電子郵件超時窗口，以保留延遲的訊息。 這為延遲的郵件在恢復期間爭取了更多時間。 它設定了一個郵件超時窗口。 Microsoft沒有給出修復服務的48小時截止日期， 也沒有保證每封郵件都會送達。

3:46 因此，請保持交付聲明的誠實性。 延遲的通知不一定已經消失， 而排隊中的訊息也不一定已經到達收件人。 對於時間敏感的工作，請透過經批准的獨立渠道驗證結果。 當後端仍在恢復時，客戶端窗口只是一個樂觀的遞送回執。 這為最終的事件報告留下了大量可讀的內容。 如果你寧願閱讀這份內容而不是聽我說，The Daily Diff每天早上都會免費發送到你的收件箱，網址是dailydiff.dev，連結在下方。 所以今天的結論是，NEEDS REVIEW。

### 48小時郵件窗口有何作用？

4:05 我會將恢復狀態保持在審查中，因為Microsoft自己的更新顯示，恢復的伺服器在流量下出現故障。 有實際工作通過的持續服務才是有效的測試。 在最終報告出來之前，最初的原因仍然不明。 這就是今天的差異。 我是來自Axrisi的Niko。 負責任地合併。 為什麼Microsoft恢復的郵件伺服器在流量下可能再次失敗？ Microsoft報告稱，恢復後的伺服器在接收到流量後可能再次變得無回應。其調查描述了超負荷的進程和處理伺服器健康狀況的組件可能存在的問題，但最初的觸發原因仍在等待最終事件報告。該事件概念性地說明了報告的恢復、工作和復發序列；它不聲稱已證明內部架構或最終根本原因。

4:28 為什麼Teams通話可以運作，而日曆功能卻失敗了？ 根據Microsoft擴展的服務健康通知，大多數核心Teams通話、會議和聊天功能保持正常。日曆和排程場景依賴於Exchange Online，在服務中斷期間可能失敗。直接的SharePoint檔案訪問也保持正常。有用的應用程式級區別在於操作背後的依賴關係，而不是將產品標誌下的每個功能都視為共享相同的失敗狀態。 48小時的電子郵件超時是否設定了修復期限？ Microsoft延長了電子郵件超時窗口，以在優先處理隊列和積壓的同時，保留延遲的訊息。這為延遲的郵件在恢復期間爭取了更多時間。公開通知未提供48小時的修復期限，也未保證每封訊息都會到達其收件人。因此，在時間敏感的工作流程依賴於待處理或排隊的通知之前，需要進行實際的交付或結果檢查。 Exchange中斷如何影響Microsoft Graph應用程式？ Microsoft表示，對Exchange Online郵件、日曆和聯絡人的請求可能會超時。應用程式在具有不同底層依賴關係的操作中可能會遇到不同的結果。該事件建議檢查操作的實際服務依賴關係。Microsoft單獨的常規節流文件討論了在缺少Retry-After標頭時遵循Retry-After和指數退避；這些策略無法確定此事件的原因或承諾恢復服務。 The Daily Diff對Microsoft的恢復判斷為何？

### 持續恢復需要證明什麼？

4:49 The Daily Diff的結論是NEEDS REVIEW。Niko將恢復情況保持在審查中，因為Microsoft的更新描述了恢復的伺服器在流量下出現故障。有實際工作通過的持續服務是有效的恢復測試。在事件報導截止時，最初的原因仍未確定，Microsoft承諾在緩解措施後發布完整的事件報告和縱深防禦措施。 Microsoft's Outlook recovery kept failing under traffic Microsoft's November 12–13 email disruption exposed a recovery loop: returned servers could become unresponsive again under traffic. At the approved November 13 11:04:50 UTC cutoff, recovery had progressed across portions of Asia Pacific while intermittent issues and work elsewhere remained. This follow-up explains dependencies and delayed-mail safeguards. Microsoft's November 12–13 email disruption exposed a recovery loop: returned servers could become unresponsive again under traffic. At the approved November 13 11:04:50 UTC cutoff, recovery had progressed across portions of Asia Pacific while intermittent issues and work elsewhere remained. This follow-up explains dependencies and delayed-mail safeguards. Check the backend dependency of each operation: most core Teams functionality and direct SharePoint file access remained functional, while Exchange-dependent features were impaired. Microsoft reported that returned servers could become unresponsive again when traffic reached them; its health-processing-component explanation remained a hypothesis. The extended forty-eight-hour email timeout was intended to preserve delayed mail during queue and backlog processing. It was no repair deadline or universal delivery guarantee.

## 來源

- [ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistorical](https://status.cloud.microsoft/) — Microsoft
- [Returned servers can become unresponsive again once they receive traffic](https://x.com/MSFT365Status/status/2121031935010951521) — Microsoft 365 Status
- [Health-processing component investigation hypothesis](https://x.com/MSFT365Status/status/2120974801388904932) — Microsoft 365 Status
- [Alternative health check returned a subset of servers](https://x.com/MSFT365Status/status/2120985048337830246) — Microsoft 365 Status
- [Isolate, restart and reintroduce traffic to test stability](https://x.com/MSFT365Status/status/2121002505911857577) — Microsoft 365 Status
- [Unavailable servers strain remaining infrastructure](https://x.com/MSFT365Status/status/2120962673911181437) — Microsoft 365 Status
- [Initial Exchange mailbox-access investigation in the Americas](https://x.com/MSFT365Status/status/2120938282204688468) — Microsoft 365 Status
- [Users in any region may be affected](https://x.com/MSFT365Status/status/2120941584220827979) — Microsoft 365 Status
- [Email timeout extended to preserve delayed messages](https://x.com/MSFT365Status/status/2121172248241348867) — Microsoft 365 Status
- [Paused deployments, traffic redistribution and server restarts](https://x.com/MSFT365Status/status/2120957934607700161) — Microsoft 365 Status
- [Independent live reporting on the Microsoft email disruption](https://www.cnn.com/2026/11/12/business/live-news/microsoft-global-outage-intl-hnk) — CNN
- [Microsoft Graph throttling guidance](https://learn.microsoft.com/en-us/graph/throttling) — Microsoft Learn
- [Exchange Online service description](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-service-description) — Microsoft Learn
- [Satya Nadella portrait by OFFICIAL LEWEB PHOTOS (2013), CC BY 2.0. Whole portrait-based artwork adapted by cropping, background removal, resizing and text/composition; vendor identity only, no endorsement or current reaction.](https://commons.wikimedia.org/wiki/File:Satya_Nadella.jpg) — OFFICIAL LEWEB PHOTOS
- [Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rights](https://creativecommons.org/licenses/by/2.0/) — Creative Commons
- [WWE still. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.](https://imgflip.com/memetemplate/234202281/AJ-Styles--Undertaker) — WWE / Imgflip source hosting
- [The Simpsons/Bob GIF. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.](https://giphy.com/gifs/the-simpsons-sideshow-bob-RSOUOj8H9A3Xq) — The Simpsons / 20th Television / Disney; GIPHY source hosting