CompTIA SY0-701: İş Sürekliliği ve Felaket Kurtarma — Çalışma kılavuzu

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Şunun bir parçası: CompTIA Security+ SY0-701 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: CompTIA sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

İş sürekliliği (İS) ve felaket kurtarma (FK), kurumsal dayanıklılığın operasyonel bel kemiğini oluşturur. Güvenlik kontrolleri olayları önlemeye çalışırken, İS/FK planlaması, fidye yazılımı saldırıları, kasırgalar, fiber kesintileri, elektrik şebekesi arızaları veya zincirleme bulut kesintileri gibi bazı aksaklıkların, önleyici duruşa bakılmaksızın meydana geleceğini kabul eder. Bu disiplin, tolere edilebilir kesintiyi ölçmeye, kurtarma yollarını tasarlamaya ve bu yolları ihtiyaç duyulmadan önce doğrulamaya odaklanır.

Kurtarma Hedefleri: RTO, RPO, MTTR ve MTBF

Her kurtarma görüşmesine iki metrik yön verir ve bunları birbirine karıştırmak, planlama dokümanlarındaki en kalıcı hatalardan biridir. Kurtarma Süresi Hedefi (RTO), bir sistemin bir kesintiden sonra ne kadar süreyle kullanılamaz durumda kalabileceğinin kabul edilebilir maksimum süresini ifade eder. Bu süre, arıza anından hizmetlerin kullanılabilir duruma geri döndürüldüğü ana kadar geçen gerçek zaman üzerinden ölçülür.

Buna karşılık Kurtarma Noktası Hedefi (RPO), veri kaybı toleransını ölçer; yani kurumun ne kadar geriye dönük işlem kaybetmeyi göze aldığını belirtir. RPO, arıza anından bilinen son iyi kurtarma noktasına kadar geriye doğru ölçülür. On beş dakikalık bir RPO, işletmenin on beş dakikaya kadar olan yazma işlemlerini kaybetmeyi tolere edebileceği anlamına gelir; dolayısıyla, yedeklemeler, replikasyon veya işlem günlüğü gönderimi en az bu sıklıkta gerçekleşmelidir.

Bu ayrımı içselleştirmenin en net yolu bir zaman çizelgesidir: RPO kesintinin solunda (veri), RTO ise sağında (kesinti süresi) yer alır. İki erişilebilirlik alanı arasında senkron bir veritabanı replikası, otomatik yük devretme (failover) yoluyla sıfıra yakın bir RPO ve saniyelerle ölçülen bir RTO sağlayabilir. Tesis dışına gönderilen gecelik bir teyp yedeği ise en iyi ihtimalle 24 saatlik bir RPO ve günlerle ölçülen bir RTO sunar.

İki destekleyici metrik daha bu terminolojiyi tamamlar. Ortalama Onarım Süresi (MTTR), arızalı bir bileşeni onarmak için gözlemlenen ortalama süredir, Arızalar Arası Ortalama Süre (MTBF) ise güvenilirliği tanımlar. Yüksek MTBF ve düşük MTTR, iddialı RTO’ları ulaşılabilir kılan mühendislik hedefleridir.

İş Etki Analizi

RTO ve RPO değerleri BT tarafından seçilmez; bir İş Etki Analizi (İEA) sonucunda ortaya çıkarlar. İEA, iş süreçlerini sistematik olarak tanımlar, bunları destekleyen teknoloji varlıklarıyla eşleştirir ve bir kesinti uzadıkça biriken operasyonel, finansal, yasal ve itibar zararını sayısallaştırır. Bir bordro sistemi, maaş çekleri iki haftada bir kesildiği için 48 saatlik mütevazı bir RTO’ya sahip olabilirken, bir hastanenin elektronik ilaç uygulama kaydı, hasta güvenliği anında bozulduğu için dakikalarla ölçülen bir RTO gerektirebilir.

İEA, birkaç türev çıktı üretir: her sistem için bir kritiklik seviyesi, kurtarmanın anlamsız hale geldiği mutlak tavan olan Maksimum Tolere Edilebilir Kesinti Süresi (MTD) ve mimari seçimlerini yönlendiren RTO/RPO çiftleri. Ayrıca bağımlılıkları da ortaya çıkarır; bir sipariş yönetim sistemini, kimlik doğrulama sağlayıcısını, veritabanını ve ödeme ağ geçidini de kurtarmadan kurtarmak, kullanılabilir hiçbir şey sağlamaz.

Kurtarma Merkezi Stratejileri

Birincil tesis kaybedildiğinde, iş yüklerinin bir yere taşınması gerekir. Üç kanonik alternatif merkez türü, maliyeti kurtarma hızıyla takas eder.

Sıcak merkez (hot site), üretim ortamının tamamen faal bir kopyasıdır. Donanım kurulmuş, yazılım lisanslanmış ve yamalanmış, veri ise sürekli olarak replike edilmektedir. Yük devretme, küresel yük dengeleme ile birleştirildiğinde dakikalar hatta saniyeler içinde ölçülebilir. Sıcak merkezler en düşük RTO ve RPO’yu sunar ancak en yüksek maliyeti taşır; altyapı harcamasını etkin bir şekilde ikiye katlar.

Ilık merkez (warm site) orta yolu temsil eder. Donanım ve bağlantı mevcuttur ve bazı temel yazılımlar kuruludur, ancak veri sürekli olarak replike edilmez; yedekten geri yüklenmelidir ve son yapılandırma aktivasyon sırasında tamamlanır. Ilık merkezler genellikle saatler ila bir gün içinde kurtarılır.

Soğuk merkez (cold site) fiziksel alan, güç, soğutma ve internet bağlantısı sağlar, ancak başka pek bir şey sunmaz. Sunucuların sevk edilmesi veya tedarik edilmesi, işletim sistemlerinin kurulması, uygulamaların dağıtılması ve verilerin yedeklerden geri yüklenmesi gerekir. Bir soğuk merkezin bakımı ucuzdur ancak faaliyete geçmesi günler veya haftalar gerektirebilir. Soğuk bir merkezi hızlı bir yük devretme hedefi olarak görmek, tekrarlanan bir planlama hatasıdır; yalnızca RTO’su günlerle ölçülen sistemler için uygundur.

Modern mimariler, bu kategorileri bulanıklaştıran bulut tabanlı kurtarma yöntemlerine (pilot ışık, ılık bekleme veya çok bölgeli aktif/aktif) giderek daha fazla dayanmaktadır. Bir pilot ışık (pilot-light) tasarımı, yığının geri kalanı talep üzerine kod olarak altyapı (infrastructure-as-code) şablonlarından oluşturulurken, minimal çekirdek hizmetleri (örneğin replike edilmiş bir veritabanı) çalışır durumda tutar.

Yük Devretme, Geri Devretme ve Yüksek Erişilebilirlik

Yük devretme (Failover), trafiği arızalı bir birincil sistemden bir yedek sisteme kaydırma eylemidir. Sağlık kontrolleri ve DNS veya BGP değişiklikleri tarafından yönlendirilen otomatik bir işlem olabileceği gibi, insan onayı gerektiren manuel bir işlem de olabilir. Geri devretme (Failback) — onarıldıktan sonra orijinal birincil merkeze geri dönmek — planlamada genellikle ihmal edilir, ancak kendi riskini taşır: kesinti sırasında yük devretme merkezine yazılan verilerin, geçişten önce uzlaştırılması ve geri replike edilmesi gerekir, aksi takdirde yazma işlemleri kaybolur.

Bileşen seviyesindeki yedeklilik bu stratejileri destekler. Yük dengeleyiciler trafiği aktif düğümler arasında dağıtır. Kümelenmiş veritabanları bir bölge içinde senkron, bölgeler arasında ise asenkron olarak replikasyon yapar. RAID, disk arızasına karşı korur ancak bir yedekleme değildir. Yedekli ağ yolları, ayrı PDU’lardan beslenen çift güç kaynakları ve farklı ISP devreleri, veri merkezi içindeki tekil hata noktalarını ortadan kaldırır.

Güç Sürekliliği: UPS, Jeneratörler ve Fail-Open Kararları

Elektrik sürekliliği her şeyin temelini oluşturur. Bir kesintisiz güç kaynağı (UPS), şebeke arızası ile jeneratörün devreye girmesi arasındaki boşluğu doldurur — genellikle 5 ila 15 dakikalık batarya çalışma süresi sağlar. Jeneratörler, genellikle dizel veya doğal gazla çalışan sürekli yedek güç sağlar ve düzenli olarak yük testinden geçirilmelidir. Yakıt sözleşmeleri, transfer şalterinin çalışması ve jeneratör başlatma sıralamaları, denenene kadar sessizce başarısız olur. Gerçek yük altında yapılan üç aylık bir test, aylık boşta çalıştırmadan çok daha fazla bilgi verir.

Güvenlik cihazları, güç veya yazılım arızası sırasında ayrı bir soruyu gündeme getirir: fail open mı yoksa fail closed mü olmalıdırlar? Fail-open bir güvenlik duvarı, cihaz arızalandığında trafiği geçirmeye devam ederek güvenlik pahasına erişilebilirliği korur. Fail-closed bir güvenlik duvarı, tüm trafiği engelleyerek erişilebilirlik pahasına güvenliği korur. Fiziksel erişim kontrolleri de aynı ikilemle karşı karşıyadır — fail-closed olan bir elektronik kapı kilidi, yangın sırasında içeridekileri mahsur bırakabilir, bu nedenle can güvenliği yönetmelikleri genellikle çıkış için fail-open (fail-safe olarak da adlandırılır) davranışını zorunlu kılar.

Test Etme: Masa Başı Tatbikatı, Gözden Geçirme, Simülasyon ve Tam Kesinti

Hiç test edilmemiş bir plan, bir hipotezden ibarettir. Testler, gerçekçilik ve risk yelpazesi boyunca ilerler.

Bir masa başı tatbikatı, paydaşları bir konferans masası etrafında toplayarak bir senaryoyu konuşmalarını sağlar — “bir fidye yazılımı olayı Pazar sabahı saat 2’de birincil VMware kümesini şifreledi; sonraki altı saati bana adım adım anlatın.” Bu tatbikat; dokümantasyon, iletişim listeleri, karar yetkisi ve varsayımlardaki boşlukları ortaya çıkarır. Operasyonel bir risk taşımaz ve uygun bir başlangıç noktasıdır.

Bir walkthrough veya yapılandırılmış gözden geçirme, plan dokümanının kendisini doğruluk açısından inceler. Bir simülasyon, rol yapma ve senaryoya yeni olaylar ekleme (inject) unsurlarını içerir. Bir paralel test, kurtarma ortamını, trafiği yönlendirmeden üretim ortamının yanında çevrimiçi hale getirir. En titiz test türü olan tam kesinti testi, üretim ortamını fiilen kurtarma ortamına devreder — pahalıdır, kesintiye neden olur ve planın gerçekten işe yaradığını kanıtlayan tek testtir.

Her test bir geri alma planı (backout plan) içermelidir: yük devretme işleminin kendisi başarısız olursa veya verileri bozarsa nasıl geri dönüleceği. Jeneratör yük testleri, yedekten geri yükleme tatbikatları ve iletişim zinciri aktivasyonları, yazılım yamalama ile aynı yinelenen takvimde yer almalıdır.

Pratik Senaryo: Test Edilmemiş Kurtarma Planının Gerçek Bir Olay Sırasında Başarısız Olması

Bölgesel bir bankanın felaket kurtarma (DR) planı, ana bankacılık sistemi için dört saatlik bir RTO ile bir warm site (ılık ortam) belirtiyordu. Plan üç yıl önce yazılmış, her yıl kağıt üzerinde gözden geçirilmiş ancak aktivasyon yoluyla hiç test edilmemişti. Bir yangın söndürme sisteminin boşalması birincil veri merkezinin soğutma altyapısını tahrip ettiğinde, banka warm site’ı etkinleştirmeye çalıştı. Ekip, yedekleme sunucusunun işletim sisteminin mevcut üretim sürümünden iki ana sürüm geride olduğunu ve mevcut uygulama sürümüyle uyumsuz olduğunu keşfetti. Veritabanı yedekleme işleri, yedekleme aracısındaki (agent) bir sertifikanın süresinin dolması nedeniyle altı haftadır sessizce başarısız oluyordu. Gerçek kurtarma 31 saat sürdü — belgelenmiş RTO’nun neredeyse sekiz katı — ve banka, belgelenmiş ve gerçek kurtarma yetenekleri arasındaki fark nedeniyle yasal denetime maruz kaldı. Alınacak ders: RTO ve RPO, hedeflenen idealler değil, mühendislik taahhütleridir ve yılda en az bir kez gerçekçi testlerle doğrulanmaları gerekir.

← Veri Güvenliği · Tüm alanlar · Uç Nokta →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →