Şirketiniz için kapsamlı felaket kurtarma planı (DRP) hazırlama kılavuzu: Kriz komitesi görev dağılımı, acil durum iletişim zinciri ve eylem adımları.
Hızlı Özet (TL;DR)
Felaket Kurtarma Planı (DRP - Disaster Recovery Plan), siber saldırı, donanım çökmesi, yangın, su baskını veya bölgesel altyapı kesintisi gibi bir kriz anında kimin ne yapacağını, hangi sistemin hangi sırayla ayağa kaldırılacağını ve hangi dış tedarikçilerden destek alınacağını belirleyen resmi bir şirket anayasasıdır. Plansız bir felaket anında panik, yetki karmaşası ve saatlerce süren kararsızlık yaşanır; hatta yanlış müdahaleler nedeniyle kurtarılabilecek veriler bile kalıcı olarak silinebilir. Kapsamlı ve ISO 22301 İş Sürekliliği Yönetim Sistemi standartlarına uyumlu bir DRP; İş Etki Analizi (BIA), RTO/RPO hedefleri, kriz komitesi görev listesi, acil durum iletişim zinciri, bağımlılık haritası ve adım adım kurtarma talimatlarını (Runbook) içerir.
1. Hazırlık Aşaması: İş Etki Analizi (BIA) ve RTO / RPO Matrisi
Bir felaket kurtarma planı yazmaya başlamadan önce şirketin hangi bilgi teknolojileri servisine ne kadar tahammülü olduğunu matematiksel olarak ölçmek gerekir. İş Etki Analizi (Business Impact Analysis - BIA) adı verilen bu çalışmada, finans, üretim, lojistik ve satış departmanlarıyla görüşülerek her bir yazılım ve sunucunun durması halinde saatlik maddi, hukuki ve operasyonel kayıp hesaplanır:
- RTO (Recovery Time Objective - Kurtarma Süresi Hedefi): Bir sistem çöktükten sonra en geç kaç dakika veya saat içinde tekrar çalışır hale getirilmesi gerektiğini tanımlar. Örneğin; sevkiyat barkod ve e-İrsaliye sisteminin RTO değeri 30 dakika iken, eski yıllara ait arşiv raporlama sunucusunun RTO değeri 48 saat olabilir.
- RPO (Recovery Point Objective - Kurtarma Noktası Hedefi): Felaket anında şirketin geriye dönük en fazla kaç dakikalık veri kaybını tolere edebileceğini gösterir. RPO değeri 15 dakika olan bir ERP veritabanı için günde bir kez gece yedek almak yetersizdir; her 15 dakikada bir ZFS anlık görüntüsü (snapshot) veya veritabanı işlem kütüğü (transaction log) replikasyonu çalıştırılmalıdır.
- MTPD (Maximum Tolerable Period of Disruption): İşletmenin geri dönüşü olmayan ticari itibar veya pazar kaybına uğramadan önce katlanabileceği maksimum toplam kesinti süresidir.
2. Bir DRP Dokümanında Bulunması Gereken 5 Ana Bölüm
ISO 22301 ve NIST SP 800-34 standartlarına uygun, hem iç denetimlerden hem de tedarik zinciri güvenlik denetimlerinden tam not alan bir felaket kurtarma planının omurgası beş temel bileşenden oluşur:
| Bölüm | İçerdiği Kritik Bilgiler | Neden Gereklidir? | Güncelleme Periyodu |
|---|---|---|---|
| 1. Kriz Komitesi & Roller | Karar verici liderler, yedek vekiller, teknik kurtarma ekibi ve halkla ilişkiler/hukuk sorumluları | Kriz anında yetki karmaşasını, çift başlılığı ve panik yönetimini önler | 6 ayda bir veya personel değişiminde |
| 2. İletişim Çağrı Ağacı | Personel, bulut/ISP sağlayıcıları, donanım üreticileri, siber sigorta, KVKK/USOM irtibat numaraları | Kurumsal telefon santrali ve e-posta sunucusu çöktüğünde alternatif kanallardan ulaşım sağlar | 3 ayda bir doğrulama |
| 3. Sistem Öncelik Sırası | Tier 1 (Kritik), Tier 2 (Önemli) ve Tier 3 (Destek) sunucuların bağımlılık ve açılış sıralaması | Kimlik doğrulama ve veritabanı açılmadan uygulama sunucusunun başlatılması hatasını önler | Yeni sunucu/servis eklendiğinde |
| 4. Teknik Kurtarma Rehberi | Adım adım konsol komutları, çevrimdışı kasa erişimi, VLAN/IP tabloları ve DNS yönlendirmeleri | Asıl sistem yöneticisi ulaşılabilir olmasa dahi yedek uzmanın sistemi hatasız açabilmesini sağlar | Her mimari değişiklik sonrası |
| 5. Denetim ve Güncelleme | Yıllık revizyon geçmişi, yapılan DR tatbikatlarının süre ölçümleri ve tespit edilen eksikler | Dokümanın kağıt üzerinde eskimesini önler ve yaşayan bir kılavuz kalmasını güvenceye alır | Yılda en az 2 kez tatbikat sonrası |
3. Kriz Anında Çağrı Ağacı (Call Tree) ve Eskalasyon Süreci Nasıl Çalışır?
Bir felaket gerçekleştiğinde (örneğin gece saat 03:00’te sistem odasında duman sensörü alarmı veya fidye yazılımı saldırısı nedeniyle sanal makinelerin şifrelenmesi), kimin kimi arayacağı ve kimin “Felaket Kurtarma Moduna Geçiş” (Failover) emri vereceği saniyesi saniyesine belli olmalıdır:
- İlk Tespit ve Doğrulama (0–15. Dakika): İzleme sistemi (Zabbix/Prometheus) veya gece vardiyası amiri Nöbetçi Sistem Yöneticisini arar. Sistem yöneticisi sorunun basit bir servis takılması mı yoksa gerçek bir felaket mi olduğunu teşhis eder.
- Kriz İlanı ve Eskalasyon (15–30. Dakika): Tahmini çözüm süresi tanımlı RTO sınırını aşacaksa, Bilgi İşlem Yöneticisi Kriz Masası Başkanına (Genel Müdür, COO veya CTO) durumu raporlar ve resmi “DRP Aktivasyon Onayı” alır.
- Paralel Bildirim ve Görev Dağılımı: Kriz Masası onay verdiğinde İletişim Sorumlusu, şirket içi sunuculardan bağımsız bir kanal (bulut tabanlı şifreli mesajlaşma veya SMS ağacı) üzerinden teknik ekibi ve departman müdürlerini toplar.
- Dış Paydaş ve Yasal Bildirimler: Olay bir siber saldırı ve kişisel veri ihlali içeriyorsa, Hukuk Müşaviri ve KVKK İrtibat Kişisi 72 saatlik yasal bildirim sürecini ve USOM/SOME raporlamasını başlatır. Kimse kriz anında “Şimdi kimi arasam?” diye düşünmez; herkes kendi görev kartındaki adımları icra eder.
Sistem Önceliklendirme ve Bağımlılık Mimarisi (Tiering)
Tüm sunucuları aynı anda yedekten geri yüklemeye çalışmak, hem depolama (Storage IOPS) hem de ağ bant genişliğini kilitleyerek kurtarma süresini saatlerce uzatır. Bu nedenle DRP içinde katı bir katmanlandırma uygulanır:
- Tier 0 (Temel Altyapı ve Ağ): Güvenlik duvarı (Firewall), çekirdek anahtarlar (Core Switch), DHCP/DNS servisleri ve Active Directory / LDAP kimlik doğrulama sunucuları. Bu katman ayağa kalkmadan diğer hiçbir sunucu birbirini bulamaz ve oturum açamaz.
- Tier 1 (Hayati Üretim ve Kurumsal Sistemler): Ana ERP veritabanı, Ortak Dosya Sunucusu ve Yedekleme havuzları, MES üretim takip sistemi ve e-Fatura/e-İrsaliye geçitleri (Hedef RTO: 15 dk – 2 saat).
- Tier 2 (Operasyonel İş Uygulamaları): Kurumsal e-posta sunucusu, CRM, kalite doküman yönetim sistemi ve BI raporlama araçları (Hedef RTO: 4 – 12 saat).
- Tier 3 (Geliştirme ve Arşiv Sistemleri): Test/Stage ortamları, yazılım geliştirme sunucuları ve geçmiş yıl soğuk arşivleri (Hedef RTO: 24 – 72 saat).
4. Runbook: Adım Adım Teknik Talimat Kitapçığı
Bir DRP’nin en pratik ve hayat kurtaran bölümü “Runbook”tur. Krizin yarattığı yüksek stres altında en deneyimli mühendisler bile temel komutları unutabilir. Bu nedenle Runbook sayfalarında yuvarlak teorik cümleler değil, kopyala-yapıştır netliğinde sıralı komutlar ve ekran adımları yer alır:
- 1. Adım (İzolasyon): Fidye yazılımı şüphesi varsa ana omurga anahtarında (Core Switch) üretim VLAN’ı ile sunucu VLAN’ı arasındaki portları kapat.
- 2. Adım (Depolama Geri Dönüşü): İkincil lokasyondaki TrueNAS yönetim arayüzüne bağlan,
tank/erp_prodveri kümesini seç ve en son temizreadonlyanlık görüntüyü (snapshot) klonlayarak ESXi/Proxmox kümesine iSCSI/NFS olarak bağla. - 3. Adım (Ağ ve Yönlendirme): Savunma Sanayii ve İmalat Siber Güvenlik standartlarına uygun yapılandırılmış güvenlik duvarı üzerinde WAN/VPN kurallarını ikincil sunucu IP bloğuna yönlendir.
- 4. Adım (Uygulama Doğrulama): ERP servislerini başlat, son işlenen stok hareketini muhasebe ekranından kontrol et ve kullanıcı erişimini kademeli olarak aç.
Basılı (Hardcopy) Kopya ve Çevrimdışı Erişim Zorunluluğu
Şirketlerin yaptığı en ölümcül hata, hazırladıkları mükemmel Felaket Kurtarma Planı PDF dosyasını yine çöken dosya sunucusunun içinde saklamaktır. Sunucular şifrelendiğinde veya sistem odasında elektrik kesildiğinde o PDF dosyasına kimse ulaşamaz. DRP dokümanı ve acil durum ağ topolojisi mutlaka su geçirmez bir klasörde basılı (hardcopy) olarak yangın kasasında ve Kriz Komitesi üyelerinin şirket ağı dışındaki güvenli şifreli mobil cihazlarında çevrimdışı (offline) erişilebilir şekilde bulundurulmalıdır.
Şirketinize özel, uygulanabilir ve resmi denetimlerden tam not alan felaket kurtarma planları hazırlamak için Ortak Dosya Sunucusu ve Yedekleme, siber dayanıklılık denetimleri için Sızma Testi ve Pentest ve altyapı danışmanlığı için Özel Yazılım Geliştirme sayfalarımıza başvurabilirsiniz.
Sıkça Sorulan Sorular
İş Sürekliliği Planı (BCP) ile Felaket Kurtarma Planı (DRP) arasındaki fark nedir?
İş Sürekliliği Planı (BCP - Business Continuity Plan), bir kriz anında şirketin tüm ticari, lojistik, insan kaynakları ve üretim operasyonlarının nasıl devam edeceğini kapsayan üst çerçevedir (örneğin fabrikanın başka bir vardiyaya kaydırılması veya alternatif tedarikçiden mal çekilmesi). Felaket Kurtarma Planı (DRP) ise BCP’nin bir alt kümesi olup doğrudan BT altyapısının, sunucuların, ağ cihazlarının, veritabanlarının ve yazılımların kesinti sonrasında nasıl ve hangi sırayla geri yükleneceğini adım adım tanımlayan teknik eylem planıdır.
Hazırlanan bir Felaket Kurtarma Planı ne sıklıkla güncellenmeli ve test edilmelidir?
BT altyapıları yaşayan organizmalardır; yıl içinde yeni sanal sunucular açılır, IP blokları değişir, yeni ERP modülleri devreye alınır veya kriz komitesindeki personeller işten ayrılabilir. Bu nedenle DRP dokümanı her önemli altyapı değişikliğinde anında, rutin olarak ise en geç 6 ayda bir güncellenmelidir. Ayrıca dokümandaki adımların gerçekte çalışıp çalışmadığını doğrulamak için yılda en az iki kez (biri masaüstü senaryosu, diğeri izole ağda canlı geri yükleme olmak üzere) DR tatbikatı yapılmalıdır.
Küçük ve orta ölçekli üretim işletmeleri (KOBİ) için de kapsamlı bir DRP şart mıdır?
Kesinlikle şarttır; hatta siber saldırı ve veri kaybı istatistiklerine göre, hazırlıksız yakalanan KOBİ’lerin %60’ı yedi günden uzun süren bir veri ve operasyon kaybının ardından 6 ay içinde ciddi finansal krize girmektedir. KOBİ ölçeğindeki bir fabrikada yüzlerce sayfalık bürokratik dokümanlar yerine; sunucu envanterini, 3-2-1-1-0 yedekleme şemasını, bulut/ikincil NAS geri dönüş adımlarını (Runbook) ve acil iletişim numaralarını içeren 15-20 sayfalık yalın ve pratik bir DRP hayati koruma sağlar.