今次故障針對的是搜尋，並非表示上述應用程式所有功能都停止運作。不過，對受影響用戶嚟講，搵唔到電郵、文件或者其他已儲存內容，已經足以令日常工作多個環節同時卡住。

MO1456424 點解會發生？

Microsoft 表示，最近一次部署引入了「資源使用效率問題」（resource utilization inefficiency issue），出事位置係處理搜尋要求的基建。簡單講，該次更新令受影響搜尋基建以唔理想的方式消耗資源，降低部分搜尋查詢的處理能力。

目前公開更新未有交代更深入的技術細節，例如涉及邊段程式碼、邊類資源、觸發門檻，或者部署改動的具體內容。

呢一點值得留意：現有證據支持的是同部署有關的資源效率問題，而唔係網絡攻擊、已確認的地區網絡故障，或者整個平台單純因容量不足而爆煲。

Microsoft 部署咗咩修復？

Microsoft 表示已經整合並開始部署修復方案，目標係降低資源壓力，以及恢復搜尋功能。其他報道亦指，修復措施針對上述效率問題，務求令受影響服務回復正常。

不過，現有事故紀錄仍然冇列出結束時間，所以單憑提供的資料，無法確認所有受影響用戶喺幾時完全恢復。紀錄亦冇交代今次係回滾更新、永久改動架構，定係採用其他更具體的技術方案。

點解叫做「事故」，但分類係服務降級？

Microsoft 365 的服務健康資料將 MO1456424 標記為 serviceDegradation，即係話事件唔係 Microsoft 365 整套服務完全停擺。但由於搜尋呢個面向客戶的核心功能，喺多個產品中對部分用戶失效，Microsoft 仍然需要將事件作為事故追蹤。

Microsoft 未有另外解釋點解採用呢個分類。比較穩妥的理解係照字面解讀：今次係跨多個產品的搜尋服務降級，並唔代表每一項 Microsoft 365 服務都用唔到。

同近期其他服務中斷有咩關係？

由於時間接近，MO1456424 容易同其他 Microsoft 或 Microsoft 旗下服務故障混為一談，但公開資料顯示，幾宗事件的成因並唔相同。

GitHub：另一宗歷時近 8 小時的事故

GitHub 於 2026 年 8 月 17 日另外發生事故，由 13:28 至 21:15 UTC，歷時 7 小時 47 分鐘。GitHub 狀態紀錄指，Issues、Pull Requests、API、Actions 及 Copilot 都出現錯誤率或延遲上升；高峰期網頁及 API 錯誤率約 20%，封存檔案及原始內容下載錯誤率則約 50%。

相關報道將事件歸因於負載平衡器飽和、錯誤的自動擴展政策，以及 Visual Studio Code 一個潛伏的重試錯誤。呢啲機制同 MO1456424 背後的搜尋基建部署問題並不一樣。

以往的 Microsoft 365 搜尋問題

Microsoft 365 之前亦發生過搜尋相關事故。2025 年 4 月，Outlook 網頁版及 SharePoint Online 用戶曾遇到搜尋延遲或失敗，原因涉及處理搜尋要求的基建組件表現低於可接受門檻。

另外，有報道提到 OneDrive 檔案搜尋曾出現問題，包括搜尋頁面顯示空白，或者明明知道已經上載檔案，搜尋卻搵唔到結果。不過，現有資料未能證明這些舊事故同 MO1456424 有相同根本原因。

7 月 23 日：範圍更廣的 Azure 及 Microsoft 365 網絡故障

2026 年 7 月 23 日的事件範圍更廣，技術成因亦完全不同。Microsoft Azure 狀態歷史顯示，事故影響時間介乎 14:44 至 19:41 UTC；部分客戶無法連線、遇到延遲上升，或者難以存取位於 West US 地區的 Azure 服務。影響主要涉及進出該地區的網絡流量，完全留喺區內的流量則不受影響。

Microsoft 將原因歸咎於自動網絡維護流程出錯，系統錯誤地從多於原定數量的設備移除 IP 路由。呢宗事故屬於網絡控制平面故障，與 MO1456424 的搜尋服務降級不同。

這幾宗事故反映到啲咩？

放埋一齊睇，三宗事故代表唔同層面的營運風險：

• MO1456424： 最近一次部署令搜尋基建出現低效率資源使用。
• GitHub 8 月 17 日事故： 負載平衡器飽和、自動擴展失效，以及重試問題令故障進一步放大。
• 7 月 Azure 事故： 自動維護流程移除過多 IP 路由。

換句話講，涉及的是應用程式部署、容量及自動擴展、網絡自動化等不同故障層面，並冇證據顯示三者由同一個根本原因造成。

現有事故報告亦未能證明，AI 帶來的需求增長導致 MO1456424、GitHub 故障，或者 7 月 Azure 事故。GitHub 曾經提到由自建數據中心遷移到公有雲，以及發展多雲路線，但呢啲策略方向本身唔足以證明同任何一宗特定事故存在因果關係。

比較穩妥的可靠性教訓係：當雲端服務及 AI 相關工作負載變得愈來愈重要，部署防護、容量規劃、避免重試風暴、故障隔離，以及經充分測試的網絡自動化，都會更加關鍵。多雲架構可以分散部分基建風險，但唔會自動防止服務自身控制平面出錯。

今次故障針對的是搜尋，並非表示上述應用程式所有功能都停止運作。不過，對受影響用戶嚟講，搵唔到電郵、文件或者其他已儲存內容，已經足以令日常工作多個環節同時卡住。

MO1456424 點解會發生？

Microsoft 表示，最近一次部署引入了「資源使用效率問題」（resource utilization inefficiency issue），出事位置係處理搜尋要求的基建。簡單講，該次更新令受影響搜尋基建以唔理想的方式消耗資源，降低部分搜尋查詢的處理能力。

目前公開更新未有交代更深入的技術細節，例如涉及邊段程式碼、邊類資源、觸發門檻，或者部署改動的具體內容。

呢一點值得留意：現有證據支持的是同部署有關的資源效率問題，而唔係網絡攻擊、已確認的地區網絡故障，或者整個平台單純因容量不足而爆煲。

Microsoft 部署咗咩修復？

Microsoft 表示已經整合並開始部署修復方案，目標係降低資源壓力，以及恢復搜尋功能。其他報道亦指，修復措施針對上述效率問題，務求令受影響服務回復正常。

不過，現有事故紀錄仍然冇列出結束時間，所以單憑提供的資料，無法確認所有受影響用戶喺幾時完全恢復。紀錄亦冇交代今次係回滾更新、永久改動架構，定係採用其他更具體的技術方案。

點解叫做「事故」，但分類係服務降級？

Microsoft 365 的服務健康資料將 MO1456424 標記為 serviceDegradation，即係話事件唔係 Microsoft 365 整套服務完全停擺。但由於搜尋呢個面向客戶的核心功能，喺多個產品中對部分用戶失效，Microsoft 仍然需要將事件作為事故追蹤。

Microsoft 未有另外解釋點解採用呢個分類。比較穩妥的理解係照字面解讀：今次係跨多個產品的搜尋服務降級，並唔代表每一項 Microsoft 365 服務都用唔到。

同近期其他服務中斷有咩關係？

由於時間接近，MO1456424 容易同其他 Microsoft 或 Microsoft 旗下服務故障混為一談，但公開資料顯示，幾宗事件的成因並唔相同。

GitHub：另一宗歷時近 8 小時的事故

GitHub 於 2026 年 8 月 17 日另外發生事故，由 13:28 至 21:15 UTC，歷時 7 小時 47 分鐘。GitHub 狀態紀錄指，Issues、Pull Requests、API、Actions 及 Copilot 都出現錯誤率或延遲上升；高峰期網頁及 API 錯誤率約 20%，封存檔案及原始內容下載錯誤率則約 50%。

相關報道將事件歸因於負載平衡器飽和、錯誤的自動擴展政策，以及 Visual Studio Code 一個潛伏的重試錯誤。呢啲機制同 MO1456424 背後的搜尋基建部署問題並不一樣。

以往的 Microsoft 365 搜尋問題

Microsoft 365 之前亦發生過搜尋相關事故。2025 年 4 月，Outlook 網頁版及 SharePoint Online 用戶曾遇到搜尋延遲或失敗，原因涉及處理搜尋要求的基建組件表現低於可接受門檻。

另外，有報道提到 OneDrive 檔案搜尋曾出現問題，包括搜尋頁面顯示空白，或者明明知道已經上載檔案，搜尋卻搵唔到結果。不過，現有資料未能證明這些舊事故同 MO1456424 有相同根本原因。

7 月 23 日：範圍更廣的 Azure 及 Microsoft 365 網絡故障

2026 年 7 月 23 日的事件範圍更廣，技術成因亦完全不同。Microsoft Azure 狀態歷史顯示，事故影響時間介乎 14:44 至 19:41 UTC；部分客戶無法連線、遇到延遲上升，或者難以存取位於 West US 地區的 Azure 服務。影響主要涉及進出該地區的網絡流量，完全留喺區內的流量則不受影響。

Microsoft 將原因歸咎於自動網絡維護流程出錯，系統錯誤地從多於原定數量的設備移除 IP 路由。呢宗事故屬於網絡控制平面故障，與 MO1456424 的搜尋服務降級不同。

這幾宗事故反映到啲咩？

放埋一齊睇，三宗事故代表唔同層面的營運風險：

• MO1456424： 最近一次部署令搜尋基建出現低效率資源使用。
• GitHub 8 月 17 日事故： 負載平衡器飽和、自動擴展失效，以及重試問題令故障進一步放大。
• 7 月 Azure 事故： 自動維護流程移除過多 IP 路由。

換句話講，涉及的是應用程式部署、容量及自動擴展、網絡自動化等不同故障層面，並冇證據顯示三者由同一個根本原因造成。

現有事故報告亦未能證明，AI 帶來的需求增長導致 MO1456424、GitHub 故障，或者 7 月 Azure 事故。GitHub 曾經提到由自建數據中心遷移到公有雲，以及發展多雲路線，但呢啲策略方向本身唔足以證明同任何一宗特定事故存在因果關係。

比較穩妥的可靠性教訓係：當雲端服務及 AI 相關工作負載變得愈來愈重要，部署防護、容量規劃、避免重試風暴、故障隔離，以及經充分測試的網絡自動化，都會更加關鍵。多雲架構可以分散部分基建風險，但唔會自動防止服務自身控制平面出錯。