Giriş: Bir lig yöneticisinin kabusu: kritik yedeklerin kaybolduğu bir sabah. Bu yazıda, olayın tespitinden sezonun kurtarılmasına kadar geçen 24 saatin saat saat anlatımı, verilen teknik ve idari kararlar, kullanılan yöntemler ve çıkarılacak dersler yer alıyor. Gerçekçi, uygulanabilir ve detaylı bir vaka incelemesi okumaya hazırsanız, başlayalım.
Olayın İlk Dakikaları: Tespit ve İlk Tepki
Saat 08:12 — Lig yönetim paneline erişim sorunları baş gösterdi. Güncelleme sırasında veri tabanına bağlanılamıyor, bazı maç sonuçları ve oyuncu kayıtları eksik görünüyordu. IT ekibi acil durum prosedürünü başlattı.
İlk adım: durum tespiti (triage). Eksik veriler mi yanlış gösteriliyor yoksa veri mi silinmiş? Loglar incelendi, erişim hataları ve disk I/O uyarıları bulundu. Bu aşamada panik zararlı; hızlı ama kontrollü hareket edilmeli.
İlk 30 Dakika: Kontrol Listesi
- Servisleri read-only moda almak
- Kritik servis hesaplarını kilitlemek/rotasyonla erişimleri kısıtlamak
- Olay yanıt ekibini çağırmak (tek bir iletişim noktası belirlemek)
- İlk log ve snapshot’ları almak
Kaybın Kökünü Aramak: Neden Backup Bulunamadı?
İlk analizler, ‘günlük tam yedekleme’ betiğinin gece boyunca bir hata verdiğini, son başarılı yedeğin üç gün önce alındığını gösteriyordu. Ayrıca, yedeklerin depolandığı sunucunun zaman damgası yanlış idi ve beklenen S3 klasöründe dosyalar gözükmüyordu.
Muhtemel sebepler:
- Yedekleme betiği hatası veya zamanlanma bozulması
- Yedeklerin yanlış konuma yazılması (konfigürasyon hatası)
- Şifreleme anahtarının kaybolması veya rotasyonu
- İnsan kaynaklı silme/taşıma
- Donanım arızası veya sağlayıcı kesintisi
İletişim Yönetimi: Paydaşlarla İlk 2 Saat
Lig yönetiminin en kritik hatalarından biri iletişimi geciktirmektir. Bu vaka başarılı oldu çünkü yöneticiler şeffaf bir tutum seçti: kulüplere, sponsorlara ve yayın ortaklarına kısa ve sık güncellemeler verildi. Panik azaltıldı ve dedikodular önlendi.
"Bilgiyi kontrollü şekilde paylaşmak, dedikodudan daha az zararlı ve daha yönetilebilir bir sonuç getirir."
Hazırlanan ilk iletişim: kısa, net, etki ve beklenen süre bilgisi veren bir mesaj. Ardından teknik ekipten detaylı bülten geldi.
Teknik Kurtarma Stratejisi: 3 Başlık
Kurtarma çalışmaları üç paralel hat üzerinde yürüdü:
- En yakın sağlıklı kaynağa geri dönme — Son tam snapshot ve artımlı yedekleri kullanma.
- Manüel rekonstrüksiyon — Kritik verileri loglardan, e-posta dizinlerinden ve üçüncü taraf sistemlerden toplama.
- Alternatif veri kaynakları — Yayıncıların maç kayıtları, bilet sağlayıcılarının veritabanları, takım yönetim panelleri gibi dış kaynakların kullanımı.
Veritabanı Kurtarma
Lig yazılımı PostgreSQL tabanlıydı. Ekip şu adımları izledi:
- Son sağlıklı snapshot bulundu ve bir test ortamına mount edildi.
- WAL (write-ahead log) arşivleri kontrol edildi; bazı artımlı kayıtlar eksikti ama binlog/WAL sayesinde maç sonuçlarının büyük bölümü kurtarıldı.
- Eksik kayıtlar için uygulama logları ve API talepleri tarandı; taraftan gelen JSON payload'lar ile manuel insert scriptleri hazırlandı.
Burada kritik nokta: RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) hedeflerinin olay sırasında bilinmesi ve önceliklendirmeyi ona göre yapmak oldu. Örneğin, canlı puan tablosu tam kurtarılması öncelikli, geçmiş arşiv verileri daha sonra tamamlanabilecek düzeyde belirlendi.
Saat Saat 24 Saatlik Kronoloji (Özet)
- Saat 08:12: Sorun tespit edildi, read-only moda geçildi.
- Saat 08:30: İletişim kanalları açıldı, paydaşlara ilk bilgilendirme yapıldı.
- Saat 09:00-11:00: Log, snapshot ve betik incelemeleri; ilk kurtarma planı hazırlandı.
- Saat 11:00-16:00: Test ortamında veri restore denemeleri yapıldı; hatalı restore senaryoları elendi.
- Saat 16:00-20:00: Kritik modeller ve puan tablosu canlıya manuel girişle geri kondu.
- Saat 20:00-24:00: Tam kurtarma; kullanıcı testleri tamamlandı, sistem normal operasyon moduna alındı.
Pratik Teknik Örnekler
Uygulanan bazı somut teknik adımlar:
- Snapshot mount: Kayıp backup sebebiyle mevcut snapshotlar test ortamına mount edilip rsync ile seçili tablolar çekildi.
- WAL replay: PostgreSQL WAL segmentleri ile artımlı değişiklikler tekrar uygulandı.
- Manuel veri toplama: Yayıncı API'lerinden maç skorları çekilip toplu SQL insert scriptleri çalıştırıldı.
- Checksum kontrolü: Restored verilerin bütünlüğü için MD5/SHA checksum karşılaştırmaları yapıldı.
Karar Anları ve Yönetimsel Stratejiler
24 saat içinde verilen kararlardan bazıları:
- Hemen tam restore yerine kademeli açılış (kritik bileşenler önce) seçildi. Bu, hizmet süresinin kısmi olarak kısa tutulmasını sağladı.
- Şeffaf iletişim stratejisi devam ettirildi; bu güven oluşturdu ve muhtemel hukuki süreçleri hafifletti.
- Olay sırasında vekalet mekanizması devreye alındı; teknik ekipler farklı görevlerde paralel çalıştı.
Sonuç ve Öğrenilen Dersler
Sezon kurtarıldı çünkü hızlı, öncelikli ve pragmatik kararlar verildi. Ancak bu olay, birçok politik ve teknik zafiyeti açığa çıkardı. Öne çıkan dersler:
- Yedekleme politikası net ve test edilmiş olmalı: Otomasyon yetmez; düzenli restore tatbikatları yapılmalı.
- Offsite ve immutable yedekler şart: Sadece bir lokasyonda yedek tutmak riskli.
- Anahtar yönetimi (encryption keys) ayrı, güvenli ve erişilebilir olmalı.
- RTO/RPO hedefleri belirlenmeli ve buna göre öncelikler planlanmalı.
- İletişim planı hazır olmalı; panik yerine güven sağlayan kısa ve düzenli bilgilendirme yapılmalı.
Pratik Kontrol Listesi (Olay Öncesi Hazırlık)
- Günlük tam ve saatlik artımlı yedekleme politikası oluşturun.
- En az 2 farklı lokasyona immutable kopya saklayın.
- Yedekleri düzenli olarak geri yükleyerek test edin (aylık/çeyreklik).
- Anahtar yönetimini, rotasyon ve acil erişim prosedürleriyle yönetin.
- Olay müdahale playbook'u hazırlayın ve ekipleri eğitin.
Son Söz
Bu vaka, teknik uzmanlığın yanı sıra liderlik, iletişim ve priortileştirme becerilerinin bir arada nasıl çalıştığını gösterdi. Kritik veriler kaybolduğunda en iyi savunma, önceden hazırlanmış bir plana sahip olmaktır. Bugün kurtarılan sezon, yarının felaketini önleyecek adımların atılmasına vesile oldu.
Eğer kendi organizasyonunuz için bir yedekleme ve kurtarma denetimi yapmak isterseniz, küçük adımlarla başlayın: bir playbook yazın, bir ayda bir restore tatbikatı gerçekleştirin ve yedeklerinizi dış lokasyona kopyalayın.
