Gerekli müşteri etkinlikleri
Olay öncesi
Azure hizmetleri için
- Azure portalında Azure Hizmet Durumu hakkında bilgi sahibi olun. Bu sayfa bir olay sırasında "tek duraklı mağaza" görevi görür.
- Azure olayları gerçekleştiğinde otomatik olarak bildirim üretmek üzere yapılandırılabilir hizmet durumu uyarılarının kullanımını göz önünde bulundurun.
Power BI için
- Microsoft 365 yönetim merkezi Hizmet Durumu hakkında bilgi sahibi olun. Bu sayfa bir olay sırasında "tek duraklı mağaza" görevi görür.
- Otomatik hizmet olayı uyarı bildirimleri almak için Microsoft 365 Yönetici mobil uygulamasını kullanmayı göz önünde bulundurun.
Olay sırasında
Azure hizmetleri için
- Azure yönetim portalında Azure Hizmet Durumu en son güncelleştirmeleri sağlayacaktır.
- Hizmet Durumu'na erişirken sorun yaşıyorsanız Azure Durumu sayfasına bakın.
- Durum sayfasına erişirken sorun yaşıyorsanız X (eski adı Twitter) sayfasına gidin @AzureSupport .
- Etki/sorunlar olayla eşleşmiyorsa (veya risk azaltmadan sonra devam ederse) bir hizmet destek bileti oluşturmak için desteğe başvurun.
Power BI için
- Microsoft 365 yönetim merkezi içindeki Hizmet Durumu sayfası en son güncelleştirmeleri sağlar
- Hizmet Durumu'na erişirken sorun yaşıyorsanız Microsoft 365 durum sayfasına bakın
- Etki/sorunlar olayla eşleşmiyorsa (veya azaltma sonrasında sorunlar devam ederse), bir hizmet destek bileti oluşturmanız gerekir.
Microsoft kurtarma sonrası
Bu ayrıntı için aşağıdaki bölümlere bakın.
Olay sonrası
Azure Hizmetleri için
Power BI için
Microsoft işlemini bekleyin
"Microsoft'u bekle" işlemi yalnızca Microsoft'un etkilenen birincil bölgedeki tüm bileşenleri ve hizmetleri kurtarmasını beklemektir. Kurtarıldıktan sonra, veri platformunun kurumsal paylaşılan hizmetlere veya diğer hizmetlere bağlanmasını, veri kümesinin tarihini doğrulayın ve ardından sistemi geçerli tarihe getirme işlemlerini yürütebilirsiniz.
Bu süreç tamamlandıktan sonra, hizmet kurtarma için paydaş onayının etkinleştirilmesi için teknik ve iş konusu uzmanı (SME) doğrulaması tamamlanabilir.
Olağanüstü durumda yeniden dağıtma
"Olağanüstü durum üzerinde yeniden dağıtma" stratejisi için aşağıdaki üst düzey süreç akışı açıklanabilir.
Contoso'nun kurumsal paylaşılan hizmetlerini ve kaynak sistemlerini kurtarma
- Bu adım, veri platformunun kurtarılması için bir önkoşuldur.
- Bu adım, kurumsal paylaşılan hizmetlerden ve operasyonel kaynak sistemlerinden sorumlu çeşitli Contoso operasyonel destek grupları tarafından tamamlanır.
Azure hizmetlerini kurtarma Azure Hizmetleri, Azure Bulut teklifinin dağıtım için ikincil bölgede kullanılabilir olmasını sağlayan uygulama ve hizmetleri ifade eder.
Azure Hizmetleri, Azure Bulut teklifini dağıtım için ikincil bölgede kullanılabilir hale getiren uygulama ve hizmetleri ifade eder.
- Bu adım, veri platformunun kurtarılması için bir önkoşuldur.
- Bu adım, Microsoft ve diğer hizmet olarak platform (PaaS)/hizmet olarak yazılım (SaaS) iş ortakları tarafından tamamlanır.
Veri platformu temelini kurtarma
- Bu adım, Platform kurtarma etkinliklerinin giriş noktasıdır.
- Yeniden dağıtım stratejisi için gerekli her bileşen/hizmet temin edilir ve ikincil bölgeye dağıtılır.
- Bu işlem ayrıca kurumsal paylaşılan hizmetlere bağlama, erişim/kimlik doğrulaması bağlantısını sağlama ve günlük boşaltma işleminin çalıştığını doğrulama ve hem yukarı hem de aşağı akış işlemlerine bağlantı sağlama gibi etkinlikleri içermelidir.
- Veri/İşleme onaylanmalıdır. Örneğin, kurtarılan platformun zaman damgasının doğrulanması.
- Veri bütünlüğüyle ilgili sorular varsa, platformu güncel hale getirmek için yeni işlemeyi yürütmeden önce zaman içinde geri alma kararı alınabilir.
- İşlemler için öncelik sırasına sahip olmak (iş etkisine bağlı olarak) kurtarmanın düzenlemesine yardımcı olur.
- İş kullanıcıları hizmetlerle doğrudan etkileşime girmediği sürece bu adım teknik doğrulamayla kapatılmalıdır. Doğrudan erişim varsa, bir iş doğrulama adımı olması gerekir.
- Doğrulama tamamlandıktan sonra, kendi olağanüstü durum kurtarma (DR) kurtarma sürecini başlatmak için tek tek çözüm ekiplerine bir teslim gerçekleşir.
- Bu aktarma işlemi, verilerin ve işlemlerin geçerli zaman damgasının onayını içermelidir.
- Temel kurumsal veri işlemleri yürütülecekse, örneğin gelen/giden akışlar gibi tek tek çözümlere dikkat edilmelidir.
Platform tarafından barındırılan tek tek çözümleri kurtarma
- Her bir çözümün kendi DR runbook'u olmalıdır. Runbook'lar en azından hizmet kurtarmanın tamamlandığını test edecek ve onaylayacak aday iş paydaşlarını içermelidir.
- Kaynak çekişmesi veya önceliğine bağlı olarak, temel çözümler/iş yükleri, örneğin geçici laboratuvarlar üzerindeki temel kurumsal işlemlere göre diğerlerine göre önceliklendirilebilir.
- Doğrulama adımları tamamlandıktan sonra, DR kurtarma sürecini başlatmak için aşağı akış çözümlerine bir geçiş gerçekleşir.
Aşağı akışa, bağımlı sistemlere devretme
- Bağımlı hizmetler kurtarıldıktan sonra E2E DR kurtarma işlemi tamamlanır.
Not
Teorik olarak bir E2E DR işlemini tamamen otomatikleştirmek mümkün olsa da, olayın riski ile E2E sürecini kapsamak için gereken SDLC etkinliklerinin maliyetine göre pek olası değildir.
Birincil bölgeye geri dönüş Geri dönüş, veri platformu hizmetini ve verilerini BAU için kullanılabilir duruma geldikten sonra birincil bölgeye geri taşıma işlemidir.
Kaynak sistemlerin yapısına ve çeşitli veri süreçlerine bağlı olarak, veri platformunun geri dönüşü, veri eko sisteminin diğer bölümlerinden bağımsız olarak yapılabilir.
Müşterilerin uygun kararı vermek için kendi veri platformlarının bağımlılıklarını (hem yukarı hem de aşağı akış) gözden geçirmeleri önerilir. Aşağıdaki bölümde, veri platformunun bağımsız bir kurtarması varsayılır.
- Tüm gerekli bileşenler/hizmetler birincil bölgede kullanılabilir hale geldikten sonra müşteriler, Microsoft kurtarmasını doğrulamak için bir duman testi tamamlar.
- Bileşen/Hizmet yapılandırması doğrulanır. Deltalar, kaynak denetiminden yeniden dağıtım yoluyla ele alınmalıdır.
- Birincil bölgedeki sistem tarihi durum bilgisi olan bileşenler arasında belirlenecek. Oluşturulan tarih ile ikincil bölgedeki tarih/zaman damgası arasındaki değişim, bu noktadan sonra veri alımı işlemleri yeniden yürütülerek veya yeniden yürütülerek ele alınmalıdır.
- Hem iş hem de teknik paydaşların onayıyla bir geri dönüş penceresi seçilir. İdeal olarak, bu durum sistem etkinliği ve işleme sırasında gerçekleşmelidir.
- Geri dönüş sırasında birincil bölge, sistem devredilmeden önce ikincil bölgeyle eşitlenir.
- Bir paralel çalıştırma süresinden sonra, ikincil bölge sistemden çevrimdışı duruma getirilir.
- İkincil bölgedeki bileşenler, seçilen DR stratejisine bağlı olarak bırakılır veya geri çıkarılır.
Sıcak Yedek işlem
"Sıcak Yedek" stratejisi için üst düzey işlem akışı, bileşenlerin ikincil bölgede zaten tedarik edilmiş olması arasındaki temel fark olan "Olağanüstü Durumda Yeniden Dağıtma" ile yakın bir şekilde hizalanır. Bu strateji, bu bölgede kendi DR'lerini tamamlamak isteyen diğer kuruluşların kaynak çekişmesi riskini ortadan kaldırır.
Sık Erişimli Yedek işlemi
"Sık Erişimli Yedek" stratejisi, PaaS ve hizmet olarak altyapı (IaaS) sistemlerini içeren Platform hizmetlerinin, ikincil sistemler birincil sistemlerle aynı anda çalışırken olağanüstü durum olayına rağmen devam edeceği anlamına gelir. "Sıcak Yedek" stratejisinde olduğu gibi, bu strateji de bu bölgede kendi DR'lerini tamamlamak isteyen diğer kuruluşların kaynak çekişmesi riskini ortadan kaldırır.
Sık Erişimli Yedek müşteriler, birincil bölgedeki bileşenlerin/hizmetlerin Microsoft kurtarmasını izler. Tamamlandıktan sonra müşteriler birincil bölge sistemlerini doğrular ve birincil bölgeye geri dönüşü tamamlar. Bu işlem, dr yük devretme işlemine benzer, yani kullanılabilir kod tabanını ve verileri denetleyin ve gerektiğinde yeniden dağıtın.
Not
Sistem meta verilerinin iki bölge arasında tutarlı olduğundan emin olmak için burada özel bir not bulunmalıdır.
- Birincil bölgeye geri dönüş tamamlandıktan sonra sistem yük dengeleyicileri, birincil bölgeyi sistem topolojisine geri getirmek için güncelleştirilebilir. Varsa, sistem için birincil bölgeyi artımlı olarak değiştirmek için bir kanarya sürümü yaklaşımı kullanılabilir.
DR plan yapısı
Etkili bir DR planı, Bir Azure teknik kaynağı tarafından yürütülebilecek hizmet kurtarma için adım adım bir kılavuz sunar. Bu nedenle, dr planı için önerilen MVP yapısı aşağıda listelanmıştır.
- İşlem gereksinimleri
- DR'yi başlatmak için gereken doğru yetkilendirme ve kurtarmayla ilgili gerekli önemli kararları alma ("bitti tanımı" dahil), hizmet desteği DR bilet başvurusu ve savaş odası ayrıntıları gibi müşteri DR sürecine özgü ayrıntılar.
- DR lideri ve yürütücü yedeklemesi de dahil olmak üzere kaynak onayı. Tüm kaynaklar birincil ve ikincil kişilerle, yükseltme yollarıyla ve takvimlerden ayrılarak belgelenmelidir. Kritik DR durumlarında, liste sistemlerinin dikkate alınması gerekebilir.
- DR yürütücüsü, DR yedeklemesi ve herhangi bir yükseltme noktası için dizüstü bilgisayar, güç paketleri veya yedekleme gücü, ağ bağlantısı ve cep telefonu ayrıntıları.
- İşlem gereksinimlerinden herhangi biri karşılanmadıysa izlenecek işlem.
- Kişi listesi
- DR liderliği ve destek grupları.
- Teknik kurtarma için test/gözden geçirme döngüsünü tamamlayacak olan iş KOBİ'leri.
- Hizmet kurtarma onaylayanları da dahil olmak üzere etkilenen İş Sahipleri.
- Teknik kurtarma onaylayanları da dahil olmak üzere etkilenen Teknik Sahipler.
- Platform tarafından barındırılan önemli çözümler de dahil olmak üzere etkilenen tüm alanlarda SME desteği.
- Etkilenen aşağı akış sistemleri – operasyonel destek.
- Yukarı akış kaynak sistemleri – operasyonel destek.
- Kurumsal paylaşılan hizmetler kişileri. Örneğin, erişim ve kimlik doğrulama desteği, güvenlik izleme ve ağ geçidi desteği
- Bulut sağlayıcıları için destek kişileri de dahil olmak üzere tüm dış veya üçüncü taraf satıcılar.
- Mimari tasarımı
- Son uç (E2E) senaryosunun ayrıntılarını açıklayın ve ilişkili tüm destek belgelerini ekleyin.
- Bağımlılıklar
- Tüm bileşenlerin ilişkilerini ve bağımlılıklarını listeleyin.
- DR önkoşulları
- Yukarı akış kaynak sistemlerinin gerektiği gibi kullanılabilir olduğunu onaylar.
- Dr yürütücü kaynaklarına yığın genelinde yükseltilmiş erişim verilmiştir.
- Azure hizmetleri gerektiği gibi kullanılabilir.
- Önkoşullardan herhangi biri karşılanmadıysa izlenecek işlem.
- Teknik kurtarma - adım adım yönergeler
- Çalıştırma sırası.
- Adım açıklaması.
- Adım önkoşulu.
- URL'ler de dahil olmak üzere her ayrı eylem için ayrıntılı işlem adımları.
- Gerekli kanıt da dahil olmak üzere doğrulama yönergeleri.
- Olasılıklar da dahil olmak üzere her adımın tamamlanması beklenen süre.
- Adım başarısız olursa izlenecek işlem.
- Hata veya SME desteği durumunda yükseltme noktaları.
- Teknik kurtarma - koşullar sonrası
- Temel bileşenler arasında sistemin geçerli tarih zaman damgasını onaylayın.
- DR sistem URL'lerini ve IP'lerini onaylayın.
- Sistem erişiminin onaylanması ve doğrulama ve onay işlemlerini tamamlayan iş KOBİ'leri de dahil olmak üzere İş Katılımcısı gözden geçirme sürecine hazırlanın.
- İş Katılımcısı incelemesi ve onayı
- İş kaynağı iletişim bilgileri.
- Yukarıdaki teknik kurtarmaya göre iş doğrulama adımları.
- kurtarmayı imzalayan iş onaylayıcısının gerektirdiği kanıt izi.
- Kurtarma sonrası koşulları
- Sistemi güncel hale getirmek için veri işlemlerini yürütmek için operasyonel desteğe devretme.
- Aşağı akış süreçlerini ve çözümlerini devretme – DR sisteminin tarih ve bağlantı ayrıntılarını onaylama.
- Kurtarma işleminin DR lideriyle tamamlandığını onaylayın; kanıt izini ve tamamlanan runbook'u onaylayın.
- Güvenlik ekiplerine yükseltilmiş erişim ayrıcalıklarının DR ekibinden kaldırılabildiğini bildirin.
Açıklama Balonları
- Her adım işleminin sistem ekran görüntülerinin eklenmesi önerilir. Bu ekran görüntüleri, görevleri tamamlamak için sistem KOBİ'lerine bağımlılığı gidermeye yardımcı olur.
- Hızla gelişen bulut hizmetlerine ayak uydurmak için, DR planı azure ve hizmetleri hakkında güncel bilgilere sahip kaynaklar tarafından düzenli olarak yeniden ziyaret edilmeli, test edilmeli ve yürütülmelidir.
- Teknik kurtarma adımları, bileşenin ve çözümün kuruluşa önceliğini yansıtmalıdır. Örneğin, temel kurumsal veri akışları geçici veri analizi laboratuvarlarından önce kurtarılır.
- Key Vault gibi temel bileşenler veya hizmet kurtarıldıktan sonra teknik kurtarma adımları iş akışlarının sırasını (genellikle soldan sağa) izlemelidir. Bu strateji, yukarı akış bağımlılıklarının kullanılabilir olmasını ve bileşenlerin uygun şekilde test edilmesini sağlar.
- Adım adım plan tamamlandıktan sonra, acil durum içeren etkinlikler için toplam süre elde edilmelidir. Bu toplam, üzerinde anlaşmaya varılan kurtarma süresi hedefi (RTO) üzerindeyse, çeşitli seçenekler vardır:
- Seçili kurtarma işlemlerini otomatikleştirin (mümkün olduğunda).
- Seçili kurtarma adımlarını paralel (mümkün olduğunda) çalıştırma fırsatlarını arayın. Ancak, bu stratejinin ek DR yürütücü kaynakları gerektirebileceğine dikkat edin.
- Temel bileşenleri, Microsoft'un hizmet kurtarma etkinliklerinin sorumluluğunu üstlendiği PaaS gibi daha yüksek hizmet katmanlarına kadar çıkarın.
- RTO'yu paydaşlarla genişletin.
DR testi
Azure Bulut hizmeti teklifinin doğası, tüm DR test senaryoları için kısıtlamalara neden olur. Bu nedenle, kılavuz, veri platformu bileşenleri ikincil bölgede kullanılabilir olacak şekilde bir DR aboneliği oluşturmaktır.
Bu temelden dr planı runbook'u seçmeli olarak yürütülebilir ve dağıtılabilir ve doğrulanabilen hizmetlere ve bileşenlere özel olarak dikkat edilir. Bu işlem, plana göre teknik ve iş doğrulama denetimlerinin onaylanmasını sağlayan, seçilmiş bir test veri kümesi gerektirir.
Dr planı, yalnızca güncel olduğundan emin olmak için değil, aynı zamanda yük devretme ve kurtarma etkinlikleri gerçekleştiren ekipler için "kas belleği" oluşturmak için düzenli olarak test edilmelidir.
- Tüm kurtarma etkinliklerini desteklemek için "amaca uygun" olduklarından emin olmak için veri ve yapılandırma yedeklemeleri de düzenli olarak test edilmelidir.
DR testi sırasında odaklanılması gereken temel alan, açıklayıcı adımların hala doğru olduğundan ve tahmini zamanlamaların hala uygun olduğundan emin olmaktır.
- Yönergeler kod yerine portal ekranlarını yansıtıyorsa, buluttaki değişikliğin temposu nedeniyle yönergeler en az 12 ayda bir doğrulanmalıdır.
Amaç tam otomatik bir DR işlemine sahip olmak olsa da, olayın nadirliği nedeniyle tam otomasyon pek olası olmayabilir. Bu nedenle, platformu teslim etmek için kullanılan İstenen Durum Yapılandırması (DSC) kod olarak altyapı (IaC) ile kurtarma temelinin oluşturulması ve ardından temele yeni projeler oluşturulurken yukarı kaldırmanın yapılması önerilir.
- Bileşenler ve hizmetler genişletildikçe zaman içinde, üretim dağıtım işlem hattının DR kapsamı sağlamak üzere yeniden düzenlenmesini gerektiren bir NFR uygulanmalıdır.
Runbook zamanlamalarınız RTO'nuzu aşarsa birkaç seçenek vardır:
- RTO'yu paydaşlarla genişletin.
- Otomasyon aracılığıyla görevleri paralel olarak çalıştırma veya daha yüksek bulut sunucusu katmanlarına geçiş yoluyla kurtarma etkinlikleri için gereken süreyi düşürebilirsiniz.
Azure Chaos Studio
Azure Chaos Studio , Azure uygulamalarınıza hata ekleyerek dayanıklılığı geliştirmeye yönelik yönetilen bir hizmettir. Chaos Studio, denemeleri kullanarak Azure kaynaklarınıza hata ekleme işlemini güvenli ve denetimli bir şekilde düzenlemenizi sağlar. Şu anda desteklenen hata türlerinin açıklaması için ürün belgelerine bakın.
Chaos Studio'nun geçerli yinelemesi yalnızca Azure bileşenlerinin ve hizmetlerinin bir alt kümesini kapsar. Daha fazla hata kitaplığı eklenene kadar Chaos Studio, tam sistem DR testi yerine yalıtılmış dayanıklılık testi için önerilen bir yaklaşımdır.
Chaos studio hakkında daha fazla bilgiyi Azure Chaos Studio belgelerinde bulabilirsiniz.
Azure Site Recovery
IaaS bileşenleri için Azure Site Recovery, desteklenen bir VM veya fiziksel sunucuda çalışan iş yüklerinin çoğunu korur
Bunun için güçlü rehberlik vardır:
- Azure VM Olağanüstü Durum Kurtarma Tatbikatı Yürütme
- İkincil Bölgeye DR yük devretmesi yürütme
- Birincil Bölgeye DR geri dönüşünü yürütme
- DR Planının otomasyonunun etkinleştirilmesi
İlgili kaynaklar
- Dayanıklılık ve kullanılabilirlik için mimari oluşturma
- İş sürekliliği ve olağanüstü durum kurtarma
- Azure uygulamaları için yedekleme ve olağanüstü durum kurtarma
- Azure'da dayanıklılık
- hizmet düzeyi sözleşmeleri (SLA) Özeti
- Hatayı Tahmin Etmek için En İyi Beş Yöntem
Sonraki adımlar
Senaryoyu dağıtmayı öğrendiğinize göre Artık Azure için DR veri platformu serisinin özetini okuyabilirsiniz.