Olağanüstü durum kurtarma stratejisi tasarlamaya yönelik öneriler

  • Makale

Bu Azure Well-Architected Framework Güvenilirlik denetim listesi önerisi için geçerlidir:

RE:09 Kurtarma hedefleriyle uyumlu yapılandırılmış, test edilmiş ve belgelenmiş iş sürekliliği ve olağanüstü durum kurtarma (BCDR) planları uygulayın. Planlar tüm bileşenleri ve sistemi bir bütün olarak kapsamalıdır.

Bu kılavuzda, bir iş yükü için güvenilir bir olağanüstü durum kurtarma stratejisi tasarlamaya yönelik öneriler açıklanmaktadır. İç hizmet düzeyi hedeflerini (SLO'lar) ve hatta müşterileriniz için garanti ettiğiniz bir hizmet düzeyi sözleşmesini (SLA) karşılamak için sağlam ve güvenilir bir olağanüstü durum kurtarma stratejisine sahip olmanız gerekir. Hatalar ve diğer önemli sorunlar beklenir. Bu olaylarla ilgilenmeye yönelik hazırlıklarınız, müşterilerinizin işletmenize güvenilir bir şekilde teslim etme konusunda ne kadar güvenebileceğini belirler. Olağanüstü durum kurtarma stratejisi, büyük olaylara hazırlanmanın omurgasını oluşturur.

Tanımlar

Süre Tanım
Yük devretme Üretim iş yükü trafiğinin kullanılamayan bir bölgeden etkilenmeyen bir coğrafi bölgeye otomatik ve/veya el ile kaydırılması.
Yeniden çalışma Üretim iş yükü trafiğinin yük devretme bölgesinden birincil bölgeye otomatik ve/veya el ile kaydırılması.

Temel tasarım stratejileri

Bu kılavuzda, güvenilirlik planlamanızın bir parçası olarak aşağıdaki görevleri zaten gerçekleştirdiğiniz varsayılır:

Güvenilir bir olağanüstü durum kurtarma (DR) stratejisi, güvenilir bir iş yükü mimarisinin temelini oluşturur. DR stratejinizi tasarlamaya başlamadan önce iyileştirilmiş kurtarma için gerekli parçaların yerine getirildiğinden emin olmak için iş yükünüzü oluşturmanın her aşamasında güvenilirliği ele alın. Bu temel, kurtarma süresi hedefi (RTO) ve kurtarma noktası hedefi (RPO) gibi iş yükünüzün güvenilirlik hedeflerinin gerçekçi ve ulaşılabilir olmasını sağlar.

Olağanüstü durum kurtarma planını koruma

bir iş yükü için güvenilir bir DR stratejisinin temel taşı , DR planıdır. Planınız, ortamınız geliştikçe rutin olarak gözden geçirilip güncelleştirilen canlı bir belge olmalıdır. Planı uygun ekiplere (operasyonlar, teknoloji liderliği ve iş paydaşları) düzenli olarak (örneğin altı ayda bir) sunun. OneDrive İş gibi yüksek oranda kullanılabilir, güvenli bir veri deposunda depolayın.

DR planınızı geliştirmek için şu önerileri izleyin:

  • Olağanüstü durum oluşturan ve dolayısıyla DR planının etkinleştirilmesini gerektiren şeyleri net bir şekilde tanımlayın.

    • Olağanüstü durumlar büyük ölçekli sorunlardır. Bunlar bölgesel kesintiler, Microsoft Entra kimliği veya Azure DNS gibi hizmetlerde kesintiler ya da fidye yazılımı saldırıları veya DDoS saldırıları gibi ciddi kötü amaçlı saldırılar olabilir.

    • Operatörlerin yanlışlıkla DR yükseltmelerini çağırmaması için tek bir kaynağın başarısız olması gibi olağanüstü durum olarak kabul edilmeyen hata modlarını belirleyin.

  • FMA belgelerinizde DR planını oluşturun. Olağanüstü durum olarak tanımlanan kesintiler için DR planınızın hata modlarını ve azaltma stratejilerini yakaladığından emin olun. Hem DR planınızı hem de FMA belgelerinizi paralel olarak güncelleştirerek ortam değiştiğinde veya test sırasında beklenmeyen davranışların ortaya çıktığı doğru olacak şekilde güncelleştirin.

    • Üretim dışı ortamlar için DR planları geliştirip geliştirmediğiniz, iş gereksinimlerinize ve maliyet etkilerinize bağlıdır. Örneğin, yayın öncesi test için belirli müşterilere kalite güvencesi (QA) ortamları sunuyorsanız, bu ortamları DR planlamanıza dahil etmek isteyebilirsiniz.

  • İş yükü ekibinde rolleri ve sorumlulukları açıkça tanımlayın ve kuruluşunuzdaki ilgili dış rolleri anlayın. Roller şunları içermelidir:

    • Olağanüstü durum ilan etmekten sorumlu olan taraf.

    • Olay kapanışını bildirmekle sorumlu olan taraf.

    • İşlem rolleri.

    • Test ve doğrulama rolleri.

    • İç ve dış iletişim rolleri.

    • Geçmişe dönük değerlendirme ve kök neden analizi (RCA) müşteri adayı rolleri.

  • Kurtarma durumunun paydaşlara iletildiğinden emin olmak için iş yükü ekibinin izlemesi gereken yükseltme yollarını tanımlayın.

  • Bileşen düzeyinde kurtarma yordamlarını, veri varlığı düzeyinde kurtarmayı ve iş yükü genelinde kurtarma işlemlerini yakalayın. Bileşenlerin en az etkili şekilde kurtarıldığından emin olmak için belirlenmiş bir işlem sırası ekleyin. Örneğin, uygulamayı kurtarmadan önce veritabanlarını kurtarın ve denetleyin.

    • Adım adım kılavuz olarak her bileşen düzeyinde kurtarma yordamını ayrıntılandırabilirsiniz. Mümkünse ekran görüntülerini ekleyin.

    • Ekibinizin sorumluluklarını ve bulut barındırma sağlayıcınızın sorumluluklarını tanımlayın. Örneğin, PaaS'yi (hizmet olarak platform) geri yüklemek Microsoft'un sorumluluğundadır, ancak verileri yeniden doldurma ve yapılandırmanızı hizmete uygulama sizin sorumluluğunuzdadır.

    • Yordamı çalıştırmak için önkoşulları ekleyin. Örneğin, toplanması gereken betikleri veya kimlik bilgilerini listeleyin.

    • Kurtarmayı başlatmadan önce olayın kök nedenini yakalayın ve azaltmayı gerçekleştirin. Örneğin, olayın nedeni bir güvenlik sorunuysa, yük devretme ortamınızda etkilenen sistemleri kurtarmadan önce bu sorunu azaltın.

  • İş yükünüzün yedeklilik tasarımına bağlı olarak, iş yükünü müşterileriniz için yeniden kullanılabilir hale getirmeden önce önemli bir yük devretme sonrası iş yapmanız gerekebilir. Yük devretme sonrası çalışma DNS güncelleştirmelerini, veritabanı bağlantı dizesi güncelleştirmelerini ve trafik yönlendirme değişikliklerini içerebilir. Kurtarma yordamlarınızdaki yük devretme sonrası tüm işleri yakalayın.

    Not

    Yedeklilik tasarımınız büyük olaylardan tamamen veya kısmen otomatik olarak kurtulmanıza olanak tanıyabilir, bu nedenle planınızda bu senaryolarla ilgili süreçler ve yordamlar bulunduğundan emin olun. Örneğin, kullanılabilirlik alanlarını veya bölgeleri kapsayan tamamen etkin-etkin bir tasarımınız varsa, kullanılabilirlik alanı veya bölgesel kesintiden sonra otomatik olarak saydam bir şekilde yük devretme gerçekleştirebilir ve DR planınızda gerçekleştirilmesi gereken adımları en aza indirebilirsiniz. Benzer şekilde, iş yükünüzü dağıtım damgalarını kullanarak tasarladıysanız damga pulları bölge içinde dağıtılırsa yalnızca kısmi bir kesinti yaşayabilirsiniz. Bu durumda DR planınız, etkilenmeyen bölgelerde veya bölgelerdeki damgaların nasıl kurtarılması gerektiğini kapsamalıdır.

  • Uygulamanızı yük devretme ortamında yeniden dağıtmanız gerekiyorsa, dağıtım işlemini mümkün olduğunca otomatikleştirmek için araçları kullanın. Uygulama dağıtımlarınıza hemen başlayabilmeniz için DevOps işlem hatlarınızın yük devretme ortamlarında önceden dağıtıldığından ve yapılandırıldığından emin olun. Tutarlı ve verimli bir dağıtım süreci sağlamak için gerektiğinde el ile onay geçitleriyle otomatik uçtan uca dağıtımlar kullanın. Tam dağıtım süresinin kurtarma hedeflerinizle uyumlu olması gerekir.

    • Dağıtım işleminin bir aşaması el ile müdahale gerektirdiğinde, el ile gerçekleştirilen adımları belgeleyin. Rolleri ve sorumlulukları net bir şekilde tanımlayın.

  • Yordamın mümkün olduğunca çoğunu otomatikleştirin. Betiklerinizde, bir kez etkililiğe izin verdiğinden bildirim temelli programlamayı kullanın. Bildirim temelli programlamayı kullanamıyorsanız, özel kodunuzu geliştirme ve çalıştırma konusunda dikkatli olun. Bozuk bir görevde takılan betiklerde zaman kaybetmemek için yeniden deneme mantığını ve devre kesici mantığını kullanın. Bu betikleri yalnızca acil durumlarda çalıştırdığınızdan, yanlış geliştirilen betiklerin daha fazla zarara neden olmasını veya kurtarma sürecinizi yavaşlatmasını istemezsiniz.

    Not

    Otomasyon risk oluşturur. Eğitilen operatörlerin otomatik işlemleri dikkatle izlemesi ve herhangi bir işlemde sorunlarla karşılaşması durumunda müdahalede bulunmaları gerekir. Otomasyonun hatalı pozitif sonuçlara tepki verme riskini en aza indirmek için DR tatbikatlarınızda kapsamlı olun. Planın tüm aşamalarını test edin. Uyarı oluşturmak için algılama simülasyonu yapın ve ardından kurtarma yordamının tamamında ilerleyin.

    DR tatbikatlarınızın kurtarma hedefi ölçümlerinizdeki güncelleştirmeleri doğrulaması veya bilgilendirmesi gerektiğini unutmayın. Otomasyonunuzun hatalı pozitif sonuçlara karşı duyarlı olduğunu fark ederseniz yük devretme eşiklerinizi artırmanız gerekebilir.

  • Dr yordamlarıyla olası karışıklıkları önlemek için yeniden çalışma planını DR planından ayırın. Yeniden çalışma planı, DR planının tüm geliştirme ve bakım önerilerine uygun olmalı ve aynı şekilde yapılandırılmalıdır. Yük devretme için gerekli olan el ile uygulanan adımlar yeniden çalışma planına yansıtılmalıdır. Yük devretme sonrasında yeniden çalışma hızlı bir şekilde gerçekleşebilir veya günler veya haftalar sürebilir. Yük devretmeden ayrı olarak yeniden çalışma seçeneğini göz önünde bulundurun.

    • Yeniden çalışma gereksinimi durumsaldır. Performans nedenleriyle trafiği bölgeler arasında yönlendiriyorsan yükün ilk olarak yük devretme bölgesinde yeniden başarısız olması önemlidir. Diğer durumlarda, iş yükünüzü herhangi bir zamanda hangi üretim ortamında bulunduğundan bağımsız olarak tam olarak çalışması için tasarlamış olabilirsiniz.

Olağanüstü durum kurtarma tatbikatları gerçekleştirme

Dr test uygulaması, iyi geliştirilmiş bir DR planı kadar önemlidir. Birçok sektörde, düzenli olarak belirli sayıda DR tatbikatı yapılmasını gerektiren uyumluluk çerçeveleri vardır. Sektörünüz ne olursa olsun, düzenli DR tatbikatları başarınızdan çok önemlidir.

Başarılı DR tatbikatları için şu önerileri izleyin:

  • Yılda en az bir üretim DR tatbikatı gerçekleştirin. Masa üstü (kuru çalıştırma) tatbikatları veya üretim dışı tatbikatlar, ilgili tarafların rollerini ve sorumluluklarını bilmeleri için yardımcı olur. Bu tatbikatlar, operatörlerin kurtarma işlemlerini izleyerek aşinalık ("kas belleği") oluşturmasına da yardımcı olur. Ancak yalnızca üretim tatbikatları DR planının ve RTO ile RPO ölçümlerinin geçerliliğini gerçekten test eder. İş yükünüz için tanımlanan RTO ve RPO hedeflerinin ulaşılabilir olduğundan emin olmak için üretim tatbikatlarınızı kullanarak bileşenler ve akışlar için kurtarma işlemlerini zamanlayarak gerçekleştirin. DNS yayma gibi denetiminizin dışında olan işlevler için, bu işlevleri içeren akışlar için RTO ve RPO hedeflerinin denetiminizin ötesindeki olası gecikmeleri hesabadığından emin olun.

  • Masa üstü tatbikatlarını yalnızca deneyimli operatörler için bilgi edinmek için değil, aynı zamanda DR işlemleri ve yordamları hakkında yeni operatörler eğitmek için kullanın. Üst düzey operatörlerin yeni operatörlerin rollerini gerçekleştirmesine izin vermesi zaman almalı ve geliştirme fırsatları için watch olmalıdır. Yeni bir işleç, yordamdaki bir adımla tereddütlü veya kafası karışmışsa, açıkça yazıldığına emin olmak için bu yordamı gözden geçirin.

Dikkat edilmesi gerekenler

  • Üretimde DR tatbikatları gerçekleştirmek beklenmeyen yıkıcı hatalara neden olabilir. İlk dağıtımlarınız sırasında üretim dışı ortamlarda kurtarma yordamlarını test edin.

  • Tatbikatlar sırasında ekibinize mümkün olduğunca fazla bakım süresi verin. Bakım süresini planlarken, test sırasında yakaladığınız kurtarma ölçümlerini gerekli minimum süre için kullanın.

  • DR tatbikatı uygulamalarınız olgunlaştıkça hangi yordamları paralel olarak çalıştırabileceğinizi ve hangilerini sırayla çalıştırmanız gerektiğini öğrenirsiniz. Detay uygulamalarınızın başında, her yordamın sırayla çalıştırılması gerektiğini ve tahmin edilmeyen sorunları işlemek için her adımda ek zamana ihtiyacınız olduğunu varsayalım.

Azure kolaylaştırma

Birçok Azure ürününde yerleşik yük devretme özellikleri vardır. Bu özellikler hakkında bilgi sahibi olun ve bunları kurtarma yordamlarına ekleyin.

IaaS (hizmet olarak altyapı) sistemlerinde yük devretme ve kurtarmayı otomatikleştirmek için Azure Site Recovery kullanın. Yaygın PaaS ürünleri için aşağıdaki makalelere bakın:

Örnek

Bir kurumsal veri varlığını DR için hazırlama hakkında rehberlik için bkz. Azure için DR veri platformu serisi.

Güvenilirlik denetim listesi

Önerilerin tamamına bakın.

Güvenilirlik denetim listesi