Gangguan Azure: Saat Sambungan ke Komputasi Awan Putus

Pada 1 Oktober 2026 pukul 03.30 sampai 09.15 WIB, layanan penghubung (gateway) Azure terganggu di 18 wilayah layanan (region), termasuk Southeast Asia. Layanan ini menghubungkan jaringan kantor atau pabrik dengan komputasi awan Microsoft. Sebagian beban kerja dapat tetap berjalan sementara jalur penghubung terganggu. Laporan tersebut tidak membuktikan kondisi setiap server yang terdampak. Rencana penggunaan komputasi awan perlu mencakup ketersediaan sambungan ke server.

Artikel ini membahas penjelasan awal Microsoft, dampak pemeliharaan rutin, dan pemeriksaan bagi cabang, hotel, atau pabrik yang bergantung pada Azure.

Apa yang terjadi pada 30 September dan 1 Oktober?

Riwayat status Azure (tracking ID 7Q30-010) mencatat gangguan mulai 20.30 UTC tanggal 30 September dan reda 02.15 UTC tanggal 1 Oktober 2026. Totalnya 5 jam 45 menit. Dalam WIB, itu dari 03.30 sampai 09.15 pagi. Jam buka kantor sudah lewat.

Layanan yang terdampak terutama mengatur sambungan dan lalu lintas menuju server.

• VPN Gateway: terowongan terenkripsi lewat internet biasa yang menyambungkan jaringan kantor ke jaringan privat di Azure.
• ExpressRoute Gateway: ujung Azure dari jalur sewa privat. Ini opsi yang dibayar lebih mahal justru karena dijanjikan lebih andal.
• Azure Firewall, Application Gateway, dan Web Application Firewall: pos pemeriksaan yang menyaring dan mengarahkan lalu lintas sebelum sampai ke server.
• Azure VMware Solution, yang menumpang di jaringan yang sama.

Dari 18 region itu, ada Southeast Asia (Singapura), East Asia (Hong Kong), Japan West, dan Korea Central. Sisanya sebagian besar Eropa, plus beberapa region di AS, India, Timur Tengah, dan Afrika.

Laporan The Register menambahkan dua detail. Sebagian VPN gateway tidak mati total, hanya kehilangan pasangan cadangannya. Dan Microsoft harus memulihkan beberapa komponen manajemen jaringan secara manual, menggunakan instans pengganti.

Mengapa pemeliharaan rutin mengganggu sambungan?

Penjelasan awal Microsoft ada dua lapis. Pertama, ada perubahan baru di layanan regional yang mengelola gateway, dan perubahan itu membuat bebannya lebih berat dari perkiraan. Kedua, di saat yang sama ada update sistem operasi yang sedang berjalan bertahap dari region ke region.

Layanan pengelola biasanya menambah kapasitas secara otomatis (autoscaling) ketika beban naik. Dalam kejadian ini, layanan pendukungnya juga kewalahan sehingga kapasitas tidak bertambah cukup cepat.

Sebagai gambaran, perbaikan jalan dapat dilakukan per lajur selama pusat pengaturannya bekerja. Jika pusat itu tidak mampu memberi arahan, pekerjaan tetap terganggu meskipun jalannya utuh. Gangguan lapisan pengelola Azure mempunyai pola serupa.

Microsoft menghentikan update itu pukul 23.05 UTC, dua setengah jam setelah gangguan mulai. Microsoft menyatakan laporan lengkap pasca-insiden biasanya tersedia dalam sekitar 14 hari. Periksa ketersediaannya melalui Azure Service Health.

Sehari sebelumnya ada insiden lain (tracking ID 7QL5-Z50). Azure OpenAI dan layanan AI Foundry di region Sweden Central terganggu hampir enam jam, dari 10.03 sampai 15.58 UTC tanggal 29 September. Penyebabnya juga dari dalam: satu proses latar belakang membanjiri basis data metadata dengan permintaan sampai layanannya restart berulang kali.

Dua insiden ini mempunyai penyebab yang berbeda, tetapi sama-sama berasal dari proses internal penyedia. Laporan insiden sebelumnya tidak menyebut pemeliharaan sebagai pemicunya. Perawatan yang tidak pernah Anda lihat jadwalnya tidak bisa dihindari. Yang bisa hanya merancang sistem supaya tahan saat itu terjadi.

Kenapa dampaknya lebih berat untuk operasional di Indonesia?

Lihat jamnya dulu. Pukul 03.30 sampai 09.15 WIB itu jam serah terima shift malam, tamu hotel yang check-out pagi, pabrik mulai shift pertama, dan toko cabang membuka kasir. Tim di Eropa mungkin tidur nyenyak melewati gangguan ini. Operator di Jakarta atau Surabaya dapat mulai bekerja ketika gangguan belum pulih.

Lalu lihat regionnya. Microsoft baru membuka Indonesia Central pada Mei 2025, region pertamanya di sini dengan tiga availability zone di sekitar Jakarta. Banyak perusahaan Indonesia yang pindah ke Azure sebelum itu dan masih berjalan di Southeast Asia, yang masuk daftar terdampak. Indonesia Central tidak masuk daftar kali ini. Namun, ketiadaan wilayah tersebut dari daftar tidak membuktikan bahwa ia bebas dari risiko serupa.

Availability zone, pusat data terpisah dalam satu wilayah, belum tentu melindungi layanan dari gangguan pengelola gateway yang digunakan bersama. Zona melindungi Anda kalau satu gedung kehilangan listrik atau pendingin. Gangguan ini ada di lapisan pengelola regional yang melayani semua zona sekaligus. Poin yang sama saya bahas di gangguan AWS us-west-2: penyebaran server ke beberapa zona belum cukup jika lapisan pengelola bersama terganggu.

Yang paling terpukul adalah sistem hybrid, yaitu sebagian dijalankan di lokasi dan sebagian di komputasi awan, disambung terowongan:

• Toko cabang yang mengirim transaksi kasir ke sistem pengelolaan sumber daya perusahaan (ERP) di Azure.
• Hotel dengan PMS (perangkat lunak operasional hotel: kamar, tamu, tagihan) di server lokal yang sinkron ke basis data atau laporan di cloud.
• Pabrik yang terminal di lini produksinya mengambil perintah kerja dari MES (perangkat lunak pengatur jalannya produksi) di cloud.
• Kantor yang login karyawannya dicek oleh server pengelola akun jaringan (domain controller) yang ditaruh di Azure.

Dalam contoh tersebut, gangguan sambungan dapat menghentikan alur kerja meskipun sistem lokal dan server komputasi awan masih berjalan.

Sistem mana saja yang lewat jalan itu?

Mulailah dengan daftar alur data yang melewati terowongan jaringan. Empat kolom berikut membantu menunjukkan pekerjaan yang akan terhenti:

Yang penting kolom terakhir. Alur yang jawabannya "lokasi berhenti kerja" adalah single point of failure: satu bagian yang kalau rusak, semuanya ikut berhenti. Cara menemukannya saya bahas di single point of failure di sistem bisnis.

Jalur cadangan yang benar seperti apa?

Jawaban standarnya "ExpressRoute utama, VPN cadangan". Di insiden ini, dua jenis gateway itu sama-sama kena di region yang sama. Pasangan itu bisa tumbang berbarengan. Jalur cadangan baru dihitung cadangan kalau tidak memakai komponen yang rusak.

Pertimbangkan tiga pilihan berikut, mulai dari dukungan kerja lokal:

1. Biarkan lokasi bekerja sendiri sementara. Cabang tetap jualan, hotel tetap melayani check-out, lini produksi tetap jalan. Transaksinya menunggu di antrean lokal sampai terowongan pulih. Ini pilihan paling andal karena sama sekali tidak butuh jalan. Detail desainnya ada di tulisan soal aplikasi lapangan offline-first.
2. Jalan kedua lewat komponen lain. Untuk segelintir alur yang benar-benar tidak bisa menunggu, buka jalur terpisah: endpoint HTTPS dengan autentikasi yang benar, terowongan ke region kedua, atau rute lewat penyedia lain. Cara ujinya mudah. Sebutkan komponen apa yang rusak tanggal 1 Oktober, lalu pastikan jalur cadangan Anda tidak memakainya. Application Gateway juga ada di daftar itu. Endpoint darurat yang lewat Application Gateway di region yang sama bukan jalan kedua.
3. Prosedur pindah jalur yang tertulis. Siapa yang memutuskan pindah, apa yang diubah, dan bagaimana kembali ke jalur utama. Jalur cadangan yang hanya satu tenaga teknis mengetahui cara menyalakannya pasti menyala terlambat.

Pilihan pertama dapat mencukupi alur yang dapat menoleransi sinkronisasi tertunda. Pilihan kedua dan ketiga baru masuk akal untuk alur yang kerugian enam jam menunggunya lebih besar daripada biaya membangunnya.

Bagaimana tahu yang putus jalannya, bukan server Anda?

Linimasa Microsoft menunjukkan jeda antara awal gangguan dan keterangan penyedia. Gangguan mulai 20.30 UTC, investigasi baru mulai 21.29 UTC, dan skala lintas region baru disadari 22.27 UTC. Selama jam pertama, tim IT yang melihat terowongannya mati tidak punya pegangan resmi apa pun. Tanpa data pembanding, tim dapat menghabiskan waktu untuk memulai ulang server atau menghubungi penyedia internet (ISP).

Pantau jalannya dari sisi Anda:

• Pasang pemeriksaan sambungan melalui terowongan. Skrip kecil di tiap lokasi yang memanggil satu alamat privat di Azure tiap menit, dan mengirim peringatan setelah tiga kali gagal. Jika internet lokasi normal tetapi pemeriksaan gagal, periksa jalur privat dan layanan tujuannya.
• Langganan Azure Service Health alert untuk region dan layanan gateway yang Anda pakai. Pengumuman dari penyedia langsung masuk ke HP, bukan menunggu di portal yang tidak dibuka siapa pun jam 4 pagi.
• Catat status terowongan di samping log aplikasi. Saat menyusun laporan insiden, "penjualan berhenti sinkron" dan "terowongan putus" bisa dicocokkan dalam hitungan menit.

Dasar pengiriman peringatan saya bahas di panduan pemantauan dan alerting untuk sistem kecil.

Apa yang dicek minggu ini?

• Daftar alur yang lewat gateway VPN atau ExpressRoute Anda, lengkap dengan kolom "kalau putus 6 jam".
• Cek apakah gateway Anda ada di salah satu dari 18 region terdampak, dan apakah ada yang benar-benar gagal di lokasi Anda antara 03.30 dan 09.15 WIB tanggal 1 Oktober.
• Untuk tiap alur yang bisa menghentikan lokasi, putuskan: antrean lokal, jalan kedua, atau terima risikonya secara tertulis.
• Pasang satu pemeriksaan melalui terowongan dan satu peringatan Service Health.
• Periksa Azure Service Health dan baca laporan pasca-insiden Microsoft ketika tersedia. Cek apakah langkah perbaikannya menyentuh gateway yang Anda pakai.

Penyedia cloud akan terus merawat mesinnya, dan sesekali perawatan itu meleset. Pastikan tim tetap dapat mengakses layanan atau melanjutkan pekerjaan lokal ketika sambungan terganggu.