強雷暴吹冧電網！微軟Azure美國西部二區大死機，AI服務都出事

• AI 同機器學習： Azure OpenAI Service
• 核心運算： Azure Virtual Machines（虛擬機器）、Azure Kubernetes Service (AKS)、Azure Functions
• 數據庫同分析： Azure SQL Database、Azure Cosmos DB、適用於 PostgreSQL / MySQL 嘅 Azure Database 彈性伺服器、Azure Data Factory、Azure Databricks
• 管理同身份驗證： Azure Resource Manager（資源管理器）、Azure Policy
• 儲存同備份： Azure Storage Accounts（儲存帳戶）、Azure NetApp Files、Azure Backup
• 整合同通訊： Azure Service Bus、Azure Communication Services
• 其他關鍵服務： Log Analytics、Azure App Service、Azure Maps、Azure Migrate

後備電源去咗邊？呢次冇壞到

有一點好緊要，就係同以往某啲轟動一時嘅數據中心死機案唔同，現有證據冇顯示今次後備供電系統（UPS／發電機）有失靈。微軟嘅狀態更新明確指出「數據中心嘅電力已經全面恢復」，即係話問題純粹係最初嘅市電中斷，而唔係現場發電機或者UPS之後再壞。

呢點同Azure其他有記錄嘅事故好唔同。例如2026年2月West US嗰次死機，係因為變電站一個電壓互感器故障，引致瞬間電壓飆升，搞到下游嘅UPS機組損壞，最終成個數據中心完全斷電。 但係喺5月29號呢單嘢，至今都冇報告話發生過類似嘅內部硬件損壞。

恢復過程時間線

一個區域性嘅電力中斷，恢復起嚟係一場漫長嘅拉鋸戰，唔係話撳個掣就搞得掂。根據Azure官方狀態更新，以下係成個事嘅關鍵發展：

• 04:27 UTC： 死機開始。強雷暴導致West US 2多個數據中心嘅市電大規模中斷。
• 恢復進展： 數據中心電力全面恢復。之後，大部分網絡同儲存基礎設施都重新上線。可用性區域2嘅基礎設施恢復正常運作。
• 殘餘影響： 恢復工作開始集中喺可用性區域1同3嘅一部分基礎設施，當中有兩個儲存單元（storage stamps）需要做最後嘅恢復同驗證。
• 最後已知狀態（「Active – Recovering」）： 截至最後可以睇到嘅狀態快照，呢單事故仍然標記為「Active – Recovering」，即係微軟仲未宣布所有受影響服務都已經完全恢復。

唔係第一次：天氣引發嘅雲端死機史

今次死機並非個別事件，而係微軟Azure平台困擾多年嘅「天氣相關漏洞」模式嘅最新一單。呢啲事故話畀我哋知，就算最先進嘅雲端基礎設施，最後都係要睇物理世界嘅面色。

• 2018年9月，South Central US： 喺美國德州聖安東尼奧附近，一場包含閃電嘅惡劣天氣事件，造成電壓驟降，搞到數據中心嘅冷卻系統離線。伺服器過熱熄機，亦因為平台架構上嘅依賴問題，個別服務中斷咗足足幾日。
• 2026年2月，West US： 一個數據中心嘅內部變電站變壓器故障，引發局部電力中斷。雖然後備系統即刻介入，但最初嘅電壓飆升已經整壞咗UPS設備，令恢復過程更加複雜，仲影響埋Microsoft Store同Windows Update服務。

呢啲前科同5月29號嘅事件都有個共通點：就係一個外部物理事件直接打中數據中心嘅供電鏈，之後就好似多米諾骨牌咁，引發一大堆依賴佢哋嘅數碼服務連鎖式崩潰。

AI可靠性嘅賭注愈嚟愈大

Azure OpenAI Service 今次榜上有名，意味住呢類死機嘅影響力已經升咗級。 隨住企業愈嚟愈將AI模型嵌入到關鍵工作流程同面向客戶嘅產品入面，區域性雲端死機已經唔單止係IT基建唔方便咁簡單，而係會直接癱瘓到啲AI應用程式、搜尋引擎同自動化流程。就算強雷暴係天災，但今次中斷都突顯咗一個問題：依賴特定雲端區域嘅AI工作負載，風險愈嚟愈集中。

值得留意嘅係，喺現有嘅資料來源入面，微軟暫時仲未就呢次特定事件發布詳細嘅根本原因分析（RCA）。所以，關於電力恢復嘅精確時序，同埋點解某啲儲存單元需要特別長嘅恢復時間，呢啲最終結論都要等官方嘅事後審查報告出爐先可以作實。