Microsoft 365 自 8 月 31 日開始的故障，到了 9 月 1 日仍未完全落幕。郵件流轉率先恢復，但 Exchange Online、SharePoint、OneDrive 與 Teams 的搜尋功能長時間不穩定，Microsoft 365 Copilot 的部分回應也跟著停擺。微軟指出的原因，是多項服務共用的一處認證設定發生問題。
一處認證設定牽動多項服務
事情從郵件開始。協調世界時 8 月 31 日 11 時 55 分前後，微軟察覺與 Exchange Online 相關的使用者回報增加，隨即展開調查。約 40 分鐘後，微軟表示已在受影響的請求中找出共同的失敗模式，與認證及通訊協定連線有關。
不過在評估修復方案的期間，影響範圍越過了 Exchange Online。微軟將當天 15 時 8 分列為這次大範圍事件的正式起始時間，並把根本原因歸結為「多項 Microsoft 365 服務共用的核心認證設定出現問題」。起初 Exchange Online 的故障編號為 EX1464935，之後併入範圍更廣的 MO1465074，涵蓋 SharePoint Online、OneDrive for Business、Teams、Microsoft Purview 以及 Microsoft Defender XDR。
從失效功能的清單，可以看出波及範圍之廣。Exchange Online 的連線與搜尋失效；SharePoint Online 與 OneDrive for Business 的檔案存取、同步、內容載入與搜尋受阻；Teams 的搜尋、行事曆與線上狀態顯示異常；Microsoft 365 Copilot 之中，需要讀取 Microsoft 365 資料的提示詞無法執行。在使用者眼中彼此獨立的應用程式，底層卻仰賴同一套認證機制。
郵件先恢復，搜尋拖到最後
修復作業分階段推進。當天 16 時 36 分左右，微軟表示正在重新檢視近期的變更，尋找安全還原認證元件的方式，其中包含回復某項更新的可能性。約一小時後，微軟稱緩解措施的測試出現正面結果；到 18 時 40 分前後，開始在部分目標基礎架構上重新套用認證元件，確認成效後逐步擴大範圍，並分批重新啟動受影響的區段。
各項服務的恢復速度並不一致。Exchange Online 的郵件連線在週一稍晚已大致恢復，但微軟提醒部分組織仍需時間清空積壓的郵件佇列。確認郵件流轉的恢復穩定之後，微軟把重心轉向搜尋功能。
搜尋的修復跨到了隔天。在 9 月 1 日 2 時 39 分的更新中，微軟僅表示在部分受影響環境裡，與搜尋相關的服務健康度遙測出現漸進式改善，並未提出完全恢復的預估時間。此後微軟通報郵件流轉與搜尋皆已恢復。從最初的回報算起，這次事件耗費了將近一整天。
Copilot 讓「停擺的代價」變得更大
其中值得注意的一點，是 Microsoft 365 Copilot 出現在受影響清單上。生成式 AI 助理看起來只要模型還在運作就能使用，但面向企業內部的助理，必須能讀取郵件、檔案、會議與聊天紀錄才談得上有用。資料層或認證層一旦中斷，模型再健全也無從回答。
企業交給 AI 代理處理的工作越多，這層相依關係就越沉重。過去「郵件掛了」「檔案打不開」的故障，往後會變成「代替人做事的機制整個停下來」。在規劃備援時，與其先煩惱模型的可用性，不如先確認認證與通往資料的路徑是否已經成為單一故障點。
值得先做的準備
使用者端能做的事有限，卻不是完全沒有。在認證類故障中，已經登入的工作階段往往還能維持，需要重新認證的裝置則最先失去存取權。故障期間貿然登出或變更密碼，可能導致在服務恢復前無法重新進入。
另一點是聯絡管道的分散。當 Teams 與 Exchange Online 同時中斷，公司內部的聯絡路徑會一併消失。把故障時的第一聯絡管道放在另一套系統上，至少能保住通報狀況與下達指示的能力。微軟管理中心的服務健康度資訊本身也可能依賴同一租戶的認證，因此搭配外部狀態頁面查看會更快掌握情況。
總結
8 月 31 日開始的 Microsoft 365 故障，源自多項服務共用的認證設定出問題，影響從 Exchange Online 擴散到 SharePoint、OneDrive、Teams 以及 Microsoft 365 Copilot。郵件流轉當天大致恢復，搜尋的修復則拖到 9 月 1 日。這起事件再次提醒我們，單一元件所支撐的範圍有多廣，而 AI 助理如今正建立在它之上。
註：縮圖為 AI 生成的示意圖。
