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 noktadan alışveriş" görevi görür
- Azure olayları oluştuğunda 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 noktadan alışveriş" görevi görür
- Otomatik hizmet olayı uyarı bildirimlerini 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ğlayacak
- 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ıyla Twitter) sayfasına gidin @AzureSupport
- Etki/sorunlar olayla eşleşmiyorsa (veya risk azaltmadan sonra devam ederse) 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ü Durumda Yeniden Dağıtma" stratejisi için aşağıdaki üst düzey süreç akışı açıklanabilir.
Contoso'da Kurtarma – Kurumsal Paylaşılan Hizmetler ve kaynak sistemler
- 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 tamamlanacak
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
- Bileşenlerin ve dağıtım stratejilerinin ayrıntılı dökümü için bu serideki Azure Hizmet ve Bileşen Bölümüne bakın
- 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 devretme, verilerin/işlemlerin geçerli zaman damgasının onayını içermelidir
- Temel kurumsal veri işlemleri yürütülecekse, tek tek çözümlere bu ( gelen/giden akışlar) dikkate alınmalıdır, örneğin
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 diğerlerine göre önceliklendirilebilir. Örneğin, geçici laboratuvarlar üzerindeki temel kurumsal işlemler
- Doğrulama adımları tamamlandıktan sonra, DR kurtarma sürecini başlatmak için aşağı akış çözümlerine bir devretme 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, E2E sürecini kapsamak için gereken SDLC etkinliklerinin maliyetine karşılık olayın riski düşük olabilir
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 alma işlemlerini yeniden yürüterek veya yeniden yürüterek ele alınmalıdır
- Hem iş hem de teknik paydaşların onayıyla bir geri dönüş penceresi seçilir. İdeal olarak, sistem etkinliği ve işleme sırasında
- 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ılabilir veya geri alınabilir
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şlem
"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ı almak gibi müşteri DR sürecine özgü ayrıntılar ("bitti tanımı" dahil), hizmet desteği DR bilet başvurusu ve savaş odası 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 ve/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
- Aşağı akış sistemlerini etkile – operasyonel destek
- Yukarı Akış Kaynak sistemleri – operasyonel destek
- Kurumsal paylaşılan hizmetler kişileri. Örneğin, erişim/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ı
- E2E senaryosunun uçtan uca ayrıntılarını açıklama ve ilişkili tüm destek belgelerini ekleme
- Bağımlılık
- Bileşenin tüm ilişkilerini ve bağımlılıklarını listeleme
- DR Önkoşulları
- Yukarı akış kaynak sistemlerinin gerektiği gibi kullanılabilir olduğunu onaylama
- Dr yürütücü kaynaklarına yığın genelinde yükseltilmiş erişim verildi
- 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
- Beklenmedik durum 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ı
- Sistemin anahtar bileşenler arasında 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ı tamamlayan iş KOBİ'lerinin de dahil olduğu İş Katılımcısı gözden geçirme sürecine hazırlanma
- İş Paydaşını Gözden Geçirme ve Onaylama
- İş kaynağı iletişim bilgileri
- Yukarıdaki teknik kurtarma işlemine göre İş doğrulama adımları
- İş onaylayanın kurtarmayı kapatması için gereken 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
- Yükseltilmiş erişim ayrıcalıklarının DR ekibinden kaldırılabildiğini Güvenlik yönetimine bildirme
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 hizmetlerinin riskini azaltmak için DR planının azure ve hizmetleri hakkında güncel bilgilere sahip kaynaklar tarafından düzenli olarak yeniden ziyaret edilmesi, test edilmesi ve yürütülmesi gerekir
- 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/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 edilebilmesini 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ştirme (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.
- Önemli bileşenleri, Microsoft'un hizmet kurtarma etkinlikleri için daha fazla sorumluluk aldığı PaaS gibi daha yüksek hizmet katmanlarına kadar kaldırma
- RTO'yu paydaşlarla genişletme
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şletme
- 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 azaltma
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 burada 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.