Sejarah status Microsoft Azure menyiarkan dua semakan pasca-insiden berturut-turut pada akhir September. Kedua-duanya bukan gangguan global, tetapi punca akarnya ialah contoh klasik yang wajar dibandingkan dengan seni bina anda sendiri.

Insiden Pertama: Perkhidmatan AI di Sweden Central (ID Penjejakan 7QL5-Z50)

Dari 10:03 hingga 15:58 UTC pada 29 September 2026, Azure OpenAI, Foundry Agent Service, Foundry Models dan Cognitive Services di wilayah Sweden Central mengalami kegagalan permintaan berselang-seli, kependaman meningkat dan ralat HTTP 5XX. Punca akar menurut Microsoft: perkhidmatan backend yang mengambil metadata mengalami tamat masa pangkalan data, lalu instance-nya mencapai ambang dan dimulakan semula berulang kali sehingga kapasiti sihat berkurang. Kadar kegagalan dikesan pada 10:14, tamat masa dikenal pasti pada 11:29, perkhidmatan diskala dan had sumber dinaikkan pada 15:22, dan pemulihan dicapai pada 15:58.

Ia risiko yang sama seperti yang kami huraikan dalam artikel kami tentang gangguan perkhidmatan AI pada 3 September: aplikasi anda baik-baik sahaja, tetapi API model yang menjadi kebergantungannya perlahan atau gagal di satu wilayah.

Insiden Kedua: Perkhidmatan Get Laluan di Lima Wilayah (ID Penjejakan 7Q30-010)

Dari 20:30 UTC pada 30 September hingga 02:15 UTC pada 1 Oktober, ExpressRoute Gateway, Azure Firewall, Application Gateway, WAF, VPN Gateway dan Azure VMware Solution mengalami masalah kesambungan di UK South, France Central, North Europe, Southeast Asia dan UK West — Southeast Asia ialah wilayah Azure di Singapura. Punca akar menurut semakan awal: perubahan terkini pada pengurusan get laluan wilayah mencetuskan beban berlebihan ketika penyelenggaraan sistem pengendalian yang tidak berkaitan sedang berjalan, dan perkhidmatan itu tidak dapat berskala secara automatik kerana kekangan perkhidmatan yang menjadi kebergantungannya. Microsoft mengaitkan insiden itu dengan penyelenggaraan tersebut lalu menghentikannya pada 23:05, pemulihan berkembang pada 01:36 dan mitigasi disahkan pada 02:15.

Membaca Kedua-duanya Bersama

  • "Mesin hidup" tidak bermaksud "perkhidmatan boleh dicapai". Dalam insiden kedua, banyak mesin maya mungkin sihat sepenuhnya, tetapi apabila get laluan, tembok api atau VPN di hadapannya tumbang, pengguna tetap tidak dapat bersambung. Pemantauan peringkat hos tidak mencukupi; uji keseluruhan laluan capaian dari luar.
  • Perubahan yang bertembung dengan penyelenggaraan ialah mod kegagalan lama. Salah satunya sahaja tidak berbahaya; bersama-sama, ia merosakkan. Begitu juga dengan pelayan anda sendiri: jarakkan naik taraf, but semula dan perubahan konfigurasi, serta sediakan laluan untuk berundur.
  • Lakarkan kebergantungan anda. Dalam laporan kami tentang gangguan separuh tahun pertama, kami mencadangkan anda memetakan permintaan mana yang melalui wilayah mana bagi pembekal mana, dan sama ada anda boleh bertukar apabila satu gagal.

Jika Anda Melayani Pengguna di Asia Tenggara

Jika pengguna anda kebanyakannya di Asia Tenggara dan pintu masuk kritikal anda terletak di satu wilayah bagi satu pembekal sahaja, insiden seperti ini hanya membiarkan anda menunggu. Susunan yang lebih kukuh menyediakan pintu masuk yang boleh mengambil alih di pembekal lain atau wilayah lain, digandingkan dengan peralihan DNS. Memilih pusat data berkependaman rendah untuk beban kerja anda menerangkan cara memilih lokasi, dan nod Singapura kami boleh menjadi salah satu pintu masuk sandaran tersebut.