Felaket Kurtarma Planı: Hedeflerden Uygulamaya
Küçük bir ağ değişikliği bile bir servisi durdurabilir. Felaket Kurtarma Planı, yalnızca yazılı adımlardan oluşmaz; bu adımların uygulanabildiğini gösteren tatbikatlarla güncel tutulmalıdır.
Felaket kurtarma planı; bölge kaybı, yanlışlıkla silme, veri bozulması veya kritik bir sağlayıcının kullanılamaması karşısında hizmetin nasıl geri getirileceğini tanımlar. İş sürekliliği planının teknik bir parçasıdır: uygulama açıldığı halde ödeme, kimlik doğrulama veya sipariş teslimi çalışmıyorsa iş hedefi sağlanmış olmayabilir. Bu rehberde RTO/RPO hedeflerini, yedek testlerini ve uygulanabilir runbook adımlarını birlikte ele alacağız.
Örneğin kampanya sırasında 20 dakikalık bir kesintinin sipariş, destek ve gelir etkisini hesapla. Ardından her hizmet için ne kadar kesintinin ve veri kaybının kabul edilebileceğini belirle. Verilen süreler bir iş hedefidir; bunların teknik olarak karşılandığını tatbikatla göstermek gerekir.
RTO ve RPO hedeflerini doğru belirlemek
RTO nedir, neden herkes ondan söz eder?
RTO (Recovery Time Objective), kesinti başlangıcından üzerinde anlaşılan kullanılabilir hizmet düzeyine dönüşe kadar kabul edilen en uzun süredir. Gerçekte ölçülen kurtarma süresiyle aynı şey değildir. Hedef yalnızca dosya geri yüklemeyi değil; tespit, karar, erişim, altyapı hazırlığı, veri dönüşü, uygulama doğrulaması ve trafik geçişini de karşılayabilmelidir. Bir ödeme yolunun hedefiyle raporlamanın hedefi farklı olabilir.
RPO nedir, ne kadar veri kaybını göze alabilirsin?
RPO (Recovery Point Objective), olay anından önceki son kurtarılabilir tutarlı veri noktasıyla olay arasındaki kabul edilebilir kayıp aralığıdır. Kurtarmanın bittiği saate göre ölçülmez. Yalnızca günlük yedeklerle dönüyorsan son kullanılabilir yedekten sonraki işlemler kaybolabilir; başarısız bir yedek bu aralığı daha da büyütebilir. Seçilen RPO, yedek alma takviminden bağımsız olarak işin neyi tolere edebildiğini belirtir.
RTO/RPO’yu belirlemenin pratik yolu
Her kritik hizmet için sahibi, bağımlılıkları, minimum kabul edilebilir işlevleri, RTO ve RPO’yu kaydet. Örneğin kesinti 10:00’da başlasın, son tutarlı kurtarma noktası 09:56 olsun ve hizmet 11:00’de kabul ölçütlerini karşılasın. Ölçülen kurtarma süresi 60 dakika, veri kaybı penceresi 4 dakikadır. Hedefler RTO 90 dakika/RPO 5 dakika ise bu prova hedefleri karşılar; bu sonuç gelecekteki her olaya garanti değildir. Veri bozulması daha önce başladıysa bilinen sağlıklı noktayı ve kayıp aralığını ayrıca belirle.
Envanter ve kurtarma bağımlılıkları
Haritayı çizmeden yola çıkılmaz
Örneğin, gözden kaçan küçük bir webhook kritik servisleri birbirine bağlıyor olabilir. İşte bu yüzden envanter ve bağımlılıklar konusunu atlamak büyük risk. Uygulamalar, veritabanları, kuyruklar, dosya depoları, üçüncü parti API’ler, DNS kayıtları, e-posta sağlayıcıları… Hepsini bir anda çıkarmak göz korkutabilir ama parça parça mümkün. Bir ekip toplantısıyla başlayıp envanteri yapılandırmalar ve servis sahipleriyle doğrulayabilirsin.
Kritik yolun peşine düş
Kullanıcı kaydı, e-posta doğrulaması, ödeme, sipariş kuyruğu ve fatura akışını uçtan uca çiz. Kritik bir hizmetten önce hangi veri, ağ, kimlik veya anahtar bağımlılığının hazır olması gerektiğini belirle. Tek sunucu, tek bölge veya tek DNS sağlayıcısı gibi arıza alanlarını kaydet. Birden fazla kopyanın aynı hesabın, ağın veya silme yetkisinin altında kalması bağımsız koruma sağlamayabilir.
Gizli bağımlılıklar ve erişim
Bulut hesabı, domain kayıtçısı, DNS, sertifikalar, parola kasası ve MFA kurtarma yollarının kim tarafından kullanılabildiğini doğrula. Runbook’a sırların kendisini değil, kontrollü erişim yerini ve prosedürünü yaz. Normal SSO veya ana bölge kullanılamıyorken acil erişimin çalışması ve planın erişilebilir bir kopyasının bulunması gerekir. Yetki talebi ve anahtar erişimi için harcanan süre de kurtarma ölçümüne girer.
Yedek stratejisi ve geri dönüş testleri
Test kapsamı ve örnek takvim
Örnek başlangıç takvimi: haftalık küçük dosya/veritabanı dönüşü, aylık tam hizmet kurtarma provası ve üç ayda bir senaryo tatbikatı. Bu sıklıklar genel bir standart zorunluluğu değildir; kritikliği, veri hacmini, değişiklik hızını ve kurumun yükümlülüklerini dikkate al. Büyük sürüm, altyapı, yetki veya saklama değişikliğinden sonra ilgili testi yenile. Haftalık bir dosya testi, tüm uygulamanın kurtarılabildiğini kanıtlamaz.
Yedekleme ritmini RPO hedefine göre belirle
Bir dakikalık RPO hedefini günlük tam yedek tek başına karşılamaz. Veritabanının desteklediği tutarlı temel yedek ve kesintisiz gerekli WAL/binlog zinciri daha dar bir kurtarma noktası sağlayabilir. Artımlı yedek her zaman istenen saniyeye dönüş anlamına gelmez; yöntem ve sürüm bunu desteklemelidir. Replikasyon silinmeyi ve bozulmayı da kopyalayabilir, bu yüzden bağımsız korunmuş geçmiş noktalar gerekir. Başka bölgeye kopyalama yanında erişim/silme yetkilerini ayır, şifrele ve saklanan yedeklerin ihtiyaç duyduğu eski anahtarlara erişimi koru. 3-2-1 yaklaşımı, üretim dahil üç kopya, iki farklı medya türü ve bir tesis dışı kopya önerir. Tesis dışında bulunmak tek başına çevrimdışı veya silmeye karşı yalıtılmış olmak değildir.
Test ederken nasıl ölçersin?
Prova kaydına kesinti başlangıcını, tespit/karar zamanlarını, veri geri yükleme bitişini, uygulamanın kabul zamanını ve son tutarlı veri noktasını yaz. RTO hedefini toplam kurtarma süresiyle, RPO hedefini olay ile veri noktası arasındaki aralıkla karşılaştır. Dosya hash’i veya satır sayısı aktarım için yararlıdır; işlevsel doğrulama için aynı kurtarma noktasına ait beklenen sipariş toplamları, ilişkiler ve kritik kullanıcı akışları da gerekir.
Gözün her şeyin üstünde olsun
Yedeklerin tamamlanma durumu, yaşı, log zinciri sürekliliği, depo/anahtar erişimi ve kapasitesi izlenmelidir. Uygulama logları, metrikler ve alarmlar olayın kapsamını ve geri dönüşün başarısını belirlemeye yardımcı olur. İlgili yaklaşım için VPS merkezi loglama rehberini inceleyebilirsin; kurtarma sırasında gerekli kayıtların da ana arıza alanı dışında erişilebilir olmasını planla.
Uygulanabilir runbook şablonu
Runbook ne işe yarar?
Runbook, belirli bir senaryo için kimin hangi adımı hangi sırayla uygulayacağını anlatır. Başlık, sahibi, son doğrulama tarihi, sürümler, hedefler, ön koşullar, komutlar, başarı kanıtı ve başarısızlık dalı bulunmalıdır. Planı ilk kez kullanan yetkili bir ekip arkadaşının gözetimli tatbikatta uygulaması, eksik varsayımları ortaya çıkarabilir.
Örnek bir runbook iskeleti
“Ödeme servisini Bölge A kaybından sonra Bölge B’de kurtarma” örneğinde sıra şöyledir: olay kapsamını ve DR etkinleştirme kararını kaydet; hedef hesap/bölge, kapasite, anahtar ve yedek erişimini doğrula; eski yazıcının yeni yazı kabul etmesini engelle; izole hedefte veriyi doğrulanmış noktaya getir; ödeme sağlayıcısı ve kuyruk kayıtlarıyla uzlaştır; uygulamayı doğrula; kontrollü trafik geçişi yap ve sonucu izle. Eski veritabanını geri getirmek dışarıda alınmış ödemeleri geri almaz. Yeniden işleme çift tahsilata veya tekrar bildirime yol açmamalıdır.
Runbook yazarken küçük ama kritik detaylar
Her değiştirici adımda hedef, beklenen çıktı, işlemi durdurma koşulu ve geri dönüş yolu açık olmalıdır. Trafik Bölge B’ye geçip yeni yazılar kabul edildikten sonra Bölge A’nın eski snapshot’ına dönmek bu yazıları kaybedebilir. Failback öncesinde A’nın kullanılabilirliğini, B’deki yeni verinin taşınmasını/uzlaşmasını ve tek yazıcı durumunu doğrula. Kullanıcı etkisi olan her adımın karar sahibini ve izleme sorumlusunu kaydet.
Soğuk, ılık ve sıcak kurtarma seçenekleri
Soğuk, ılık ve sıcak yaklaşımlar
Bulut bağlamında yedekten yeniden kurma, ihtiyaç anında altyapıyı ve veriyi hazırlamayı gerektirir. Pilot light çekirdek parçaları hazır tutar fakat hizmet için ek başlatma/dağıtım ister. Warm standby, düşük kapasitede çalışan işlevsel bir kopyadır; tam yük için ölçekleme gerekir. Hot standby daha yüksek hazırlıkta bekleyen pasif hedef, active/active ise birden fazla yerde etkin hizmet anlamına gelir. Bunlar aynı yapı değildir. Daha fazla hazır kapasite maliyeti artırabilir ve kurtarmayı hızlandırabilir; etiketler tek başına RTO/RPO garantisi vermez.
DNS ve yönlendirme anı
DNS TTL’si, çözümleyicinin önbellekteki kaydı ne kadar tutacağını etkiler. Geçişten önce düşürülen TTL yardımcı olabilir; olay sırasında düşürmek eski TTL ile önbelleğe alınmış kayıtları geriye dönük değiştirmez. Açık bağlantılar ve istemci davranışı da geçişi etkiler. Yeni hedefin kapasitesini, sertifikalarını ve uygulama sağlığını doğrula; DNS değişikliğini tek başına kurtarma sayma. Yaklaşımlar AWS felaket kurtarma rehberinde karşılaştırılır.
Veri tutarlılığı ve küçük sürprizler
Replika gecikmesini, çift yazıcı oluşmasını, kuyrukların yeniden işlenmesini, zaman damgalarını ve önbellek durumunu birlikte denetle. Kurtarma provasında üretimden yalıtılmış hedef, test hesapları ve ödeme sandbox uçları kullan; gerçek e-posta, webhook veya tahsilat üretme. Kritik akışları veri ve log kontrolleriyle doğrula. Bir HTTP 200 yanıtı ya da kısa tıklama turu tek başına veri tutarlılığı kanıtı değildir.
Tatbikat, iletişim ve olay sonrası çalışma
“Oyun günü” kültürü
Senaryo tatbikatında örneğin ana bölgeye erişimi yok sayarak yetkili başka bir kişinin planı uygulamasını iste. Staging provası bazı üretim bağımlılıklarını kapsamayabilir. Üretimde tatbikat yapılacaksa kapsam, etkilenebilecek kullanıcılar, yetkilendirme, durdurma koşulları ve geri dönüş adımları önceden belirlenmelidir. Amaç süre ve doğrulama kanıtı toplamak; eksik erişim veya belirsiz adımları görünür kılmaktır.
İletişim planı olmadan plan yoktur
Olay koordinatörü, teknik uygulayıcı ve iletişim sorumlusu belirle; küçük ekipte roller birleşebilir ama sahipliği belirsiz kalmamalıdır. Ana sohbet veya SSO çalışmadığında kullanılacak iletişim yolunu hazırla. Müşteriye doğrulanan etkiyi, bilinen durumu ve bir sonraki güncelleme zamanını aktar; kanıtlanmamış çözüm saatini kesin söz gibi sunma. Atlassian olay yönetimi çerçevesi bu akışı düzenlemek için bir kaynaktır.
Olay sonrası değerlendirme
Her olay ve tatbikatın ardından zaman çizelgesini, başarısız kontrolleri ve hedef sapmalarını incele. Bulgulara sahibi, son tarih ve yeniden test ölçütü ata; runbook’u güncelle ve düzeltilen yolu yeniden dene. Yalnızca tatbikat toplantısını tamamlamak, açık işlerin kapandığı anlamına gelmez.
Otomasyon, erişim ve sağlayıcı bağımlılıkları
Altyapıyı yazıyla kur, yazıyla döndür
Altyapıyı kodla tanımlamak tekrarlanabilirliği artırabilir, ancak hedef hesap, bölge, state, kota, paket görüntüleri ve sır erişimi doğru olmalıdır. Aşağıdakiler hazır bir depo için CLI örnekleridir; DR altyapısı veya playbook sağlanmıyor. dr/region-b altında önceden initialize edilmiş Terraform modülü ve doğru DR hesabı, bölgesi, backend state’i ve workspace’i varsayılır. Kaydedilen planı ve hedef değişikliklerini incele, sonra apply adımını ayrı çalıştır. Plan dosyası sır içerebilir; kayıtlı planla apply ayrıca onay sorusu sormaz.
# Example repository paths; initialized module and DR state/account required.
terraform -chdir=dr/region-b plan -out=dr.tfplan
terraform -chdir=dr/region-b show dr.tfplan
# Run separately only after reviewing this saved plan and its target.
terraform -chdir=dr/region-b apply dr.tfplan
Mevcut site-dr.yml playbook’u ve inventory/dr-b.yml envanteri için depo kökünden çalışılır. Gerçek hedefleri, görevleri, değişkenleri ve erişimi doğrula. Syntax-check ve list-hosts kurtarmanın başarılı olacağını kanıtlamaz; son komut görevleri hedeflerde yürütür.
# Existing playbook and inventory; run from the repository root.
ansible-playbook -i inventory/dr-b.yml site-dr.yml --syntax-check
ansible-playbook -i inventory/dr-b.yml site-dr.yml --list-hosts
# Execute separately only after validating targets, tasks and access.
ansible-playbook -i inventory/dr-b.yml site-dr.yml
Güvenli erişimi unutanın kurtarma süresi uzar
Acil erişim prosedürü normal kimlik hizmetinden bağımsız biçimde sınanmalıdır. İstisna gerekiyorsa yetkisi ve süresi sınırlandırılmalı, kullanımı kaydedilmeli ve sonrasında geri alınmalıdır. Sertifika veya anahtar değişimi saklanan yedekleri çözülemez hale getirmemelidir. NIST SP 800-34 yayın kaydından 11 Kasım 2010’da güncellenmiş Rev. 1 sürümünü seçebilirsin. Federal bilgi sistemleri için yazılmış bu çerçeveyi bağlamına uyarla; her kurum için kendiliğinden bir yasal zorunluluk sayma.
Üçüncü taraf hizmetler ve sözleşmeler
Ödeme, e-posta, DNS, CDN ve kimlik sağlayıcılarının arıza alanları, destek kanalları, veri erişimi ve alternatif çalışma seçenekleri kayıtta olmalıdır. Sağlayıcının SLA’sı uygulamanın bütün bağımlılıklarıyla RTO/RPO hedefine döneceğini garanti etmez. Ana destek kanalı kullanılamadığında hangi alternatifin kullanılacağını ve maliyet kararını kimin vereceğini runbook’a ekle.
Örnek üç haftalık başlangıç planı
İlk taslağı doğrulanabilir hale getirmek
Birinci hafta envanteri, bağımlılık sırasını ve hizmet başına RTO/RPO hedeflerini çıkar. İkinci hafta bağımsız yedek erişimini, saklama ve anahtar zincirini doğrula; haftalık küçük dönüş, aylık tam prova ve üç aylık senaryo takvimini başlangıç önerisi olarak değerlendir. Üçüncü hafta öncelikli iki runbook’u yazıp izole ortamda uygula. Bu süre ekibin kapsamına bağlı bir örnektir; tamamlanma ölçütü takvim değil, kabul kontrolleri ve kapanmış bulgulardır.
Geri dönüş sonrası kapasite ve güvenlik
Kullanıcı açılışından önce önbellek ısınmasını, bağlantı havuzlarını, kuyruk birikmesini ve hedef bölgenin kapasitesini ölç. Trafik üreticisi test hesaplarıyla çalışmalı ve dış sistemlerde gerçek yan etki üretmemelidir. Isınma toplam kurtarma süresinin parçasıdır. Yeni çalışma noktasının yedeğini oluştur, geçici yetkileri kaldır ve sonraki geri dönüş için güncel doğrulanmış kayıt bırak.
Kaynakları kurumuna uyarlamak
Yukarıda bağlantısı verilen AWS, NIST ve olay yönetimi kaynakları farklı ortamlar için çerçeve sunar. Bunlardaki yöntemleri; gerçek veri hacmi, sağlayıcı kapasitesi, kurumun yükümlülükleri ve ekip erişimiyle birlikte değerlendir. Hiçbir genel şablon uygulamanın kendi geri dönüş provasının yerini tutmaz.
Planın hazır olduğunu gösteren kanıtlar
Kullanılabilir bir DR planında onaylı iş hedefleri, erişilebilir envanter, bağımsız kurtarma verisi ve anahtarları, açık sahipli runbook’lar ve zamanlanmış test kayıtları bulunur. Son prova hedefleri karşılamadıysa açığı, geçici önlemi ve yeniden test tarihini yaz. Mimari veya bağımlılık değiştiğinde ilgili kurtarma yolunu yeniden doğrula.
