Felaket Kurtarma Planı: Bahis Operatörü için Hazırlık

Felaket kurtarma (Disaster Recovery, DR) planı, 'bize olmaz' diye ertelenen işlerin başında gelir. Oysa bir bahis operasyonunda en kötü senaryo çoğu zaman en kötü zamanda gerçekleşir: büyük bir maçın ortasında, yoğun bir kampanya döneminde ya da ekibin yarısı izindeyken. İyi bir DR planı, kriz anında kimin neyi hangi sırayla yapacağını önceden belirleyerek paniği prosedüre dönüştürür.

Hangi senaryolara hazırlanmalısın?

• Veri merkezi ya da bulut bölgesi arızası: Güç, soğutma ya da ağ sorunları bir bölgenin tamamını devre dışı bırakabilir. Coğrafi olarak ayrı bir yedek ortam gerekir.
• Veritabanı bozulması: Yazılım hatası ya da yanlış bir sorgu verileri bozabilir. Replikasyon bu bozulmayı yedeğe de taşıyabileceği için belirli bir ana geri dönebilmek (point-in-time recovery) kritiktir.
• Fidye yazılımı: Sistemlerin şifrelenmesi durumunda çevrim dışı ve değiştirilemez yedekler tek çıkış yolu olabilir.
• Sağlayıcı kaybı: Barındırma, alan adı, ödeme ya da altyapı sağlayıcısının hizmeti kesmesi. Tek sağlayıcıya bağımlılık başlı başına bir risktir.
• Kritik bilgi kaybı: Sistemleri yalnızca bir kişinin bilmesi ve bu kişiye ulaşılamaması.

RTO ve RPO: hedefini sayıyla yaz

RTO (Recovery Time Objective), bir kesintiden sonra hizmeti en geç ne kadar sürede ayağa kaldırman gerektiğidir. RPO (Recovery Point Objective) ise kabul edebileceğin en fazla veri kaybını zaman olarak ifade eder. Bahis platformlarında kupon ve bakiye verisinin kaybı doğrudan finansal ve itibari sonuç doğurduğu için RPO'nun mümkün olduğunca sıfıra yakın olması hedeflenir; bu da sürekli replikasyon gerektirir.

Önemli olan, bu hedefleri her sistem için ayrı ayrı yazmak ve iş tarafıyla birlikte onaylamaktır. Oyuncu hesabı ve cüzdan için kabul edilebilir kayıp, kampanya sayfaları ya da blog için kabul edilebilir kayıpla aynı değildir. Her sisteme aynı hedefi koymak ya bütçeyi gereksiz yere şişirir ya da kritik sistemleri korumasız bırakır.

Yedekleme: 3-2-1 kuralı

Yaygın kabul gören 3-2-1 kuralı iyi bir başlangıç noktasıdır: verinin en az üç kopyası, iki farklı ortamda ve bir kopyası farklı bir lokasyonda bulunmalıdır. Fidye yazılımı riskine karşı bu kopyalardan en az birinin çevrim dışı ya da değiştirilemez (immutable) olması gerekir. Yedeklerin gerçekten geri yüklenebildiğini düzenli olarak test etmeyen bir ekip, aslında yedeği olmayan bir ekiptir. Ayrıntılar için veri yedekleme stratejisi rehberimize göz at.

Standby modelleri

• Cold standby: Yedek ortam kapalıdır ve felaket anında sıfırdan ayağa kaldırılır. Maliyeti düşüktür, ancak geri dönüş saatler sürebilir.
• Warm standby: Yedek ortam çalışır durumdadır, veri replikasyonu sürer ama trafik almaz. Geri dönüş dakikalar mertebesindedir; çoğu orta ölçekli operatör için dengeli bir seçenektir.
• Hot standby / aktif-aktif: Hot standby'da yedek ortam tamamen çalışır ve senkron durumdadır, arıza anında neredeyse kesintisiz devralır; aktif-aktif kurulumda ise iki ortam aynı anda trafik alır. Bu modeller en yüksek dayanıklılığı sağlar, ancak maliyeti ve veri tutarlılığı karmaşıklığı da en yüksektir.

Runbook şablonu

Runbook, belirli bir senaryoda adım adım ne yapılacağını anlatan belgedir. Kriz anında okunacağı için kısa, net ve teknik olmayan bir yöneticinin de takip edebileceği şekilde yazılmalıdır. Her senaryo için şu başlıkları doldur:

1. Tetikleyici: Bu runbook hangi durumda devreye girer? Hangi alarm ya da gözlem onu başlatır?
2. Sorumlular: Olay yöneticisi kim, teknik müdahaleyi kim yapar, iletişimi kim yürütür? Yedek kişiler kimler?
3. İlk 15 dakika: Durumu doğrulama, etkiyi sınırlandırma ve ekibi toplama adımları.
4. Geri dönüş adımları: Yedek ortama geçiş, DNS değişikliği ve veritabanı geri yükleme gibi somut komut ve kontroller.
5. İletişim: Oyunculara, iş ortaklarına ve ekibe hangi kanaldan, hangi sıklıkla bilgi verileceği.
6. Kapanış: Normal duruma dönüş kriterleri ve olay sonrası değerlendirme toplantısı.

Güvenlik olaylarına özgü müdahale adımları için olay müdahale planı rehberimiz bu şablonu tamamlar. Felaket sonrası kişisel API anahtarlarını yenilemeyi (yeni anahtar oluşturup eskisini iptal ederek) ve webhook görevlerini silip yeniden oluşturarak yeni gizli anahtar almayı da kapanış adımlarına eklemeyi unutma.

Tatbikat: plan ancak test edilince plandır

Yılda en az bir kez gerçekçi bir tatbikat yap: birincil ortamı kontrollü biçimde devre dışı bırak, yedek ortama geç ve RTO ile RPO hedeflerini tutturup tutturamadığını ölç. Tatbikatta ortaya çıkan her eksik, gerçek bir felakette yaşamayacağın bir sürprizdir. Daha küçük ölçekte, yedekten geri yükleme testlerini daha sık tekrarlayabilir ve her testten sonra runbook'u güncelleyebilirsin.

Dış izleme ve erken uyarı

Pek çok felaket bir anda değil, küçük işaretlerle başlar: yanıt sürelerinin uzaması, aralıklı erişim sorunları, belirli sitelerde tekrarlayan hatalar. Bu işaretleri erken görmek için siteleri dışarıdan, gerçek bir istemci gibi kontrol eden bir mekanizma gerekir.

• LLCBullet'te kurduğun site kontrolü görevleri, paketindeki altyapılara bağlı sitelerden seçtiklerinin erişilebilirliğini ve yanıt sürelerini kaydeder; erişilemeyen site bulunduğunda Telegram, panel ya da tarayıcı üzerinden bildirim alırsın.
• Görevlerin istatistikler bölümü altyapı bazında başarı oranlarını ve yanıt sürelerini göstererek kademeli bozulmaları fark etmeni kolaylaştırır.
• Sonuçları kendi olay yönetim sistemine aktarmak için imzalı webhook görevleri kullanabilirsin.

Kullandığın araçların kendisinin durumunu bilmek de önemlidir: LLCBullet mağaza, panel, ödeme takibi ve Telegram botunun anlık durumunu ve planlı altyapı bakımlarını sistem durumu sayfasında yayınlar.

Sonuç

Felaket kurtarma planı; net hedefler, test edilmiş yedekler, yazılı runbook'lar ve düzenli tatbikatlardan oluşur. Bu parçaları sakin bir dönemde tamamlamak, kriz anında saatler ve ciddi kayıplar kazandırır.