打不開信箱那一刻，大家先懷疑了自己的電腦

臺灣時間 11 月 13 日的上班早晨，不少辦公室上演同一幕：筆電開機，Outlook 的圈圈轉了三十秒還在轉，Teams 的會議邀請點不開，就連 SharePoint 的共用資料夾也整片灰白。第一個念頭多半往自己身上找：昨天是不是裝了什麼軟體、網路線是不是鬆了，或者分享器又該重開了。折騰一輪，打開公司羣組，才發現整層樓的人都在做同一件事。

問題出在雲端那頭。依 Techaeris 整理的時間線（公開報導），美東時間 11 月 12 日 12 時 39 分起、臺灣時間 13 日凌晨 1 時 39 分，Microsoft 365 的使用者回報開始湧入；美東 13 時 09 分，單是 Outlook 一項就累積 128,874 筆回報。Exchange Online、Teams、SharePoint、Copilot、Defender XDR 同一天列進異常名單，微軟的辦公全家桶一次集體請假。

十二萬筆回報，和一個事件編號

128,874 這個數字值得多看兩眼。它是使用者「自報」的通報數，一筆代表一個人到當機追蹤平臺按了一次回報，並不等於受影響人數；實際被卡住的人，通常比願意按按鈕的人多得多。大規模當機從來沒有官方的即時受害統計，規模只能靠眾人自報，數字像投票一樣慢慢疊上去。這也是為什麼每次事件的新聞標題，掛的都是「回報數」而非「災情人數」。

臺灣使用者的體感則是「一覺醒來」。美東的午後正是臺北的凌晨，回報高峯發生在多數人的睡夢中，等到上班時間打開電腦，看到的往往是已經修到一半的殘局。企業帳號另有對帳管道：Microsoft 365 系統管理中心的「服務健康狀態」會列出租戶專屬事件，這次 Exchange Online 的事件編號是 EX1550543，管理員憑編號就能追微軟的處置進度。依自由時報報導（公開報導），臺灣時間 13 日上午 7 時左右部分地區連線改善，但微軟始終沒有宣布全面排除，恢復與否，一律以官方服務狀態頁為準。

先查狀態頁，再重開機

英國情境喜劇《The IT Crowd》有句流傳近二十年的臺詞：「你試過把它關掉再打開嗎？」雲端時代的殘酷之處在於，這句萬用咒語失效了：你重開的機器，和出事的機器，根本不在同一個機房。當機的排查順序因此整個倒轉，先確認故障範圍，比反覆重開自己的電腦更快找到下一步。

個人端的排除步驟可以濃縮成四步：

• 用手機或另一臺電腦打開 Microsoft 365 服務狀態頁，看 Outlook、Exchange Online、Teams 是否列出事件。
• 用瀏覽器登入 Outlook 網頁版比對。網頁版能收發、只有桌面程式卡住，問題較可能在自己電腦；網頁版也打不開、同事同步出狀況，雲端故障的機率就高。帳號設定、租戶政策或公司網路也可能造成類似症狀，企業環境仍要由管理員核對。
• 只有桌面版卡住時，按 Win＋R 輸入 Outlook.exe /safe，以安全模式開啟。增益集是裝在 Outlook 裡的擴充功能，會議外掛或簽章工具其中一個出錯，就可能讓整個程式卡住，安全模式會暫時停用它們，方便逐一清查；若系統找不到程式，微軟文件建議改用完整路徑。
• 記下錯誤訊息和出現時間。回報 IT 時，這些截圖比一句「就是打不開」有用得多。

安全模式只幫得上本機問題，微軟端的異常仍要等官方修復。這也是當機自查最微妙的地方：一般人永遠無法完全確定問題在哪一端，資訊不對稱是結構性的。這種「家裡的東西壞了、主人卻看不出病因」的處境並不新鮮，五個上門維修師傅只有兩個說實話的測試影片，測的正是同一道難題。差別在於，這回的「師傅」是微軟的狀態頁，而它不一定即時，也不一定完整。

從 MSN 到藍屏那一夜，當機一直有人陪

把鏡頭拉遠，服務中斷在中文網路一直有圍觀傳統。MSN Messenger 當家的年代，聯絡人清單刷不出來的那個下午，辦公室會陷入一種短暫的、不知道該做什麼的安靜；確認故障的方法很原始，打電話問同學，或等晚間新聞。2021 年 Facebook、Instagram、WhatsApp 大斷線約六小時，大家湧向其他平臺互相確認「原來不是自己的網路」。2024 年 7 月 CrowdStrike 事件讓全球大批 Windows 電腦跳出藍底白字的當機畫面，機場櫃檯改發手寫登機證的畫面，很多人到現在還記得。

每一次大規模當機，當機追蹤平臺的曲線都會變成一場直播。數字往上跳，留言區跟著排隊，有人回報地區、有人貼出錯誤代碼的截圖，更多人只是來確認一件事：原來大家都一樣。這種把數字當連續劇追的班底，和英偉達單日重挫那晚排起的慰問隊伍是同一批觀眾，一個百分比、一條曲線，都能被圍觀成即時內容。

當機還有一個少被提起的副作用。它可能是現代辦公室裡，全員同時做同一件事的少數時刻之一：平常各忙各的樓層，在 Teams 轉不出來的那半小時，突然有了共同話題，順便確認了彼此的存在。

Copilot 一起安靜了，這次的帳多一欄

這次異常名單上有一個新面孔：Copilot。受影響的也不只是微軟自家的 AI 助手，所有透過 Microsoft 365 連接器讀信箱、讀行事曆的第三方 AI 工具，同一時間失去上遊。以前服務中斷，直接停擺的是人；這次多了一層，替人工作的 AI 也一起停，而且它停得比人安靜，沒有人會替一個機器人按下回報。

對企業來說，這次事件等於一張現成的依賴地圖：哪些流程掛在 Exchange Online 上、哪些自動化靠連接器餵資料，平常盤點一次，當機時就知道要手動補哪些洞。對個人來說，比較實際的功課是替自己的 AI 工具想好退路，知道連接器斷了之後，哪些事情回到手動還做得動。

恢復之後還有一段收尾。檢查寄件匣和草稿，確認哪些信還在排隊；記下 Teams 訊息與共用檔案最後成功送出的時間，恢復後才知道哪些要重寄、哪些已經送達，避免重複寄信或覆蓋別人的檔案。這套災後對帳的功夫，和損害規模一樣，總是比想像中花時間。

下一次圈圈轉起來

雲端服務把「能不能開機」的責任從我們手裡收走，也順手收走了故障時的解釋權。我們剩下的主動權不多：把手機裡的狀態頁書籤準備好，把「先查再重開」的順序記住，然後在羣組裡比同事早三十秒貼出事件編號。

下一次 Outlook 的圈圈又轉起來，你會是先重開分享器的人，還是先打開狀態頁的人？

資料來源：本站編輯參考 APPI News〈Microsoft 365 當機自查指南：Outlook、Teams 無法使用怎麼辦〉（作者：張饒輝 Lightman Chang）改寫而成，原文出處；原文文字內容採 CC BY 4.0 授權。