Her turnuva teknik ekibi için en büyük kabus, final günü ortasında sunucunun çökmesidir. Bu yazıda, bir turnuva teknisyeni olarak yaşadığım 24 saatlik kesintiyi, attığım adımları, yapılan hataları ve çıkarılan dersleri adım adım aktaracağım. Amaç, benzer bir durumda hızlı, kontrollü ve takımı yarışmada tutacak bir kurtarma süreci sunmak.
Giriş: Olayın kısa özeti
Turnuva başlamadan 90 dakika önce, ana oyun sunucularından biri yüksek CPU ve I/O beklenmeyen şekilde artınca otomatik ölçekleme başarısız oldu ve servisler zaman içinde stabil bağlantı kuramaz hale geldi. İlk 15 dakika hatanın tespiti, sonraki 3 saat kurtarma ve geçici çözümler, kalan sürede kalıcı düzeltmeler ve post-mortem hazırlığı yapıldı. Aşağıda olayın teknik ayrıntılarını, karar anlarını ve pratik önerileri bulacaksınız.
1. İlk 60 dakika: Tespit ve izolasyon
Durum tespiti için yaptığım ilk işler şunlardı:
- Sistem monitörlerinden (CPU, RAM, disk I/O, ağ) anlık metrikleri kontrol etmek.
- Uygulama loglarını hızlıca taramak; hata paternleri, timeout, OOM veya GC logları aramak.
- Load balancer ve ağ katmanını incelemek; health check sonuçları ve son konfigürasyon değişiklikleri.
Bulduğum ana ipuçları: belirli bir işlem hattında disk I/O yoğunluğu, artan thread sayısı ve aralıklı veritabanı gecikmeleri. İlk izlenim, trafik spike'ı ya da arka plandaki görevlerin üretim sunucularını etkilemesi yönündeydi.
Yapılan hızlı izolasyon
- Etki altındaki sunucuları load balancer üzerinden pasif moda alıp trafiği sağlıklı düğümlere yönlendirdim.
- Yoğun kaynak tüketen süreçleri belirleyip, non-critical batch işlerini durdurdum.
- Disk I/O'yu azaltmak için logging seviyesini geçici olarak düşürdüm.
2. 1–6. saatler: Kurtarma ve geçici çözümler
Burada amaç, turnuvayı olabildiğince az kesintiyle devam ettirmekti. Hedef: 30 dakikalık bir pencerede maçları sürdürür durumda olmak.
Adımlar
- Önceliklendirme: Oyunun temel akışını sağlayan servisleri (oturum yönetimi, matchmaking, oyun logic) önceliklendirdik; telemetri ve analiz sistemleri ikincil önceliğe alındı.
- Rollback: Son 48 saatte yapılan config ve kod değişiklikleri loglandı; bir konfigürasyon değişikliğinin tetikleyici olma olasılığı yüksek görünüyordu, hızlı bir rollback uygulandı.
- Kaynak artırımı: Vertikal ölçekleme mümkün değilse yatay yeni instance'lar devreye alındı ve load balancer konfigürasyonu güncellendi.
- Cache kademesi: Veritabanına binen yükü azaltmak için cache önbellekleri (Redis/Memcached) kısa süreli önceliklendirme ile yoğunlaştırıldı.
Bu adımlar sayesinde 2.5 saat içinde sistem stabil hale getirildi ve maç akışı normale döndü. Ancak bu, tam bir çözüm değildi; altta yatan nedenler hala araştırılıyordu.
3. 6–18. saatler: Kök neden analizi ve kalıcı düzeltmeler
Geçici çözümler etkinleştirildikten sonra asıl işi yapmak gerekiyordu: tekrar oluşmasını engelleyecek kalıcı değişiklikler.
Kök neden tespiti
- Uygulama tarafında belirli bir sorgunun beklenenden çok daha fazla disk I/O ürettiği saptandı: büyük bir JOIN sorgusu yanlış indeks nedeniyle full table scan yapıyordu.
- Bazı arka plan görevleri (geçmiş veriyi temizleyen cron) yanlış cron tab'i nedeniyle peak saatlerde çalışıyordu.
- Otomatik ölçeklendirme (auto-scaling) politikası yalnızca CPU'ya bakıyordu; I/O veya queue length artışını dikkate almıyordu.
Uygulanan kalıcı düzeltmeler
- Veritabanına uygun indeksler eklendi ve sorgular optimize edildi.
- Arka plan job zamanlamaları gözden geçirildi; batch işlerini gece penceresine kaydırdık.
- Auto-scaling politikaları genişletildi: I/O, disk queue length ve custom app-metric'leri tetikleyici yapıldı.
- Sağlık kontrolleri (health checks) daha derin hale getirildi: yalnızca TCP değil, uygulama yanıt sürelerini ve temel endpoint sonuçlarını kontrol eden probe'lar eklendi.
4. Yapılan hatalar ve ne olmalıydı
Hatalardan kaçınmak tekrar oluşumu engeller. Olay sırasında yaptığımız ve sonradan düzeltmek zorunda kaldığımız hatalar:
- İlk iletişimde belirsizlik: Takım içinde görev dağılımı net değildi; kritik kararlar gecikti. Her acil durumda bir incident commander atanmalı.
- Over-privileged erişimler: Hızlı müdahale için veritabanı erişimleri geniş tutulmuştu; bu, yanlışlıkla tehlikeli komutların çalışmasına olanak verdi.
- Test olmayan roll-back: Rollback adımı önceden test edilmemişti; bir kısmı geri alma sürecinde sorun yarattı. Rollback prosedürleri tatbikatla doğrulanmalı.
Olay yönetiminde hız önemlidir, ancak plansız hız uzun vadede daha büyük zararlara yol açar.
5. Hemen uygulanabilir kontrol listesi (turnuva öncesi)
Aşağıdaki kısa checklist'i turnuva başlamadan önce mutlaka uygulayın:
- İzleme: CPU, RAM, Disk I/O, network, GC ve uygulama-level latency dashboard'ları çalışır durumda mı?
- Otomatik alarmlar: queue length, DB slow queries ve error rate için uyarılar aktif mi?
- Rollback planı: kod, konfigürasyon ve altyapı değişiklikleri için test edilmiş geri alma prosedürleri var mı?
- İletişim: acil durum zinciri, Slack/Discord kanalları ve arama listesi güncel mi?
- Load test: beklenen 1.5–2x trafik yükü simüle edildi mi?
- Yedekleme: kritik veritabanı yedekleri ve snapshot stratejisi güncel mi?
6. Operasyonel öneriler ve otomasyon fikirleri
Teknisyen olarak öğrendiğim pratik otomasyonlar:
- Canary release'ler ve safedeploy ile risk taşıyan değişiklikleri kademeli açın.
- Auto-remediation scriptleri yazın: örneğin yüksek I/O tespitinde logging seviyesini otomatik düşüren bir job.
- Playbook oluşturun: adım adım yapılacaklar, kim ne yapar, hangi komutlar, hangi ekran görüntüleri alınmalı, vs.
- Incident tatbikatları düzenli aralıklarla yapın; ekip rollerine alışsın.
7. Sonuç: Şampiyonluğa giden teknik kültür
Sunucu çöküşlerini tamamen ortadan kaldırmak mümkün olmayabilir; ancak hazırlık, iletişim ve otomasyon ile turnuva zamanlarında felaketleri küçük kesintilere dönüştürebilirsiniz. Önemli olan üç nokta var:
- Hızlı tespit: doğru metriklerle olayı ilk dakikada anlamak.
- Kontrollü müdahale: geçici çözümler ile akışı korumak.
- Kök neden düzeltmesi: aynı hatanın tekrar etmesini engellemek.
Bu 24 saatlik günce, teknik kararların neden alındığını, hangi hataların yapıldığını ve ne tür kalıcı önlemlerle şampiyonluğun teknik altyapısının korunabileceğini somut örneklerle gösterdi. Umarım kendi turnuva altyapınız için pratik ve uygulanabilir bir rehber olur.
Ek kaynak ve şablon: Olay sonrası (post-mortem) şablonu, oyun sunucusu health-check örnekleri ve acil durum playbook'u isterseniz paylaşabilirim.
