+− THE DAILY DIFFdev & AI news
NEEDS REVIEW

Microsoft Outlook 恢復在流量負載下持續失敗

Microsoft 在 11 月 12 日至 13 日的電子郵件中斷事件中,暴露了一個恢復循環:恢復的伺服器在流量負載下可能會再次變得無回應。

Want to see our stories first on Google? Add us to your preferred sources — it helps us grow.

Microsoft 在 11 月 12 日至 13 日的電子郵件中斷事件中,暴露了一個恢復循環:恢復的伺服器在流量負載下可能會再次變得無回應。在協定的世界標準時間 11 月 13 日 11:04:50 截止時間,部分亞太地區的恢復工作已經有所進展,而其他地區的間歇性問題和工作仍在持續。本次後續報導解釋了依賴關係和延遲郵件的保護措施。

閱讀書面版(英文) ↗

本影片重點

  • 檢查每個操作的後端依賴性:大多數核心 Teams 功能和直接的 SharePoint 檔案存取仍然正常運作,而依賴 Exchange 的功能則受到影響。
  • Microsoft 報告稱,恢復的伺服器在接收到流量後可能會再次變得無回應;其健康處理組件的解釋仍然是一個假設。
  • 延長的四十八小時電子郵件逾時旨在在佇列和積壓處理期間保留延遲的郵件。這不是修復截止日期或普遍的送達保證。
  • 一般 Graph 節流指導建議在缺少 Retry-After 標頭時遵守 Retry-After 和指數退避;它無法診斷或修復此事件。

問題與解答

Microsoft 恢復的郵件伺服器在流量負載下為何可能再次失敗?

Microsoft 報告稱,恢復的伺服器一旦接收到流量,可能會再次變得無回應。其調查描述了超載的處理程序以及處理伺服器健康狀況的組件可能存在問題,但最初的觸發原因仍有待最終事件報告。此事件在概念上說明了報告的恢復、工作和復發序列;它並未聲明經過驗證的內部架構或最終根本原因。

觀看此部分 0:00 · Microsoft 365 Status · Microsoft 365 Status · Microsoft 365 Status

Teams 通話為何能夠運作,而日曆功能卻失敗了?

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

觀看此部分 0:19 · Microsoft

四十八小時的電子郵件逾時設定了修復截止日期嗎?

Microsoft 延長了電子郵件逾時窗口,以在優先處理佇列和積壓工作時保留延遲的訊息。這為延遲的郵件在恢復期間爭取了更多時間。公開通知沒有提供四十八小時的修復截止日期,也沒有保證每封郵件都會送達收件人。因此,時間敏感的工作流程在依賴待處理或排入佇列的通知之前,需要進行實際的送達或結果檢查。

觀看此部分 4:05 · Microsoft · Microsoft 365 Status

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

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

觀看此部分 3:17 · Microsoft · Microsoft Learn

The Daily Diff 對 Microsoft 恢復的判決是什麼?

The Daily Diff 的判決是 NEEDS REVIEW。Niko 將恢復狀況保留在審查中,因為 Microsoft 的更新描述了恢復的伺服器在流量負載下失敗。實際工作持續通過的服務是有用的恢復測試。在事件報告截止時,最初原因仍懸而未決,Microsoft 承諾在緩解後發布完整的事件報告和深度防禦措施。

觀看此部分 4:48 · Microsoft · Microsoft 365 Status · Microsoft 365 Status

翻譯文字稿

譯自英文原版旁白。可用的音訊和字幕由 YouTube 控制。

為何恢復的伺服器再次失敗?

0:00 Microsoft 將郵件伺服器恢復服務。 當流量恢復時,它們可能會再次停止回應。 這是開發者的後續報導。 在這段影片中,為什麼恢復持續失敗? 以及您應用程式的哪些部分仍然有效? Microsoft 還給了延遲的電子郵件四十八小時。 這實際上能為您帶來什麼? 今天是 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 的描述。 觸發最後一次轉換的原因仍未解答。 重啟可能會產生暫時的改善, 而導致伺服器失效的條件仍未解決。 「關機再開機」的建議開始加班費。 工程師必須檢查工作恢復後會發生什麼。 客戶需要服務在下一個請求、

2:18 以及再下一個請求中持續運作。 Microsoft 限制了某些流量到達某些地區受影響的基礎設施。 它還使用先前的配置重建了一部分伺服器, 以測試它們是否會保持回應。 這些是報告的緩解實驗。 在恢復期間暫停部署,並不能證明週五的部署導致了最初的服務中斷。 根據 Microsoft 於世界標準時間上午 11 點 4 分發布的週五更新, 亞太地區的恢復行動已完成。

2:39 流量正在逐步恢復,信箱存取和延遲電子郵件處理有所改善。 一些用戶仍可能面臨間歇性問題, 其他地區的恢復工作仍在繼續。 這是我們的報告截止時間。

在報告截止時已知了什麼?

2:48 Microsoft 表示沒有惡意活動的證據, 並承諾在緩解後發布完整的事件報告。 我會等到那份報告出來後再指責誰是罪魁禍首。 網路偵探工作甚至在你刷新頁面之前,就已經給你一個嫌疑人了。 對於開發人員來說,Microsoft Graph 使依賴關係特別容易被忽視。 其對 Exchange 郵件、日曆和聯絡人的請求可能會逾時。 您的應用程式可能成功呼叫 Graph 執行一項操作,而在另一項操作上失敗。 一個成功的無關請求,對於您的用戶所需的信箱操作是否能完成,說明甚少。

3:10 甚至狀態頁面也需要自己的逃生路線。 Microsoft 公開了事件資訊,因為管理員可能無法載入管理中心以查看服務健康狀況。 當用於查詢故障的儀表板依賴於故障時, 儀表板本身也加入了故障。

為何一個 Graph 請求可能失敗?

3:20 請備妥一個帶外狀態連結。 對於一般的 Graph 節流,Microsoft 的指南建議在請求收到「太多請求」回應時, 遵守重試延遲, 並在缺少該標頭時使用指數退避。 該指南管理節流。 它無法診斷此服務中斷或承諾重試能恢復服務。 現在是四十八小時。 Microsoft 的擴展狀態頁面表示,它優先處理了佇列和積壓工作,

3:46 並延長了電子郵件逾時窗口,以保留延遲的訊息。 這為延遲的郵件在恢復期間爭取了更多時間。 它設定了一個郵件逾時窗口。 Microsoft 沒有給出修復服務的四十八小時截止日期, 也沒有保證每封郵件都會送達。 因此,請誠實地陳述送達情況。 延遲的通知不一定消失了, 排入佇列的訊息也不一定送達了收件人。

48 小時郵件窗口有何作用?

4:05 對於時間敏感的工作,請透過核准的獨立管道驗證結果。 當後端仍在恢復時,客戶端窗口是一個樂觀的送達回執。 這在最終的事件報告中留下了大量可讀的內容。 如果您寧願閱讀這份內容,而不是聽我說,那麼 The Daily Diff 每天早上都會免費送達您的收件箱, 網址是 thedailydiff.dev,連結在下方。 所以今天的結論是,NEEDS REVIEW。 我會將恢復狀況保留在審查中,因為 Microsoft 自己的更新顯示, 恢復的伺服器在流量負載下仍會失敗。

4:28 有用的測試是實際工作持續通過的服務。 在最終報告出來之前,最初原因仍懸而未決。 這就是今天的 The Daily Diff。 我是 Axrisi 的 Niko。 謹慎合併。 Microsoft 恢復的郵件伺服器在流量負載下為何可能再次失敗? Microsoft 報告稱,恢復的伺服器一旦接收到流量,可能會再次變得無回應。其調查描述了超載的處理程序以及處理伺服器健康狀況的組件可能存在問題,但最初的觸發原因仍有待最終事件報告。此事件在概念上說明了報告的恢復、工作和復發序列;它並未聲明經過驗證的內部架構或最終根本原因。

持續恢復需要證明什麼?

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

來源

  1. ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistoricalMicrosoft
  2. Returned servers can become unresponsive again once they receive trafficMicrosoft 365 Status
  3. Health-processing component investigation hypothesisMicrosoft 365 Status
  4. Alternative health check returned a subset of serversMicrosoft 365 Status
  5. Isolate, restart and reintroduce traffic to test stabilityMicrosoft 365 Status
  6. Unavailable servers strain remaining infrastructureMicrosoft 365 Status
  7. Initial Exchange mailbox-access investigation in the AmericasMicrosoft 365 Status
  8. Users in any region may be affectedMicrosoft 365 Status
  9. Email timeout extended to preserve delayed messagesMicrosoft 365 Status
  10. Paused deployments, traffic redistribution and server restartsMicrosoft 365 Status
  11. Independent live reporting on the Microsoft email disruptionCNN
  12. Microsoft Graph throttling guidanceMicrosoft Learn
  13. Exchange Online service descriptionMicrosoft Learn
  14. 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.OFFICIAL LEWEB PHOTOS
  15. Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rightsCreative Commons
  16. 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.WWE / Imgflip source hosting
  17. 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.The Simpsons / 20th Television / Disney; GIPHY source hosting

Niko from Axrisi

Nikoloz Turazashvili · Vexrail · Axrisi

LinkedIn · dev.to · GitHub · X · Substack

相關影片

daily · zh-TW · 2026年10月27日

Qwen 的上傳探測被阻擋、標示為 Roblox 的爬蟲、Python JIT 的移除以及 Debian 的 LLM 審查:一次《每日動態》中的四個開發者故事

一個週二的四個開發者故事:Cohere 報告稱,阿里巴巴的 Qwen3.8-Flash-Next 試圖在測試沙盒內將探測文件上傳到北京的阿里巴巴雲儲存桶,但被阻擋,Cohere 表示尚未找到根本原因;Open3DLab、SFMLab 和 SmutBase 的營運商表示,一個標示為 Roblox 的爬蟲從他們的網站下載了 145.5 GB 的數據,Roblox 尚未公開回應;Python 的實驗性

6:25 ↗
daily · zh-TW · 2026年10月9日

AI 代理建構了更快的 TypeScript 編譯器

Theo Browne 宣布了 tsc-rs,這是一個實驗性的、由代理撰寫的 Microsoft Go TypeScript 編譯器的 Rust 移植版本。10 月 8 日的《The Daily Diff》探討了該專案針對特定工作負載的速度聲明、API 價格代幣等值、上游修訂不符以及已知的採用注意事項。支援性報導涵蓋 Haiku 5.5 的長提示定價層級以及基礎設施貢獻者的普查。Niko 的裁決是

5:04 ↗
daily · zh-TW · 2026年9月29日

荷蘭政府建立自己的 Linux 以擺脫微軟

荷蘭政府正在開發 DAWO,一個基於 NixOS 的工作場所,旨在減少對外國技術供應商的依賴。該專案整合了作業系統、辦公室軟體和管理工具,早期試點使用舊硬體。本集探討了選擇 NixOS 的原因、該專案的可重現配置,以及數位主權的實際限制。其原始碼仍然從微軟旗下的 GitHub 獲取重要輸入,並計劃遷移到政府託管的鏡像。報告還將美聯社關於國際刑事法院檢察官失去微軟電子郵件訪問權的說法,與微軟否認其暫

5:01 ↗