Google Cloud Memublikasikan Detail Insiden GCVE

• Insiden Google Cloud pada Mei 2024 adalah penghapusan sebagian lingkungan GCVE milik pelanggan Australia UniSuper; setelah peninjauan internal, penyebab dan langkah pemulihannya dipublikasikan
• Cakupan dampak terbatas pada satu pelanggan, satu region, satu layanan serta salah satu dari beberapa GCVE Private Cloud milik pelanggan; pelanggan lain dan layanan Google Cloud lainnya tidak terdampak
• Pada proses deployment awal, satu nilai input di tool internal kosong, dan sistem memperlakukannya sebagai periode tetap 1 tahun, sehingga Private Cloud otomatis dihapus setelah periode tersebut berakhir
• Pelanggan dan tim Google menjalankan pemulihan 24x7 selama beberapa hari; backup yang berada di GCS dan software backup pihak ketiga digunakan untuk pemulihan
• Google Cloud mengambil langkah agar insiden sejenis tidak terulang, termasuk menghentikan tool internal tersebut, melakukan pemeriksaan manual atas seluruh GCVE Private Cloud, dan memperbaiki perilaku penghapusan

---

Cakupan insiden

• Insiden ini berdampak pada pelanggan Google Cloud UniSuper, dan Google Cloud menyelesaikan peninjauan internal setelah memulihkan sistem pelanggan
• Dampaknya terbatas berdasarkan layanan yang dikelola Google
  • Satu pelanggan
  • Satu region cloud
  • Penggunaan Google Cloud VMware Engine(GCVE) oleh pelanggan
  • Satu Private Cloud yang tersebar di dua zone dari beberapa GCVE Private Cloud milik pelanggan
• Item yang tidak terdampak juga dibedakan
  • Layanan Google Cloud lainnya
  • Pelanggan lain yang menggunakan GCVE atau layanan Google Cloud lainnya
  • GCVE Private Cloud lain milik pelanggan tersebut, Google Account, Orgs, Folders, Projects
  • Backup data Google Cloud Storage(GCS) di region yang sama

Penyebab: parameter kosong pada tool internal

• Pada awal 2023, operator Google men-deploy salah satu GCVE Private Cloud pelanggan dengan tool internal untuk memenuhi kebutuhan penempatan kapasitas tertentu
• Tool ini digunakan dalam proses pengecualian untuk manajemen kapasitas, lalu dihentikan dan sepenuhnya diotomatisasi pada kuartal IV 2023 sehingga tidak lagi memerlukan intervensi manusia
• Operator mengikuti prosedur kontrol internal, tetapi satu parameter input kosong dalam proses provisioning Private Cloud
• Karena parameter kosong tersebut, sistem menetapkan nilai default yang saat itu tidak diketahui, yaitu periode tetap 1 tahun, pada parameter tersebut
• Setelah periode 1 tahun yang ditetapkan sistem berakhir, GCVE Private Cloud milik pelanggan dihapus

Alasan tidak ada pemberitahuan kepada pelanggan

• Penghapusan ini bukan berasal dari permintaan pelanggan, melainkan dari parameter kosong yang ditinggalkan saat operator Google menggunakan tool internal
• Jika pelanggan meminta penghapusan secara langsung, pemberitahuan sebelumnya akan diberikan, tetapi pada penghapusan kali ini tidak ada pemberitahuan pelanggan yang dikirim
• Google Cloud menjelaskan bahwa mereka telah memperbaiki kondisi yang memicu insiden dan perilaku subsistem agar hal yang sama tidak terjadi lagi

Proses pemulihan

• Pelanggan dan tim Google bekerja sama secara 24x7 selama beberapa hari untuk melakukan pemulihan
  • Pemulihan GCVE Private Cloud pelanggan
  • Pemulihan konfigurasi jaringan dan keamanan
  • Pemulihan aplikasi
  • Pemulihan data untuk memulihkan seluruh operasi
• Pendekatan arsitektur pelanggan yang kokoh dan resilien membantu proses pemulihan
• Backup data yang disimpan di Google Cloud Storage pada region yang sama tidak terdampak penghapusan
• Backup tersebut dan software backup pihak ketiga berperan penting dalam pemulihan cepat

Langkah pencegahan agar tidak terulang

• Google Cloud melakukan beberapa langkah untuk mencegah insiden terulang
  • Menghentikan tool internal yang memicu alur insiden
  • Meski manajemen kapasitas tertentu diperlukan, kini pelanggan mengendalikannya melalui antarmuka pengguna, dan bagian terkait sepenuhnya diotomatisasi
  • Membersihkan database sistem dan meninjau secara manual semua GCVE Private Cloud untuk memastikan deployment GCVE lain tidak terpapar risiko
  • Memperbaiki perilaku sistem dalam workflow deployment tersebut yang menetapkan GCVE Private Cloud sebagai target penghapusan
• Google Cloud menilai bahwa insiden dengan karakter seperti ini belum pernah terjadi sebelumnya dan bukan merupakan masalah sistemik
• Layanan Google Cloud memiliki proteksi berupa kombinasi soft delete, pemberitahuan sebelumnya, dan human-in-the-loop sesuai kebutuhan, dan Google Cloud mengonfirmasi bahwa proteksi tersebut terus dipertahankan
• Kolaborasi erat dengan pelanggan penting untuk pemulihan cepat, dan manajemen risiko yang resilien serta fail-safe untuk menghadapi insiden tak terduga sangat penting bagi pemulihan cepat
• Google Cloud menyatakan bahwa meski ini insiden sekali terjadi, uptime dan resiliensinya termasuk yang tertinggi di antara cloud besar dan telah diverifikasi secara independen

[GN⁺]

Komentar Hacker News

• Melihat skala dampak insiden ini, mengejutkan bahwa langkah perbaikannya tidak lebih mendalam. Yang dilakukan hanya sebatas memastikan masalah yang sama tidak terulang dengan cara yang sama, jadi kalau nanti muncul cacat setara di tempat lain, hasilnya bisa serupa atau lebih buruk
  Misalnya, saat layanan dihentikan seharusnya data tidak langsung dihapus, melainkan disimpan beberapa hari dalam kondisi yang bisa dipulihkan dengan satu tombol, atau alur penghapusan semua layanan diaudit agar pelanggan diberi tahu sebelum penghentian apa pun alasannya, atau penghentian layanan aktif di atas skala tertentu harus melewati tinjauan manual
  Tanpa langkah luas seperti ini, analisis pascakejadian tersebut sama sekali tidak menenangkan. Untuk insiden seabsurd ini, penyedia yang punya sedikit saja kebanggaan pada layanannya atau ingin menjaga reputasi seharusnya menunjukkan upaya berlebihan agar ini tidak pernah terjadi lagi, tetapi Google Cloud tampaknya hanya melakukan yang paling minimal

  • Tidak langsung menghapus data saat layanan dihentikan adalah dasar perangkat lunak enterprise yang begitu jelas, jadi fakta bahwa Google belum punya ini pada 2024 mengatakan banyak hal
    Sejak masih junior pun, gagasan untuk langsung menghapus data yang tidak lagi dibutuhkan terasa tidak masuk akal. Di database, dasarnya adalah memakai soft delete dengan kolom penanda hapus, lalu data di disk dipindahkan atau diganti namanya sampai benar-benar yakin boleh dihapus, dan backup tetap disimpan
  • Sangat setuju. Mereka tampak lebih tertarik menekankan bahwa tidak ada masalah sistemik dalam cara operator GCP mengelola platform, dan justru karena itu tulisan tersebut terasa makin mengisyaratkan adanya masalah sistemik dan jadi meresahkan. Tidak adanya langkah yang masuk akal di analisis pascakejadian membuatnya terlihat seperti mereka tidak berniat memperbaikinya
  • Jika penghapusan nyata diubah menjadi flag hapus, bisa muncul bug menarik lain seperti “Google Cloud melanggar regulasi UE karena gagal menghapus data pelanggan.” Google tampaknya akan memilih penghapusan tak sengaja ketimbang kegagalan menghapus tak sengaja, dan setidaknya di UE itu terdengar masuk akal
  • Tidak melakukan hal seperti ini terasa seperti lelucon. Sulit dipercaya penyedia cloud raksasa tidak terpikir menaruh pengaman pada penghapusan data. Secara realistis, mereka mungkin sudah memikirkannya berkali-kali tetapi tidak menerapkannya karena biaya
  • “Analisis pascakejadian” Google benar-benar sulit dipahami. Siapa pun yang pernah menjalankan layanan online bisa melihat bahwa ini jelas tidak memadai, dan kesimpulannya pun penuh keangkuhan. Nadanya seperti, “Ini insiden satu kali, tidak akan terjadi lagi, kami sangat menyesal, tapi kami hebat dan akan terus hebat,” sehingga sama sekali tidak menebus momen memalukan bagi Google Cloud

• Jika Anda pelanggan GCP dan punya TAM, pertanyaan seperti ini kemungkinan akan membuat mereka tidak nyaman. Tanyakan apa pengaman yang mencegah GCP secara keliru menghapus banyak resource di akun Anda ketika mereka melakukan kesalahan operasional
  Mereka mungkin akan menjawab bahwa masalah spesifik ini telah dimitigasi dengan memensiunkan alat tersebut dan menambah otomatisasi, lalu Anda bisa menindaklanjuti dengan, “Saya tahu itu sudah diperbaiki. Jadi, apakah ada manusia yang meninjau sebelum penghapusan skala besar?”
  Dari sudut pandang saya yang dulu bekerja di GCP dan sudah lebih lama aktif memakai AWS, pengaman berbasis manusia di GCP hampir tidak ada, dan tampaknya jauh lebih sedikit dibanding AWS. Apa pun itu, tetap layak menanyakan risiko nyata ini kepada TAM

  • Tinggal tekan saja lebih keras. Dengan begitu TAM akan belajar menangani sistem internal dengan lebih baik. Mereka mungkin tidak bisa mengubahnya sendirian, tetapi kadang Anda bisa mendapatkan janji jalur eskalasi atau kesepakatan tidak resmi
    Jika cukup banyak TAM bersuara keras, pada akhirnya mungkin seseorang di atas akan bergerak
  • Mungkin akan lebih efektif secara internal jika dibingkai sebagai kesempatan bagi karyawan Google untuk menghubungi saat aset pelanggan akan dihapus dan mencoba retensi pelanggan. Efek sampingnya, semua orang juga jadi diberi tahu dengan jelas bahwa sesuatu akan segera hilang

• Katanya “tim Google bekerja 24x7 selama beberapa hari”, tetapi sepertinya mereka tidak tahu angka 7 di situ artinya apa

  • Mungkin maksudnya 24 engineer bekerja 7 jam sehari. Termasuk pijat dan makanan kantin gratis dari chef
  • Kalau dipahami terlalu harfiah memang agak tidak masuk akal. Tetapi x7 jelas berarti 7 hari seminggu, jadi bekerja dari Kamis sore sampai Selasa pagi pun bisa disebut 24x7. Artinya mereka tidak libur saat akhir pekan
  • Mungkin mereka bekerja terlalu banyak sampai beberapa hari terasa seperti beberapa minggu
  • Kalau pekerjaan mitigasi berlangsung melewati akhir pekan, masih masuk akal juga
  • Bisa juga artinya anggota tim bergiliran sehingga pekerjaan terus berjalan tanpa henti pada malam hari maupun akhir pekan. Secara pribadi, menurut saya untuk proyek besar seperti ini memang seharusnya itu jadi standar

• Wah, saya salah. Saya kira default-nya adalah penghapusan langsung tanpa masa pemulihan, seperti di Terraform, dan ada orang di UniSuper yang salah menentukan cakupan saat menguji penghapusan. Itu tetap masalah default, tetapi saya mengira ini soal alat pihak ketiga dan kesalahan di pihak UniSuper
  Fakta bahwa ini sebenarnya masalah di pihak Google benar-benar gila. UniSuper pasti reaksinya seperti, “Apa-apaan ini?”

  • Di artikelnya dijelaskan apa yang terjadi dan ini tidak ada hubungannya dengan UniSuper. Google menerapkan private cloud dengan alat internal, dan alat internal Google itu disetel agar otomatis terhapus setahun kemudian
  • Saya membayangkan Google memberi kredit dalam jumlah sangat besar pada tagihan GCP, atau bahkan membayar kompensasi terpisah

• Tulisan terkait: UniSuper members go a week with no account access after Google Cloud misconfig[0](186 points, 16 days ago, 42 comments), Google Cloud accidentally deletes customer's account [1](128 points, 15 days ago, 32 comments)
  [0]: https://news.ycombinator.com/item?id=40304666
  [1]: https://news.ycombinator.com/item?id=40313171

• Fakta bahwa mereka tidak berhenti pada penyelidikan terhadap alat atau prosedur tertentu saja, tetapi juga memeriksa apakah bagian lain memiliki masalah penghapusan otomatis serupa dan meninjau perilaku soft delete, terdengar seperti peninjauan yang cukup menyeluruh.
  Selangkah lebih jauh, mereka juga bisa meninjau semua kasus nilai default untuk melihat apakah ada perilaku bawaan yang mengejutkan. Namun, bisa jadi sulit menentukan apa yang dianggap “mengejutkan”. Soalnya, justru orang-orang yang paling tidak memahami alat atau API sering kali menggunakan nilai default apa adanya

  • Bagian “meninjau perilaku soft delete juga” itu tepatnya muncul di mana? Yang dikatakan hanya bahwa mereka telah memastikan skenario penghapusan otomatis spesifik ini tidak akan terjadi lagi, dan alasan utamanya tampak seperti “sekarang deployment sudah diotomatisasi.”
    Sebelumnya juga sudah otomatis, dan sekarang hanya jadi lebih otomatis, tapi itu sama sekali tidak memberi rasa aman bahwa mekanisme penghapusan ini konsisten aman. Itu hanya berarti tidak ada lagi operator di kursi pengemudi
  • Insiden seperti ini justru menjadi alasan bagus untuk memakai AWS, jadi kemungkinan besar orang-orang di internal cukup panik.
    “Private Cloud GCVE milik pelanggan dihapus setelah periode satu tahun yang diberikan sistem berakhir. Penghapusan dipicu karena operator Google yang menggunakan alat internal membiarkan parameternya kosong, dan karena itu bukan permintaan penghapusan dari pelanggan, pemberitahuan ke pelanggan tidak dikirim. Jika penghapusan dimulai langsung oleh pelanggan, akan ada pemberitahuan sebelumnya.”
    Tada! Kami cukup tidak kompeten sampai membiarkan penghapusan besar-besaran terjadi tanpa peninjauan manusia. Untungnya pelanggan ini tidak sepenuhnya percaya pada kami dan punya backup di luar GCP, jadi tidak sampai benar-benar hancur total
    “Di Google Cloud, belum pernah ada insiden dengan karakteristik seperti ini sebelumnya. Ini bukan masalah sistemik.”
    Kalau diterjemahkan: “Ya ampun, para sales AWS dan Azure mengutip kegagalan besar kami ini lalu mengirim tiga email ke setiap calon pelanggan”

• Sulit dipercaya bahwa target pertama dari kejadian seperti ini adalah reksa dana bernilai miliaran dolar. Syukurlah masalah UniSuper terselesaikan, tapi rasanya mungkin ada kasus-kasus lain yang lebih kecil dan dianggap tidak cukup penting.
  Saya hanya berharap ini menjadi dorongan yang dibutuhkan GCP

  • GCVE, yaitu VMware terkelola, adalah layanan yang cukup obscure. Ini biasanya hanya dipakai oleh perusahaan bernilai miliaran dolar yang ingin mengangkat dan memindahkan kumpulan VMware mereka yang sudah ada ke cloud apa adanya
  • Inti insiden ini adalah adanya konfigurasi khusus yang kebanyakan pelanggan tidak miliki atau gunakan, dan itu melewati sebagian pemeriksaan keamanan. Jadi pelanggan kecil yang “umum” tidak mungkin terdampak
  • Kalaupun pelanggan kecil, mereka pasti akan membawanya ke media, dan media jelas akan meliputnya, jadi sulit melihatnya seperti itu.
    “Google menghapus layanan cloud kami” adalah berita besar untuk perusahaan dengan skala apa pun

• Disebutkan bahwa “CIO pelanggan dan tim teknisnya layak dipuji atas kerja sama erat dengan tim Google Cloud dan pelaksanaan pemulihan 24x7 yang cepat dan akurat”, jadi saya penasaran apakah mereka cuma dapat pujian di postingan blog atau juga berhasil menegosiasikan kredit Google Cloud dalam jumlah besar

  • Kalau pelanggannya kompeten, rasanya mustahil mereka tidak membuat Google menanggung biaya ini. Saya tidak akan kaget kalau tagihan tahun ini jadi nol sama sekali
  • Seharusnya ada ganti rugi yang bersifat menghukum juga

• Saya adalah pelanggan UniSuper di Australia. Saat itu saya tidak tahu apa yang sebenarnya terjadi, tapi saya menerima email setiap hari selama mereka berusaha menyelesaikannya. Saya baru tahu apa yang sebenarnya terjadi dari berita. Rasanya kejadian itu dikecilkan seolah hanya downtime sistem biasa.
  Membayangkan apa yang benar-benar terjadi pada uang orang dan miliaran dolar yang terkumpul dalam dana pensiun itu mengerikan

  • Apakah Anda menerima email yang sama seperti orang lain? Email datang hampir setiap hari, dan kata-kata seperti “disruption”, “apologies”, dan “frustration” dipakai berulang kali.
    Beberapa hari kemudian juga ada email berjudul “A letter from the CEO”
    “Kami ingin memberi Anda pembaruan tentang gangguan layanan.”
    “Pertama-tama, saya ingin secara pribadi meminta maaf atas gangguan ini dan berterima kasih atas kesabaran Anda sementara tim kami bekerja siang malam untuk memulihkan sistem kami kembali online secara bertahap.”
    Dalam situasi saat itu, rasanya sulit menuntut komunikasi yang lebih jelas atau penjelasan yang lebih gamblang tentang apa yang terjadi di dalam Google Cloud

• Pengumuman awal tentang kejadian ini cukup menyesatkan. Kedengarannya seperti Google tidak sengaja menghapus seluruh akun GCP. Setelah membaca tulisan ini, saya agak lega. Sepertinya yang hilang hanya mesin virtual seukuran satu region, dan hal seperti itu memang bisa terjadi, serta saya rasa sistem saya bisa menanganinya tanpa masalah besar.
  Tulisan aslinya terdengar seolah semua bucket GCS, database SQL, dan lain-lain di seluruh region ikut hilang, padahal itu masalah yang sama sekali berbeda, dan saya berharap kita masih bisa percaya bahwa Google tidak melakukan hal seperti itu

  • Saat UniSuper mengatakan yang dihapus adalah langganan, bukan akun, itu seharusnya sudah menjadi tanda bahaya. Banyak orang terburu-buru menarik kesimpulan dari situ