- Insiden terlama dalam sejarah Devsisters, yaitu gangguan 36 jam pada CookieRun: Kingdom
- Menggunakan CockroachDB sebagai DB terdistribusi utama: 4 node, 12TB storage, 7 replika
- Saat pekerjaan ekspansi database berlangsung, setengah dari node mati
- Akibatnya terjadi gangguan pada seluruh layanan, dan engineer support dari pihak CockroachDB menilai pemulihan tidak mungkin dilakukan
- Karena itu, ini adalah tulisan yang merangkum upaya-upaya yang dilakukan untuk menemukan data yang tersimpan langsung di storage
24 komentar
Tulisannya memang sangat memicu kontroversi ya..? Dari sisi layanan mungkin entah bagaimana, tetapi para pengembang yang mengerjakannya sepertinya pasti merasa sangat bangga.
Saya tidak tahu bagaimana reaksi para pengguna, tetapi sebagai pengguna saya ingin memberi satu pujian karena mereka berupaya mencegah rollback.. Meski jika memikirkan pengguna yang mungkin pergi dan pengalaman pelanggan selama 36 jam itu, kerugiannya bisa jadi lebih besar, dari sudut pandang developer saya rasa ini adalah tantangan yang menarik. Bagaimana jadinya jika perusahaannya bukan game, melainkan bank?
Katanya Pokémon Go menggunakan Spanner dari GCP (https://cloud.google.com/blog/topics/…), dan di AWS memang tidak ada alternatif yang benar-benar pas.
Berdasarkan dokumen tersebut, jika memahami maksud tim pengembang, sepertinya pada proyek itu memang seharusnya tidak menggunakan CockroachDB.
Database apa yang seharusnya digunakan?
Tergantung layanannya, ini bisa jadi konten yang bikin merinding.
Saya membacanya dengan seru.
Sepertinya blog tersebut mengunggah rangkaian tulisan tentang insiden itu. Setelah saya baca terus, yang paling berkesan adalah betapa kacaunya mental orang-orang yang harus membereskan itu.
Saya kurang yakin apakah, secara bisnis, memulihkan semua data pengguna selama 36 jam adalah keputusan yang lebih tepat dibanding rollback yang merusak pengalaman sebagian pengguna demi melindungi mayoritas. Dari sudut pandang pengembang, isinya memang menarik.
Ada bagian seperti ini di isi artikelnya.
Misi kami adalah memberikan pengalaman terbaik kepada pelanggan, dan kami berupaya keras untuk benar-benar mewujudkannya. Tidak seorang pun merasa putus asa lalu menyerah.
Bahkan di sini saya mendengar bahwa demi uang, sebagian pengguna dianggap boleh dibuang; ini sekali lagi membuat saya merasakan bagaimana pengguna diperlakukan di industri game Korea.
Itu seperti sudut pandang yang terlalu dipelintir. Kalau dilihat dari hasil akhirnya, jika masalahnya tidak berhasil diselesaikan, waktu tetap terbuang percuma dan rollback server juga tetap terjadi sehingga pasti akan menuai keluhan.
Dan dari sudut pandang bahwa ketika layanan tidak bisa digunakan berarti pengguna ditelantarkan selama waktu itu, poinnya juga sama.
Saya sangat, sangat, sangat setuju...
Dari sudut pandang pengembang, ini bacaan yang sangat menarik (termasuk judulnya yang provokatif), tetapi saya juga melihatnya dari perspektif yang mirip. Karena ini adalah isi yang disebutkan dalam artikel yang sudah agak lama, mungkin ada perbedaan dengan kenyataannya, tetapi sepertinya pendapatan Cookie Run: Kingdom melebihi 300 miliar won, jadi mungkin ini adalah keputusan yang diambil setelah membandingkan downtime 36 jam yang dikonversi ke estimasi pendapatan dengan jumlah kompensasi yang harus dibayarkan setelah rollback.
Saya juga pikir fakta bahwa ini adalah organisasi dengan budaya pengembang yang kuat dan menekankan penyelesaian masalah kemungkinan turut berpengaruh sampai tingkat tertentu.
Kalau saya, sampai sekarang pun saya masih tidak yakin keputusan apa yang akan saya ambil.
Di game belakangan ini (terutama game dengan sistem gacha acak), rollback itu... benar-benar metode yang cuma bisa dipakai dalam kondisi terburuk... Kecuali seperti game L yang tidak terlalu peduli dengan citra, itu nyaris mustahil, jadi khusus untuk insiden ini justru karena tidak melakukan rollback dan kemudian memberi kompensasi besar, para pemain sampai bercanda, kalau kekurangan mata uang apakah server akan meledak sekali lagi? Jadi menurut saya itu adalah keputusan yang tepat.
Karena ini game, sepertinya jika di-rollback ke 36 jam sebelumnya, kerugian finansial akibat hal-hal terkait cash bisa sangat besar.
Saya juga memilih bahwa itu sepertinya bukan keputusan yang tepat secara bisnis.
Kesalahan konfigurasi yang tidak disengaja (ini human error paling konyol namun paling kritis. Melakukan perubahan besar yang sampai membuat replika tidak bisa berfungsi dengan cara seperti ini; bahkan kalau semua pengembang perancang DB dikumpulkan pun, ini tidak bisa dipulihkan)
Jadi karena datanya tidak bisa dihapus seluruhnya... meski harus mengorbankan konsistensi data terbaru, mereka sampai mencari langsung data DB dalam bentuk biner terakhir yang tersimpan (7 TB) lalu menulis program Go untuk mengubahnya menjadi csv... ?
Tapi membuat program konversi Go seperti ini, sehebat apa pun dibuatnya, memang ada artinya ya..
Huh.. benar-benar bikin sesak hanya dengan membayangkannya. Kenapa harus sampai seperti ini..
Yang paling penting sepertinya memperkuat proses agar human error seperti ini tidak terjadi. Jangan cerita soal susah payah mengurus insiden sambil konversi biner.
Apakah ada alasan lain mengapa cerita seperti ini tidak boleh dibagikan? Membuka postmortem itu sendiri sudah bermakna, menurut saya.
Menurut saya, kalau benar-benar ingin menulis artikel yang membantu, bukankah judulnya seharusnya seperti ini?
"Analisis penyebab error cluster gagal akibat kesalahan konfigurasi node serta pelajarannya"
Tulisan seperti itu bisa ditulis terpisah; “analisis penyebab gangguan” dan “proses penyelesaian gangguan” adalah topik yang berbeda, dan keduanya sama-sama penting, jadi sulit dipahami jika nilai tulisan ini direndahkan hanya karena tidak ada “analisis penyebab gangguan”...
Anda cukup mengatakan bahwa akan lebih baik jika tulisan analisis penyebabnya juga menyusul, tetapi menyebutnya tidak bernilai sebelum itu bukanlah sikap yang baik.
Tepatnya, ini bukan 'proses penanganan gangguan', melainkan proses "kerja manual memulihkan data yang tidak lengkap". Hanya saja berhasil sedikit mengurangi cakupan kehilangan? Kurang lebih begitu.
Di mana dalam tulisan di atas ada isi yang menyebut pemulihan data itu “tidak lengkap”? Setidaknya berdasarkan isi tulisan di atas, yang disebutkan justru berhasil melakukan pemulihan sepenuhnya. Lalu, kalau memulihkan DB yang sempat terhapus itu bukan penyelesaian insiden, lalu apa? Setelah kejadian itu, apakah layanan tersebut langsung menghentikan operasinya?
Itu bukan alasan untuk tidak menceritakan kisah ini, bukan?
Hidup Anda tampaknya benar-benar berat.