CTO’nun kariyerini ortaya koyup bit seviyesine kadar inerek DB’yi hacklediği hikâye
(tech.devsisters.com)- Devsisters tarihindeki en uzun
CookieRun: Kingdomkesintisi: 36 saat - Ana dağıtık veritabanı olarak CockroachDB kullanılıyor: 4 düğüm, 12 TB depolama, 7 kopya
- Veritabanını ölçeklendirme çalışması sırasında düğümlerin yarısı çöktü
- Bunun sonucunda tüm hizmette kesinti yaşandı ve CockroachDB tarafındaki destek mühendisi kurtarmanın mümkün olmadığına karar verdi
- Bu yüzden, depolamada kaydedilmiş verileri doğrudan bulmak için yapılan çabaları derleyen bir yazı
24 yorum
Oldukça tartışmalı bir yazı gibi görünüyor..? Hizmet tarafında nasıl olduğunu bilmiyorum ama üzerinde çalışan geliştiriciler muhtemelen inanılmaz gurur duymuştur.
Kullanıcıların tepkisinin nasıl olduğunu bilmiyorum ama geri alımı önlemek için çaba göstermiş olması açısından, bir kullanıcı olarak takdiri hak ettiğini düşünüyorum.. 36 saat boyunca yaşanmış olabilecek kullanıcı kaybını ve müşteri deneyimini düşününce zarar daha büyük olmuş olabilir ama bir geliştirici açısından bakınca bunun ilginç bir meydan okuma olduğunu düşünüyorum. Şirket bir oyun firması değil de banka olsaydı ne olurdu?
Pokémon Go'nun GCP üzerinde Spanner kullandığı söyleniyor (https://cloud.google.com/blog/topics/…); AWS tarafında ise buna denk düzgün bir alternatif pek yok gibi görünüyor.
Söz konusu belgeye dayanarak geliştirme ekibinin niyetini anladığımda, bu projede CockroachDB kullanılmaması gerekiyormuş.
Hangi DB'yi kullanmalıydık?
Hizmete bağlı olarak ürkütücü olabilecek bir içerik.
Keyifle okudum.
Gördüğüm kadarıyla ilgili blogda bu arızayla ilgili içeriği bir yazı dizisi olarak paylaşmışlar. Baştan sona okuyunca, bunu toparlamaya çalışan insanların yaşamış olabileceği zihinsel çöküş gerçekten çok etkileyiciydi.
Bazı kullanıcıların deneyimini bozup çoğunluğu koruyan bir rollback yerine, 36 saat boyunca tüm kullanıcı verilerini geri yüklemenin iş açısından doğru bir karar olup olmadığından pek emin değilim. Geliştirici açısından ise ilgi çekici noktalar var.
Metinde şöyle bir ifade yer alıyor.
Müşterilere en iyi deneyimi sunmak bizim misyonumuzdu ve bunu içtenlikle hayata geçirmek için çaba gösterdik. Hiç kimse hayal kırıklığına uğrayıp vazgeçmedi.
Paranın hatırına bazı kullanıcıların gözden çıkarılabileceği söylemini burada da duymak, Kore oyun sektöründe kullanıcılara nasıl davranıldığı gerçeğini bir kez daha hissettiriyor.
Bence bu, olaya fazla zorlama bir yorum katmak gibi görünüyor; sonuç odaklı bakıldığında, sorun çözülememiş olsaydı hem zaman boşa harcanmış olacak hem de rollback yapılmış olacağı için sitem toplardı.
Ayrıca hizmet verilemediğinde, o süre boyunca kullanıcıların yüzüstü bırakıldığı görüşü de aynı şekilde geçerli.
Buna çok ama çok güçlü biçimde katılıyorum...
Geliştirici açısından okuması çok ilgi çekiciydi (kışkırtıcı başlık dahil), ama ben de buna benzer bir açıdan baktım. Biraz eski bir haberde geçen bilgiler olduğu için gerçekle farklar olabilir ama sanırım CookieRun: Kingdom gelirinin 300 milyar wonu aştığı söyleniyordu; 36 saatlik kesintiyi beklenen gelire çevirdiğinizde ortaya çıkacak rakam ile rollback sonrası ödenecek tazminat tutarını karşılaştırıp ona göre karar vermişlerdir.
Sorun çözmeyi önemseyen geliştirici kültürünün güçlü olduğu bir organizasyon olması da belli ölçüde etkili olmuş olabilir diye düşünüyorum.
Ben olsam nasıl bir karar verirdim, hâlâ pek emin değilim.
Günümüzde oyunlarda (özellikle rastgele çekiliş/gacha türü sistemler olan oyunlarda) rollback, gerçekten ancak en kötü durumda kullanılabilecek bir yöntem... L adlı oyunda olduğu gibi imajı umursamıyorsanız ayrı ama normalde mümkün değil; bu olayda da özellikle rollback yapmayıp sonrasında büyük telafi ödülleri vermeleri sayesinde kullanıcılar bile "Kaynağımız azalınca sunucu bir kez daha çökmez mi?" diye kendi aralarında şaka yapıyordu... Bence doğru karardı.
Oyun olduğu için, 36 saat öncesine rollback yapılması durumunda cache ile ilgili olarak ciddi parasal kayıp yaşanmış olabileceğini düşünüyorum
İş açısından doğru bir karar gibi görünmediğini düşünenlerdenim.
İstenmeden yapılan bir ayar hatası (en kritik ve en saçma insan hatası buydu. Replikaların çalışmasını engelleyecek kadar büyük bir değişikliğin bu şekilde yapılmış olması; DB tasarım geliştiricilerinin hepsini toplasanız bile bu geri getirilemez)
Bu yüzden verinin tamamını kaybedemeyecekleri için... en güncel veri tutarlılığından vazgeçmek pahasına bile son kaydedilmiş ikili biçimdeki DB verisini doğrudan bulup (7 TB) bunu CSV'ye dönüştürmek için bir Go programı yazmışlar... ?
Bu dönüşüm için Go programı yapmak, ne kadar iyi yapılırsa yapılsın gerçekten ne anlam ifade eder ki..
Off.. bunu düşünmek bile insanı boğuyor. Neden ille de böyle olmak zorundaydı ki..
Böyle insan hatalarının yaşanmaması için süreci güçlendirmek en önemli şey gibi görünüyor. Arızayı çözerken ikili dönüşümle uğraşıp ne kadar zorlandıklarını anlatmasalar daha iyi.
Böyle bir şeyi anlatmamak için ayrıca bir sebep mi var? Asıl anlamlı olan, postmortem’i kamuya açıklamanın kendisi.
Bana göre, gerçekten faydalı bir yazı yazılacaksa başlık şöyle olmalı değil mi?
"Node yapılandırma hatası nedeniyle oluşan cluster yapılamıyor hatasının neden analizi ve çıkarılan dersler"
Böyle bir yazı ayrıca yazılabilir; “sorunun kök neden analizi” ile “sorunun çözüm süreci” ayrı konular ve ikisi de önemli. Ancak “kök neden analizi” yok diye yazının değerini küçümsemek bana anlaşılması zor bir tavır gibi geliyor...
"Kök neden analizi" yazısının da devamında gelirse daha da iyi olacağını söyleyebilirsiniz; ama ondan önce değersiz olduğunu söylemek pek iyi bir tutum değil.
Kesin konuşmak gerekirse bu bir 'arıza çözüm süreci' değil, "eksik veriyi el emeğiyle kurtarma" süreciydi. Sadece kaybın kapsamını biraz azalttık, o kadar.
Yukarıdaki yazıda veri kurtarmanın “eksik” olduğuna dair nerede bir ifade var? En azından yukarıdaki yazının içeriğine bakılırsa tam kurtarmanın başarıldığı söyleniyor. Ayrıca silinip giden veritabanını geri getirmek, arıza giderme değilse nedir? O olaydan sonra ilgili hizmet aynen faaliyetini sonlandırdı mı?
Ama bu, bu hikâyeyi anlatmamak için bir neden değil ki?
Hayatı gerçekten çok zor yaşıyorsunuz.