Felaket Kurtarma Planı (DRP) Hazırlama: 8 Adımda BCP

Bir Pazartesi sabahı ofise geldiğinizde sunucu odası su altında. Yangın tüpü patlamış, sigorta yapacağı zararı tespit ediyor. "Şimdi ne yapacağız?" sorusuna cevap için 5 kişiye birden danışmak, telefonun ucunda bekleyen IT'yi tekrarlanan sorularla yormak ve bu arada müşteri taleplerini kaçırmak — felaket anında işlerin tipik seyri. Bunun yerine bir felaket kurtarma planı (DRP) varsa, herkes ne yapacağını bilir, kararlar önceden alınmıştır, yalnızca uygulama gereklidir. Bu rehber KOBİ ölçeğinde uygulanabilir bir DRP/BCP iskeletini 8 somut adımda gösterir.

DRP ve BCP Farkı

İki kavram sık karıştırılır:

• BCP (Business Continuity Plan — İş Sürekliliği Planı): Tüm iş süreçleri için kapsam. "Müşteri çağrılarına nasıl cevap veririz, fatura nasıl kesilir, depodan nasıl mal sevk edilir" gibi operasyonel sorulara cevap verir.
• DRP (Disaster Recovery Plan — Felaket Kurtarma Planı): BCP'nin BT bileşeni. "Sunucu çökerse nasıl kurtarılır, e-posta sistemine nasıl dönülür" gibi teknolojik sorulara cevap verir.

KOBİ'de ikisi tek dokümanda birleştirilebilir; kâğıt üstünde "DRP/BCP" denilir ve hem operasyon hem BT kapsanır.

Adım 1: Kapsam ve Hedef Belirleme

Plan ne kadar derin olacak? KOBİ için pratik kapsam:

• Hangi felaketleri kapsayacağız? — yangın, sel, fidye yazılımı, donanım arızası, uzun elektrik kesintisi, salgın, kritik personel kaybı
• Hangi sistemler/süreçler kritik? — muhasebe, e-posta, dosya sunucusu, müşteri portalı
• Plan hangi süre için? — 24 saat içinde geçici, 7 gün içinde tam ayağa kalkış

Kapsam belirleme yöneticilerle birlikte yapılır; sadece IT'nin işi değildir. Üst yönetimin onayı sonraki adımlara meşruiyet katar.

Adım 2: Kriz Yönetim Ekibi

Kim ne yapacak? Önceden belirlenmiş roller kriz anında sürtünmeyi azaltır:

• Kriz lideri: Genellikle CEO/sahip. Final karar makamı.
• BT lideri: Teknik kurtarma sürecini yönetir.
• İletişim sorumlusu: Müşteri, çalışan, basın iletişimi.
• Operasyon sorumlusu: İş akışlarının manuel devamı.
• Saha lideri: Fiziksel iyileşme (yangın, sel sonrası).

Her rol için ana ve yedek kişi belirlenir. "Sahibinde X olursa kim karar verecek?" sorusu cevaplanmalıdır. İletişim listesinde herkesin telefonu, alternatif numara, e-postası yazılı tutulur.

Adım 3: İş Etki Analizi (BIA)

Hangi sistem ne kadar kritik? Sıralama bütçeyi etkiler. KOBİ ortamında basit BIA tablosu:

Sayılar tahminidir; hesaba dahil edilmesi gereken: gelir kaybı, müşteri kaybı, geç teslim cezaları, çalışan boşa harcanan süreler. Üst yönetimle bu sayılar oturup belirlenir.

Adım 4: RTO ve RPO Tanımları

Her sistem için hedeflenen kurtarma zamanı (RTO) ve kabul edilebilir veri kaybı (RPO) yazıya dökülür. Detay için RTO/RPO rehberimize bakın. Bu sayılar sonraki adımdaki teknoloji seçimini belirler.

Adım 5: Kurtarma Prosedürleri

En önemli ve genellikle eksik kalan adım. Her kritik sistem için adım adım nasıl ayağa kaldırılacağı yazılır. Örnek:

Sistem: Muhasebe Sunucusu (Windows Server 2022 + SQL)

Senaryo: Donanım arızası, sunucu açılmıyor.

Prosedür:

1. Yedek sunucuyu ofis deposundan getir (etiketli rafta)
2. Network kablo ve power bağla
3. BIOS'tan boot order kontrol et — SSD ilk
4. Veeam Console'a admin olarak gir (hesap: dr-admin, parola: kasada)
5. "Restore entire VM" → kaynak: 2026-04-26 21:00 yedeği → hedef: yedek sunucu
6. Restore süresince otomatik IP atama; eski sunucunun IP'si kullanılacak (192.168.1.50)
7. Tahmini restore süresi: 90 dakika
8. Restore sonrası SQL servisi otomatik başlar; manuel kontrol et
9. ERP yazılımı bir test kayıt kaydetmeyi dene
10. Çalışanlara duyuru: "sistem hazır, login olabilirsiniz"

Bu prosedür kâğıda basılı + IT klasöründe + bulut Drive'da bulunmalı. Kriz anında tıklama tıklama izlenebilir olmalı.

Adım 6: İletişim Planı

Kriz anında kim, nasıl, neyi haber verecek? Üç yön:

• İçeride: Çalışanlara durumun ne olduğu, ne zaman normalleşeceği, geçici çalışma yöntemi (örneğin: "Bugün e-posta yok, WhatsApp grubu üzerinden iletişim"). 1 saat içinde mesaj atılmalı.
• Müşterilere: Etkilenen müşteriye proaktif iletişim. Sorulmadan haber verilmesi güven artırır. "Sistemlerimizde kısa süreli bir aksaklık yaşanıyor, X saat içinde çözülecek" tarzı net mesaj.
• Tedarikçilere/iş ortaklarına: Sevkiyat, teslimat, faturalama gecikecekse önceden haber. Kontrat şartlarına dikkat (geç teslim cezası vb).

Hazır şablonlar plan dokümanında olur. Kriz anında yazı bulmak yerine yapılı kalıp yapıştırılır.

Adım 7: Test ve Tatbikat

Test edilmemiş plan kâğıt üstünde tatlı cümlelerden ibarettir. KOBİ ortamı için pratik test takvimi:

• 3 ayda bir küçük test: Tek dosyayı, tek e-postayı yedekten geri yükleme. 1 saatlik egzersiz.
• 6 ayda bir orta test: Bir kritik sistemin tam restore. Test sunucusuna restore et, çalıştığını doğrula. Yarım gün egzersiz.
• Yılda 1 büyük tatbikat: "Sunucu odamız tamamen yandı" senaryosu. Ekibin tüm rollerinin uygulanması, gerçek restore + iletişim + operasyonel devam denemesi. 1-2 günlük egzersiz.

Tatbikat sonrası raporlama yapılır: ne çalıştı, ne yetmedi, hangi prosedür güncellenmeli. Bu raporlar planın sonraki revizyonunun temelini oluşturur.

Adım 8: Revizyon ve Güncelleme

Plan canlı bir dokümandır. Şu durumlarda mutlaka güncellenir:

• Yeni bir sistem devreye girince
• Çalışan sayısı %20+ değişince
• Fiziksel taşınma olunca
• Yeni bir tehdit (ör. yeni ransomware varyantı) öne çıkınca
• Test sonucunda eksik bulunduğunda

Yıllık formal review (yöneticilerin onayıyla) zorunlu olarak yapılır. Plan tarihi, versiyonu, son test tarihi belge başında görünür.

Yaygın Hatalar

• Plan yazıp dolaba kaldırmak: Test edilmeyen plan en başarılı şekilde başarısız olur. "Yıllık 1 tatbikat" şartını esnetmeyin.
• Sadece IT'yi sürece dahil etmek: İş sürekliliği BT'nin tek başına çözebileceği konu değil. Üst yönetim, finans, operasyon, müşteri ilişkileri katılmalı.
• Tek sayfalık ad listesi yapıp "plan" demek: Pratik prosedürler yoksa kriz anında imkansız uygulanır. Her kritik sistem için adım adım talimat şart.
• Eski versiyonu güncellememek: Plan 3 yıl önce yazılmış ve hâlâ aynı; bu sürede sunucular değişmiş, çalışanlar gitmiş, yedekleme yazılımı upgrade olmuş. Eski plan yanlış yönlendirir.
• Kâğıt çıktıyı unutmak: Dijital yangın kapsayıcı senaryoda dijital plan da kayıp olabilir. Kâğıt çıktı + farklı lokasyon kopyası bulundurun.

Sıkça Sorulan Sorular

Ekip kim olmalı? IT bölümümüz yok, dış kaynaktan IT alıyoruz.

Bu durumda IT lideri rolünü dış servis sağlayıcı (Yamanlar Bilişim gibi) üstlenir; sözleşmeye DR sorumluluğu net yazılmalıdır. Kriz anında ulaşılabilir 7/24 hat olmalı, RTO sayısına bağlı SLA tanımlanmalıdır.