Pada 20 Oktober 2026, salah satu zona ketersediaan Google Cloud di London mengalami pemadaman selama hampir 8 jam. Lima hari sebelumnya, DeepSeek juga sempat tidak bisa diakses selama hampir setengah hari. Banyak developer bertanya-tanya: apakah aplikasi AI mereka juga bisa ikut tumbang lain kali?
Layanan hulu bisa saja tumbang kapan pun. Anda yang hanya memanggil API model tidak perlu memindahkan pusat data, tetapi jangan hanya menggantungkan bisnis pada satu model.
Manfaat utama: Setelah membaca artikel ini, Anda akan tahu situasi mana yang perlu ditangani dan mana yang tidak, serta cara menyiapkan model cadangan.
Dua gangguan layanan minggu ini, masing-masing menyebabkan apa?
Pertama, Google Cloud. Pada 20 Oktober 2026, pukul 14.08 hingga 22.00 waktu Beijing, zona ketersediaan europe-west2-b di London mengalami gangguan akibat masalah pasokan listrik. Gangguan berlangsung selama 7 jam 52 menit. Komputasi, penyimpanan, basis data, dan jaringan yang berada di zona ini terdampak. Mereka yang hanya memanggil API model dari jarak jauh tidak terkena dampak langsung. Namun, jika layanan Anda kebetulan berjalan di zona ini, pekerjaan di latar belakang, koneksi basis data, dan antarmuka eksternal akan terhenti sepanjang sore. Tidak ada yang bisa menyelesaikan pekerjaan itu lebih dulu untuk Anda.
Berikutnya, DeepSeek. Mulai 15 Oktober 2026 pukul 08.11 waktu Beijing, situs web, layanan percakapan, serta sebagian API V4 Pro dan V4.1 Flash mengalami gangguan. Laman status resmi mencatat gangguan berlangsung selama 4 jam 52 menit dan layanan pulih pada pukul 13.04 hari itu. Caixin dan South China Morning Post menyebutnya “hampir 5 jam”; untuk durasi, acuan yang tepat adalah catatan resmi. DeepSeek kemudian mengembalikan pemakaian dari 8 sampai 14 Oktober dalam bentuk kredit. Pihak resmi tidak mengumumkan penyebabnya, jadi kita tidak akan berspekulasi. Bagi pengguna, apakah layanan bisa dipakai pagi itu bergantung pada ada tidaknya jalur alternatif, bukan pada penyebab gangguannya.
Gambar: Pemberitahuan dari DeepSeek tentang pemulihan layanan dan kompensasi untuk pengguna. Layanan API tidak dapat digunakan dengan normal pada 15 Oktober, pukul 08.11–13.04 waktu Beijing. Jumlah yang dikembalikan sepenuhnya dalam bentuk kredit bonus dihitung berdasarkan pengeluaran akun pada 8–14 Oktober. Kredit akan masuk otomatis, dan biaya API akan dipotong terlebih dahulu dari saldo bonus.
Dampak dari kedua kejadian ini sama: model merupakan salah satu bagian dari alur kerja harian. Begitu antarmukanya terputus, pekerjaan seperti menulis kode, mencari informasi, dan menjalankan pemrosesan batch ikut terhenti. Saat layanan hulu pulih, setengah hari sudah berlalu. Pengembalian kredit hanya mengompensasi tagihan, bukan waktu kerja yang terbuang. Jika pada hari itu tim harus menyelesaikan sejumlah terjemahan, menjalankan satu putaran evaluasi, atau mengejar jadwal peluncuran, semua pekerjaan itu tidak akan selesai dengan sendirinya berkat kompensasi. Pekerjaan hanya akan tertunda dan ikut memadatkan jadwal keesokan harinya.
| Item | Fakta terverifikasi tentang insiden Google Cloud |
|---|---|
| ID insiden | Xs2XTHzAVC9YnafnPyzj |
| Cakupan dampak | Zona ketersediaan europe-west2-b di region europe-west2 |
| Penyebab | Gangguan pasokan listrik; pihak resmi tidak memberikan detail lebih lanjut |
| Waktu mulai | 20 Oktober 2026, pukul 14.08 waktu Beijing |
| Waktu berakhir | 20 Oktober 2026, pukul 22.00 waktu Beijing; berlangsung selama 7 jam 52 menit |
| Tidak terdampak | Looker Studio |
Apa bedanya zona ketersediaan dan region?
Saat melihat kabar “pemadaman di London”, banyak orang langsung mengira seluruh Google Cloud di London tumbang. Padahal tidak demikian. Region (europe-west2) bisa dibayangkan sebagai sekumpulan pusat data milik Google di London. Zona ketersediaan (europe-west2-a, b, dan c) adalah beberapa gedung yang terpisah di dalam kumpulan pusat data tersebut. Setiap zona dirancang memiliki pasokan listrik dan jaringan sendiri, sehingga saat satu gedung bermasalah, gedung lainnya masih bisa mengambil alih. Kali ini, satu dari tiga zona padam, sementara dua lainnya tetap online.
Jadi, yang paling terdampak adalah tim yang hanya menempatkan layanannya di zona b. Tim yang layanannya sudah tersebar di zona a dan c dapat mengalihkan lalu lintas ke zona yang masih aktif, sehingga dampaknya jauh lebih kecil. Mereka yang hanya memanggil API model dari jarak jauh nyaris tidak merasakan pemadaman ini.
Melihat kedua gangguan secara berdampingan
| Aspek perbandingan | Google Cloud London | DeepSeek |
|---|---|---|
| Waktu (Beijing) | 20 Oktober 2026, pukul 14.08 hingga 22.00 | 15 Oktober 2026, pukul 08.11 hingga 13.04 |
| Durasi | 7 jam 52 menit | 4 jam 52 menit |
| Layanan yang terdampak | Komputasi, penyimpanan, basis data, dan jaringan di europe-west2-b | Situs web, layanan percakapan, serta API V4 Pro dan V4.1 Flash |
| Penyebab | Gangguan pasokan listrik; tidak ada detail lebih lanjut | Tidak diumumkan pihak resmi |
| Tindakan setelah kejadian | Pihak resmi menyarankan migrasi ke zona ketersediaan atau region lain jika memungkinkan | Pemakaian dari 8 hingga 14 Oktober dikembalikan dalam bentuk kredit |
| Dampak bagi pengguna yang hanya memanggil API model | Tidak terdampak langsung | Terdampak langsung; tanpa layanan cadangan, hanya bisa menunggu |
Jika dibandingkan, perbedaannya jelas: insiden Google berdampak pada mereka yang menempatkan mesin di zona b; solusinya adalah deployment lintas zona ketersediaan. Insiden DeepSeek berdampak pada mereka yang hanya terhubung ke satu model; solusinya adalah menyiapkan model cadangan sejak awal. Yang pertama berkaitan dengan pusat data, sedangkan yang kedua berkaitan dengan pemanggilan model. Bagian selanjutnya membahas yang kedua.
Pelajaran dari Gangguan Kali Ini
Satu layanan bisa saja tumbang, jadi siapkan jalur kedua dan ketiga sejak awal. Sebaiknya, jalur-jalur ini tidak bergantung pada penyedia yang sama. Beralih ke paket yang lebih murah dari penyedia yang sama bukanlah rencana cadangan. Kalau seluruh penyedia bermasalah, kedua paket itu bisa ikut tumbang.
Ada aturan soal kapan harus beralih: ganti model hanya untuk error 429, 500, 502, 503, 504, dan timeout. Error-error ini menandakan pihak penyedia sedang kewalahan, jadi mencoba model lain berpeluang berhasil. Jangan beralih untuk error 401, 403, atau penolakan keamanan konten. Masalahnya ada pada kunci API atau kontennya sendiri, jadi sepuluh model berbeda pun akan tetap menolak. Satu hal lagi yang perlu dibedakan: model cadangan tidak akan membantu jika database dan penyimpanan yang Anda kelola sendiri berada di zona ketersediaan yang sedang offline. Untuk mengatasinya, pertimbangkan penerapan lintas zona ketersediaan. Cadangan model dan pemulihan bencana di pusat data adalah dua hal berbeda, jangan dicampuradukkan.
Setelah cadangan siap, jangan dibongkar begitu gangguan berakhir. Cadangan tidak mengirim permintaan tambahan saat tidak digunakan. Jika model utama berhasil sekali jalan, model cadangan tidak akan dipakai. Namun, saat gangguan berikutnya terjadi, cadangan akan aktif otomatis tanpa perlu mengubah kode tengah malam. Sebelum mulai, kirim satu permintaan paling sederhana ke setiap model untuk memastikan nama model sudah benar dan responsnya normal. Setelah itu, barulah susun alur penggunaannya. Gaya jawaban tiap model bisa berbeda. Jika format keluaran penting bagi bisnis Anda, tetapkan formatnya secara spesifik di petunjuk system agar perbedaan setelah beralih model tidak terlalu terasa.
Menentukan pengaturan untuk alur cadangan
Sekadar tahu bahwa sistem harus beralih saat gagal belum cukup. Jika beralih terlalu cepat atau terlalu lambat, masalah bisa muncul. Berikut beberapa hal yang paling sering ditanyakan. Tidak ada jawaban baku, jadi sesuaikan dengan kebutuhan bisnis Anda.
| Pengaturan | Saran | Alasannya |
|---|---|---|
| Berapa kali mencoba ulang model yang sama | Maksimal 1 kali, lalu beralih ke model berikutnya jika masih gagal | Saat penyedia sedang bermasalah, mencoba model yang sama berulang kali biasanya hanya membuat Anda mengantre sekali lagi |
| Berapa lama menunggu satu permintaan | Lebih singkat untuk percakapan, lebih lama untuk pembuatan teks panjang | Jika menunggu terlalu lama, pengguna bisa menutup halaman sebelum sistem sempat beralih |
| Apa yang dilakukan saat menerima error 429 | Tunggu satu atau dua detik, lalu beralih | Pembatasan laju terkadang hanya terjadi karena lonjakan sesaat dan segera mereda |
| Berapa lama maksimal menunggu seluruh alur | Total waktu untuk ketiga tingkatan tidak boleh melebihi waktu tunggu yang bisa diterima pengguna | Mencegah permintaan terus tertahan jika ketiga model sama-sama lambat |
| Log apa yang perlu dicatat | Model mana yang berhasil atau gagal, serta kode error-nya | Agar setelah kejadian, Anda bisa mengetahui penyedia mana yang bermasalah dan apakah urutannya perlu diubah |
| Kapan harus memberi peringatan | Saat proporsi penggunaan model cadangan tiba-tiba meningkat | Pengguna mungkin tidak menyadari bahwa cadangan sudah aktif. Tim Anda juga bisa luput menyadarinya, jadi harus ada yang tahu bahwa model utama sedang bermasalah |
Poin terakhir paling mudah terlewat. Semakin baik sistem cadangan bekerja, semakin tidak terasa pula saat model utama bermasalah. Jika tidak ada yang memeriksa log, model utama bisa saja sudah bermasalah seharian sementara semua orang mengira semuanya normal—padahal tagihan sudah membengkak karena banyaknya pemanggilan model cadangan.
Ganti Model Tak Perlu Ganti Key
Yang paling dikhawatirkan saat menyiapkan model cadangan adalah perubahan yang terlalu rumit. Kalau setiap model mengharuskan kita membuat akun terpisah, mengganti alamat, dan mengubah format permintaan, kebanyakan tim akan menundanya sampai masalah berikutnya terjadi.
Cara APIYI sederhana: gunakan alamat yang sama, https://api.apiyi.com/v1/chat/completions, dan Key yang sama. Cukup ubah model di badan permintaan. Model utama menggunakan claude-opus-5-5. Jika gagal, beralih ke claude-sonnet-5-5, lalu ke gemini-4-argon jika masih gagal. Dua model pertama berasal dari penyedia yang sama, sedangkan model ketiga berasal dari penyedia lain. Jadi, jika satu penyedia mengalami gangguan, masih ada jalur lain. Perubahannya pun minim: cukup tambahkan daftar nama model yang dicoba secara berurutan di kode aplikasi. Format permintaan, metode autentikasi, dan struktur respons tidak perlu diubah, sehingga pengujiannya juga mudah.
| Urutan | Nama model | Harga input | Harga output | Peran |
|---|---|---|---|---|
| 1 | claude-opus-5-5 | 4 | 20 | Model utama |
| 2 | claude-sonnet-5-5 | 2 | 10 | Cadangan pertama, versi lebih murah dari penyedia yang sama |
| 3 | gemini-4-argon | 2 | 10 | Cadangan kedua, dari penyedia lain |
| Bisa diganti | gpt-6-astra | 10 | 50 | Cadangan yang lebih mahal, hanya melalui antarmuka OpenAI |
| Bisa diganti | deepseek-v4.1-flash | 0.30 | 1.20 | Cadangan yang lebih murah |
Harga pada tabel di atas dalam dolar AS per satu juta token, berdasarkan halaman harga per 2026-10-21 dengan pengali 1. Harga dapat berubah. Silakan merujuk ke halaman harga di api.apiyi.com.
Siapkan Model Cadangan dalam Tiga Langkah
Langkah pertama, dapatkan Key. Daftar di api.apiyi.com dan buat satu Key. Biayanya dihitung berdasarkan pemakaian, dan layanan bisa diakses langsung dari Indonesia tanpa perlu kartu kredit luar negeri. Satu Key ini bisa digunakan untuk memanggil semua model di tabel.
Langkah kedua, uji setiap model. Isi alamat antarmuka dengan https://api.apiyi.com/v1. Formatnya kompatibel dengan antarmuka OpenAI, jadi jika kode Anda sebelumnya menggunakan pustaka resmi OpenAI, cukup ganti alamat dan Key. Gunakan petunjuk yang sama untuk menguji claude-opus-5-5, claude-sonnet-5-5, dan gemini-4-argon satu per satu. Pastikan semuanya mengembalikan respons dengan benar dan formatnya sesuai harapan.
Langkah ketiga, atur urutannya lalu lakukan simulasi. Masukkan nama ketiga model ke konfigurasi sesuai urutan, lalu tentukan kapan harus beralih dengan mengikuti aturan di bagian sebelumnya. Setelah selesai, jangan langsung meluncurkannya. Atur waktu tunggu model utama menjadi sangat singkat untuk sementara, lalu sengaja buat model itu mengalami timeout. Pastikan permintaan beralih ke model cadangan berikutnya dan peralihan tersebut tercatat di log. Setelah simulasi berhasil, barulah jalur cadangan ini benar-benar siap. Untuk parameter lebih lanjut, lihat dokumentasi integrasi di docs.apiyi.com.
Menentukan Urutan untuk Berbagai Jenis Bisnis
Urutan yang digunakan dalam artikel ini mengutamakan kualitas, tetapi bukan satu-satunya pilihan. Urutan model utama bisa disesuaikan dengan kebutuhan bisnis.
| Jenis bisnis | Urutan yang disarankan | Alasan |
|---|---|---|
| Pemrograman dan penalaran kompleks | claude-opus-5-5 → claude-sonnet-5-5 → gemini-4-argon | Mengutamakan kualitas; ini urutan default dalam artikel |
| Layanan pelanggan dan percakapan sehari-hari | claude-sonnet-5-5 → gemini-4-argon → deepseek-v4.1-flash | Volume pemanggilan tinggi dan sensitif terhadap harga, jadi model utama tidak harus yang paling mahal |
| Penerjemahan massal dan peringkasan | deepseek-v4.1-flash → gemini-4-argon → claude-sonnet-5-5 | Volume pemakaian tinggi; mulai dari model yang lebih murah, lalu naik ke model berikutnya jika gagal |
| Output dengan persyaratan format ketat | Dahulukan dua model dari penyedia yang sama, lalu tempatkan penyedia lain di urutan terakhir | Model dari penyedia yang sama biasanya memiliki gaya yang lebih serupa, sehingga peralihannya tidak terlalu terasa |
Ada dua prinsip dalam menentukan urutan: usahakan model terakhir berasal dari penyedia lain, dan sesuaikan harga model dengan nilai tugas yang dikerjakan. Baris penerjemahan massal juga menunjukkan manfaat model cadangan. Jika DeepSeek yang berada di urutan pertama mengalami gangguan pada 15 Oktober, permintaan akan otomatis beralih ke dua penyedia berikutnya dan tugas tetap berjalan.
Perlu dipahami bahwa pergantian model menjaga agar “pemanggilan model tetap berjalan”, tetapi tidak bisa memperbaiki pemadaman listrik di pusat data.
Penyedia di Hulu Bisa Mengalami Gangguan, Siapkan Jalur Alternatif
Contoh yang sudah dipublikasikan adalah gangguan resmi DeepSeek pada 2026-10-15. Saat itu, APIYI beralih ke kanal versi penuh Volcengine. Nama model tidak perlu diubah, dan lingkungan produksi kembali normal. Sumber: pembaruan real-time di docs.apiyi.com.
Penyedia di hulu bisa mengalami gangguan, dan itu bukan kesalahan siapa pun. Menyiapkan jalur alternatif lebih berguna daripada menunggu tanpa kepastian selama berjam-jam. Persiapannya hampir tidak memerlukan biaya atau tenaga jika dilakukan sebelum masalah terjadi. Kalau baru dikerjakan setelah gangguan, Anda harus mengubah sistem sambil terburu-buru.
Saat Gangguan Terjadi, Periksa Tiga Hal Ini
Jika permintaan tiba-tiba banyak yang gagal, jangan buru-buru mengubah kode. Luangkan dua menit untuk memeriksa tiga hal: pertama, Google Cloud Service Health untuk memastikan apakah ada masalah di tingkat pusat data; kedua, halaman status resmi penyedia model terkait, seperti halaman status DeepSeek dalam kejadian ini; ketiga, pembaruan langsung di docs.apiyi.com. Jika ada perubahan pada rute hulu APIYI, informasinya akan dicantumkan di sana.
Jika ketiganya menunjukkan kondisi normal, baru periksa sistem Anda sendiri: apakah Key sudah kedaluwarsa, apakah saldo mencukupi, serta apakah ada masalah dengan koneksi keluar jaringan atau DNS. Jika urutannya dibalik, Anda bisa menghabiskan banyak waktu mencari masalah di kode sendiri, lalu baru menyadari bahwa gangguannya berasal dari penyedia di hulu.
Empat Hal yang Bisa Diselesaikan Hari Ini
- Buat daftar semua titik dalam bisnis yang memanggil model, lalu periksa mana yang hanya terhubung ke satu penyedia.
- Untuk setiap titik yang hanya terhubung ke satu penyedia, tambahkan setidaknya satu model cadangan dari penyedia lain.
- Ikuti aturan di atas: lakukan peralihan hanya untuk respons 429, 5xx, dan timeout, lalu catat setiap peralihan di log.
- Sengaja buat model utama mengalami timeout satu kali untuk memastikan permintaan benar-benar beralih ke model cadangan.
Setelah empat hal ini selesai, saat terjadi gangguan berikutnya—baik karena pusat data mati listrik maupun penyedia model terputus—aplikasi Anda paling-paling hanya melambat beberapa detik, bukan berhenti selama setengah hari.
Pertanyaan Umum
Q1: Setelah terjadi pemadaman listrik di Google Cloud London, apakah kita harus segera pindah dari London?
Belum tentu. Anjuran resmi menyebut “jika memungkinkan”, bukan mengharuskan semua orang segera pindah. Tim dengan beban kerja di europe-west2-b bisa mempertimbangkan untuk pindah ke zona atau region lain. Tim yang hanya memanggil API model tidak perlu pindah; cukup siapkan model cadangan terlebih dahulu.
Q2: Apakah mengganti model akan membuat biayanya lebih mahal?
Dengan urutan di atas, biayanya justru lebih murah. Harga input dan output model utama claude-opus-5-5 masing-masing 4 dan 20, sedangkan kedua model cadangan masing-masing 2 dan 10. Biaya baru meningkat jika Anda memasukkan model seperti gpt-6-astra, yang harga input dan outputnya 10 dan 50, ke dalam daftar cadangan.
Q3: Bisakah satu Key digunakan untuk memanggil model dari beberapa penyedia ini?
Bisa. Semua model ini menggunakan alamat yang kompatibel dengan OpenAI. Anda hanya perlu menggunakan Key yang sama dan mengubah `model`. Namun, gpt-6-astra hanya bisa digunakan melalui antarmuka OpenAI, jadi perhatikan hal ini saat menggunakannya.
Q4: Apakah kualitas jawaban akan menurun saat beralih ke model cadangan?
Kualitasnya mungkin berbeda, terutama saat beralih dari model terbaik ke versi yang lebih murah. Namun, bagi kebanyakan bisnis, jawaban yang sedikit lebih lambat dan kurang bagus masih lebih baik daripada langsung menerima pesan error. Untuk kebutuhan dengan persyaratan format ketat, tetapkan format output secara spesifik dalam petunjuk system. Anda juga bisa membandingkan output dari beberapa model lebih awal dengan metode pada langkah kedua agar tahu hasilnya sebelum meluncurkan sistem.
Q5: Apakah model cadangan tetap menambah biaya saat tidak ada gangguan?
Tidak. Dengan penagihan berdasarkan pemakaian, Anda hanya membayar permintaan yang benar-benar dikirim. Jika model utama berhasil, model cadangan tidak akan dipanggil dan tidak menimbulkan biaya. Biaya yang perlu diperhitungkan hanya waktu untuk integrasi dan beberapa permintaan uji coba saat simulasi.
Inti Utama
- Dua gangguan: Google Cloud europe-west2-b mengalami pemadaman listrik selama 7 jam 52 menit; DeepSeek mencatat gangguan resmi selama 4 jam 52 menit.
- Batasan fakta: Tidak seluruh Eropa mengalami gangguan, dan modelnya sendiri tidak berhenti beroperasi karenanya. DeepSeek tidak mengumumkan penyebabnya.
- Kapan harus beralih: Beralih hanya untuk respons 429, 500, 502, 503, 504, dan timeout. Jangan beralih untuk 401, 403, atau penolakan terkait keamanan konten.
- Cara melakukannya: Sebaiknya model cadangan berasal dari penyedia lain. Gunakan alamat dan Key yang sama, lalu ubah
model. - Pengujian: Setelah integrasi selesai, sengaja buat model utama mengalami timeout satu kali. Pastikan permintaan beralih ke model cadangan dan peralihannya tercatat di log.
Kredit pengembalian bisa membantu membayar tagihan, tetapi tidak bisa mengganti pekerjaan yang terhenti. Atur urutan model dari sekarang. Jika penyedia di hulu mengalami masalah nanti, pengguna paling-paling hanya merasakan aplikasi sedikit lebih lambat.
Referensi
- Google Cloud Service Health: Insiden pada beberapa layanan di europe-west2 (Xs2XTHzAVC9YnafnPyzj), 2026-10-20
- Google Cloud Service Health: Insiden pada produk keamanan Google SecOps di europe-west2 (dicatat terpisah), 2026-10-20
- BBC: Laporan tentang gangguan Google Cloud yang berdampak pada bank dan layanan publik di Inggris, 2026-10-20
- Halaman status resmi DeepSeek: Catatan gangguan layanan pada 2026-10-15
- Dokumentasi resmi: Pembaruan langsung di docs.apiyi.com
Penulis: Tim Teknologi APIYI
Diskusi teknis: Jika Anda mengalami kendala saat menyiapkan model cadangan, silakan tinggalkan komentar untuk berdiskusi.
