İş sürekliliği, yüksek kullanılabilirlik ve olağanüstü durum kurtarma nedir?

Bu makalede, yüksek kullanılabilirlik ve olağanüstü durum kurtarma tasarımı aracılığıyla risk yönetimi açısından iş sürekliliği ve iş sürekliliği planlaması tanımlanmaktadır. Bu makale, kendi iş sürekliliği gereksinimlerinizi karşılama hakkında açık rehberlik sağlamasa da, Microsoft'un güvenilirlik kılavuzunda kullanılan kavramları anlamanıza yardımcı olur.

İş sürekliliği , bir işletmenin hatalar, kesintiler veya olağanüstü durumlar sırasında işlemlere devam etmesi durumudur. İş sürekliliği için proaktif planlama, hazırlık ve dayanıklı sistem ve süreçlerin uygulanması gerekir.

İş sürekliliğini planlamak için riskleri tanımlama, anlama, sınıflandırma ve yönetme gerekir. Risklere ve bunların olasılıklarına bağlı olarak, hem yüksek kullanılabilirlik (HA) hem de olağanüstü durum kurtarma (DR) için tasarım.

Yüksek kullanılabilirlik , günlük sorunlara dayanıklı olacak ve kullanılabilirlik için iş gereksinimlerini karşılayacak bir çözüm tasarlamayı ifade eder.

Olağanüstü durum kurtarma , yaygın olmayan risklerle ve sonuçlanabilecek yıkıcı kesintilerle nasıl başa çıkabileceğinizi planlamaktır.

İş sürekliliği

Genel olarak bulut çözümleri doğrudan iş operasyonlarına bağlıdır. Bir bulut çözümü kullanılamadığı veya ciddi bir sorunla karşılaştığında, iş operasyonları üzerindeki etki ciddi olabilir. Ciddi bir etki, iş sürekliliğini bozabilir.

İş sürekliliği üzerindeki ciddi etkiler şunlar olabilir:

• İş geliri kaybı.
• Kullanıcılara önemli bir hizmet sağlanamaması.
• Müşteriye veya başka bir tarafa verilen taahhüdün ihlali.

İş yükünü tasarlayan, uygulayan ve çalıştıranlar dahil olmak üzere önemli paydaşlara iş beklentilerini ve başarısızlıkların sonuçlarını anlamak ve iletmek önemlidir. Bu paydaşlar daha sonra bu vizyonun karşılanmasında yer alan maliyetleri paylaşarak yanıt verir. Genellikle bütçeye ve diğer kısıtlamalara göre bu vizyon üzerinde bir müzakere ve düzeltme süreci vardır.

İş sürekliliği planlaması

İş sürekliliğini denetlemek veya olumsuz bir etkiden tamamen kaçınmak için, proaktif olarak bir iş sürekliliği planı oluşturmak önemlidir. İş sürekliliği planı, risk değerlendirmesine ve bu riskleri çeşitli yaklaşımlarla kontrol etme yöntemleri geliştirmeye dayanır. Belirli riskler ve azaltma yaklaşımları her kuruluş ve iş yükü için farklılık gösterir.

İş sürekliliği planı yalnızca bulut platformunun dayanıklılık özelliklerini değil, aynı zamanda uygulamanın özelliklerini de dikkate alır. Sağlam bir iş sürekliliği planı, kişiler, işle ilgili el ile veya otomatik süreçler ve diğer teknolojiler dahil olmak üzere işletmedeki desteğin tüm yönlerini de içerir.

İş sürekliliği planlaması aşağıdaki sıralı adımları içermelidir:

1. Risk belirleme. bir iş yükünün kullanılabilirliği veya işlevselliğinin risklerini belirleme. Olası riskler ağ sorunları, donanım hataları, insan hatası, bölge kesintisi vb. olabilir. Her riskin etkisini anlama.

2. Risk sınıflandırması. Her riski ortak bir risk olarak sınıflandırın. Bu risk, HA planlarına eklenmelidir veya DR planlamasının bir parçası olması gereken yaygın olmayan bir risktir.

3. Risk azaltma. Yedeklilik, çoğaltma, yük devretme ve yedeklemeler gibi riskleri en aza indirmek veya azaltmak için HA veya DR için risk azaltma stratejileri tasarlar. Ayrıca, teknik olmayan ve işlem tabanlı risk azaltmaları ve denetimleri göz önünde bulundurun.

İş sürekliliği planlaması tek seferlik bir olay değil, bir süreçtir. Oluşturulan tüm iş sürekliliği planları, ilgili ve etkin kalmasını ve mevcut iş gereksinimlerini desteklediğini güvence altına almak için düzenli olarak gözden geçirilmeli ve güncelleştirilmelidir.

Risk belirleme

İş sürekliliği planlamasının ilk aşaması, bir iş yükünün kullanılabilirliği veya işlevselliğiyle ilgili riskleri belirlemektir. Her risk, olasılığını ve önem derecesini anlamak için analiz edilmelidir. Önem derecesinin olası kapalı kalma süresini veya veri kaybını içermesi ve çözüm tasarımının geri kalanının olumsuz etkileri telafi edip etmeyeceğini içermesi gerekir.

Aşağıdaki tablo, olasılığı azaltarak sıralanmış, kapsamlı olmayan bir risk listesidir:

İş sürekliliği planlaması yalnızca bulut platformu ve altyapısıyla ilgili değildir. İnsan hatası riskini göz önünde bulundurmak önemlidir. Ayrıca, geleneksel olarak güvenlik, performans veya operasyonel risk olarak değerlendirilebilecek bazı riskler de çözümün kullanılabilirliğini etkilediğinden güvenilirlik riskleri olarak değerlendirilmelidir.

Burada bazı örnekler verilmiştir:

Hata modu analizi (FMA), bir iş yükünün veya bileşenlerinin başarısız olabileceği olası yolları ve çözümün bu durumlarda nasıl davrandığını belirleme işlemidir. Daha fazla bilgi edinmek için bkz . Hata modu analizi gerçekleştirme önerileri.

Risk sınıflandırması

İş sürekliliği planları hem yaygın hem de yaygın olmayan riskleri ele almalıdır.

• Yaygın riskler planlı ve beklenen risklerdir. Örneğin, bulut ortamında kısa ağ kesintileri, yamalar nedeniyle donanım yeniden başlatmaları, hizmet meşgul olduğunda zaman aşımları vb. gibi geçici hatalar olması yaygın bir durumdur. Bu olaylar düzenli olarak gerçekleştiği için iş yüklerinin bunlara dayanıklı olması gerekir.

  Yüksek kullanılabilirlik stratejisi, bu tür her riski dikkate almalı ve denetlemelidir.

• Yaygın olmayan riskler genellikle olağanüstü bir kesintiye yol açabilecek doğal afet veya büyük ağ saldırısı gibi öngörülemeyen bir olayın sonucudur.

  Olağanüstü durum kurtarma işlemleri bu nadir risklerle ilgilenir.

Yüksek kullanılabilirlik ve olağanüstü durum kurtarma birbiriyle ilişkilidir ve bu nedenle her ikisi için de stratejileri birlikte planlamak önemlidir.

Risk sınıflandırmasının iş yükü mimarisine ve iş gereksinimlerine bağlı olduğunu ve bazı risklerin bir iş yükü için HA ve başka bir iş yükü için DR olarak sınıflandırılabileceğini anlamak önemlidir. Örneğin, tam bir Azure bölgesi kesintisi genellikle o bölgedeki iş yükleri için dr riski olarak kabul edilir. Ancak tam çoğaltma, yedeklilik ve otomatik bölge yük devretmesi ile etkin-etkin bir yapılandırmada birden çok Azure bölgesi kullanan iş yükleri için bölge kesintisi HA riski olarak sınıflandırılır.

Risk azaltma

Risk azaltma, iş sürekliliği risklerini en aza indirmek veya azaltmak için HA veya DR'ye yönelik stratejiler geliştirmektir. Risk azaltma teknoloji tabanlı veya insan tabanlı olabilir.

Teknoloji tabanlı risk azaltma

Teknoloji tabanlı risk azaltma, iş yükünün nasıl uygulandığını ve yapılandırıldığını temel alan risk denetimlerini kullanır, örneğin:

• Yedeklilik
• Veri çoğaltma
• Yük devretme
• Yedekler

Teknoloji tabanlı risk denetimleri, iş sürekliliği planı bağlamında dikkate alınmalıdır.

Örneğin:

• Düşük kapalı kalma süresi gereksinimleri. Bazı iş sürekliliği planları, katı yüksek kullanılabilirlik gereksinimleri nedeniyle herhangi bir kapalı kalma süresi riskini tolere edemez. Bir insanın bildirimde bulunup ardından yanıt vermesi için zaman gerektirebilecek belirli teknoloji tabanlı denetimler vardır. Yavaş el ile gerçekleştirilen işlemleri içeren teknoloji tabanlı risk denetimleri, risk azaltma stratejilerine dahil edilmeye uygun olmayabilir.

• Kısmi hataya dayanıklılık. Bazı iş sürekliliği planları, düzeyi düşürülmüş durumda çalışan bir iş akışını tolere edebilir. Bir çözüm düzeyi düşürülmüş durumda çalıştığında, bazı bileşenler devre dışı bırakılmış veya işlevsiz olabilir, ancak temel iş işlemleri gerçekleştirilmeye devam edebilir. Daha fazla bilgi edinmek için bkz . Kendi kendini iyileştirme ve kendini koruma önerileri.

İnsan tabanlı risk azaltma

İnsan tabanlı risk azaltma, aşağıdakiler gibi iş süreçlerini temel alan risk denetimlerini kullanır:

• Yanıt playbook'u tetikleme.
• El ile yapılan işlemlere geri dönmek.
• Eğitim ve kültürel değişiklikler.

İnsan tabanlı risk denetimleri genellikle teknoloji tabanlı denetimlerden daha yavaş olduğundan ve insan hatasına daha yatkın olduğundan, iyi bir iş sürekliliği planı, çalışan sistemin durumunu değiştirecek her şey için resmi bir değişiklik denetimi süreci içermelidir. Örneğin, aşağıdaki işlemleri uygulamayı göz önünde bulundurun:

• İş yüklerinizi iş yükü kritikliğine uygun olarak sıkı bir şekilde test edin. Değişiklikle ilgili sorunları önlemek için iş yükünde yapılan değişiklikleri test edin.
• İş yükünüzün güvenli dağıtım uygulamalarının bir parçası olarak stratejik kalite geçitlerini tanıtın. Daha fazla bilgi edinmek için bkz . Güvenli dağıtım uygulamaları için öneriler.
• Geçici üretim erişimi ve veri işleme yordamlarını resmileştirin. Bu etkinlikler ne kadar küçük olursa olsun güvenilirlik olaylarına neden olma riski yüksek olabilir. Yordamlar başka bir mühendisle eşleştirmeyi, denetim listelerini kullanmayı ve betikleri yürütmeden veya değişiklikleri uygulamadan önce eş gözden geçirmeleri almayı içerebilir.

Yüksek kullanılabilirlik

Yüksek kullanılabilirlik, belirli bir iş yükünün geçici hatalar ve aralıklı hatalar sırasında bile günlük olarak gerekli çalışma süresini koruyabildiği durumdur. Bu olaylar düzenli olarak gerçekleştiğinden, her iş yükünün belirli uygulama ve müşteri beklentilerinin gereksinimlerine uygun olarak yüksek kullanılabilirlik için tasarlanması ve yapılandırılması önemlidir. Her iş yükünün HA'sı, iş sürekliliği planınıza katkıda bulunur.

HA her iş yüküne göre farklılık gösterebileceğinden, yüksek kullanılabilirliği belirlerken gereksinimleri ve müşteri beklentilerini anlamak önemlidir. Örneğin, kuruluşunuzun ofis malzemeleri sipariş etmek için kullandığı bir uygulama nispeten düşük bir çalışma süresi düzeyi gerektirirken, kritik bir finansal uygulama çok daha yüksek çalışma süresi gerektirebilir. Bir iş yükünde bile farklı akışlar farklı gereksinimlere sahip olabilir. Örneğin, bir e-Ticaret uygulamasında müşterilerin siparişlere göz atmasını ve sipariş vermesini destekleyen akışlar, sipariş karşılama ve arka ofis işleme akışlarından daha önemli olabilir. Akışlar hakkında daha fazla bilgi edinmek için bkz . Akışları tanımlama ve derecelendirme önerileri.

Genellikle çalışma süresi, çalışma süresi yüzdesindeki "dokuz" sayısına göre ölçülür. Çalışma süresi yüzdesi, belirli bir süre boyunca ne kadar kapalı kalma süresine izin verdiğinizle ilgilidir. Burada bazı örnekler verilmiştir:

• %99,9 çalışma süresi gereksinimi (üç dokuz) bir ay içinde yaklaşık 43 dakikalık kapalı kalma süresi sağlar.
• %99,95 çalışma süresi gereksinimi (üç buçuk dokuz) bir ay içinde yaklaşık 21 dakikalık kapalı kalma süresi sağlar.

Çalışma süresi gereksinimi ne kadar yüksekse kesintilere o kadar az tolerans sağlarsınız ve bu kullanılabilirlik düzeyine ulaşmak için o kadar fazla çalışmanız gerekir. Çalışma süresi, düğüm gibi tek bir bileşenin çalışma süresiyle değil, tüm iş yükünün genel kullanılabilirliğiyle ölçülür.

Yüksek kullanılabilirlik tasarım öğeleri

HA gereksinimlerini karşılamak için bir iş yükü bir dizi tasarım öğesi içerebilir. Yaygın öğelerden bazıları bu bölümde listelenmiştir ve aşağıda açıklanmıştır.

Yüksek kullanılabilirliği destekleyen Azure hizmetleri ve katmanları

Birçok Azure hizmeti yüksek oranda kullanılabilir olacak şekilde tasarlanmıştır ve yüksek oranda kullanılabilir iş yükleri oluşturmak için kullanılabilir. Burada bazı örnekler verilmiştir:

• Azure Sanal Makine Ölçek Kümeleri, sanal makine örneklerini otomatik olarak oluşturup yöneterek ve altyapı hatalarının etkisini azaltmak için bu VM örneklerini dağıtarak sanal makineler (VM) için yüksek kullanılabilirlik sağlar.
• Azure Uygulaması Hizmeti, çalışanları otomatik olarak iyi durumda olmayan bir düğümden iyi durumdaki bir düğüme taşıma ve birçok yaygın hata türünden kendi kendini düzeltme özellikleri sağlama dahil olmak üzere çeşitli yaklaşımlar aracılığıyla yüksek kullanılabilirlik sağlar.

Hizmetin özelliklerini anlamak, hangi katmanların kullanılacağına karar vermek ve yüksek kullanılabilirlik stratejinize hangi özelliklerin dahil edilmesi gerektiğine karar vermek için her hizmet güvenilirlik kılavuzunu kullanın.

Beklenen kullanılabilirlik düzeylerini ve karşılamanız gereken koşulları anlamak için her hizmetin hizmet düzeyi sözleşmelerini (SLA) gözden geçirin. Belirli kullanılabilirlik düzeylerine ulaşmak için belirli hizmet katmanlarını seçmeniz veya bu katmanlardan kaçınmanız gerekebilir. Microsoft'un bazı hizmetleri, geliştirme veya temel katmanlar gibi SLA sağlanamadığı veya kaynağın spot tabanlı teklifler gibi çalışan sisteminizden geri alınabileceği anlayışıyla sunulur. Ayrıca bazı katmanlar kullanılabilirlik alanları desteği gibi güvenilirlik özellikleri de ekledi.

Hataya dayanıklılık

Hataya dayanıklılık, sistemin bir hata durumunda belirli bir kapasitede çalışmaya devam edebilmesidir. Örneğin, bir web uygulaması tek bir web sunucusu başarısız olsa bile çalışmaya devam etmek için tasarlanmış olabilir. Hataya dayanıklılık, yedeklilik, yük devretme, bölümleme, düzgün performans düşüşü ve diğer tekniklerle elde edilebilir.

Hataya dayanıklılık için uygulamalarınızın geçici hataları işlemesi de gerekir. Kendi kodunuzu oluştururken geçici hata işlemeyi etkinleştirmeniz gerekebilir. Bazı Azure hizmetleri, bazı durumlar için yerleşik geçici hata işleme sağlar. Örneğin, Azure Logic Apps varsayılan olarak başarısız istekleri diğer hizmetlere otomatik olarak yeniden denenir. Daha fazla bilgi edinmek için bkz . Geçici hataları işlemeye yönelik öneriler.

Yedeklilik

Yedeklilik, iş yükünün güvenilirliğini artırmak için örnekleri veya verileri yineleme uygulamasıdır.

Yedeklilik, çoğaltmaların veya yedekli örneklerin dağıtılmasıyla aşağıdaki yolların tümünün tümüne ulaşılabilir:

• Veri merkezinin içinde (yerel yedeklilik)
• Bir bölge içindeki kullanılabilirlik alanları arasında (alanlar arası yedeklilik)
• Bölgeler arasında (coğrafi olarak yedeklilik).

Bazı Azure hizmetlerinin yedeklilik seçeneklerini nasıl sağladığına dair bazı örnekler aşağıda verilmiştir:

• Azure Uygulaması Hizmeti, bir örnek başarısız olsa bile uygulamanın kullanılabilir durumda kalmasını sağlamak için uygulamanızın birden çok örneğini çalıştırmanızı sağlar. Alanlar arası yedekliliği etkinleştirirseniz, bu örnekler kullandığınız Azure bölgesindeki birden çok kullanılabilirlik alanına yayılır.
• Azure Depolama , verileri en az üç kez otomatik olarak çoğaltarak yüksek kullanılabilirlik sağlar. Alanlar arası yedekli depolamayı (ZRS) etkinleştirerek bu çoğaltmaları kullanılabilirlik alanları arasında dağıtabilir ve birçok bölgede coğrafi olarak yedekli depolama (GRS) kullanarak depolama verilerinizi bölgeler arasında çoğaltabilirsiniz.
• Azure SQL Veritabanı, bir çoğaltma başarısız olsa bile verilerin kullanılabilir durumda kalmasını sağlamak için birden çok çoğaltmaya sahiptir.

Yedeklilik hakkında daha fazla bilgi edinmek için bkz . Yedeklilik tasarlama önerileri ve Kullanılabilirlik alanlarını ve bölgelerini kullanma önerileri.

Ölçeklenebilirlik ve esneklik

Ölçeklenebilirlik ve esneklik, bir sistemin kaynakları ekleyip kaldırarak (ölçeklenebilirlik) artan yükü ele alma ve gereksinimleriniz değiştikçe (esneklik) bunu hızlı bir şekilde gerçekleştirme özellikleridir. Ölçeklenebilirlik ve esneklik, sistemin yoğun yükler sırasında kullanılabilirliği korumasına yardımcı olabilir.

Birçok Azure hizmeti ölçeklenebilirliği destekler. Burada bazı örnekler verilmiştir:

• Azure Sanal Makine Ölçek Kümeleri, Azure API Management ve diğer birçok hizmet Azure İzleyici otomatik ölçeklendirmesini destekler. Azure İzleyici otomatik ölçeklendirme ile "CPU'm tutarlı olarak %80'in üzerine çıktığında başka bir örnek ekle" gibi ilkeler belirtebilirsiniz.
• Azure İşlevleri isteklerinize hizmet vermek için örnekleri dinamik olarak sağlayabilir.
• Azure Cosmos DB, hizmetin belirttiğiniz ilkelere göre veritabanlarınıza atanan kaynakları otomatik olarak yönetebildiği otomatik ölçeklendirme aktarım hızını destekler.

Ölçeklenebilirlik, kısmi veya tam arıza sırasında dikkate alınması gereken önemli bir faktördür. Çoğaltma veya işlem örneği kullanılamıyorsa, daha önce hatalı düğüm tarafından işlenen yükü işlemek için kalan bileşenlerin daha fazla yük taşıması gerekebilir. Sisteminizin, beklenen yük değişikliklerinizi işleyecek kadar hızlı ölçeklendirilemediğini fazla sağlamayı göz önünde bulundurun.

Ölçeklenebilir ve elastik bir sistem tasarlama hakkında daha fazla bilgi için bkz . Güvenilir ölçeklendirme stratejisi tasarlama önerileri.

Sıfır kapalı kalma süresi dağıtım teknikleri

Dağıtımlar ve diğer sistem değişiklikleri önemli bir kapalı kalma süresi riski oluşturur. Kapalı kalma süresi riski yüksek kullanılabilirlik gereksinimleri için bir zorluk olduğundan, güncelleştirmeleri ve yapılandırma değişikliklerini gerekli kapalı kalma süresi olmadan yapmak için sıfır kapalı kalma süresi dağıtım uygulamalarının kullanılması önemlidir.

Sıfır kapalı kalma süresi dağıtım teknikleri şunları içerebilir:

• Kaynaklarınızın bir alt kümesini aynı anda güncelleştirme.
• Yeni dağıtıma ulaşan trafik miktarını denetleme.
• Kullanıcılarınız veya sisteminiz üzerinde herhangi bir etki olup olmadığını izleme.
• Önceki bilinen iyi dağıtıma geri dönerek sorunu hızla düzeltin.

Sıfır kapalı kalma süresi dağıtım teknikleri hakkında daha fazla bilgi edinmek için bkz . Güvenli dağıtım uygulamaları.

Azure kendi hizmetlerimiz için sıfır kapalı kalma süresi dağıtım yaklaşımları kullanır. Kendi uygulamalarınızı oluştururken, şunlar gibi çeşitli yaklaşımlar aracılığıyla sıfır kapalı kalma süresi dağıtımlarını benimseyebilirsiniz:

• Azure Container Apps, uygulamanızın birden çok düzeltmesini sağlar ve bu düzeltmeler sıfır kapalı kalma süresi dağıtımlarına ulaşmak için kullanılabilir.
• Azure Kubernetes Service (AKS), çeşitli sıfır kapalı kalma süresi dağıtım tekniklerini destekler.

Sıfır kapalı kalma süresi dağıtımları genellikle uygulama dağıtımlarıyla ilişkili olsa da, yapılandırma değişiklikleri için de kullanılmalıdır. Yapılandırma değişikliklerini güvenli bir şekilde uygulamanın bazı yolları şunlardır:

• Azure Depolama, depolama hesabı erişim anahtarlarınızı birden çok aşamada değiştirmenize olanak tanır ve bu da anahtar döndürme işlemleri sırasında kapalı kalma süresini önler.
• Azure Uygulaması Yapılandırması, yapılandırma değişikliklerinin nasıl uygulandığını denetlemenize yardımcı olacak özellik bayrakları, anlık görüntüler ve diğer özellikler sağlar.

Sıfır kapalı kalma süresi dağıtımları uygulamamaya karar verirseniz, kullanıcılarınızın beklediği bir zamanda sistem değişiklikleri yapabilmeniz için bakım pencereleri tanımladığınızdan emin olun.

Otomatikleştirilmiş test

Çözümünüzün HA kapsamında olduğunu düşündüğünüz kesintilere ve hatalara dayanabilme becerisini test etmek önemlidir. Bu hataların çoğu test ortamlarında benzetilebilir. Çözümünüzün çeşitli hata türlerini otomatik olarak tolere etme veya kurtarma yeteneğini test etmek için kaos mühendisliği denir. Kaos mühendisliği, HA için katı standartlara sahip olgun kuruluşlar için kritik öneme sahiptir. Azure Chaos Studio , bazı yaygın hata türlerinin benzetimini yapabilecek bir kaos mühendisliği aracıdır.

Daha fazla bilgi edinmek için bkz . Güvenilirlik testi stratejisi tasarlama önerileri.

İzleme ve uyarı

İzleme, otomatik azaltmalar gerçekleştiğinde bile sisteminizin durumunu bilmenizi sağlar. İzleme, çözümünüzün nasıl davrandığını anlamak ve artan hata oranları veya yüksek kaynak tüketimi gibi erken hata sinyallerini izlemek için kritik öneme sahiptir. Uyarılar sayesinde ortamınızda önemli değişiklikleri proaktif olarak alabilirsiniz.

Azure, aşağıdakiler de dahil olmak üzere çeşitli izleme ve uyarı özellikleri sağlar:

• Azure İzleyici , Azure kaynaklarından ve uygulamalarından günlükleri ve ölçümleri toplar ve uyarılar gönderebilir ve panolarda veri görüntüleyebilir.
• Azure İzleyici Application Insights , uygulamalarınızın ayrıntılı izlenmesini sağlar.
• Azure Hizmet Durumu ve Azure Kaynak Durumu Azure platformunun ve kaynaklarınızın durumunu izler.
• Zamanlanmış Olaylar , sanal makineler için bakım planlandığında öneride bulunur.

Daha fazla bilgi için bkz . Güvenilir izleme ve uyarı stratejisi tasarlama önerileri.

Olağanüstü durum kurtarma

Olağanüstü durum , bir uygulamanın tasarımının yüksek kullanılabilirlik açısından azaltamaya kıyasla daha büyük ve daha uzun süreli etkisi olan benzersiz, yaygın olmayan, önemli bir olaydır. Olağanüstü durumlara örnek olarak şunlar verilebilir:

• Kasırgalar, depremler, sel veya yangınlar gibi doğal afetler.
• Üretim verilerini yanlışlıkla silme gibi önemli bir etkiye neden olan insan hataları veya hassas verileri kullanıma sunan yanlış yapılandırılmış bir güvenlik duvarı.
• Veri bozulmasına, veri kaybına veya hizmet kesintilerine yol açan hizmet reddi veya fidye yazılımı saldırıları gibi önemli güvenlik olayları.

Olağanüstü durum kurtarma , bu tür durumlara nasıl yanıt vereceğinizi planlamaktır.

Olağanüstü durum kurtarma gereksinimleri

Olağanüstü durum olaylarının seyri ve önem derecesi nedeniyle, DR planlaması yanıtınız için farklı beklentiler getirir. Birçok kuruluş, olağanüstü durum senaryosunda belirli bir kapalı kalma süresinin veya veri kaybının kaçınılmaz olduğunu kabul eder. Tam bir DR planı, her akış için aşağıdaki kritik iş gereksinimlerini belirtmelidir:

• Kurtarma Noktası Hedefi (RPO), olağanüstü durum durumunda kabul edilebilir maksimum veri kaybı süresidir. RPO, "30 dakikalık veri" veya "dört saatlik veri" gibi zaman birimleriyle ölçülür.

• Kurtarma Süresi Hedefi (RTO), "kapalı kalma süresinin" belirtiminize göre tanımlandığı bir olağanüstü durum durumunda kabul edilebilir kapalı kalma süresinin üst sınırıdır. RTO ayrıca "sekiz saatlik kapalı kalma süresi" gibi zaman birimleriyle de ölçülür.

İş yükündeki her bileşenin veya akışın tek tek RPO ve RTO değerleri olabilir. Gereksinimlere karar verirken olağanüstü durum senaryosu risklerini ve olası kurtarma stratejilerini inceleyin. RPO ve RTO belirtme işlemi, benzersiz iş endişelerinizin (maliyetler, etki, veri kaybı vb.) sonucu iş yükünüz için dr gereksinimleri oluşturur.

Olağanüstü durum kurtarma planları

Olağanüstü durum nedeni ne olursa olsun, iyi tanımlanmış ve test edilebilir bir DR planı oluşturmanız önemlidir. Bu plan, etkin bir şekilde desteklemek için altyapı ve uygulama tasarımının bir parçası olarak kullanılacaktır. Farklı durum türleri için birden çok DR planı oluşturabilirsiniz. DR planları genellikle süreç denetimlerine ve el ile müdahaleye dayanır.

DR, Azure'ın otomatik bir özelliği değildir. Ancak birçok hizmet, DR stratejilerinizi desteklemek için kullanabileceğiniz özellikler ve özellikler sağlar. Hizmetin nasıl çalıştığını ve özelliklerini anlamak için her Azure hizmetinin güvenilirlik kılavuzlarını gözden geçirmeniz ve ardından bu özellikleri DR planınızla eşlemeniz gerekir.

Aşağıdaki bölümlerde olağanüstü durum kurtarma planının bazı yaygın öğeleri listelenmiştir ve Azure'ın bunları başarmanıza nasıl yardımcı olabileceği açıklanmaktadır.

Yük devretme ve yeniden çalışma

Bazı olağanüstü durum kurtarma planları, başka bir konumda ikincil dağıtım sağlamayı içerir. Bir olağanüstü durum çözümün birincil dağıtımını etkilerse trafik diğer siteye yük devredilebilir. Yük devretme dikkatli bir planlama ve uygulama gerektirir. Azure, yük devretmeye yardımcı olmak için aşağıdakiler gibi çeşitli hizmetler sağlar:

• Azure Site Recovery , Azure'da şirket içi ortamlar ve sanal makine tarafından barındırılan çözümler için otomatik yük devretme sağlar.
• Azure Front Door ve Azure Traffic Manager , farklı bölgelerde olduğu gibi çözümünüzün farklı dağıtımları arasında gelen trafiğin otomatik yük devretmesini destekler.

Yük devretme işleminin birincil örneğin başarısız olduğunu algılaması ve ikincil örneğe geçmesi genellikle biraz zaman alır. İş yükünün RTO'sunun yük devretme süresiyle uyumlu olduğundan emin olun.

Kurtarıldıktan sonra birincil bölgedeki işlemleri geri yükleme işlemi olan yeniden çalışma işlemini de göz önünde bulundurmanız önemlidir. Yeniden çalışma planlamak ve uygulamak karmaşık olabilir. Örneğin, birincil bölgedeki veriler yük devretme başladıktan sonra yazılmış olabilir. Bu verileri işleme şeklinize ilişkin dikkatli iş kararları almanız gerekir.

Yedekler

Yedeklemeler, verilerinizin bir kopyasını almayı ve belirli bir süre boyunca güvenli bir şekilde depolamayı içerir. Yedeklemelerle, başka bir çoğaltmaya otomatik yük devretme mümkün olmadığında veya veri bozulması oluştuğunda olağanüstü durumlardan kurtarabilirsiniz.

Yedeklemeleri bir olağanüstü durum kurtarma planının parçası olarak kullanırken aşağıdakileri göz önünde bulundurmak önemlidir:

• Depolama konumu. Yedeklemeleri bir olağanüstü durum kurtarma planının parçası olarak kullandığınızda, bunlar ana verilere ayrı olarak depolanmalıdır. Yedeklemeler genellikle başka bir Azure bölgesinde depolanır.

• Veri kaybı. Yedeklemeler genellikle seyrek alındığından, yedekleme geri yükleme işlemi genellikle veri kaybı içerir. Bu nedenle, yedekleme kurtarma son çare olarak kullanılmalı ve bir olağanüstü durum kurtarma planı, bir yedekten geri yüklemeden önce gerçekleşmesi gereken adım ve kurtarma girişimlerinin sırasını belirtmelidir. İş yükü RPO'sunun yedekleme aralığıyla uyumlu olduğundan emin olmak önemlidir.

• Kurtarma süresi. Yedekleme geri yükleme işlemi genellikle zaman alır, bu nedenle yedeklemelerinizi ve geri yükleme işlemlerinizi test ederek bunların bütünlüğünü doğrulamak ve geri yükleme işleminin ne kadar sürdüğünü anlamak çok önemlidir. yedeklemenizi geri yüklemek için gereken süre boyunca iş yükünün RTO'sunun hesap olduğundan emin olun.

Aşağıdakiler gibi birçok Azure veri ve depolama hizmeti yedeklemeleri destekler:

• Azure Backup sanal makine diskleri, depolama hesapları, AKS ve çeşitli diğer kaynaklar için otomatik yedeklemeler sağlar.
• Azure SQL Veritabanı ve Azure Cosmos DB gibi birçok Azure veritabanı hizmeti, veritabanlarınız için otomatik yedekleme özelliğine sahiptir.
• Azure Key Vault gizli dizilerinizi, sertifikalarınızı ve anahtarlarınızı yedeklemeye yönelik özellikler sağlar.

Otomatik dağıtımlar

Olağanüstü bir durumda gerekli kaynakları hızla dağıtmak ve yapılandırmak için Kod olarak altyapı (IaC) varlıklarını (Örneğin, Bicep dosyaları, ARM şablonları veya Terraform yapılandırma dosyası) kullanın. IaC kullanmak, kaynakları el ile dağıtmaya ve yapılandırmaya kıyasla kurtarma sürenizi ve hata olasılığını azaltır.

Test ve tatbikatlar

Dr planlarınızı ve daha geniş güvenilirlik stratejinizi düzenli olarak doğrulamak ve test etmek çok önemlidir. Tatbikatlarınıza tüm insan süreçlerini dahil edin ve yalnızca teknik süreçlere odaklanmayın.

Kurtarma işlemlerinizi olağanüstü durum simülasyonunda test etmediyseniz, bunları gerçek bir olağanüstü durumda kullanırken büyük sorunlarla karşılaşma olasılığınız daha yüksektir. Ayrıca, DR planlarınızı ve gerekli süreçlerinizi test ederek RTO'nuzun fizibilitesini doğrulayabilirsiniz.

Daha fazla bilgi edinmek için bkz . Güvenilirlik testi stratejisi tasarlama önerileri.

İlgili içerik

• Her Azure hizmetinin tasarımında güvenilirliği nasıl desteklediğini anlamak ve HA ve DR planlarınızda oluşturabileceğiniz özellikler hakkında bilgi edinmek için Azure hizmeti güvenilirlik kılavuzlarını kullanın.
• Azure'da güvenilir bir iş yükü tasarlama hakkında daha fazla bilgi edinmek için Azure İyi Tasarlanmış Çerçeve: Güvenilirlik sütununu kullanın.
• Her Azure hizmetini güvenilirlik gereksinimlerinizi karşılayacak şekilde ve İyi Tasarlanmış Çerçeve'nin diğer yapılarında nasıl yapılandıracağınızı öğrenmek için Azure hizmetlerinde İyi Tasarlanmış Çerçeve perspektifini kullanın.
• Olağanüstü durum kurtarma planlaması hakkında daha fazla bilgi edinmek için bkz . Olağanüstü durum kurtarma stratejisi tasarlama önerileri.