Listrik Padam, Zona Google Cloud London Tumbang Berjam-jam

Pada Selasa, 20 Oktober 2026, salah satu zona Google Cloud di London, europe-west2-b, padam total. Penyebabnya listrik: pasokan dari jaringan utilitas terputus, lalu genset cadangan yang seharusnya mengambil alih tidak pernah menyala. Banyak layanan di region London terganggu sejak pagi waktu setempat, dan pemulihan utamanya memakan waktu sekitar enam jam menurut laporan.

Kejadian ini penting karena menyentuh hal yang sering dianggap beres dengan sendirinya: daya cadangan di pusat data. Bagi siapa pun yang menjalankan aplikasi di cloud, termasuk di Indonesia, ada pelajaran soal cara menyusun arsitektur dan rencana pemulihan.

Apa yang terjadi di London?

Region europe-west2 (London) punya tiga zona ketersediaan. Yang tumbang adalah zona b. Di status resminya, Google awalnya hanya menulis bahwa "power event" menyebabkan gangguan di zona europe-west2-b.

Menurut The Register, gangguan pada pelanggan mulai terasa sekitar pukul 06.08 UTC. Menjelang siang Google memperkirakan pemulihan beban kerja yang sudah berjalan selesai sekitar pukul 13.00 UTC, dengan catatan perkiraan itu masih tentatif. Sekitar pukul 14.03 UTC Google menyatakan masalah sudah tertangani untuk sebagian besar pelanggan, meski segelintir pelanggan masih terdampak. Google juga sempat memperingatkan bahwa pelanggan mungkin belum bisa membuat beban kerja baru selama masa pemulihan.

Layanan yang disebut terdampak antara lain:

• BigQuery Data Transfer Service
• Cloud Filestore dan Google Cloud NetApp Volumes
• Cloud Run dan Google App Engine
• Google Kubernetes Engine (GKE)
• Managed Service for Apache Kafka

Seorang akademisi yang dikutip The Register memperkirakan sekitar 38 layanan ikut terganggu. Media itu juga menyebut layanan sejumlah perusahaan besar Inggris ikut kena imbasnya, termasuk Lloyds, HSBC, Royal Mail, dan bank digital Revolut.

Kenapa genset tidak menyala?

Jawabannya baru keluar lewat laporan insiden Google yang diperbarui 4 November 2026 dan diulas The Register sehari kemudian. Kronologinya kira-kira begini.

Fasilitas itu memakai dua jalur listrik utilitas, A dan B, ditambah genset yang dikendalikan PLC (programmable logic controller) ganda. Pada 14 Oktober, uji beban genset rutin per kuartal menemukan masalah, sehingga pemutus jalur B sengaja dibuka untuk perbaikan. Akibatnya seluruh beban kritis ditanggung jalur A.

Pada 20 Oktober, kabel bawah tanah milik penyedia listrik yang memasok jalur A putus. UPS langsung bekerja, tetapi kapasitasnya hanya sekitar lima menit. Di titik inilah genset seharusnya menyala otomatis. Masalahnya, sensor tegangan dipasang di sisi yang keliru dan logika PLC salah dikonfigurasi. PLC "mengira" masih ada sumber listrik utilitas yang sehat, padahal kedua jalur sudah mati. Perintah menyalakan genset tidak pernah dikirim, baterai UPS habis, dan zona padam.

Layanan baru pulih setelah fasilitas tersambung lagi ke listrik utilitas dan pengaturan PLC dibenahi.

Apa yang dijanjikan Google setelahnya?

Menurut The Register, Google menyatakan sudah melakukan perubahan kelistrikan di lokasi dan mengujinya. Ada dua tindak lanjut lain yang disebut: mempercepat pemberitahuan ke pelanggan untuk insiden yang berdampak pada satu lokasi, dan memperluas pengujian di seluruh platform untuk kejadian setingkat infrastruktur.

Laporan insiden itu, seperti dikutip situs pemantau status pihak ketiga, juga menyebut sebagian pelanggan yang beban kerjanya ada di zona lain (europe-west2-a dan europe-west2-c) ikut mengalami masalah tak terduga. Detail ini menarik, karena banyak orang menganggap zona lain otomatis aman.

Pelajaran apa untuk pengguna cloud di Indonesia?

Insiden seperti ini bisa terjadi di penyedia mana pun, besar atau kecil. Yang bisa kamu kendalikan adalah desain di sisimu sendiri.

Jangan taruh semua beban di satu zona. Aplikasi yang hanya berjalan di satu zona akan ikut mati saat zona itu padam. Menyebar instance, node Kubernetes, dan replika database ke minimal dua zona adalah langkah dasar.

Untuk layanan kritis, pertimbangkan region kedua. Dr Amro Al-Said Ahmad dari Keele University, yang dikutip The Register, menyebut ketahanan butuh penyebaran multi-region, beban kerja yang mudah dipindah, dan rencana pemulihan bencana yang sudah diuji. Biayanya memang lebih besar, jadi tentukan dulu layanan mana yang benar-benar tidak boleh mati. Kerangka RPO dan RTO membantu menghitung seberapa lama dan seberapa banyak data yang masih bisa ditoleransi.

Siapkan jalan keluar di level DNS. Kalau ada lokasi cadangan, DNS failover bisa mengarahkan pengunjung ke sana secara otomatis.

Uji, jangan hanya rencanakan. Kasus London memperlihatkan bahwa cadangan yang tidak teruji bisa gagal tepat saat dibutuhkan. Hal yang sama berlaku untuk backup data: uji restore secara berkala dan pastikan ada salinan di luar penyedia utama. Untuk bisnis kecil, langkah-langkahnya dirangkum di strategi disaster recovery untuk server bisnis kecil.

Perhatikan estimasi pemulihan dengan kritis. Newsquawk mencatat bahwa pemulihan beban kerja yang sudah berjalan berbeda dengan pemulihan penuh. Antrean data, pengecekan konsistensi, dan restart layanan yang saling bergantung sering butuh waktu lebih lama dari estimasi awal.

Ringkasnya

Zona europe-west2-b padam bukan karena satu kegagalan, melainkan rangkaian: jalur cadangan sedang diperbaiki, kabel utama putus, lalu genset tidak diperintah menyala. Pemulihan utama memakan waktu sekitar enam jam menurut laporan, dan imbasnya terasa sampai ke bank serta layanan publik di Inggris.