一場 Microsoft 365 全球故障，令大量上班族在 11 月 13 日（周五）早上無法收發電郵。事件由香港時間當日凌晨前後開始，到下午一時仍未完全恢復。微軟已確認這不是網絡攻擊，也不是用戶流量突然暴增；起點是一批伺服器過不了自動健康檢查而退出服務，剩下的機器承受集中過來的流量，最後被壓垮。
截至香港時間 11 月 13 日下午 1 時 01 分（05:01 UTC），微軟 @MSFT365Status 最新貼文仍表示，正以多條工作線同時處理「當前障礙」，把部分服務基礎設施帶回健康狀態。官方公開狀態頁在下午 12 時 58 分（04:57:55 UTC）最後更新，仍列為「服務降級」，並指用戶可能無法連接多項 Microsoft 365 服務。微軟未公布最終根因報告，也未宣布全面恢復的時間。
為何這件事重要：電郵是第一個倒下的一環
事故中心是 Exchange Online，也就是 Outlook 背後的電郵系統。網頁版、桌面版與手機版 Outlook 的郵件收發都失敗或嚴重延誤。更麻煩的是連帶影響：日曆、Teams 的會議排程與邀請、Copilot 取用工作郵件與檔案的流程，以至 SharePoint、OneDrive 與 Defender XDR，都屬於同一個事件編號 MO1550821 的範圍。微軟確認任何地區的連接都可能受影響。
- 投訴規模：故障追蹤網站 DownDetector 的 Outlook 報告在美東時間下午 1 時 15 分（香港時間 13 日凌晨 2 時 15 分）高峰超過 13 萬宗；Downdetector 指報告在一小時內已擴及 74 個國家及地區。
- 不等於全員離線：微軟財報披露的 Microsoft 365 商用付費席次以億計，但那是用戶基數，不是當時實際無法連線的人數。兩者不應混為一談。
- 香港：《南華早報》報道本港金融業受影響，高盛香港辦公室改用替代郵箱系統收發郵件，部分野村員工要離線工作。一名野村員工在上午 11 時 10 分表示，由凌晨起已未能收發電郵。
- 下游：OpenAI 與 Anthropic 均表示，其 Microsoft 365 連接器受影響，新連線可能中斷，工具未能如常運作。
背景：Exchange、Teams 與 Copilot 不是同一層
要理解為何有人「完全做不到事」、有人「Teams 仍在聊」，需要分清三層。Exchange Online 是電郵與行事曆的後端服務，Outlook 只是它的前端介面；Teams 的聊天與會議走另一套服務，所以聊天相對正常；但會議邀請依賴行事曆，於是同樣受牽連；Copilot 則要讀取郵件、行事曆與檔案才有內容可用，上游一斷，它就沒有材料。
同一個「死機」感受，實際是幾個互相依賴的層同時受壓。這種連鎖效應在雲端服務事故中並不少見，本站早前報道過日本十月網攻潮：雲端服務商被勒索 495 客戶連鎖停擺，一家供應商出事就沿供應鏈拖垮下游機構。分別在於：那次是勒索軟件攻擊，今次微軟明確否定惡意活動。
微軟說法一：不是網絡攻擊
微軟在服務健康頁的更新（香港時間上午 11 時 34 分）表明，無跡象顯示事件由惡意活動造成。Microsoft 365 Copilot 執行副總裁 Charles Lamanna 在 X 的帖文亦指出：「我們會繼續在掌握資訊後分享，目前我可以確認，沒有跡象顯示這是惡意或網絡活動所致。」
在大型雲端事故中，這一句與「沒有數據外洩」同樣關鍵。用戶經歷長時間無法收發電郵時，第一反應往往是最壞情況；官方及早排除網攻，可以減少市場與客戶的錯誤假設。
微軟說法二：不是流量暴增，而是連鎖過載
微軟的解釋在數小時內逐步收窄。香港時間凌晨 2 時 35 分，微軟指多個地區的基礎設施承受「負載上升」；到 3 時 31 分，說法變得具體：負載上升並非來自流量增加，而是「大量伺服器突然無法使用，令其餘基礎設施承受壓力」。這一句是整場事故的關鍵——不是太多人同時登入，而是可用機器突然變少。
到 4 時 19 分，微軟表示未發現與事故起點相關的近期變更，但失敗的健康檢查可能源自一個負責處理伺服器健康狀況的元件。稍後微軟開始回退一項與事故起點時間吻合的網絡組態變更。這是官方調查動作，並非已確認的根因。
機制可以這樣理解：健康檢查是雲端平台自動判斷「這台機器可否繼續服務」的機制。當大批機器在同一時間被判定不健康而退出，原本分散的流量就集中到餘下機器；而每台機器上負責建立安全連線的程序會最先飽和，伺服器於是停止處理請求。微軟在早上 6 時 09 分確認：「受影響伺服器上的一個核心程序正被淹沒，導致容量流失。」
修復為何反覆：一接回流量就再倒下
這場事故最值得記錄的一點，是恢復本身無法持續。微軟多次把伺服器帶回服務，但機器一開始接收流量，就再度失去反應。以下時間為香港時間 11 月 13 日，內容取自微軟 @MSFT365Status 公開貼文及服務健康頁更新。
| 香港時間 | 微軟公布的進展 |
|---|---|
| 02:35 | 多個地區基礎設施負載上升，可能導致連線錯誤 |
| 03:31 | 負載上升並非流量增加，而是大量伺服器突然無法使用 |
| 04:19 | 未發現與事故起點相關的變更；失敗的健康檢查或源自處理伺服器健康的元件 |
| 05:00 | 驗證另一種健康檢查方法，部分伺服器成功回到服務，並擴大套用 |
| 06:09 | 已採取措施未帶來預期緩解；核心程序被淹沒，容量流失 |
| 07:04 | 部分伺服器回到服務並保持穩定，部分地區出現有限恢復 |
| 11:13 | 已套用的變更未如預期，正尋找其他方法增加容量 |
| 12:36 | 調整流量協定、重新分配流量、策略性封鎖部分流量；只見部分地區恢復，且未能持續 |
| 13:01 | 多條工作線並行，處理當前障礙，把部分基礎設施回復健康 |
微軟期間嘗試過替代健康檢查、全面重啟、把流量改道、按地區隔離、限制流量類型，以至用舊版軟件組態重建部分伺服器。每一次把機器接回流量，都等於再做一次壓力測試，這也是為何「已恢復」的說法一再落空。
為何全世界一度以為 Google 和 AWS 也倒下了
故障期間，DownDetector 上 AWS、Google 及其他消費與雲端服務的報告同時急升，部分報道因此描述為「多雲同時故障」。官方紀錄並不支持這個說法。
- AWS 在 X 表明，AWS 服務「一直運作正常」，並指網上其他地方一宗無關的中斷，令部分新聞報道出現不準確的描述。
- Google Cloud 官方狀態頁在 11 月 13 日下午 1 時顯示「No broad severe incidents」，即沒有廣泛嚴重事故。
- 微軟自己的狀態頁亦顯示 Azure「No Azure issues detected」。
合理的解釋是溢出現象與誤報：當一個辦公室同時失去電郵、行事曆與依賴同一身分系統的流程，員工會把任何打不開的服務都歸入同一場故障，投訴量隨之擴散。投訴量是感受的指標，不是故障範圍的證據。
香港：通宵出事，周五早上仍在
時差令香港成為最早感受到影響的市場之一。美國東岸時間 11 月 12 日中午前後開始的事故，換算即香港 13 日凌晨；到周五上班時間，問題仍然存在。對以電郵串連審批、對外通訊與交易流程的金融機構而言，這不只是「不方便」，而是要把工作流程臨時改道。
值得留意的是，香港媒體已有的報道集中在「周五早上收發電郵受阻」的場面。真正需要解釋的問題是：為何一個組態與健康檢查問題，可以令全球性服務連續十多小時無法穩定恢復。
對企業的四個實際啟示
- 復原不等於穩定。判斷供應商是否真正恢復，要看官方狀態頁持續多久維持正常，而不是第一條「已恢復」的通告。今次正是最佳例子。
- 電郵要有第二通道。即時通訊、電話，以及預先演練過的替代郵箱，比事發當日才討論更有效。
- 自動化判斷本身要納入變更管理。健康檢查與網絡組態是雲端事故的常見起點；回退計劃要覆蓋這些「維運邏輯」，不只是應用程式碼。
- 畫出依賴鏈。Copilot、第三方連接器與自動化流程，多數都依賴同一個身分與郵件層。上游中斷時，它們不會各自獨立。
企業層面的準備工作，本站另文分析香港企業數據韌性 2026：備份與災難復原方案如何選，討論如何由「有備份」走向「可驗證的復原」。
常見問題
Microsoft 365 現在恢復了嗎？
未完全恢復。截至香港時間 11 月 13 日下午 1 時 01 分，微軟仍表示正處理「當前障礙」，官方狀態頁維持「服務降級」。部分地區曾出現恢復，但未能持續。
今次是黑客攻擊嗎？
微軟表示沒有跡象顯示事件由惡意或網絡活動造成。這個說法來自服務健康頁更新及 Copilot 執行副總裁 Charles Lamanna 的公開帖文。
Google 和 AWS 也有死機嗎？
沒有官方事故。AWS 稱服務一直運作正常；Google Cloud 狀態頁顯示沒有廣泛嚴重事故；微軟狀態頁亦顯示 Azure 無事故。投訴量急升屬溢出現象。
為何 Teams 聊天仍可用，電郵卻不行？
兩者屬不同服務層。Exchange Online 是電郵與行事曆的後端，Teams 聊天與會議走另一套服務；但會議邀請依賴行事曆，所以仍會受影響。
微軟何時會完全修復？
微軟未公布時間，亦未發表最終根因報告。官方目前的說法是部分地區有限度恢復，並持續調整流量與修復伺服器。
數據來源：微軟 @MSFT365Status 公開貼文、Microsoft 服務健康狀態頁（status.cloud.microsoft）、AWS 與 Google Cloud 官方狀態頁、CNBC、The Guardian、《南華早報》。時間除特別註明外均為香港時間。