ERP ortamlarında felaket kurtarma konusu çoğu zaman yalnızca veritabanı replikasyonu olarak ele alınıyor. Oysa gerçek hayatta toparlanma başarısı; veri tutarlılığı, entegrasyon akışları, batch takvimi, kimlik servisleri ve ağ yönlendirmesinin birlikte düşünülmesine bağlıdır. Uygulama ayağa kalksa bile entegrasyon kuyruğu bozulmuş, kullanıcı oturumu kopmuş veya dış sistem yönlendirmesi güncellenmemişse kurumsal tarafta kesinti bitmiş sayılmaz.
Neden aktif-pasif model hâlâ yaygın?
Kurumsal ERP yüklerinde aktif-aktif model her zaman ekonomik veya operasyonel olarak mantıklı değildir. Lisans maliyetleri, veri tutarlılığı gereksinimi ve kritik süreçlerin sıralı işlenmesi nedeniyle aktif-pasif yaklaşım çoğu durumda daha kontrollü bir tercih olur. Ancak bu tercih, pasif bölgenin gerçekten hazır tutulduğu anlamına gelmelidir.
Pasif taraf yalnızca “sunucular var” seviyesinde bırakılıyorsa felaket kurtarma değil, iyimserlik yönetiliyordur.
Planın merkezine hangi bileşenler alınmalı?
ERP sistemlerinde en kritik katmanlar genellikle şunlardır:
- Uygulama sunucuları ve oturum yönetimi
- Veritabanı ve transaction tutarlılığı
- Mesaj kuyruğu veya entegrasyon aracısı
- Dış sistem bağlantıları
- Batch ve zamanlanmış iş akışları
Bu bileşenlerden yalnızca biri atlanırsa failover teoride mümkün görünür, pratikte ise iş birimleri üretime dönemeyebilir.
Veri tutarlılığı için neye dikkat edilmeli?
Aktif-pasif yapıda ilk soru “kaç dakikada ayağa kalkarız?” değil, “hangi veri noktasına döneriz?” olmalıdır. Çünkü bazı ERP süreçlerinde birkaç dakikalık veri kaybı bile finansal veya operasyonel uzlaşma gerektirir.
Bu yüzden aşağıdaki başlıklar net tanımlanmalıdır:
- Hedeflenen RPO ve RTO değerleri
- Hangi tablolar veya modüller eşzamanlıya yakın korunmalı
- Entegrasyon mesajlarının yeniden oynatılma stratejisi
- Failback sırasında veri çatışmasının nasıl engelleneceği
Ağ ve yayın katmanı neden ayrı başlık olmalı?
Birçok kurum veri replikasyonunu tasarlar ama kullanıcıyı ve entegrasyon partnerini yeni bölgeye nasıl yönlendireceğini geç düşünür. Sağlam tasarımda şu katmanlar hazır olmalıdır:
- DNS failover veya kontrollü yönlendirme politikası
- İç ağ ACL ve firewall kurallarının iki bölge için eşlenik olması
- VPN, MPLS veya özel hat terminasyonlarının pasif bölgede doğrulanması
- Gerekirse üçüncü tarafların erişim allowlist bilgilerinin önceden tanımlanması
Felaket anında ağ ekibi ayrı, uygulama ekibi ayrı keşif yapıyorsa kaybedilen süre hızla büyür.
Operasyon rolleri nasıl tanımlanmalı?
Aktif-pasif senaryolarda teknik doğruluk kadar komuta netliği de önemlidir. Benim önerdiğim yapı şu şekilde:
- Incident komutanı: Karar akışını ve iletişimi yönetir.
- Altyapı sahibi: Bölge aktivasyonu, ağ ve compute adımlarını yürütür.
- Uygulama sahibi: ERP servis sağlığını ve batch etkisini doğrular.
- Entegrasyon sahibi: Dış sistem akışlarını test eder.
Bu roller önceden net değilse teknik ekipler aynı işi iki kez kontrol ederken bazı kritik adımlar sahipsiz kalır.
Tatbikat yapmadan plan geçerli sayılır mı?
Hayır. Özellikle ERP gibi kesinti maliyeti yüksek ortamlarda gerçekçi tatbikat olmadan belgeye güvenmek doğru değildir. İyi tatbikatlarda:
- Belirli modüller için sentetik iş senaryosu koşturulur.
- Kullanıcı girişi, kritik işlem akışı ve raporlama birlikte test edilir.
- Dış sistem entegrasyonlarından en az bir uçtan uca örnek akış doğrulanır.
- Tatbikat sonrası iyileştirme listesi tarih ve sahiplik ile kapatılır.
Sonuç
ERP altyapılarında aktif-pasif felaket kurtarma, ikinci lokasyon kiralamaktan ibaret değildir. Asıl değer; veri, yayın ve operasyon katmanlarının aynı toparlanma hikâyesine bağlanmasında oluşur. Kurumsal teknoloji mimarisinde güvenilirlik arayan ekipler için doğru soru “DR ortamımız var mı?” değil, “gerçek bir kesintide iş süreçlerini düzenli biçimde geri getirebiliyor muyuz?” olmalıdır.