Bir oyun şirketinde küçük bir eylem bazen zincirin en zayıf halkasını kırar. Bu yazıda, bir butona basılmasıyla başlayan, 48 saat süren ve 300 oyuncunun sezonunu etkileyen gerçek bir olayın teknik, süreçsel ve insan boyutlarını ayrıntılı biçimde anlatıyorum. Amacım yalnızca duygu aktarmak değil: hangi hata yapıldı, neden hızlıca düzeltilmedi, bundan ne öğrendik ve aynı hatanın tekrarlanmaması için neler değiştirildi—bunları adım adım paylaşacağım.
Olayın kısa özeti
Bir pazarlama güncellemesi sırasında, canlı sisteme uygulanan bir database migration rollback düğmesine yanlışlıkla basıldı. Yanlış kapsamlı bir SQL betiği, sezon verilerini ve oyuncu ilerlemelerini eski bir duruma çeviren bir işlemi tetikledi. Sonuç: yaklaşık 300 oyuncunun sezon içi istatistikleri, sıralamaları ve bazı kazanılmış ödüller 48 saat içinde ya silindi ya tutarsız hale geldi. Tam bir kurtarma ve doğrulama süreci iki günü buldu.
Teknik olarak ne oldu?
Kısa cevap: operasyonel bir kombo hata. Uzun cevapsa birkaç katmanlıydı:
- Kötü tasarlanmış rollback betiği: Betik, üretim veritabanında bir tabloyu yeniden oluşturuyor ve eski snapshotı geri yüklüyordu. Ancak betiğin WHERE koşulu yanlış kapsamdaydı; sezonları filtreleyen koşul eksikti.
- Staging-production farkı: Rollback betiği staging ortamında test edilmişti, fakat stagingdeki veri hacmi ve id dağılımı prod ile eşleşmiyordu. Bu yüzden betik prodde farklı davranış gösterdi.
- Eksik feature flag ve akış güvenliği: Değişiklik bir feature flag veya canary rollout ile kademeli olarak dağıtılmadı. Tek bir düğme tüm üretimi etkiledi.
- İzleme ve alarmlar: İlk 15 dakikada anomali izlenebiliyordu ancak uygulanan alarm eşiği yanlış konfigüre edilmişti; olayın fark edilmesi gecikti.
Zaman çizelgesi - 48 saatin mikro adımları
- T+0:00 Pazarlama ekibi için bir versiyon geri alma planlandı. Bir geliştirici konsolda 'rollback' düğmesini çalıştırdı.
- T+0:05 Betik tamamlandı, sistem normal göründü. İlk 10 dakika içinde bazı oyuncular sıralamalarının düştüğünü bildirmeye başladı.
- T+0:20 Oyun içi match history eşleşmiyor; müşteri destek kayıtları artmaya başladı.
- T+1:00 İlk postmortem çağrısı; hızlı bir geri yükleme planı oluşturuldu.
- T+6:00 Tam bir yedekten geri dönüş denendi ancak veri tutarsızlıkları ortaya çıktı—bazı ödüller iki kez verilebilirdi.
- T+24:00 Manuel scriptlerle oyuncu bazlı düzeltmeler başladı; her düzeltme elle doğrulandı.
- T+48:00 Büyük çoğunluk için sezon verileri tutarlı hale getirildi, iletişim ve telafi planları uygulandı.
İletişim ve oyuncu deneyimi
Teknik düzeltmeler kadar önemli olan bir diğer alan da iletişimdi. İlk saatlerde oyunculara net bilgi verilememesi güvensizlik yarattı. Hata mesajları kafa karıştırıcı, müşteri destek yanıtları ise tutarsızdı. Bu bölümde yapılan hatalar ve doğru yaklaşımın nasıl olması gerektiğini özetliyorum.
- Hızlı ve şeffaf haberleşme: Olay tespit edildiğinde görünürdeki oyunculara kısa, net bir açıklama yapılmalıydı: ne olduğu, hangi verilerin etkilenebileceği ve tahmini çözüm süresi.
- Tekil iletişim kaynağı: Birden çok ekip farklı mesaj verdi. İletişimde tek bir doğrulanmış kanal/söz sahibi olmalı.
- Tazminat politikası: Oyunculara kademeli telafi sunuldu; zarar gören sezonlar için premium içerik, oyun-içi para ve özel iletişim sağlandı. Ancak bu politika önceden belirlenmiş olmalıydı.
Kayıplar ve geri kazanım maliyeti
Bu tür olayların maliyeti sadece doğrudan mühendislik saatleriyle ölçülmez. İtibar kaybı, oyuncu güveninin azalması, destek maliyeti ve pazarlama gecikmeleri de işin içindedir. Somut olarak:
- 300 oyuncunun sezonu doğrudan etkilendi.
- Toplam mühendislik müdahalesi ~350 insan-saat.
- İletişim ve destek maliyeti yükseldi; müşteri memnuniyeti puanlarında haftalar süren düşüş gözlendi.
Ne yapıldı: teknik ve süreçsel düzeltmeler
Olay sonrası hemen uygulanan teknik ve organizasyonel değişiklikler şunlardı:
- Feature flag ve kademeli dağıtım: Kritik veritabanı değişiklikleri artık canary rollout ile önce %1 trafik üzerinde test ediliyor.
- Rollback güvenlik katmanı: Rollback betikleri artık dry-run ve kapsam doğrulaması yapmadan üretimde çalıştırılamıyor. Scriptler yalnızca parametrik ve WHERE doğrulaması geçtikten sonra çalışıyor.
- Staging-prod veri paritesi: Staging verisi prod ile daha yakın olması için anonymize edilmiş büyük veri setleri kullanıldı.
- İzleme düzeltilmesi: Kritik metriğe dayalı alarm eşikleri yeniden ayarlandı; anomali tespiti için daha kısa aralıkla kontrol eklendi.
- Olay yanıt prosedürü: Runbook güncellendi; kim ne söyler, hangi kanal kullanılır, telafi politikası nasıl uygulanır açıklandı.
Dersler ve öneriler
Bu vaka tek bir şirketin dersi değil; benzer mimarilerde çalışan herkes için çıkarılabilecek net sonuçlar var:
- En tehlikeli düğmeleri azaltın: Üretim üzerinde destruktif işlemler için ikili onay, locked UI ya da fiziksel 2FA kullanın.
- Rollbackleri test edin: Geri dönüş senaryoları, sadece yedekten geri yükleme değil; veri tutarlılığı ve ödül/tallies denetimi içererek test edilmeli.
- Staging verisinin gerçekçiliği: Düşük hacimli test verisi tehlikelidir; adet ve id dağılımı gerçek hayata yakın olmalı.
- Kaos mühendisliği: Sınırlı hataların kontrollü olarak üretilmesi, sistemin beklenmedik durumlarda nasıl davranacağını gösterir.
- İletişim planı hazır olsun: Olay anında kim, ne zaman ve nasıl bilgilendirir sorusu önceden yanıtlanmalı.
Teknik hatalar kaçınılmazdır. Önemli olan bu hataların etkisini en aza indirmek ve oyuncularla kurulan güveni hızla yeniden inşa etmektir.
Pratik kontrol listesi (iyi uygulamalar)
Aşağıda, benzer bir felaketi önlemek için uygulanabilecek hızlı kontrol maddeleri var. Her prod değişikliğinde bu liste gözden geçirilsin:
- Rollback betikleri için dry-run ve kapsam doğrulaması
- İkili onay ve role-based erişim kontrolü
- Canary dağıtımı ve feature flag kullanımı
- Staging-prod veri paritesi ve büyük veri anonimleştirme
- Olay iletişim şablonları ve telafi politikası hazır
- Anomali tabanlı gerçek zamanlı uyarılar
Sonuç
Bu incident bize teknik hataların ötesinde süreç, iletişim ve organizasyonel kültürün önemini hatırlattı. Bir butona basılınca sadece kod değil, oyuncuların emekleri ve güveni de etkileniyor. 48 saatlik zorlu onarım süreci, hatanın tekrarlanmaması için somut politikalar ve teknik önlemlerle sonuçlandı. Eğer bir öneri ile bitirmek gerekirse: üretimdeki her destruktif eylem için "durdurma mekanizması" kurun; hatayı olasılık olarak değil, kaçınılmaz olarak kabul edip hazırlanmak en iyi savunmadır.
Bu metin, yaşanmış bir vakadan esinlenmiştir; isimler ve bazı teknik detaylar gizlilik ve genel eğitim amaçlı soyutlandırılmıştır.
