Laporan Insiden Google Cloud – 2025-06-13

• Pada 12 Juni 2025, terjadi peningkatan global pada error 503 untuk permintaan API eksternal di layanan Google Cloud dan Google Workspace
• Penyebab error adalah perubahan kode pada sistem Service Control dan penerapan kebijakan yang salah yang menyertakan field kosong dalam data kebijakan
• Penanganan error yang tidak memadai pada biner inti dan tidak diterapkannya feature flag memperparah penyebaran masalah
• Pemulihan memakan waktu 2–3 jam, dan region us-central-1 mengalami waktu pemulihan lebih lama karena kelebihan beban infrastruktur
• Google mengumumkan langkah pencegahan agar tidak terulang, seperti pemisahan arsitektur, peningkatan penanganan error, dan penguatan validasi data

---

Gambaran umum insiden

Ringkasan gangguan layanan Google Cloud dan Google Workspace

• Mulai 12 Juni 2025 pukul 10:49 pagi (PDT), banyak layanan termasuk Google Cloud, Google Workspace, dan Google Security Operations mengalami lonjakan error 503 untuk permintaan API eksternal
• Google menyampaikan permintaan maaf yang mendalam atas dampak serius terhadap layanan pelanggan dan kepercayaan pengguna
• Control plane manajemen dan kontrol API Google menangani pemeriksaan kebijakan dan kuota untuk setiap permintaan, dan sistem pemeriksaan inti berjalan sebagai biner bernama Service Control

Analisis penyebab insiden

Perubahan struktur sistem – Service Control

• Pada 29 Mei 2025, fitur baru untuk memperkuat pemeriksaan kebijakan kuota ditambahkan ke Service Control
• Peluncuran dilakukan bertahap per region, tetapi kode yang bermasalah hanya berjalan ketika kebijakan benar-benar diterapkan, sehingga sebelumnya tidak terpicu dan pengujian awal menjadi tidak memadai
• Jalur fitur baru tersebut tidak memiliki penanganan error dan feature flag yang memadai, sehingga biner mengalami crash berantai dalam situasi null pointer

Kronologi terjadinya insiden

• Pada 12 Juni 2025 pukul 10:45 pagi (PDT), perubahan kebijakan dimasukkan ke tabel Regional Spanner
• Data kebijakan ini berisi field kosong (Blank Field) yang tidak diinginkan, dan direplikasi hampir secara real-time ke seluruh dunia
• Saat Service Control memproses kebijakan ini, terjadi crash akibat null pointer, dan instance di tiap region secara global masuk ke Crash Loop
• Dalam 2 menit tim SRE mulai menyadari masalah, dalam 10 menit penyebabnya teridentifikasi lalu jalur biner diblokir sementara (red-button), dan dalam 40 menit sebagian besar region telah pulih

Isu pemulihan tambahan

• Beberapa region besar (us-central-1) mengalami kelebihan beban infrastruktur (tabel Spanner) akibat herd effect saat task Service Control dimulai ulang
• Service Control tidak menerapkan randomized exponential backoff, sehingga beban infrastruktur makin berat
• Pemulihan di region tersebut tertunda hingga 2 jam 40 menit; dampak diminimalkan melalui pengalihan trafik, dan secara keseluruhan pemulihan layanan selesai dilakukan

Dampak ke pelanggan dan cakupan insiden

• Pelanggan mengalami gangguan akses API dan antarmuka pengguna, sementara streaming dan resource IaaS tidak terdampak
• Dampak latensi dan backlog berlanjut lebih dari 1 jam pada sebagian layanan
• Daftar produk Google Cloud dan Google Workspace yang terdampak disajikan secara luas
  • Contoh: IAM, Cloud Build, Cloud Storage, BigQuery, AppSheet, Gmail, Google Drive, dan puluhan layanan lainnya

Rencana perbaikan ke depan

• Memodularisasi arsitektur layanan untuk memisahkan tiap fungsi dan menerapkan penanganan terbuka saat gagal (fail open) ketika insiden terjadi
• Menyebarkan replikasi data global secara bertahap serta memperkuat proses validasi yang nyata
• Merevisi kebijakan agar setiap perubahan pada biner utama selalu dibungkus dengan feature flag dan dinonaktifkan secara default
• Meninjau desain agar memungkinkan fail open saat insiden melalui analisis statis dan peningkatan pengujian untuk deteksi error
• Akan memperkuat kebijakan randomized exponential backoff serta keandalan monitoring/komunikasi
• Menyempurnakan redundansi infrastruktur dan komunikasi otomatis agar monitoring dan penyampaian informasi ke pelanggan tetap cepat saat insiden terjadi

Pemberitahuan insiden dan komunikasi

• Dalam waktu 1 jam setelah kejadian, pemberitahuan dipasang di Cloud Service Health, tetapi infrastruktur monitoring itu sendiri juga mengalami gangguan
• Sebagian pelanggan kesulitan menangkap sinyal insiden dan memahami dampaknya karena sistem monitoring berbasis Google Cloud mereka sendiri tidak berfungsi normal
• Google berjanji akan memperkuat infrastruktur monitoring dan komunikasi ke pelanggan ke depan

Timeline utama insiden (ringkasan mini report)

• Awal insiden: 12 Juni 2025 10:49 (PDT)
• Sebagian besar region pulih: 12 Juni 2025 12:48 (PDT)
• Insiden berakhir: 12 Juni 2025 13:49 (PDT)
• Total durasi: sekitar 3 jam
• Wilayah terdampak: global

Ringkasan langkah pascainsiden

• Akan disiapkan mekanisme pencegahan kegagalan saat terjadi error atau kerusakan data pada platform manajemen API
• Validasi, pengujian, dan monitoring akan diperkuat sebelum propagasi metadata global
• Penanganan error sistem dan pengujian menyeluruh untuk data yang tidak valid akan diperluas

Daftar layanan terdampak (cuplikan)

Layanan utama Google Cloud

• Identity and Access Management, Cloud Build, Google Cloud Storage, Cloud Monitoring, BigQuery, Vertex Gemini API, Cloud Firestore, Looker, Cloud Run, Compute Engine, dan lainnya

Layanan utama Google Workspace

• AppSheet, Gmail, Google Drive, Google Meet, Docs, Chat, Calendar, dan lainnya

Kesimpulan

• Insiden ini merupakan hasil gabungan dari masalah pada struktur sistem manajemen kebijakan/kuota, kurangnya validasi integritas data, dan tidak adanya mekanisme penanganan error
• Google berjanji melakukan perbaikan pada level arsitektur serta memperkuat kemampuan respons terhadap insiden

[kunggom]

Ini tautan ke versi artikel yang bukan GN+.

• https://id.news.hada.io/topic?id=21447

[GN⁺]

Opini Hacker News

• Saya orang dalam dan sedang memakai akun sementara; akar penyebab insiden ini adalah kepemimpinan mengabaikan prinsip demi mempercepat laju, praktik seperti ini berlangsung bertahun-tahun dan akhirnya mencapai batasnya. ‘Query of death’ yang terjadi kali ini adalah jenis kegagalan yang sangat khas dan nyaris tak terelakkan pada server C++ lama yang crash karena kueri tertentu. Service Control ditulis dalam C++ dan telah berupaya meminimalkan kegagalan semacam ini dengan berbagai pedoman engineering. Selama 10 tahun layanan ini beroperasi tanpa insiden besar, tetapi kebijakan kuota global yang baru-baru ini dibuat dengan tergesa-gesa di bawah tekanan kepemimpinan menjadi sumber masalah. Fitur baru seperti ini seharusnya dikembangkan sebagai layanan terpisah, atau setidaknya mengikuti pedoman yang sudah ada. Standar yang selama ini dijaga tim jauh lebih tinggi daripada langkah perbaikan yang disebutkan dalam laporan resmi. Tim berusaha mempertahankan standar lama sebisa mungkin.

  • Tidak semua tanggung jawab bisa dibebankan hanya pada kepemimpinan. Tidak meninjau deployment dengan radius global secara sangat hati-hati juga merupakan kegagalan budaya engineering. Setidaknya, kebijakan global seharusnya diterapkan lebih dulu daripada deployment service control per regional.

• Menurut saya laporan insidennya menarik. Tim SRE merespons cepat dalam 2 menit, dan rollout ‘red button’ pun dimulai. Masalahnya, ketika task Service Control restart di region besar seperti us-central-1, muncul ‘herd effect’ yang membebani infrastruktur secara berlebihan, khususnya tabel Spanner. Karena Service Control tidak memiliki random exponential backoff, pemulihan penuh tertunda hingga 2 jam 40 menit. Dalam situasi seperti ini kuota normal cepat terlampaui dan memicu gangguan baru. Jika infrastrukturnya sanggup menahan, menurut saya ada baiknya kuota dihentikan sementara atau pekerjaan pemulihan dibatasi agar berjalan lebih lambat.

  • Dalam situasi ini exponential backoff bukan langkah yang tepat. Saat server mulai dan membaca data penting, penanganannya memang sengaja dilakukan tanpa retry, jadi backoff tidak akan diterapkan. Cara yang lebih baik adalah cepat mendistribusikan beban ke database cadangan yang memang sudah ada. Ada juga cara lain.

• Ini terasa seperti kesalahan yang benar-benar amatir. NPE, tidak ada error handling, tidak ada exponential backoff, tidak ada test coverage, tidak ada pengujian di staging, tidak ada rollout bertahap—semuanya kegagalan serius. Semua ini sudah tertulis di buku SRE: daftar isi Google SRE Book, Building Secure and Reliable Systems TOC. Saya jadi bertanya-tanya apakah standarnya memang sudah turun sejauh ini atau buku-buku itu cuma materi pemasaran.

  • Menurut saya, baik manusia maupun otomasi tidak pernah punya pertahanan yang sempurna; pada akhirnya semuanya adalah rangkaian trade-off. Sebanyak apa pun unit test, integration test, static analysis, dan rollout berurutan yang dilakukan, pada skala besar celah tak terduga tetap bisa muncul. Alasannya sama seperti yang dijelaskan buku itu tentang “upaya yang jauh lebih besar untuk menambah satu angka 9 lagi”. Dalam skenario terburuk, mungkin perlu menggandakan seluruh stack dan memutar ulang traffic selama berbulan-bulan, dan biaya/manfaat pada level seperti itu tidak akan sanggup ditanggung siapa pun. Dalam pekerjaan OpenZFS pun saya pernah melihat kode yang tampak baik-baik saja tetapi masalahnya baru muncul pada edge case data yang ditulis 10 tahun lalu. Ketika sistem menjadi cukup kompleks, menguji semua variasi menjadi mustahil, jadi pada praktiknya keputusan tetap harus didasarkan pada cost-benefit. Sebagai catatan, saya SRE di Google tetapi bukan dari tim yang terkait insiden ini, dan ini pendapat pribadi saya.

  • Hampir semua outage global Google berkembang dengan pola seperti ini: sistem kustom yang diluncurkan cepat secara global menerima konfigurasi yang salah. Pada rollout binary atau config push biasa, rollout bertahap umumnya diterapkan. Di Google Cloud dulu juga banyak sistem yang terikat secara global, tetapi sekarang sudah jauh lebih terlokalisasi dan lebih andal. Dulu outage global juga sering terjadi, tetapi tidak dipublikasikan sehingga kebanyakan pengguna mengira itu masalah ISP mereka. Saya tidak merasa keadaan saat ini secara khusus lebih buruk. Tambahan konteks, saya juga punya pengalaman SRE.

  • Dari sudut pandang orang luar, setelah PHK besar-besaran, pernyataan CEO soal ‘kemalasan’, dan sebagainya, semua orang jadi lebih fokus pada kecepatan dan hasil yang terlihat daripada kualitas. Perlahan muncul perubahan budaya di mana orang yang mempermasalahkan hal seperti ini justru tersisih.

  • Saya berharap detail yang lebih lengkap dipublikasikan. Menurut saya, masalahnya bukan seperti yang disebutkan di sini bahwa tidak ada pengujian sama sekali, melainkan tidak ada pengujian untuk field kosong dalam policy, yaitu input yang bermasalah itu. Juga tidak ada penjelasan bahwa tidak ada pengujian di staging; justru disebutkan bahwa kalau ada flag, hal ini kemungkinan akan tertangkap. Ini pendapat pribadi.

  • Ini mengingatkan saya pada laporan gudang mesiu tahun 1864: “bahkan alat yang paling berbahaya pun, ketika sudah terbiasa digunakan, membuat orang kehilangan kehati-hatian dan menganggap aturan itu terlalu ketat tanpa perlu.”

• Saya berasal dari tim lain di Cloud. Secara umum, semua kode memiliki unit test dan integration test. Perubahan binary atau konfigurasi dilakukan bertahap per tugas dan per region selama beberapa hari, disertai analisis canary. Bahkan rollback pun dilakukan pelan-pelan karena jika terlalu terburu-buru justru bisa memperburuk keadaan. Misalnya, kami menilai pemadaman 40 menit lebih baik daripada gangguan 4 jam jika alternatifnya adalah membebani database global sekaligus. Saya tidak terlibat langsung dalam insiden ini, tetapi dari PM tampaknya kodenya memang diuji, hanya saja edge case ini terlewat. Masalahnya adalah konfigurasi kebijakan kuota diterapkan bukan sebagai binary atau file konfigurasi, melainkan sebagai update database yang menyebarkan perubahan ke semua database di seluruh dunia dalam hitungan detik. Soal null pointer, di bahasa lain pun kemungkinan bisa terjadi lewat assert(). Dibandingkan risiko menulis ulang layanan inti seperti ini ke bahasa lain, menurut saya jauh lebih masuk akal untuk memasang flag guard pada semua pemeriksaan policy, membuat pemeriksaan quota policy bersifat fail-open, dan menyebarkan perubahan DB secara perlahan per region. Ini pendapat pribadi.

  • assert adalah sesuatu yang secara kebijakan jauh lebih mudah dilarang.

  • Kalau kodenya diuji tetapi edge case ini terlewat, bukankah itu pada akhirnya tetap berarti tidak diuji?

  • Hanya karena perubahan DB bukan perubahan binary atau konfigurasi tidak berarti sifat masalahnya berbeda. Jika perubahan itu menyebar secara global pada saat yang sama, apa pun jenisnya, itu tetap benih bencana. Polanya persis seperti insiden Crowdstrike.

  • Jika pendapatnya adalah “menulis ulang dengan bahasa lain terlalu berisiko”, saya jadi bertanya apakah itu berarti kebutuhan layanannya belum benar-benar dipahami, atau layanannya tidak cukup penting untuk layak mendapat migrasi yang hati-hati.

• Intinya binary crash karena null pointer tanpa error handling yang layak. Pada titik ini, wajar kalau orang melontarkan lelucon tentang ‘kesalahan triliunan dolar’.

  • Saya penasaran berapa banyak SLA tahunan yang hangus gara-gara insiden ini.

  • Saya jadi berpikir andai ada bahasa yang bisa mencegah masalah seperti ini. /s

• Service Control (Chemist) adalah layanan yang sudah cukup tua dan memainkan peran inti dalam autentikasi, otorisasi, pemantauan, kuota, dan lain-lain di banyak API GCP. Dalam alur request, sebagian besar API GCP melewati Chemist, sehingga saya rasa mitigasi fail-open tidak terlalu efektif. Baik Chemist maupun proxy ditulis dalam C++, dan banyak legacy code yang menumpuk selama bertahun-tahun. Tiap tim memiliki static analysis, test, rollout bertahap, feature flag, red button, serta sistem monitoring dan alert yang kuat. Tim SRE khususnya sangat bagus. Karena Chemist memverifikasi beragam policy seperti IAM dan kuota, banyak tim berkontribusi ke codebase ini. Agar tidak perlu melewati proses persetujuan Chemist setiap kali mengubah sesuatu, makin banyak bagian yang dikembangkan lewat jalur pintas. Belakangan ini, karena banyak reorganisasi dan offshore, fokusnya lebih ke proyek baru yang mencolok dan dipimpin level L8/L9, sementara kualitas, pemeliharaan, dan keandalan justru turun prioritasnya; saya meninggalkan Cloud karena perubahan budaya seperti ini. Best practice server/layanan umum di Google sendiri sering tidak diikuti di sini. Isu kali ini lebih dekat ke lemahnya kode dan code review: kode cacat disetujui, lalu perubahan konfigurasi langsung dipropagasikan lewat Spanner sehingga masalah membesar.

• Data service policy berisi field kosong yang tidak disengaja, dan saat Service Control membaca field kosong itu (null) ketika melakukan pengecekan kuota per region, terjadilah exception. Ini contoh lain dari ‘kesalahan miliaran dolar’ ala Hoare yang terulang di berbagai sistem Google. Sejak awal, membiarkan ‘field kosong’ seperti ini bisa masuk sudah merupakan masalah; schema seharusnya secara eksplisit menyatakan null tidak diperbolehkan (NOT NULL). Sayangnya, di Spanner default-nya nullable sehingga harus ditetapkan secara terpisah. Ada peluang lain di level kode aplikasi untuk merancang agar state tidak valid menjadi mustahil lewat type system atau schema language. Bisa juga menambahkan validasi schema yang dipaksakan saat melakukan deserialisasi dari datastore ke objek aplikasi. Mengingat isu utama terjadi di code path baru, saya menduga masalah ini tidak tersaring di lapisan data. Fakta bahwa program Service Control sendiri ditulis dalam bahasa yang memungkinkan null pointer dereference juga merupakan masalah. Jika saya yang bertanggung jawab, saya akan mempertimbangkan rencana intervensi minimal untuk mengubah policy di kode aplikasi menjadi struktur seperti ‘tagged enum type’ yang tidak bisa merepresentasikan null. Proto3 tidak punya batasan seperti itu, tetapi ada contoh seperti ini.

• Multi-region sering disebut sebagai sarana ketahanan dan ketersediaan, tetapi menarik melihat bahwa dalam kondisi outage, bahkan cloud provider besar pun ternyata masih sangat terikat kuat antar-region.

  • Ini terutama menonjol di GCP, karena GCP memperlakukan region secara berbeda dibanding pihak lain. Dari sudut pandang ketahanan, GCP sebaiknya dilihat sebagai satu region tunggal dengan banyak zone yang digabung.

  • Meski begitu, tetap bisa ada “outage yang tidak kita ketahui”, jadi jangan sampai kita terlalu meremehkan manfaat sharding region/zone.

  • Ada juga banyak kasus di mana deployment multi-region justru mencegah insiden, jadi lebih tepat menarik kesimpulan setelah benar-benar melihat contoh-contoh seperti itu.

• Saya selalu kagum pada detail postmortem Google, baik dari dalam maupun dari luar perusahaan. Mereka belajar agar tidak mengulangi kesalahan, memperkuat protokol dan error handling, lalu berkembang menjadi sistem yang lebih tangguh. Di tempat sebesar Google, selalu ada sesuatu yang salah, tetapi yang penting adalah mengisolasinya agar tidak berdampak ke pelanggan, pengguna, atau sistem lain. Bahkan dari dalam pun, tergantung timnya, ada banyak isu yang tidak terlihat. Menurut saya ini termasuk salah satu sistem paling kompleks yang pernah dibuat manusia. Kecuali AGI, saya rasa ini bukan area di mana manusia bisa berbuat jauh lebih baik.

  • Tapi dalam insiden ini terjadi rangkaian kesalahan level junior: gagal menangani data null, kurangnya pengujian, tidak ada test coverage untuk fitur baru, dan tidak memverifikasinya di produksi skala kecil sebelum rollout penuh. Saya yakin di Google 10 tahun lalu, semua orang akan menertawakan kesalahan seperti ini.

  • Dalam pemahaman saya, penyebab outage kali ini adalah 1) fitur global di-rollout ke seluruh dunia sekaligus 2) terjadi null pointer dereference 3) tidak ada kebijakan retry yang memadai sehingga memicu masalah ‘thundering herd’. Semuanya adalah kesalahan yang familiar bagi orang industri. Ini bukan logika distributed systems yang aneh atau rumit, melainkan kombinasi khas dari ‘kesalahan pemula’.

  • Orang bilang “kita tidak akan mengulangi kesalahan yang sama lagi”, tetapi kenyataannya perubahan ini di-rollout tanpa feature flag, klien tidak memiliki exponential backoff, dan server tidak punya load shedding. Semua ini sudah tertulis di google SRE book sejak bertahun-tahun lalu.

  • Error ini adalah masalah null pointer yang tidak tertangkap. Jika perusahaan sekelas Google dengan skala dan kualitas seperti itu bisa menjatuhkan sebagian besar stack dengan cara begini, itu bisa dibaca sebagai sinyal kurangnya langkah pencegahan agar masalah serius tidak terulang.

  • Ini adalah kesalahan yang sama yang sudah berulang kali terjadi. “Fitur baru dideploy dengan hati-hati, tetapi bug baru muncul ketika data baru masuk” adalah kalimat yang merangkum sebagian besar outage global. Sistem sempurna itu tidak ada; satu-satunya yang tanpa cacat dalam perdebatan outage FAANG hanyalah ‘ahli kursi’ di HN.

• Sering kali, saat melihat downtime orang lain, kita gampang mengkritiknya sebagai ‘kesalahan level junior’, tetapi ketika itu terjadi pada pekerjaan kita sendiri, alasannya berubah jadi tak terhindarkan dan tak terduga. Kesalahan manusia tidak bisa dihindari, dan ekspektasinya sendiri terlalu tinggi. Kalau toko offline mendadak tutup pun biasanya cukup dengan satu kata “maaf”. Hanya industri TI yang menjadi sangat stres karena outage beberapa jam; saya berharap semua orang bisa sedikit lebih santai menghadapinya.