Bulut, Sunucu ve Yönetilen BT
Felaket Kurtarma Planı Hazırlamak İçin Teknik Kontrol Listesi
İş etkisi analizinden RTO ve RPO hedeflerine, kurtarma sırasından tatbikatlara kadar uygulanabilir bir felaket kurtarma planı için teknik kontrol listesi.
Planın kapsamını iş süreçlerinden başlayarak belirleyin
Felaket kurtarma planı hazırlamak, sunucuların nasıl yeniden açılacağını yazmaktan daha kapsamlıdır. Amaç, kesinti sonrasında kritik iş süreçlerini kabul edilen koşullarda yeniden çalıştırmaktır. Bu nedenle başlangıç noktası teknoloji listesi değil; satış, üretim, finans, müşteri hizmetleri ve operasyon gibi süreçlerin ihtiyaçları olmalıdır. Hangi hizmetin neden öncelikli olduğunu ilgili süreç sahibiyle birlikte belirleyin.
İş sürekliliği planı, işletmenin kesinti sırasında faaliyetlerini nasıl sürdüreceğini ele alır. Felaket kurtarma planı ise bunun teknik altyapı tarafına odaklanır; sistemlerin, verilerin, bağlantıların ve erişimlerin nasıl geri getirileceğini tanımlar. Yedekleme bu yapının önemli bir parçasıdır. Ancak yedeğin bulunması, uygulamanın çalışacağını, kullanıcıların bağlanacağını veya entegrasyonların doğru veri işleyeceğini tek başına göstermez.
Veri merkezi kaybı, bulut hizmeti kesintisi, fidye yazılımı, yanlış yapılandırma ve veri bozulması senaryolarını ayrı değerlendirin. Aynı kurtarma yöntemi her olay için uygun olmayabilir. Plan sahibi, onaylayan yönetici, kapsanan hizmetler ve kapsam dışındaki sistemler dokümanın başında yer alsın. Her süreç için kesintinin etkisini, kullanılabilecek geçici yöntemi ve biriken işlerin nasıl tamamlanacağını kaydedin. Böylece teknik öncelikler, işletmenin gerçek ihtiyaçlarına dayanır.
Karşılaştırma
RTO ve RPO hedeflerini iş etkisiyle ilişkilendirin
RTO, hizmetin kabul edilen düzeyde yeniden kullanılabilir olması için hedeflenen süredir.
RPO, kabul edilebilecek veri kaybının zaman cinsinden sınırıdır.
Hizmet ne kadar süre kullanılamaz kalabilir?
Ne kadar geriye dönük veri kaybı telafi edilebilir?
Öne çıkanlar
Sistem envanterini bağımlılıklarıyla birlikte çıkarın
Kurtarma envanteri yalnızca cihaz adlarını sıralamamalıdır. Her kayıt, hizmetin iş açısından önemini ve çalışmak için ihtiyaç duyduğu bileşenleri göstermelidir. Uygulama sunucusu açık olsa bile kimlik servisi, DNS veya veritabanı erişimi çalışmıyorsa iş süreci kesintide kalabilir. Envanteri süreç sahipleriyle doğrulayın ve dış hizmet bağımlılıklarını da ekleyin. İş önceliği ile teknik kurtarma sırasını birbirinden ayırın. Öncelikli bir uygulama, başka altyapı hizmetlerinin hazırlanmasını bekleyebilir. Bağımlılıkları görünür kılmak, kurtarma sırasında yanlış sırayla işlem yapılmasını önler. Yeni uygulama, ağ kuralı, sertifika veya sağlayıcı değişikliğinde envanterin güncellenmesi için sorumlu belirleyin. Planın güncelliğini yalnızca dönemsel gözden geçirmelere bırakmayın. Envanteri hazırlarken kurtarma için gereken bilgilerin nerede tutulduğunu da gösterin. Teknik ekibin kullandığı bir kayda erişim kesinti sırasında mümkün olmayabilir. Özellikle dış sağlayıcı bağlantılarını, destek başvuru yöntemlerini ve işletmenin kontrolünde olmayan ön koşulları görünür kılın. Belirsiz kalan bağımlılıkları tatbikatta sınanacak maddeler arasına alın.
Hizmet ve sorumlular
İş sürecini, teknik sahibi, iş birimi temsilcisini ve karar verebilecek yedek sorumluyu kaydedin.
Teknik bağımlılıklar
Kimlik, DNS, ağ, depolama, veritabanı, sertifika, lisans, zaman senkronizasyonu ve dış API bağlantılarını ilişkilendirin.
Kurtarma bilgileri
Yedek konumunu, geri yükleme yöntemini, yazılım sürümlerini, yapılandırma kayıtlarını ve hizmete özgü kabul testlerini belirtin.
Uygulama süreci
Kurtarma sırasını uygulanabilir adımlara dönüştürün
Kurtarma sırasını bağımlılık haritasından çıkarın. Her adım için sorumlu, ön koşul, işlem, başarı ölçütü ve başarısızlık durumunda izlenecek yolu yazın. Komutların veya otomasyonların hangi ortamda çalıştırılacağı açık olsun. Yönerge, işlemi normalde yapan kişi bulunmadığında başka bir yetkilinin de izleyebileceği açıklıkta hazırlanmalıdır. Ortama özgü ayrıntıları belirsiz ifadelerle geçiştirmeyin. Felaket ilanını, alternatif ortama geçişi ve hizmetin yeniden açılmasını kimin onaylayacağını belirleyin. Teknik doğrulama ile iş birimi kabulünü ayrı karar noktaları olarak ele alın. Kullanıcıları erken yönlendirmek tutarsız veriyle işlem yapılmasına neden olabilir. Aşağıdaki akışı başlangıç çerçevesi olarak kullanın; sıralamayı kendi mimarinize göre uyarlayın. Her adımın sonucunu olay kaydına ekleyin. Bir işlem beklenenden farklı sonuç verirse hangi koşulda durulacağını, kime danışılacağını ve önceki duruma nasıl dönüleceğini belirtin. Özellikle veri üzerinde değişiklik yapan işlemlerde geri alma sınırlarını önceden bilmek, olay sırasında kontrolsüz denemelerin önüne geçmeye yardımcı olur ve kararları izlenebilir kılar.
- 01
Olayı değerlendirin
Kesintinin kapsamını belirleyin, gerekli izolasyonu uygulayın ve kurtarma kararını kaydedin. Güvenlik olayında inceleme için gerekli kayıtları koruyun.
- 02
Altyapıyı hazırlayın
Ağ, yönetim erişimi, kimlik, DNS ve depolama bağımlılıklarını gereken sırada doğrulayın; alternatif ortamın kapasitesini kontrol edin.
- 03
Veriyi ve uygulamaları geri getirin
Uygun kurtarma noktasını seçin, tutarlılığı kontrol edin ve uygulamaları sırayla açın. Kuyrukların ve zamanlanmış işlerin aynı işlemi tekrarlama riskini değerlendirin.
Kontrol listesi
Planı hazır saymadan önce kanıtları kontrol edin
Tamamlandı işareti, yalnızca bir dokümanın bulunduğunu değil, ilgili adımın uygulanabildiğini göstermelidir. Açık maddeleri, iş etkilerini ve geçici önlemleri yönetimle paylaşın. Karşılanamayan hedefleri gizlemek yerine teknik eksik ve iş riski olarak kaydedin. Hazırlık düzeyini değerlendirirken altyapının yanında ekip kapasitesini ve işletim yükünü de dikkate alın. Ana ortama dönüşte hangi ortamın esas veri kaynağı olacağını açıkça belirleyin. Alternatif ortamda oluşan verinin aktarılması, geçiş sırasında yazma işlemlerinin yönetilmesi ve başarısız dönüşte izlenecek yol önceden tanımlanmalıdır. İki ortamın kontrolsüz biçimde aynı anda işlem kabul etmesini önleyecek mekanizmaları da doğrulayın. Dönüşü yalnızca trafik yönlendirme işlemi olarak değerlendirmeyin. Plan sürümünü, onay tarihini ve test kayıtlarını birlikte tutun. Kontrolleri altyapı değişiklikleriyle ilişkilendirin; değişiklik tamamlanırken ilgili kurtarma adımlarının gözden geçirilmesini sağlayın. Ana ortama dönüşten sonra yedekleme, izleme ve güvenlik kontrollerinin yeniden doğrulanmasını da planın parçası yapın. Hangi yönergenin geçerli olduğu olay sırasında tartışmalı kalmamalıdır.
- ✓
Kapsam ve hedefler
Kritik süreçler, RTO ve RPO hedefleri, kapsam dışı hizmetler ve karşılanamayan hedefler onaylandı mı?
- ✓
Envanter ve erişimler
Bağımlılıklar, sorumlular, kurtarma sırası, gerekli yetkiler ve başarı ölçütleri güncel mi?
- ✓
Yedekler ve alternatif ortam
Yedekler geri yüklenebiliyor mu; anahtarlar erişilebilir, kapasite yeterli ve uygulama verisi tutarlı mı?
- ✓
Ana ortama dönüş
Uygulama süreci
Senaryo bazlı tatbikatlarla planı sınayın
Tatbikat sıklığını sistemin kritikliği, değişiklik yoğunluğu ve ekip kapasitesine göre belirleyin. Mimari değişikliklerden sonra etkilenen adımları yeniden sınayın. Masa başı değerlendirme, karar ve iletişim eksiklerini; teknik geri yükleme testi ise erişim, veri ve uygulama sorunlarını ortaya çıkarabilir. Bu yöntemleri birbirinin alternatifi değil, tamamlayıcısı olarak kullanın. Yalnızca geri yükleme aracının çalışma süresini ölçmeyin. Sorumluya ulaşma, onay alma ve ortam hazırlama gibi beklemeleri de kaydedin. Test ortamı üretimden farklıysa sonuçlara etkisini belirtin. Eksik bir adımı geçici müdahaleyle tamamlamak, yönergenin yeterli olduğunu göstermez. Müdahaleyi kaydedin ve düzeltmeden sonra ilgili adımı yeniden test edin. Kullanıcının yapacağı temel işlemleri deneyerek iş sürecinin gerçekten çalıştığını doğrulayın. Tatbikatın başarı ölçütlerini başlamadan önce paylaşın. Böylece ekip yalnızca sistemi açmaya değil, kabul edilen hizmet düzeyini göstermeye odaklanır. Test sırasında ortaya çıkan süre farklarını, erişim engellerini ve veri tutarlılığı sorunlarını ayrı kaydedin. Bulguları önem sırasına koyarak hangi eksiklerin kurtarma hedeflerini doğrudan etkilediğini görünür hâle getirin.
- 01
Senaryoyu tanımlayın
Kullanılamayan bileşeni, üretime etkileri, durdurma koşullarını ve geri dönüş yöntemini önceden belirleyin.
- 02
Planı uygulayıp ölçün
Adımları yönergeyle yürütün; süreleri, erişim sorunlarını ve eksik bağımlılıkları kaydedin. İşlevleri ve son tutarlı veri noktasını doğrulayın.
- 03
Bulguları kapatın
Her eksik için sorumlu ve takip kaydı oluşturun. Dokümanı, otomasyonları ve iletişim listesini güncelleyin; gerekli adımları tekrar sınayın.
Planın bakımını ve sorumluluk paylaşımını sürdürün
Felaket kurtarma planı, bir defalık doküman değil, bakım gerektiren bir çalışma düzenidir. Envanterin güncellenmesi, erişimlerin sınanması ve tatbikat bulgularının kapatılması için zaman ve sorumluluk ayırın. Ekip bunları günlük operasyonla birlikte sürdüremiyorsa dış destek ihtiyacını yalnızca olay anındaki müdahale üzerinden değerlendirmeyin. Önce en kritik süreç için doğrulanmış bir kurtarma akışı oluşturup ardından diğer hizmetlere genişleyin.
Bikare’nin [Felaket Kurtarma ve Yedekleme Çözümleri](/yedekleme-ve-felaket-kurtarma) hizmetini, mevcut altyapınızla kurtarma hedefleriniz arasındaki ihtiyaçları değerlendirmek için inceleyebilirsiniz. Günlük bakım ve teknik takip ihtiyacı için [BT Bakım ve Teknik Destek Hizmetleri](/bt-bakim-ve-teknik-destek-hizmetleri) de değerlendirilebilir. Görüşmeye envanter, yedekleme düzeni, iş beklentileri ve son test bulgularıyla hazırlanmak, kapsamı somutlaştırır.
İşletmede kalacak karar yetkileriyle sağlayıcının teknik görevlerini ayrı yazın. İzleme, bakım, geri yükleme, tatbikat ve doküman güncelleme sorumluluklarını netleştirin. Planın uygulanabilirliği, yalnızca teknik araçlara değil, bu görevlerin düzenli olarak yerine getirilmesine de bağlıdır. Hizmet kapsamının dışında kalan işleri ve bunlardan sorumlu kişileri de görünür tutun.
Keşfetmeye devam et
İlgili içerik ve hizmetler
Konuyu tamamlayan Bikare içeriklerine göz atın.
