Pada 3 September 2026, beberapa perkhidmatan AI merosot dalam tetingkap masa yang sama. Ia wajar ditulis bukan terutamanya kerana skala kesannya, tetapi kerana ia sekali lagi menunjukkan dengan jelas jurang antara pemerhatian pihak ketiga dan pengesahan oleh vendor — dan perbezaan itulah yang menentukan ke mana anda membelanjakan wang dan tenaga kejuruteraan selepas ini.

Apa yang Disahkan

  • Halaman status OpenAI menandakan ralat meningkat pada ChatGPT dan Codex. Itu sumber pertama.
  • Laporan Downdetector meningkat daripada lebih 5,000 kepada lebih 74,000, antara puncak laporan terbesar yang dijejaki platform itu bagi sesebuah perkhidmatan AI pada tahun tersebut.
  • Tetingkap gangguan berlangsung kira-kira 10:58 hingga 14:56 waktu Timur AS — hampir empat jam.
  • Menjelang pagi 4 September, penjejak luar menunjukkan ChatGPT dan Codex beroperasi normal semula.

Apa yang Sekadar Diatributkan

Beberapa penerbitan mengaitkan kemerosotan serentak beberapa perkhidmatan AI itu dengan kegagalan serantau Azure East US, melaporkan bahawa Claude dan Grok turut terjejas dalam tetingkap sama manakala Gemini — yang berjalan di Google Cloud — memuncak sekitar 500 laporan sahaja.

Namun pada masa penulisan, sejarah status Azure yang diterbitkan Microsoft tidak menyenaraikan insiden East US yang sepadan bagi September 2026. Ulasan pasca insiden terbaharu yang kelihatan di sana bertarikh 23 Julai 2026 dan melibatkan isu ketersambungan rangkaian West US, ID penjejakan ZJV6-SGG.

Itu tidak menjadikan laporan media salah — ulasan pasca insiden vendor lazimnya mengambil masa berhari-hari atau berminggu-minggu untuk muncul. Maksudnya lebih sempit dan lebih berguna: sehingga anda memperoleh pengesahan sumber pertama, rantaian sebab itu kekal sebagai "menurut laporan", dan ia tidak layak dijadikan fakta dalam keputusan seni bina anda. Inilah disiplin yang sama seperti dalam "Kedudukan Bergoncang 1 hingga 3 Ogos dan Google Tidak Mengesahkan Apa-apa": beberapa pemantau menyala serentak membuktikan korelasi, tidak pernah sebab-akibat.

Apa Pun Punca Asasnya, Kesimpulan Kejuruteraannya Sama

Jika produk anda memanggil API model terhos, itu ialah kebergantungan keras: apabila ia rosak, ciri anda rosak, dan anda tiada keupayaan membaikinya mahupun hak untuk diberitahu apa yang berlaku. Semua itu tidak berubah sama ada puncanya Azure, vendor itu sendiri, atau sesuatu yang lain. Perkara yang boleh dilaksanakan serta-merta:

  • Tetapkan tamat masa yang tegas. Jangan warisi nilai lalai SDK yang selalunya tidak terbatas atau terlalu panjang. Panggilan yang melebihi had yang anda boleh terima patut gagal ke laluan sandaran, bukan menambat benang permintaan pengguna.
  • Cuba semula dengan backoff eksponen dan jitter, dan bezakan pengehadan kadar daripada kegagalan serantau — mencuba lebih kuat terhadap yang kedua hanya membesarkan kesesakan.
  • Sediakan mod merosot. Jawapan dari cache, baris gilir tak segerak, atau mesej jujur — semuanya lebih baik daripada membiarkan pemutar berpusing selama empat jam.
  • Baris gilirkan kerja supaya permintaan pengguna terpisah daripada panggilan model. Kegagalan kemudiannya bermakna "lebih perlahan" dan bukan "hilang" — perubahan seni bina paling berbaloi dalam senarai ini.
  • Pastikan penyedia boleh ditukar. Sekurang-kurangnya abstrakkan panggilan model di sebalik konfigurasi supaya anda boleh bertukar vendor tanpa mengubah kod. Jika pelan sandaran anda ialah model hos sendiri, baca dahulu artikel kedua dalam kumpulan ini — komponen hos sendiri membawa masalah pendedahannya sendiri.
  • Jalankan halaman status dan amaran anda sendiri. Anda patut tahu sebelum pengguna anda, bukan melalui tiket sokongan.

Tuliskan Senarai Kebergantungan Itu

Dalam ulasan kami tentang corak gangguan separuh pertama 2026, kami mencadangkan melukis peta kebergantungan: DNS, CDN, pengeluaran sijil, storan objek, akaun dan pengebilan, capaian luar jalur — setiap satu dengan nota tentang apa yang berlaku apabila ia gagal. API model terhos kini layak mendapat barisnya sendiri pada peta itu.

Satu instance yang anda kawal sepenuhnya boleh memainkan beberapa peranan di situ yang tidak boleh digantikan: mengehos halaman status dan halaman merosot (yang tidak boleh berkongsi nasib dengan perkhidmatan utama), bertindak sebagai pelayan asal sementara selepas penukaran DNS, dan menyimpan salinan sandaran yang tidak berada dengan vendor yang sama. Strategi sandaran VPS menerangkan apa yang menjadikan salinan itu benar-benar boleh dipulihkan, dan apa itu CDN dan bila anda memerlukannya menjelaskan sempadan tanggungjawab pelayan asal. SharkCloud mempunyai nod di Jepun, Singapura, Hong Kong dan Amerika Syarikat — dan meletakkan mesin sandaran itu dengan penyedia berbeza di rantau berbeza ialah kotak paling mudah untuk diisi pada peta tersebut.