Felaket kurtarma planı, bir kesintiden sonra hangi sistemlerin hangi sırayla geri döneceğini belirler. RPO ve RTO kavramlarını işletmenizin gerçek ihtiyaçlarına göre nasıl kullanacağınızı öğrenin.
Elektrik ya da internet kesintisi, donanım arızası, yanlış silme, siber olay veya fiziksel hasar günlük işi beklenmedik bir anda durdurabilir. Felaket kurtarma planı, böyle bir durumda hangi sistemin önce ayağa kalkacağını, verinin nereden geri getirileceğini ve kararları kimin vereceğini önceden belirleyen çalışma düzenidir. Amaç felaketi tahmin etmek değil, belirsizlik anında düzenli hareket edebilmektir.
İş etkisini anlayın
Planı teknoloji listesiyle değil, iş süreçleriyle başlatın. Sipariş alma, üretim, satış, muhasebe, müşteri hizmetleri ya da saha ekibinin hangi uygulamalara bağlı olduğunu yazın. Her süreç için bir kesintide kimlerin etkileneceğini, geçici olarak nasıl çalışılabileceğini ve hangi sistemin önce dönmesi gerektiğini konuşun.
Bu değerlendirmeye işletme sahipleri, bölüm yöneticileri ve BT sorumluları birlikte katılmalıdır. Teknik ekip sistemlerin nasıl çalıştığını bilir; iş birimleri ise durmanın ne anlama geldiğini. Farklı öncelikleri tek bir listede uzlaştırmak planı kullanılabilir kılar.
RPO ve RTO nedir?
RPO (Recovery Point Objective, kurtarma noktası hedefi), kabul edilebilir en fazla veri kaybını zaman cinsinden ifade eder: kurtarmadan sonra en geç hangi ana ait veriye dönebilmeniz gerektiğini gösterir. Örneğin bir sistem yalnızca gece yedekleniyorsa, gün içinde yapılan değişiklikler kaybolabilir; bu düzenin karşılayabildiği RPO yaklaşık 24 saattir. Bu, her sistemi aynı sıklıkta yedeklemeniz gerektiği anlamına gelmez; sıklık, verinin kritikliğine göre belirlenir.
RTO (Recovery Time Objective, kurtarma süresi hedefi) ise kesinti başladıktan sonra bir sistemin en geç ne kadar sürede yeniden kullanılabilir olması gerektiğini belirler. Bu süre, işin kabul edilemez zarar görmeden katlanabileceği en uzun kesinti süresinin içinde kalmalıdır. RTO bir hedef ve karar aracıdır; satın alınan bir ürünün kendiliğinden sağladığı bir vaat değildir. Daha kısa RPO ve RTO genellikle daha fazla hazırlık, ek altyapı ve maliyet gerektirir.
RPO ve RTO değerlerini teknik ekip tek başına belirlememelidir. Bu değerler, işin ne kadar veri kaybını ve kesintiyi kaldırabileceğine ilişkin yönetim kararıdır; teknik ekip ise bu hedeflerin hangi altyapı ve maliyetle karşılanabileceğini ortaya koyar.
Planın temel parçaları
Sistem ve bağımlılık envanteri
Sunucuları, bulut uygulamalarını, dosya alanlarını, ağ cihazlarını, e-postayı, internet bağlantısını ve kimlik doğrulama hizmetlerini listeleyin. Her uygulamanın çalışmak için hangi hizmetlere bağlı olduğunu ekleyin. Satış uygulaması internete, kullanıcı hesaplarına, veritabanına ve dosya depolamaya ihtiyaç duyuyorsa bunların hepsi kurtarma sırasında yer almalıdır; aksi hâlde "uygulamayı geri getirdik ama kimse giriş yapamıyor" gibi sürprizler yaşanabilir. Karmaşık bir şema yerine, olay anında bakılabilecek kısa bir sıralama daha kullanışlıdır.
Yedekleme ve geri yükleme tasarımı
Hangi verinin ne sıklıkla, nereye ve kimin sorumluluğunda yedeklendiğini belgeleyin. Yedeklerin ana sistemden ayrı bir ortamda tutulması, yedeklere erişimin sınırlanması ve geri yüklemenin düzenli denenmesi planın temel parçalarıdır; kopyaların dağılımı için 3-2-1 kuralı iyi bir başlangıç noktasıdır. Yedekleme başarısız olduğunda kimin uyarı alacağı da belli olmalıdır.
İletişim ve karar zinciri
Olay anında çalışanlara, müşterilere, hizmet sağlayıcılara ve yönetime kim bilgi verecek? Teknik sorumlu, uygulama sahibi, karar verecek yönetici, internet ve bulut hizmeti sağlayıcıları ve dış destek için güncel iletişim bilgilerini tutun. Bu liste ve planın kendisi, sistemler çalışmazken de erişilebilir olmalıdır; güvenli bir dijital kopyanın yanında çevrimdışı ya da basılı bir kopya bulundurun. Teknik müdahale, iş önceliği ve dış iletişim için ayrı sorumlular atanabilir.
Alternatif çalışma yöntemi
Kritik sistem dönene kadar işin nasıl yürüyeceğini yazın. Elle kayıt, telefonla sipariş, sınırlı erişim ya da başka bir lokasyondan çalışma gibi geçici yollar her işletmede farklıdır. Bu yöntemin ne zaman devreye gireceğini ve bu sürede tutulan kayıtların sonradan sisteme nasıl işleneceğini de belirleyin.
Planı adım adım oluşturun
İşe en kritik birkaç süreçle başlayın. Her biri için sistem sahibini, RPO ve RTO değerlerini, yedek kaynağını, kurtarma sorumlusunu ve doğrulama adımını yazın. Ağ, internet, kullanıcı hesabı ya da lisans erişimi gibi ayrıntılar kurtarmayı geciktirebilir; bunları da bağımlılıklar arasına ekleyin.
Kurtarma adımlarını yalnızca teknik terimlerle bırakmayın. Süreci kimin başlatacağı, kimin onaylayacağı ve iş birimine "hazır" bilgisini kimin vereceği açık olsun. Her adımın yanına gerekli erişim bilgisinin ya da belgenin nerede bulunduğunu yazın; ancak parolaları ve erişim anahtarlarını plan dosyasına koymayın.
Planın yönetim onayı ve bütçeyle bağlantısı olmalıdır. Hedeflenen süreye ulaşmak için ek yedek alanı, alternatif internet bağlantısı ya da destek anlaşması gerekiyorsa karar vericiler bunu bilmelidir; aksi hâlde planda yazanla gerçekte sağlanan kaynaklar arasında açık oluşur.
Test ve iyileştirme
Test edilmeyen plan bir varsayımdır. İlk aşamada masa başı tatbikatla bir kesinti senaryosunu ekipçe adım adım yürütün. Ardından seçilmiş bir veri ya da sistem için gerçek bir geri yükleme deneyin.
Her testte bütün sistemi kapatmak gerekmez. Bir kullanıcı hesabının geri kazanılması, örnek bir klasörün yedekten dönmesi ya da iletişim listesinin aranması gibi dar kapsamlı denemeler de değerli bilgi verir. Her denemede geçen süreyi, karşılaşılan engelleri ve sonraki iyileştirme adımını not edin; bu kayıtlar RPO ve RTO hedeflerinin gerçekçi olup olmadığını gösterir.
Testte başarısız olmak da değerli bir sonuçtur, çünkü sorunları gerçek olaydan önce görünür kılar. Planı yeni bir uygulama, yeni lokasyon, hizmet sağlayıcı değişimi ya da görev değişikliği gibi her büyük değişiklikten sonra güncelleyin.
Kurtarma sonrası doğrulama
Bir sistemi açmak kurtarmanın sonu değildir. Uygulamanın doğru veriyle çalıştığını, kullanıcıların gerekli erişime sahip olduğunu ve iş biriminin temel işlemleri yapabildiğini birlikte doğrulayın. Kısmi geri dönüşte hangi işlemlerin ertelendiğini görünür tutun. Siber olaylarda ise geri yüklemeye başlamadan önce saldırganın erişiminin kapatıldığından ve kullanılan yedeğin olaydan etkilenmemiş bir zamana ait olduğundan emin olun.
Normal çalışma düzenine dönüş ve geçici çözümlerin kaldırılması kararını sorumlu kişi vermelidir. Olay kapandıktan sonra kısa bir değerlendirme yapın: hangi adım iyi çalıştı, hangisi gecikme yarattı? Bu notlar bir sonraki tatbikatı ve gerçek bir olaydaki kararları güçlendirir.
Kontrol listesi
- Kritik iş süreçleri ve bunları destekleyen sistemler belirlendi mi?
- Her kritik süreç için RPO ve RTO iş birimleriyle kararlaştırıldı mı?
- Sistem bağımlılıkları ve kurtarma sırası yazılı mı?
- Yedeklerin konumu, sorumlusu ve geri yükleme denemesi belli mi?
- Plana ve iletişim listesine sistemler çalışmazken de erişilebiliyor mu?
- Kesinti sırasında kullanılacak alternatif çalışma yöntemi tanımlı mı?
- Plan masa başı tatbikatla ya da gerçek geri yüklemeyle test edildi mi?
- Yeni sistem ve görev değişikliklerinde plan güncelleniyor mu?