Güvenilirlik yolculuğu, sistemlerin kullanılabilir kalmasını ve kullanıcı beklentilerini karşılamasını sağlamak için her aşamanın bir önceki aşamaya göre derlendiği adım adım bir süreçtir. Bu olgunluk modeli, geçerli durumunuzu değerlendirmenize ve iyileştirme için yapılandırılmış bir yol sunmanıza yardımcı olmak için tasarlanmıştır.
İlk adım, geniş kapsamlı optimizasyon gerektirmeden anında iyileştirmeler için alanlar arası yedeklilik gibi yerleşik Azure güvenilirlik özelliklerini kullanarak Azure'un sunduğu temel güvenilirlik özelliklerini devreye alarak başlar.
Karşıtlık olarak, yüksek güvenilirlik elde etmenin yolu hataları kabul etmek kaçınılmazdır. Her sorunu önlemeye çalışmak yerine, sorun oluştuğunda sisteminizin nasıl yanıt vereceğini planlamak daha etkilidir. İş gereksinimleriniz, hangi risklerin proaktif olarak ele alındığını belirlemenize yardımcı olur. Ekipler, yapılandırılmış gözlemlenebilirlik ile gelişmiş izleme özelliklerine yatırım yapar, uygulama düzeyi endişelerini içerecek şekilde hata azaltmayı genişletir ve dayanıklılık önlemlerini test etmeye başlar.
Ekipler daha sonra iş içgörülerini teknik becerilerle tümleştirir. Ekipler sistem durumu modellemesi uygular, hata modu analizi gerçekleştirir ve kapsamlı olağanüstü durum kurtarma planları hazırlar. Bu aşama, ölçülebilir hedefler ve çeşitli hata senaryoları için sistematik hazırlık yoluyla sorumluluk sağlar.
Sistem canlı hale geldikten sonra, değişiklik yönetimi, veri büyümesi ve operasyonel karmaşıklık ile ilgilenme ve bunların sisteminizin güvenilirliğini nasıl etkilediği gibi üretim ortamlarının zorluklarını yönetmeye geçilir.
Son düzeyin amacı dayanıklı kalmaktır ve kesintisiz çalışır. Bu düzey, teknik denetimlerin ötesinde mimari uyarlanabilirliğe geçişi temsil eder. Bu düzey, iş yükleri geliştikçe ve büyüdükçe sistemlerin yeni ve öngörülemeyen risklere dayanmasını sağlama konusuna odaklanır.
Model, her biri birincil hedefe ve bir dizi temel stratejiye sahip beş ayrı olgunluk düzeyine yapılandırılmıştır. Her düzeyi keşfetmek için aşağıdaki sekmeli görünümleri kullanın. İlerledikçe vurgulanan dengeleri ve ilişkili riskleri de gözden geçirmeyi unutmayın.
İyileştirme görevlerine zaman harcamak yerine iş yükü altyapısında ve işlemlerinde dayanıklılık için sağlam bir temel oluşturun.
Olgunluk modelinin 1. düzeyi, iş yükü ekiplerinin sistem güvenilirliği için güçlü bir temel oluşturmasına yardımcı olmak için tasarlanmıştır. Gelecekteki güvenilirlik kararları için gerekli temel bilgileri kurma işlemi olan temellendirme, odak noktasıdır. Bu aşama çoğunlukla geçerli uygulamalara yönelik küçük uzantılarla işlevsel uygulamayı içerir.
Bu aşama araştırmayı, içgörü kazanmayı ve sistemlerinizin envanterini oluşturmayı içerir. Ayrıca Azure'da anında iyileştirmeler için alanlar arası yedekliliği etkinleştirme gibi yerleşik güvenilirlik özelliklerini de kullanır.
Bu temel bilgileri oluşturarak, sisteminizin dayanıklılığını ve performansını aşamalı olarak geliştirmek için ekibinizi güvenilirlik olgunluk modeli düzeylerinde ilerlemeye hazırlayabilirsiniz.
Temel stratejiler
✓ Operasyonel sorumluluğu boşaltma fırsatlarını değerlendirme
Bu strateji temelde bir inşa etme ve satın alma veya başka birine güvenme yaklaşımıdır. Karar, gelecekteki gelişimi desteklerken bu aşamada ne kadar sorumluluğun yönetilebilir olduğuna bağlıdır. İş yüküyle ilgili kaynakları kullanmak istiyorsunuz, ancak bakım sorumluluğunu devretme fırsatlarını her zaman keşfetmeniz gerekir. Bu yaklaşımı uygulamak isteyebileceğiniz bazı klasik kullanım örnekleri aşağıdadır.
Hizmet olarak platform (PaaS) çözümlerini seçerek sorumlulukları bulut platformuna devredin. Çoğaltma, yük devretme ve yedekleme depoları gibi yaygın dayanıklılık gereksinimleri için hazır çözümler sağlar. Bu yaklaşımı benimsediğinizde, bulut sağlayıcısı barındırma, bakım ve dayanıklılık geliştirmelerini işler.
Örneğin, bulut sağlayıcısı verileri birden çok işlem düğümü arasında çoğaltır ve çoğaltmaları kullanılabilirlik alanlarına dağıtır. Sanal makineler (VM' ler) üzerinde kendi çözümünüzü oluşturursanız, zaman alan ve karmaşık olabilecek bu özellikleri kendiniz yönetmeniz gerekir.
Doğrudan iş yükünün iş hedefleriyle bağlantılı olmayan işlemler için sorumlulukları devredin. Veritabanı yönetimi ve güvenlik gibi bazı özel işlemler, iş yükünüzün güvenilirliğini etkileyebilir. Bu görevleri deneyimli ekiplere, teknolojiye veya her ikisine birden sahip olma olasılığını keşfedin.
Örneğin, ekibinizin veritabanı uzmanlığı yoksa, sorumluluğu sağlayıcıya kaydırmaya yardımcı olmak için yönetilen hizmetleri kullanın. Bu yaklaşım, ekibinizin iş yükünün işlevselliğine odaklanmasını sağladığından, başlangıç yaptığınızda yararlı olabilir. Birçok kuruluş, paylaşılan ve merkezi olarak yönetilen hizmetlere sahiptir. Platform ekipleri kullanılabilir durumdaysa, bu işlemleri işlemek için bu ekipleri kullanın. Ancak bu yaklaşım bağımlılıkları ve kurumsal karmaşıklığı ekleyebilir.
Alternatif olarak, ekibiniz doğru uzmanlığa sahipse, becerilerini kullanmak ve yönetim özelliklerini içermeyen hizmetleri seçmek için açık bir karar vekleyebilirsiniz.
Sorumlulukları Microsoft dışı satıcılara devredin. Başlangıç noktası olarak kullanıma açık ürünleri seçin. Yalnızca iş yükünüzün iş değerine katkıda bulunduklarında özelleştirilmiş çözümler oluşturun.
Risk:Satın alma veya güvenme seçeneği gereksinimlerinizi kısmen karşılıyorsa, özel uzantılar uygulamanız gerekebilir. Bu yöntem, güncellemelerin ve modernizasyonun uygulanabilir olmadığı "özelleştirme kilitlenmesi" durumuna neden olabilir. Gereksinimlerinizi düzenli olarak gözden geçirin ve çözümün özellikleriyle karşılaştırın. İkisi arasında önemli bir sapma olduğunda için bir çıkış stratejisi geliştirin.
Bunun tersi bir senaryo da bir risktir.
Satın alma veya güvenme seçeneği ilk başta daha basit görünse de PaaS hizmetinin, satıcı çözümünün veya platforma ait kaynakların sınırlamaları iş yükü için gereken ayrıntı düzeyini veya özerklik düzeyini karşılamıyorsa daha sonra yeniden değerlendirme ve yeniden tasarlama gerektirebilir.
✓ Kritik kullanıcı ve sistem akışlarını tanımlama
İş yükünü akışlara ayırmak bu aşamada çok önemlidir.
Kullanıcı ve sistem akışlarına odaklanın. Kullanıcı akışları kullanıcı etkileşimlerini, sistem akışları ise kullanıcı görevleriyle doğrudan ilişkilendirilmemiş iş yükü bileşenleri arasındaki iletişimi belirler.
Örneğin, bir e-ticaret uygulamasında müşteriler gezinti ve sipariş verme gibi ön uç aktiviteleri gerçekleştirir. Bu arada arka uç işlemleri ve sistem tarafından tetiklenen işlemler kullanıcı isteklerini yerine getirmekte ve diğer görevleri yerine getirmektedir. Bu ayrı akışlar aynı sistemin bir parçasıdır, ancak farklı bileşenler içerir ve farklı amaçlara hizmet eder.
Bu aşamada akış kataloğu oluşturmaya başlayın. Kullanıcı etkileşimlerini ve bileşen iletişimlerini gözlemleyin. Akışları listeleyin ve kategorilere ayırın, başlangıç ve bitiş noktalarını tanımlayın ve bağımlılıkları not edin. Netlik için diyagramları kullanarak sonuçları ve özel durumları belgeleyin. Bu katalog, iş paydaşlarıyla yapılan ilk konuşmanın en önemli yönlerini kendi açılarından belirlemesi için önemli bir araç olabilir. Bu konuşma ilk öncelik belirleme düzeyini bilgilendirebilir.
Birincil iş etkinlikleri üzerindeki riski ve etkiyi değerlendirerek bir akışı kritik olarak sınıflandırın. Kesinti bekliyorsanız, düzgün bir düşüş bu kritik akışların korunmasına odaklanır. E-ticaret örneğinde kritik akışlar ürün aramalarını, sepete ürün eklemeyi ve kullanıma alma işlemini içerir çünkü bu görevler iş için çok önemlidir. Ürün verilerini güncelleştirme ve ürün görüntülerini koruma gibi diğer işlemler bu kadar kritik değildir. Kullanıcıların ürün aramaya ve sepete ürün eklemeye devam etmesini sağlayarak gelir kaybını önlemek için kesinti sırasında kritik akışların çalışır durumda kaldığından emin olun.
Uyarı
Bir iş süreci, zamana duyarlı olmasa bile kritik olabilir. Zaman açısından kritiklik önemli bir faktördür. Örneğin, denetim gereksinimlerini karşılamak kritik bir süreçtir, ancak bir denetim için verileri hemen sunmanız gerekmeyebilir. İşlem önemli olmaya devam eder, ancak birkaç saat içinde kurtarma kabul edilebilir olduğundan güvenilirliği zaman açısından kritik değildir.
Daha fazla bilgi için bkz. Azure Well-Architected Framework: Akışları kullanarak iş yükü tasarımını iyileştirme.
✓ Doğru tasarım modelini, kaynakları ve özellikleri seçin
Bu stratejiyi aşağıdaki düzeylerde uygulamanız gerekir:
Mimarlık: İş yükü tasarımı, çeşitli altyapı katmanlarında güvenilirlik beklentilerini hesaba katmalıdır. İlk kararlarınız kapsayıcıya alma ile uygulamayı barındırmak için PaaS arasında seçim olabilir. İsterseniz merkez-uç veya tek bir sanal ağ gibi ağ kurulumlarını da göz önünde bulundurabilirsiniz.
İşlevselliğe göre segmentasyon oluşturan sınırlar da ayarlamanız gerekir. Örneğin, her şeyi tek bölgeli bir sanal diskle tek bir VM'de barındırmak yerine işlem ve veri depolamayı bölmeyi ve ayrılmış hizmetleri kullanmayı göz önünde bulundurun.
Dikkat
Geçiş senaryolarında, yeni fırsatları gözden geçirmeden lift-and-shift yaklaşımını benimsemek, eksik avantajlara ve verimsizliklere yol açabilir. Değiştirilmesi zor olan kurulumlarla takılmamak ve daha iyi seçeneklerden ve geliştirmelerden yararlanmak için modernleştirmeyi erken araştırmak önemlidir.
Azure hizmetleri: Tasarımınız için doğru hizmetleri seçmenize yardımcı olması için karar ağaçlarını kullanın. Geçerli gereksinimlerinizi karşılayan bileşenleri seçin, ancak iş yükünüz geliştikçe ve daha fazla özellik gerektikçe hizmetleri değiştirebilmeniz için esnek kalın.
Azure hizmetlerindeki SKU'lar veya katmanlar: Her SKU'nun özelliklerini gözden geçirin ve platformun kullanılabilirlik garantilerini anlayın. Yayımlanan yüzde dilimi etrafında sağlanan kapsamı anlamak için hizmet düzeyi sözleşmelerini değerlendirin.
Güvenilirliği destekleyen özellikler: Kodu değiştirmeden basit yapılandırmalar aracılığıyla kullanılabilirliği geliştirmek için buluta özel hizmetleri seçin. Seçenekleri anlamak ve bölge yedekliliğini artırma veya verileri ikincil bölgeye çoğaltma gibi yapılandırmaları bilerek seçmek önemlidir.
✓ Temel düzeyde yedeklilik ile dağıtım
Çözümünüzün her bölümünde tek örnek gibi tek hata noktalarından kaçının. Bunun yerine yedeklilik için birden çok örnek oluşturun. Azure hizmetleri genellikle yedekliliği sizin için işler; özellikle de genellikle varsayılan olarak yerel yedeklilik ve yükseltme seçenekleri içeren PaaS hizmetlerinde. Tercihen, bu örnekleri birden çok Azure veri merkezine yaymak için alanlar arası yedeklilik kullanın. Aksi takdirde, en azından yerel yedeklilik olduğundan emin olun, ancak bu yöntem daha yüksek riskle birlikte gelir. Gelecekteki düzeylerde, çözümü coğrafi olarak yedekli bileşenlerle genişleterek güvenilirlik gereksinimlerinizin karşılanıp karşılanmayacağını değerlendirirsiniz.
Denge: Önemli bir denge, artan yedeklilik maliyetidir. Ayrıca bölgeler arası iletişim gecikme süresine neden olabilir. En düşük gecikme süresi gerektiren eski uygulamalar için yedeklilik performansı düşürebilir.
Risk: Bir uygulama birden çok örnekli bir ortam için tasarlanmamışsa, birden çok etkin örnekle mücadele edebilir ve bu da tutarsız verilere yol açabilir. Ayrıca, bir uygulama düşük gecikme süresine sahip bir şirket içi kurulum için oluşturulmuşsa kullanılabilirlik alanlarının kullanılması performansını kesintiye uğratabilir.
✓ Akışları izlemek için ölçümleri, günlükleri ve izlemeleri etkinleştirin
Ölçümlerin, günlüklerin ve izlemelerin görünürlüğünü sağlamak için Azure İzleyici gibi platforma özel araçları seçin. Olası sorunlara yönelik uyarılar ayarlamak için yerleşik özellikleri kullanın. Bildirim göndermek ve uyarılar almak için temel bir uyarı sistemi kurmalısınız. Aşağıdakiler gibi hizmetlerin sistem durumundaki değişiklikleri gösteren Azure platformu özelliklerinden yararlanın:
Hem altyapı hem de uygulama için Azure İzleyici eylem gruplarını ayarlayın.
Ödün: Daha fazla günlük toplarken, artan hacmi yönetmeniz gerekir, bu da bu günlüklerin depolama ile ilgili maliyetlerini etkiler. Saklama politikalarını kullanarak hacmi yönetin. Çalışma alanında günlük üst sınır ayarlamak için Azure İzleyici'yi kullanın. Daha fazla bilgi için bkz . Güvenilirlik için yapılandırma önerileri.
Aşağıdaki katmanlarda gözlemlenebilirlik oluşturmaya başlayın.
Altyapı
Tanılama günlüklerini etkinleştirerek ve analiz için platform bileşenlerinden yerel ölçümler topladığınızdan emin olarak başlayın. CPU, bellek, giriş/çıkış ve ağ etkinliği gibi kaynak kullanımı hakkında bilgi toplayın.
Uygulama
Bellek tüketimi veya istek gecikmesi gibi uygulama düzeyinde ölçümleri toplayın ve uygulama etkinliklerini günlüğe yazın. Günlük işlemlerini ana uygulama iş parçacığından ayrı bir iş parçacığında veya işlemde yapın. Bu yaklaşım, log kaydının uygulamanın birincil görevlerini yavaşlatmasına neden olmaz.
Ayrıca, Application Insights'taki temel kullanılabilirlik testlerini denetleyin.
Data
Veritabanlarını temel düzeyde izlemek için veritabanı kaynaklarının yaydığı önemli ölçümleri toplayın. Altyapı bileşenlerine benzer şekilde, ağ ölçümleri gibi veri depoları bağlamında kaynak kullanımını izleyin. Bağlantıların havuzda nasıl yönetildiği hakkında veri toplamak, sonraki aşamalarda verimliliği artırmak için önemlidir.
Güvenilirlik açısından etkin ve başarısız bağlantıları izleme gibi bağlantı ölçümlerini izlemek önemlidir. Örneğin Azure Cosmos DB'de, istek sayısı ayrılan istek birimlerini aştığında ve bağlantılar başarısız olduğunda 429 durum kodu döndürülür.
✓ Hata azaltma playbook'u oluşturmaya başlama
Hatalar, aralıklı ve hafifçe genişletilmiş geçici arızalar ile yıkıcı kesintiler arasında değişir.
Düzey 1'de platform hatalarına odaklanın. Bunlar sizin denetiminizin dışında olsa da, bunları işlemeye yönelik stratejilere sahip olmanız gerekir. Örneğin, kullanılabilirlik alanlarını kullanarak bölge kesintilerini çözün. Platform düzeyinde geçici hataları tahmin edin ve bunları iş yükünüzde işleyin.
Bu hataları işleme işlemi karmaşıklığa göre değişir. Olası platform düzeyindeki hataları, bunların ilişkili risklerini ve risk azaltma stratejilerini belgelemeye başlayın. Bu alıştırma öncelikli olarak teoriktir ve ileri düzeylerde otomasyon ile olgunlaşır.
Olasılık, etki ve risk azaltma stratejileri gibi faktörler de dahil olmak üzere hataları belgelemeniz gerekir. İş yükünüzün hedeflerine uygun bir kritiklik ölçeği kullanın. Ölçeğiniz şunları içerebilir:
Yüksek. Önemli mali kayıplara ve kullanıcı güveninde düşüşe neden olan eksiksiz bir sistem kesintisi.
Orta. İş yükünün bir bölümünü etkileyen ve kullanıcının rahatsız olmasına neden olan geçici bir kesinti.
Düşük. Uygulamanın önemsiz bir özelliğini etkileyen ve kullanıcılar için en düşük kapalı kalma süresine neden olan küçük bir yazılım sorunu.
Örnek bir şablon aşağıda verilmişti:
| Sorun |
Riske |
Kaynak |
Şiddet |
Olasılık |
Azaltma |
| Geçici ağ hatası |
İstemci, uygulama sunucusuyla bağlantısını kaybeder. |
Azure platformu |
Yüksek |
Büyük olasılıkla |
yeniden deneme mantığı ve devre kesiciler gibi istemci tarafı mantığındaki tasarım desenlerini kullanın. |
| Bölge kesintisi |
Kullanıcı uygulamaya erişemiyor. |
Azure platformu |
Yüksek |
Büyük olasılıkla değil |
Tüm bileşenlerde bölge dayanıklılığını etkinleştirin. |
| Aktarım Katmanı Güvenliği (TLS) sertifikası süre sonu |
İstemci, uygulamayla bir TLS oturumu oluşturamıyor. |
İnsan hatası |
Yüksek |
Olası |
Otomatik TLS sertifika yönetimini kullanın. |
| CPU veya bellek kullanımı tanımlı sınırlara ulaşır ve sunucunun başarısız olmasına neden olur. |
İstekler zaman aşımına uğradı. |
Uygulama |
Orta |
Olası |
Otomatik yeniden başlatmaları uygulayın. |
| Bileşen güncelleştirme sırasında kullanılamaz. |
Kullanıcı uygulamada işlenmeyen bir hatayla karşılaşır. |
Dağıtım veya yapılandırma değişikliği |
Düşük |
Dağıtımlar sırasında yüksek ihtimalle ve diğer zamanlarda olasılık düşük. |
İstemci tarafı mantığında bileşenleri ele alın. |
Düzey 1'de, her zaman öngörülemeyen hata durumları olduğundan tamlık için çabalamayın. Beklenmeyen kesintilerle karşılaşırsanız, playbook'taki nedenleri ve azaltmaları belgeleyin. Bu varlığı, zaman içinde güncelleştirdiğiniz canlı bir belge olarak değerlendirin.
✓ Geçici hatalardan kurtarmak için mekanizmalar ekleyin
Bulut ortamında geçici hatalar yaygın olarak görülür. Bunlar, yeniden denemelerin genellikle saniyeler içinde çözebileceği kısa vadeli sorunları belirtir.
Sistemi etkin tutmak için bu hataları işlemek için yerleşik SDK'ları ve yapılandırmaları kullanın. Yerleşik yapılandırmalar genellikle varsayılan ayardır, bu nedenle uygulamayı doğrulamak için test etmeniz gerekebilir. Ayrıca, mimarinizdeki geçici hataları yönetmek için tasarlanmış tasarım desenleri uygulayın. Daha fazla bilgi için bkz . Güvenilirliği destekleyen mimari tasarım desenleri.
Süregelen sorunlar geçici olmayan bir arıza veya bir kesintinin başlangıcına işaret edebilir. Bu senaryo, uygulama içindeki yerelleştirilmiş sorunları çözmekten daha fazlasını gerektirir. Sistemin kritik kullanıcı ve sistem akışlarını incelemeyi ve kendini koruma teknikleri ve kurtarma çalışmalarını eklemeyi içerir. Bu yöntemler, Düzey 2'nin açıklandığı olgun yöntemlerdir.
✓ Temel testleri çalıştırma
Temel güvenilirlik testini yazılım geliştirme yaşam döngüsünün ilk aşamalarında tümleştirin. İşlevselliği ve yapılandırmaları doğrulamak için birim testlerinden başlayarak test yapma fırsatlarını arayın.
Ayrıca risk azaltma playbook'unda tanımladığınız sorunlar için basit test çalışmaları geliştirin. Daha yüksek etki, daha düşük efor azaltma işlemlerine odaklanın. Örneğin, yeniden deneme mantığınızın kesintileri nasıl çözeceğini görmek için ağ kesintilerini veya aralıklı bağlantı sorunlarını simüle edin.
Risk: Test genellikle geliştirme döngüsünde sürtüşmelere neden olabilir. Bu riski azaltmak için güvenilirlik testini geliştirme görevleriyle birlikte izlenebilir hale getirin.
Öncelik özellik geliştirmedir ve test, geliştirme döngüsünde uyuşmalara neden olabilir. Özellik geliştirme tamamlanmadan önce teste başlamak daha kolaydır. Uygulamanın başlangıçta işlevsiz yönlerini tasarlamak, daha sonra ele alınacak bir sorun kapsamı oluşturmak yerine işlevsel özellikler ekledikçe bunları genişletmenize olanak tanır. Bu yaklaşım başlangıçta daha fazla çaba gerektirse de yönetilebilir ve daha sonra daha büyük sorunları önler.
Kendini koruma özellikleri ekleyerek ve hataları yönetmek için temel bir kurtarma planına sahip olarak sistemin işlevsel ve kararlı kalmasını sağlayın.
Buluttaki hatalar kaçınılmazdır. Dayanıklılık stratejileriniz, sistemi her koşulda çalışır durumda tutmak için çaba göstermelidir. Düzey 1 geçici hataları giderme yöntemlerini tanıtır. Düzey 2, uzun süreli hataları önlemek, algılamak ve kurtarmak için kendini koruma stratejilerini birleştirmeye odaklanır. Çözümlenmemiş bırakılırsa, bu sorunlar tam kesintilere dönüşebilir.
Düzey 1'de tanımladığınız kritik akışlar önceliklidir. Uygulamalar, hizmetler ve veritabanları dahil olmak üzere tüm bileşenler için daha fazla dayanıklılık ve kurtarma çalışması gerektirir. Güvenilirlik risklerini azaltmak için ilk sağlama boyutlarınızı, örnek sayılarınızı ve otomatik ölçeklendirme ilkelerinizi ayarlamayı bekleyebilirsiniz.
Bu düzeyde, izleme ve test uygulamalarınız hakkında bilinçli olun. Teknik gereksinimlere uygun ve kapsamı geliştirme ekiplerine göre belirlenmiş gelişmiş izleme tekniklerini kullanın. Uygulama kodu gibi kendi geliştirdiğiniz ve sahip olduğunuz mimari bileşenleri kapsayacak şekilde basit playbook'u genişletin.
Temel stratejiler
✓ Hatalara karşı korumak için geçerli dayanıklılık durumunu değerlendirin
Yedeklilik düzeyi hatalara dayanacak kadar iyi mi? Korunacak yedekli kaynakların sayısını belirten bir yedeklilik stratejisi tanımlayın. Yerel olarak, bölgeler arasında veya coğrafi olarak dağıtılmış konumlarda bu kaynakların nereye yerleştirileceğini belirleyin. Bulut platformunun ayarlarını değerlendirin ve iş gereksinimlerini ve kabul edilebilir dengeleri karşılayan bir düzey seçin.
İş yükü bileşenleri hatalarını içerecek kadar yalıtılmış mı?
Bulkhead deseni gibi desenler dayanıklılık ve hata yalıtımı oluşturmaya yardımcı olur. Bulkhead deseni, hataların sistemin diğer bölümlerine art arda gelmesini önlemek için sistemi bölme olarak bilinen yalıtılmış bileşenlere ayırır.
Kritik yoldaki bileşenler zaman uyumsuz olarak iletişim kurar mı? Aksi takdirde kuyruklar gibi iletişim yöntemlerini kullanın. Bu yaklaşım, aşağı akış bileşeni başarısız olsa bile sistemi çalışır durumda tutar. Ayrıca sistemin belirsiz bir duruma girmesini de engeller. Kuyruklar için Azure Service Bus ve olay akışları için Azure Event Hubs dahil olmak üzere Azure seçeneklerini keşfedin.
Ödün: Asenkron iletişim, işlemleri ayrıştırarak basamaklı hataları önlemeye yardımcı olabilir. Ancak, iletişim yoluna gecikme süresi ekler ve bu da kritik bileşenler için sorun oluşturabilir. Tasarım düzeni değişiklikleri yapmadan önce performans etkisini değerlendirin.
İşlemler tutarlılık için mi tasarlanmıştır? Uygulama gizli dizileri ve sertifikalar gibi varlıkların süresi dolabilir ve düzenli yenileme gerekebilir. Rutin güncelleştirmelerdeki tutarsızlıklar güvenilirlik sorunlarına neden olabilir.
İdeal olarak, insan tarafından çalıştırılan sürekli görevleri belirleyin ve ortadan kaldırın çünkü bunlar hataya açıktır ve güvenilirlik riskleri oluşturan tutarsızlıklara neden olabilir. Bulut sağlayıcısına mümkün olduğunca çok işlem görevi boşaltın. Örneğin, Microsoft Entra Id'nin sağladığı yönetilen kimlikleri ve Azure Front Door'un yönettiği Aktarım Katmanı Güvenliği (TLS) sertifikalarını kullanın.
sertifika süre sonunu izleme ve bildirimleri alma gibi proaktif ölçüler için izleme gereklidir. Uygulamanın son kullanma tarihine yakın bir TLS sertifikası gibi önemli olayları günlüğe kaydetmesi gerekir. Olası hataları denetlemek için birden çok yöntem kullanmak, gerekli eylemlerin gerçekleştirilmesini sağlamaya yardımcı olur.
✓ İzleme sisteminize teknik özellikler ekleyin
Düzey 1'de, altyapıya odaklanarak iş yükü bileşenlerinden izleme verilerini topladınız. Temel analiz tamamlanır ve temel uyarılar ayarlanır. Bu kurulum, iş yükü bileşenlerinin temel performansını anlamak ve anormal davranışları belirlemek için gereklidir.
Düzey 2, iş yükü kaynaklarınıza gelişmiş gözlemlenebilirlik özellikleri ekleyerek ve izleme verilerini analiz etmek için daha yapılandırılmış bir yaklaşım benimseyerek izlemeyi bir adım ileri taşır. Bulut hizmetinizin sağladığı analiz araçlarından yararlanın. Örneğin, VM içgörüleri ve ağ içgörüleri gibi Azure İzleyici içgörü araçları, bağımlılıklar arasında sistem durumu ve performans görselleştirmeleri sağlar.
Gözlemlenebilirlik özelliklerini aşağıdaki katmanlarda planlayın.
Uygulama
Sağlık durumu yoklamasına yanıt verin. Uygulamanın yoklamalardan gelen sistem durumu denetimi isteklerine yanıt vermesini sağlayın. Uygulamanın, en azından sağlıklı veya sağlıklı olmayan gibi durum bilgileri sağlayan sağlık kontrolleri için ayrılmış uç noktaları olmalıdır. Bu yaklaşım, izleme sistemlerinin uygulamanın düzgün çalışıp çalışmadığını ve istekleri işleyip işleyemeyeceğini veya çözülmesi gereken sorunlar olup olmadığını değerlendirmesine olanak tanır.
Azure Front Door, Azure Traffic Manager, Azure Application Gateway ve Azure Load Balancer gibi Azure yük dengeleme hizmetleri sistem durumu yoklamalarını destekler. Sağlık probları uygulamalara sağlık kontrolü istekleri gönderir.
Anlamsal kayda ilerleyin. Uygulamadaki olaylar ve eylemler hakkında yapılandırılmış bilgiler ekleyin. Yapılandırılmış günlük kaydıyla, günlük verileri iyi tanımlanmış bir şema kullanılarak tutarlı bir biçimde kaydedilir. Bu şema, daha sonraki aşamalarda otomasyon, arama ve analiz oluşturmayı kolaylaştırır. Sorunları hızla tanımlamaya ve gidermeye yardımcı olmak için zaman damgaları ve hata kodları gibi belirli alanları ekleyin.
Dağıtılmış izleme uygulayın. Bir istek sistemin farklı bileşenleri üzerinden aktığında, izleme verilerini sınırlar arasında yakalamak önemlidir. Bu veriler uygulama davranışıyla ilgili içgörüler elde etmek ve performans sorunlarını, hataları ve gecikme sorunlarını belirlemek için kullanışlıdır. Azure İzleyici, Application Insights ile OpenTelemetry tabanlı veri toplamayı destekler.
Data
Sorgu süresini, başarısız sorguları ve diğer ilgili ölçümleri izleyin. Uzun süre çalışan sorgular kaynak kısıtlamalarını ve şema tasarımını ayarlama gereksinimini gösterebilir.
Bu aşamada veritabanınız bir süredir çalışıyor. Özellikle beklenmedik şekilde hızlı büyüyen tablolarda veri büyüme hızına dikkat edin. Bu bilgiler gelecekteki depolama gereksinimlerini planlamak ve performans sorunlarını erken çözmek için çok önemlidir.
Veritabanı yönetim sisteminin sağladığı araçları ve panoyu kullanarak veritabanı çoğaltma durumunu izleyin. Örneğin, Azure Cosmos DB kullanıyorsanız Azure Cosmos DB içgörülerini kullanın. Azure SQL Veritabanı veya Azure SQL Yönetilen Örneği için veritabanlarınızla ilgili tanılama ayrıntılarını almak için veritabanı izleyicisini kullanmayı göz önünde bulundurun.
Veritabanı büyüdükçe şema sorunları daha belirgin hale gelebilir ve bu da performansı etkiler. Sorgu verimliliğini iyileştirmek için dizinleri eklemeyi veya şemayı değiştirmeyi göz önünde bulundurun çünkü bu değişiklikler güvenilirliği etkileyebilir.
Operasyonlar
Düzey 1, önceki katmanlara odaklanır. Düzey 2'de, izleme sistemi etrafında işlemler oluşturmaya başlarsınız.
İçgörü elde etmek için günlükleri yeterince uzun tutun. Güvenilirlik açısından bakıldığında, bekletme süresini yapılandırarak hata desenlerini algılamak, sorunları gidermek ve kök neden analizi gerçekleştirmek için yeterli veri toplayabilirsiniz.
Yedekleme ve kurtarma işlemlerini izleyin. Yedeklemelerin planlandığı gibi konumlarda başarıyla depolandığından ve iş yükü verilerinin makul bir zaman çerçevesi içinde kurtarıldığından emin olun. Bu işlemleri izlemek, kurtarma noktası hedefi (RPO) ölçümlerinizin temellerini daha sonraki düzeylerde ayarlamak için önemlidir.
✓ Hata azaltma playbook'unuzu genişletin
Düzey 1, beklenen platform hatalarına odaklanır. Düzey 2'de, kendi iş yükünüzdeki bileşenler ve işlemler üzerindeki hata noktalarını ele alırsınız. Kodunuz platformda çalışırken platform ile uygulama arasındaki etkileşim noktaları artar. Kodunuzdaki hatalardan, başarısız dağıtımlardan ve insan hatalarından hata bekleyebilirsiniz. Kendini koruma veya kurtarma taktiklerini kullanarak bu sorunları hafifletin.
Hata azaltma playbook'unuzu hataları ve dağıtım sorunlarını içerecek şekilde genişletin. Aşağıdaki tablo, Düzey 1'den şablon üzerinde derlenmiştir:
| Sorun |
Riske |
Kaynak |
Şiddet |
Olasılık |
Azaltma |
| Kod en az bir kez ileti teslimini yönetmez. |
Veri yolu iletilerinde yinelenen işlemler veri bozulmasına neden olur. |
Uygulama |
Yüksek |
Olası |
- Veri yolu bölme kullanımı için yeniden tasarlayın ve sürece idempotentlik ekleyin.
- Performansın bir ödün olduğu rekabetçi tüketici modelinden uzaklaşın. |
| Günlük depolama yedekleme betiği çalıştırılamıyor. |
Veriler 24 saatten eski olduğundan RPO ihlal edilir. |
Otomatik işlem |
Yüksek |
Büyük olasılıkla değil |
Yedekleme işleminde bir uyarı ayarlayın. |
| Yeni bir sürümden sonra normal kullanıcı ve kullanım artışları. |
Uygulama performansı düşer ve kullanıcı talepleri zaman aşımına uğrar. |
Uygulama |
Yüksek |
Büyük olasılıkla değil |
Zamanlamaya dayalı ölçek genişletme işlemlerini yapılandırın. |
| Eşzamanlılık hatası kodda. |
Öngörülemeyen davranış ve olası veri bozulması. |
Uygulama |
Yüksek |
Olası |
Güvenli eşzamanlılık biçimlerini kullanın ve eşzamanlılık denetimlerinin el ile işlenmesinden kaçının. |
| Dağıtım sırasında beklenmeyen hata ortamı tutarsız durumda bırakır. |
Uygulama kesintisi. |
Dağıtım boru hatları |
Orta |
Olası |
Değişiklikleri aşamalı olarak dağıtmak için mavi-yeşil dağıtımları, kanarya dağıtımlarını veya diğer yaklaşımları kullanın. |
Olası her hatayı hesaba aktarmaya çalışırsanız bu alıştırma zor olabilir. Bunu kolaylaştırmak için kritik kullanıcı akışlarının parçası olan bileşenlere odaklanın. İş yükü büyüdükçe bu canlı belge büyümeye devam ediyor.
✓ Temel bir kurtarma planı geliştirin
Hata azaltma playbook'u, temel kurtarma planı oluşturmanın temelini oluşturur. Azaltma stratejileri arasında tasarım deseni uygulaması, platform yapılandırma ayarlamaları, canlı site olay yönetimi, otomatik testler ve kod incelemeleri sırasında sorunları algılamak için eğitim personeli yer alabilir.
Sistemin parçaları düzgün çalışmadığında geçici düzeltmeler içeren düzgün bir düşüş stratejisiyle başlayın. Amaç, çalışma dışı bölümleri devre dışı bırakarak ve kullanıcı deneyimini ayarlayarak hatalara rağmen kullanıcılara hizmet etmeye devam etmektir. Örneğin, veritabanı kapalıysa uygulama etkilenen özelliği devre dışı bırakabilir ve HTTP durum kodlarını kullanarak istemcilere hizmetin geçici olarak kullanılamadığını bildirebilir.
Uygun şekilde bozulmanın çalışabilmesi için, sistem bileşenlerini yalıtın ve yalnızca etkilenen parçaların sorun yaşamasını sağlarken diğer bileşenler çalışmaya devam etsin. Hata yalıtımı elde etmek için Bulkhead desenini kullanın.
Bu fırsattan yararlanarak kurtarma sürecini yavaşlatabilecek tasarım kararlarını gözden geçirin. Örneğin, Etki Alanı Adı Sistemi (DNS) kayıtlarının doğrudan Azure App Service'te uygulamanıza işaret edilmesi, DNS yayma nedeniyle kurtarma sırasında gecikmelere neden olabilir. Kurtarma adımları sırasında daha kolay yeniden yapılandırma için giriş noktası olarak Azure Front Door gibi ayrılmış bir hizmet kullanın.
Bu temel planın daha olgun düzeylerde tam bir olağanüstü durum kurtarma planına dönüşmesini bekleyebilirsiniz.
✓ Test planları oluşturma
Risk azaltma playbook'unda tanımlanan kesintileri ve sorunları simüle ederek test planları oluşturun. Bu azaltmaları basit test çalışmalarıyla destekleyip beklendiği gibi çalıştıklarından ve uygun olduklarından emin olun. Bu özelliklerin doğru çalıştığını doğrulayın ve sistemin belirli bileşenler başarısız olduğunda nasıl performans sergilediğini görmek için performans düşüşü testleri gerçekleştirin. Testin başarısız olmasını veya başarılı olmasını sağlayarak sonucu basit tutun.
HTTP isteklerine hataları enjekte etmek için mocking framework'ler gibi test araçlarını kullanarak yeniden deneme ilkelerini daha açık bir şekilde test edebilirsiniz. Azure Chaos Studio, bileşen kesintilerinin ve diğer sorunların simülasyonu için kapsamlı bir test paketi sunar ve bu da onu keşfedilecek değerli bir hizmet haline getirir. Özelliklerine alıştıkça Chaos Studio'yu aşamalı olarak benimseyebilirsiniz.
✓ Ölçeklendirme işlemlerinin güvenilirlik üzerindeki etkisini değerlendirin
Yükteki ani artışları işlemek için kritik bileşenlerin ölçeği genişletebilmesi veya ölçeği verimli bir şekilde artırabilmesi gerekir. Azure'ın sağladığı otomatik ölçeklendirme özelliklerinden yararlanın. Bu özellikler, önceden tanımlanmış yapılandırmalara göre bir hizmetin kapasite sınırlarını ayarlar. Bu ayarlama, hizmetin ölçeğini gerektiği gibi artırmanıza veya azaltmanıza olanak tanır.
Olası performans sorunlarını belirleyin ve ortaya çıkabilecek riskleri anlayın. Örneğin, yüksek aktarım hızı akışın bozulmasına neden olmamalıdır.
Yük desenlerini anlama. Statik kullanım desenleri performans sorunlarını daha az kritik hale getirse de, kullanım ve tüketim dinamiklerindeki değişiklikler riskleri kötüleştirebilir.
Uyarı
Monolitik veritabanları ve eski uygulamalar gibi ölçeği genişletilemeyen bileşenler olabilir. Gerekirse yeniden mimari oluşturma olanağı sağlamak için yük eğrisini proaktif olarak izleyin.
Performans ve güvenilirlik gereksinimlerine göre makul ölçeklendirme sınırlarına karar verin. Performansla ilgili endişeler için ölçeği aşamalı olarak artırma en yaygın olanıdır. Ancak kritik akışlara yönelik güvenilirlik endişeleri, kesintileri önlemek için daha hızlı ölçeklendirme gerektirebilir. Her iki durumda da sonsuz ölçeklendirmeden kaçının.
Risk: Performansla ilgili sorunlarla karşılaştığınızda ölçeklendirme yararlı bir azaltma stratejisi olabilir. Ancak ölçeklendirme geçici bir düzeltmedir ve çözüm değildir. Bellek sızıntısı veya kaçak işlemi gibi temel sorunu araştırın ve çözün. Aksi takdirde, aynı risk azaltma önlemini başka bir kritik noktada tekrar uygulayıp ihtiyacınız olmayan kaynaklara ödeme yapma riski taşıyorsunuz. Kök nedeni ele alarak uzun vadeli kararlılık ve maliyet verimliliği sağlayabilirsiniz.
Kurtarma yordamlarında ekibin sorumlu olmasını sağlamak için güvenilirlik hedeflerini ve hedeflerini ayarlayın.
Erken düzeylerde ekipleriniz kolay galibiyetlere ve temel özelliklere odaklanır. Bunlar küçük iyileştirmelerle başlar ve güçlü bir temel oluşturmak için basit sorunları çözerken çoğunlukla Azure güvenilirlik özelliklerine dayanır. Ekipleriniz büyüdükçe kendi varlıkları ve süreçleriyle ilgili daha teknik zorlukların üstesinden gelir.
Düzey 3'te ekipleriniz, kurtarma planlaması için iş içgörülerini ve teknik becerileri tümleştirmelidir. Gelişmiş izleme kullanarak hedefleri belirler ve kurtarma işlemlerini planlar. Bu yaklaşım, site güvenilirlik mühendislerinin (SRE) güvenilirlik hedeflerini hızla karşılamalarına yardımcı olur.
Temel stratejiler
Güvenilirlik hedefleri, iş yükü ekipleri için sorumluluk ayarlamaya yardımcı olur. Kurtarma sürelerini ve maliyetlerini tartışmak ve iş hedeflerine uygun tavizler vermek için iş paydaşlarıyla işbirliğine dayalı bir konuşma yapmak önemlidir. Paydaşları toplayın ve bu tartışmayı bir atölye çalışması olarak düzenleyin. Atölye gündemi için aşağıdaki noktaları göz önünde bulundurun:
Hedeflerin ardındaki ölçümleri açıklama. Hizmet düzeyi hedefleri, kurtarma süresi hedefleri (GPO'lar) ve kurtarma noktası hedefleri (RPO'lar) gibi hedefleri tanımlamak için kullanılan temel ölçümleri açıklayarak başlayın. Bu ölçümlerin iş hedefleriyle nasıl uyumlu olduğunu gösterin. Kritik kullanıcı akışlarına odaklanın. Örneğin, bir e-ticaret uygulamasında, e-posta tercihlerini güncellemek için gerekli RTO, kullanıcıların alışveriş sepetlerini tamamlaması kadar önemli değildir.
Dengeleri bildir. Paydaşlar genellikle elde edilebileceklerden daha fazlasını beklerler. Kapsamı genişletmenin bütçeyi, operasyonel gereksinimleri ve performansı nasıl etkilediğini açıklama.
Hedef hedefler önerin. Mimari deneyim ve iş yükü tasarımına dayalı olarak, RPO ve RTO'yu dört saatte ayarlayarak 99,9% çalışma süresi hedefi gibi hedefleri öneririz. Paydaşların geri bildirim sağlamaları ve ayarlamalar yapmaları için tartışmayı kolaylaştırma. Hem iş hem de teknik paydaşların gerçekçi olmayan beklentilere karşı korumasını sağlayın. tartışmalara işbirliğine dayalı bir düşünce yapısıyla yaklaşın.
Bir fikir birliğine veya karara varın. Fikir birliğine varmayı hedefleyin, ancak bu mümkün değilse, ilerlemeyi sağlamak için bir karar alıcının hedefleri kesinleştirmesini sağlayın.
✓ Sağlık modelinizi kullanarak proaktif olarak izleme
Düzey 1'de izleme verileri, platform hizmetleri ve uygulamalar da dahil olmak üzere iş yükü bileşenlerinden toplanır. Temel performans oluşturmak ve anomalileri tanımlamak için temel analiz ve uyarılar ayarlanır. Düzey 2'de odak, uygulama kodu gibi iş yükü bileşenlerinden gözlemlenebilirlik verilerini elde etmeye geçer.
Düzey 3, kritik akışlara iş bağlamı ekleyerek ve sistem durumu modellemesi aracılığıyla sağlıklı, iyi durumda olmayan ve düzeyi düşürülmüş durumları tanımlayarak izlemeyi geliştirir. Kabul edilebilir kullanıcı deneyimi tavizlerini belirlemek için paydaş mutabakatı gereklidir ve sistem sağlık durumlarını tanımlamak için bir giriş olarak kullanılmalıdır.
Sağlık modellemesi, işletimsel olgunluk ve izleme araçları konusunda uzmanlık gerektirir. Ekibiniz ham verileri, performans düzeylerini ve günlükleri inceleyip akışın sistem durumunu tanımlayan özel ölçümler ve eşikler oluşturur. Bu değerlerin sistemin genel durumuyla nasıl ilişkili olduğunu anlamaları gerekir. Açık tanımları ve eşikleri paydaşlara iletin.
SRE'lerin iyi durumda olmayan veya düzeyi düşürülmüş akışlara odaklanarak sorunları hızla belirlemesine yardımcı olmak için panolarda sistem durumu modelini görselleştirin.
Sistem durumu modeli, uygulamanın durumunu ve kritik akışlarını tanımlar. Yeşil, tüm kritik akışların beklendiği gibi çalıştığını gösterir. Kırmızı bir hatayı gösterir. Sarı, sorunlara yönelik eğilimleri gösterir. Sağlık modeli sürümlerini yinelemek, güvenilirlik ve doğruluk sağlar ancak büyük uygulamalar için önemli çaba gerektirir.
Sağlık durumu değişikliği uyarılar olarak yapılandırılmalıdır. Ancak uyarıları kasıtlı olarak tutmak için bileşenin kritikliği dikkate alınmalıdır.
Daha fazla bilgi için bkz .Well-Architected Framework: Sağlık modelleme.
✓ Eyleme dönüştürülebilir uyarılar ayarlama
Yanıt verimliliğini artırmak için uyarıları net bir şekilde tanımlayın ve hızlı işlem için yeterli bilgi sağlayın. Ayrıntılı uyarı adları ve açıklamaları, sorun giderme sırasında zaman ve çaba tasarrufu sağlamaya yardımcı olabilir. Önem derecelerine özellikle dikkat ederek önem derecesini, adı ve açıklamayı dikkatle yapılandırın. Her olay acil bir durum değildir. Önem düzeylerini dikkatle değerlendirin ve her düzey için 80%'den 90'a% bir CPU artışının acil durum olarak nitelenip nitelenmeyeceği gibi ölçütler belirleyin. Uyarıların etkili bir şekilde tanımlandığından emin olmak için uygun eşikleri ayarlayın.
Etkili uyarı yönetimi, uyarıların doğru kişileri doğru zamanda bilgilendirmesini sağlar. Sık ve kesintiye neden olan uyarılar, ayarlama gereksinimini gösterir ve göz ardı edildiğinde verimsizliğe yol açabilir. Yanlış alarmları filtrelemek için uygun eşikleri ayarlayarak gereksiz bildirimleri azaltın. Otomasyonun operasyonel yordamları tetikleyebileceği fırsatları belirleyin.
Uyarıların sorunlarını verimli bir şekilde gidermek için gerekli bilgilere sahip tek bir giriş sayfası oluşturun. Bu yaklaşım, Azure portalında oturum açma ve ölçümleri arama ile karşılaştırıldığında zaman kazandırır. Azure İzleyici yerleşik özellikleri ihtiyaçlarınızı tam olarak karşılamıyorsa özel bir pano geliştirmeyi göz önünde bulundurun.
✓ Hata modu analizi gerçekleştirme
Önceki düzeylerde, tek tek bileşenler için basit bir hata azaltma playbook'u oluşturdunuz. Bu düzeyde, bu playbook'u resmi bir hata modu analizi (FMA) alıştırmasına dönüştürebilirsiniz. Bu alıştırmanın amacı olası hata modlarını proaktif olarak belirlemektir.
FMA, iş yükünüzdeki olası hata noktalarını tanımlamanızı ve kendi kendini düzeltme veya olağanüstü durum kurtarma (DR) gibi risk azaltma eylemlerini planlamanızı gerektirir. Başlamak için, artan hata oranlarını izleyin ve kritik akışlar üzerindeki etkileri algılayın. Olası hataları belirlemek ve patlama yarıçaplarını değerlendirmek için geçmiş deneyimleri kullanın ve verileri test edin. Bölge genelinde kesinti gibi önemli sorunların önceliklerini belirleyin.
Eylemleri önleyici veya reaktif olarak sınıflandırmak önemlidir. Önleyici eylemler, kesintiye neden olmadan önce riskleri belirler ve bu da olasılıklarını veya önem derecelerini azaltır. Reaktif eylemler, bozulmuş bir sağlık durumu veya kesintiyi hafifletmek için sorunları ele alır.
E-ticaret örnek uygulamasında, iş yükü ekibi kendilerini büyük bir etkinliğe hazırlamak için FMA yapmak istiyor. Önemli kullanıcı akışlarından biri sepete öğe eklemektir. Akışın parçası olan bileşenler ön uç, CartAPI, ProductCatalogAPI, UserProfileAPI, PricingAPI, Azure Cosmos DB ve Azure Event Hubs'dır.
| Sorun |
Riske |
Olası kaynak |
Şiddet |
Olasılık |
Eylemler |
| Alınan sipariş sayısı saatte 100'ün altına düşer ve kullanıcı oturumu etkinliğinde buna karşılık gelen bir düşüş olmaz |
Uygulama kullanılabilir olsa bile müşteriler sipariş veremiyor. |
CartAPI, ÖdemelerAPI |
Yüksek |
Büyük olasılıkla değil |
Reaktif eylemler:
- Sorunu belirlemek için sistem durumu modelini veya izleme verilerini gözden geçirin.
- İşlevselliğini doğrulamak için uygulamayı test edin.
- Bir bileşen kesintisi oluşursa, başka bir altyapı kümesine yük devretme gerçekleştirin.
Önleyici eylemler:
- Akışın çalıştığını doğrulamak için yapay siparişler yerleştirin.
- Uçtan uca akışın izlendiğinden emin olmak için gözlemlenebilirliği geliştirin. |
| Azure Cosmos DB'de siparişleri depolarken beklenmeyen yük artışı zaman aşımlarına neden oluyor |
Müşteriler sipariş veremiyor veya sipariş verebiliyorsa memnuniyetsiz bir performans alıyor. |
Azure Cosmos DB veritabanı |
Yüksek |
Büyük olasılıkla değil |
Reaktif eylemler:
- Uygulama telemetrisi temelinde yükü doğrulayın.
- Azure Cosmos DB istek birimlerinin ölçeğini geçici olarak artırma.
Önleyici eylemler:
- Otomatik ölçeklendirmeyi yapılandırın.
- Beklenen yükü yeniden gözden geçirme ve ölçek kurallarını yeniden hesaplama.
- Bu akıştan veritabanı yükünü azaltmak için bazı etkinlikleri bir arka plan işlemine taşıyın. |
| Öneriler hizmeti tamamen çevrimdışı oluyor |
Öneri hizmetini çağıran bir özel durum nedeniyle alışveriş sepeti sayfası yüklenemiyor. |
Uygulama |
Orta |
Büyük olasılıkla değil |
Reaktif eylemler:
- Öneri işlevselliğini devre dışı bırakmak veya alışveriş sepeti sayfasında sabit kodlanmış öneri verilerini görüntülemek için düzgün bir düşüş stratejisi uygulayın. Hizmeti değerlendirirken bir özel durum oluştuğunda bu yaklaşımı uygulayın. |
| Yoğun yük altında alışveriş sepeti sayfasından fiyatlandırma API'sine erişilirken aralıklı zaman aşımları oluşur |
Alışveriş sepeti sayfasına erişirken oluşan hatalar nedeniyle alışveriş sepeti sayfasında aralıklı hatalar oluşur. |
Uygulama |
Orta |
Büyük olasılıkla (ağır yük altında) |
Reaktif eylemler:
- Önbellek fiyatlandırma değerini, önbellek süresi dolum zaman damgasıyla birlikte alışveriş sepeti veri deposunda uygulayın.
- Fiyatlandırma API'sine yalnızca fiyatlandırma veri önbelleğinin süresi dolduğunda erişin. |
FMA karmaşıktır ve zaman alabilir, bu nedenle zaman içinde analizinizi aşamalı olarak oluşturun. Bu süreç yinelemeli ve sonraki aşamalarda gelişmeye devam ediyor.
Daha fazla bilgi için bkz. RE:03 FMA gerçekleştirme önerileri.
✓ Afet Kurtarma planı hazırlama
Düzey 2'de, sistem işlevselliğini geri yüklemek için teknik denetimlere odaklanan bir kurtarma planı oluşturdunuz. Ancak, felaket seviyesinde kayıp veya başarısızlık nedeniyle felaketler daha geniş bir yaklaşım gerektirir. DR planları işlem tabanlıdır. İletişimi, ayrıntılı kurtarma adımlarını kapsar ve betikler gibi teknik yapıtları içerebilir.
İlk olarak, bölge kesintileri, Azure genelindeki hatalar, altyapı kesintileri, veritabanı bozulması ve fidye yazılımı saldırıları gibi planlayacak olağanüstü durum türlerini belirleyin. Ardından her senaryo için kurtarma stratejileri geliştirin ve işlemleri geri yüklemek için mekanizmaların hazır olduğundan emin olun. İş gereksinimleri, RTO'lar ve RPO'lar DR planlarını yönlendirmelidir. Düşük GPO'lar ve RPO'lar açık otomatik işlemler gerektirirken, daha yüksek GPO'lar ve RPO'lar daha basit kurtarma yöntemlerine ve el ile analize olanak sağlar.
DR temel olarak aşağıdaki eylemleri içerir:
Sorumlu taraflara bildirin. Kimlerin ve ne zaman dahil edilmesi gerektiğinde netlik sağlamak önemlidir. Ekibinizin doğru işlemleri kullandığından, doğru izinlere sahip olduğundan ve kurtarmadaki rollerini anladığınızdan emin olun. Ceo'nun pazara raporlaması veya mevzuat gereksinimlerini ele alması gibi bazı sorumluluklar erken belirlenmelidir.
İdeal olarak, ayrı kurtarma ve iletişim rollerine sahip olmanız ve her role farklı kişiler atamanız gerekir. Başlangıçta, sorunu keşfeden BT işlemleri kişisi her iki rolü de işleyebilir. Ancak durum tırmandıkça, üst düzey personel teknik kurtarmayı üstlenebilirken iletişimi bir iş kişisi yönetebilir.
İş kararları alın. Bir olağanüstü durum sırasında stres düzeyleri yüksek olabilir ve bu da net bir karar alma sürecini gerekli kılar. İyi yapılandırılmış bir DR planı, ön karar seçeneklerini tanımlamak için teknik ekip ve iş paydaşları arasında sürekli tartışmalar yapılmasını gerektirir. Örneğin, iş yükü kaynaklarının başka bir bölgedeki yedeklerle bir Azure bölgesinde mi çalıştırılacağı yoksa IaC varlıklarının yeni kaynaklar oluşturmak veya yük devretme sırasında yedekten geri yüklemek için önceden hazırlanması gerekip gerekmediğini göz önünde bulundurun.
DR planlarına göre yapılan eylemler yıkıcı olabilir veya önemli yan etkilere sahip olabilir. Seçenekleri anlamak, artılarını ve eksilerini tartmak ve bunları uygulamak için doğru zamanı belirlemek önemlidir. Örneğin, birincil bölgenin kabul edilebilir bir zaman dilimi içinde çalışır durumda olması bekleniyorsa farklı bir bölgeye kurtarmanın gerekli olup olmadığını değerlendirin.
Sistem işlemlerini geri yükleme. Olağanüstü durum sırasında, nedeni belirlemeye değil işlemleri geri yüklemeye odaklanılmalıdır. Özellikle bölge yük devretmesinde teknik kurtarma için etkin-aktif, aktif-pasif, sıcak bekleme veya soğuk bekleme gibi yaklaşımlara önceden karar verin.
Seçilen yaklaşıma göre belirli kurtarma adımlarını hazırlayın. İşlemleri geri yükleme adımlarının somut bir listesiyle başlayın. Süreç olgunlaştıkça, DR planını manuel etkileşimi en aza indiren bir betik olarak tanımlamayı hedefleyin. Kolay erişim için sürüm denetimini kullanın ve betiği güvenli bir şekilde depolayın. Bu yaklaşım önceden daha fazla çaba gerektirir ancak gerçek bir olay sırasında stresi en aza indirir.
Daha fazla bilgi için bkz DR için etkin-pasif dağıtımı.
Olay sonrası analiz gerçekleştirin. Olayın nedenini belirleyin ve gelecekte bunu önlemenin yollarını bulun. Kurtarma işlemlerini geliştirmek için değişiklikler yapın. Bu alıştırmada yeni stratejiler de ortaya çıkabilir. Örneğin, sistem ikincil ortama geçtiyse, birincil ortamın hala gerekli olup olmadığını ve yeniden çalışma işleminin ne olması gerektiğini belirleyin.
DR planı, iş yükünüzdeki değişikliklere uyum sağlayan canlı bir belgedir. Yeni bileşenler ve riskler ortaya çıktıktan sonra DR planınızı güncelleştirin. DR operatörlerinden gerçekçi bilgiler toplayarak tatbikatlardan veya gerçek olağanüstü durumlardan elde edilen içgörülere göre planı geliştirin.
Teknik ve operasyonel değişikliklerden kaynaklanan riskleri denetleyin ve olay yönetimine öncelik verin.
Önceki düzeylerde iş yükü ekibiniz özellikleri oluşturmaya ve sistemi çalışır hale getirmeye odaklanır. Düzey 4'te odak, sistemin üretimde güvenilir kalmasını sağlamak için değişir. Güvenlik olayı yönetimi, sistemin kararsız olmasını önlemek için yapılan değişikliklerin kapsamlı bir şekilde test edilmesi ve güvenli bir şekilde dağıtılması kadar önemlidir.
Bu süreç, güvenilirlik olaylarını yönetmek için ayrılmış ekiplere yatırım yapma gibi operasyonel denetimlerde iyileştirmeler gerektirir. Ayrıca, sistem güvenilirliğini önceki düzeylerde güçlendirilen kritik bileşenlerin ötesinde geliştirmek için teknik denetimler gerektirir. Sistem üretimde çalışmaya devam ettikçe, veri büyümesi güvenilir erişim ve bakım sağlamak için bölümleme gibi yeniden tasarımlar gerektirebilir.
Temel stratejiler
✓ Güvenilir değişiklik yönetimi
En büyük güvenilirlik riskleri yazılım güncelleştirmeleri, yapılandırma ayarlamaları veya işlem değişiklikleri gibi değişiklikler sırasında ortaya çıkar. Bu olaylar güvenilirlik açısından kritik önem taşır. Amaç, sorun, kesinti, kapalı kalma süresi veya veri kaybı olasılığını en aza indirmektir. Her değişiklik türü, benzersiz risklerini etkili bir şekilde yönetmek için belirli etkinlikler gerektirir.
Düzey 4'te Güvenilirlik, operasyonel mükemmellik bölümünde açıklanan güvenli dağıtım uygulamalarıyla, değişiklikleri yönetirken kararlı bir ortamın korunmasında kesişmektedir. Güvenilir değişiklik yönetimi, iş yükü kararlılığı elde etmek için bir gereksinimdir. Aşağıdaki önemli yönleri göz önünde bulundurun:
Platform güncelleştirmelerine tepki verme. Azure hizmetlerinin hizmetleri güncelleştirmek için farklı mekanizmaları vardır.
Bakım işlemleri hakkında bilgi edinin ve kullandığınız her hizmetin ilkelerini güncelleştirin. Hizmetin otomatik veya el ile yükseltmeleri destekleyip desteklemediğini ve el ile güncelleştirmeler için zaman dilimini anlayın.
Planlı güncelleştirmeleri olan hizmetler için, düşük etkili zamanlarda zamanlayarak bu güncelleştirmeleri etkili bir şekilde yönetin. Otomatik güncelleştirmelerden kaçının ve riski değerlendirene kadar erteleyin. Bazı hizmetler zamanlamayı denetlemenize olanak tanırken, diğer hizmetler yetkisiz kullanım süresi sağlar. Örneğin, Azure Kubernetes Service (AKS) ile güncelleştirmenin otomatik hale gelmesi için 90 gününüz vardır. Regresyonları önlemek için üretim kurulumunuzu yansıtan üretim dışı bir kümede güncelleştirmeleri test edin.
Güncelleştirmeleri aşamalı olarak uygulayın. Test, güncelleştirmenin güvenli olduğunu gösterse bile, bunu tüm örneklere aynı anda uygulamak riskli olabilir. Bunun yerine, bir kerede birkaç örneği güncelleştirin ve her küme arasında bekleyin.
Etkinlik günlüklerinde veya hizmete özgü diğer kanallarda bulunabilecek güncelleştirmelerle ilgili bildirimleri düzenli olarak denetleyin.
Güncelleştirme uygulandıktan sonra ani veya aşamalı değişiklikleri izleyin. İdeal olarak, sistem durumu modeliniz bu değişiklikleri size bildirmelidir.
Otomasyon ile kapsamlı test. Değişiklikleri dağıttığınızda derleme ve dağıtım hatlarınıza daha fazla test tümleştirin. El ile gerçekleştirilen işlemleri işlem hatlarınızın otomatik bölümlerine dönüştürme fırsatlarını arayın.
Değişikliklerin beklendiği gibi çalıştığını ve uygulamanın diğer bölümlerini etkilemediğini onaylamak için çeşitli aşamalarda farklı test türlerinin birleşimini kullanarak kapsamlı testler yapın. Örneğin, pozitif test sistemin beklendiği gibi çalıştığını doğrulayabilir. Hata olmadığını ve trafiğin doğru şekilde aktığını doğrulamalıdır.
Güncelleştirmeleri planlarken test geçitlerini ve uygulanacak test türlerini belirleyin. Çoğu test, dağıtım öncesi aşamalarda gerçekleşmelidir, ancak her ortamda güncelleştirdiğinizde duman testleri de yapılmalıdır.
Güvenli dağıtım uygulamalarını izleyin. Doğrulama pencerelerini ve güvenli dağıtım uygulamalarını içeren dağıtım topolojilerini kullanın. Esnekliği ve güvenilirliği artırmak için kanarya ve mavi-yeşil dağıtımlar gibi güvenli dağıtım desenleri uygulayın.
Örneğin, kanarya dağıtımlarında kullanıcıların küçük bir alt kümesi önce yeni sürümü alır. Bu işlem, tüm kullanıcı tabanına dağıtımdan önce izleme ve doğrulamayı etkinleştirir. Özellik bayrakları ve gizli başlatmalar gibi teknikler, tüm kullanıcılara değişiklikleri yayınlamadan önce üretimde testi kolaylaştırır.
DR planınızı güncelleştirin. İlgili ve etkili olması için DR planınızı düzenli olarak güncelleştirin. Güncel olmayan yönergelerden kaçının. Bu yaklaşım, planın üretime dağıtılan ve kullanıcılar tarafından güvenilen sisteminizin geçerli durumunu yansıtmasını sağlar. Tatbikatlardan ve gerçek olaylardan alınan dersleri birleştirin.
Daha fazla bilgi için bkz . Operasyonel Mükemmellik Düzeyi 4
✓ Olayları işlemek için özel bir ekise yatırım yapın
Başlangıçta geliştirme ekibi olaylara dahil olabilir. Düzey 4'te, olay yönetimi için site güvenilirliği mühendisliğine (SRE) yatırım yapın. SRE'ler üretim sorunları konusunda uzmandır ve verimlilik, değişiklik yönetimi, izleme, acil durum yanıtı ve kapasite yönetimi konusunda uzmandır. Uzman bir SRE ekibi, mühendislik ekibine bağımlılığı önemli ölçüde azaltabilir.
SRE'lere olayları bağımsız olarak işlemek için gereken araçları, bilgileri ve bilgileri sağlayın. Bu hazırlık, mühendislik ekibine bağımlılığı azaltır. Site Güvenilirlik Mühendisleri, ortak desenleri hızla tanıyıp hafifletme sürecini başlatabilmek için önceki seviyelerde geliştirilen kılavuzlar ve iş yükü sağlık modeli konusunda eğitilmelidir.
Mühendislik ekibi, tekrarlayan sorunlar üzerinde düşünüp uzun vadeli stratejiler geliştirmek için zamanı olmalıdır, her seferinde tek tek ele almak yerine.
✓ Kendi kendini iyileştirme süreçlerini otomatikleştirme
Önceki düzeylerde, kendi kendini iyileştirme stratejileri yedeklilik ve tasarım desenleri kullanılarak tasarlanmıştır. Ekibinizin gerçek dünya kullanımı konusunda deneyimi olduğuna göre, yaygın hata desenlerini azaltmak ve mühendislik ekibine bağımlılığı azaltmak için otomasyonu tümleştirebilirsiniz.
Denge: Otomasyonun ayarlanması zaman alabilir ve maliyetli olabilir. Öncelikle sık gerçekleşen veya kesintilere neden olabilecek görevler gibi en etkili görevleri otomatikleştirmeye odaklanın.
Tetikleyicileri temel alan eylemleri yapılandırın ve zaman içinde yanıtları otomatikleştirerek SRE'ler için otomatik bir playbook oluşturun. Bir yaklaşım, azaltma adımlarını uygulayan betiklerle playbook'u geliştirmektir. Çeşitli görevleri otomatik olarak başlatan tetikleyicileri ayarlamak için Azure İzleyici eylem gruplarını kullanma gibi Azure'a özel seçenekleri keşfedin.
✓ Dayanıklılığı arka plan görevlerine genişletme
çoğu iş yükü, kullanıcı akışlarını doğrudan desteklemeyen ancak bir uygulamanın genel iş akışında kritik bir rol oynayan bileşenleri içerir. Örneğin, bir e-ticaret sisteminde kullanıcı sipariş ettiğinde sistem kuyruğa bir ileti ekler. Bu eylem e-posta onayı, kredi kartı ücreti sonlandırma ve gönderim hazırlığı için ambar bildirimi gibi çeşitli arka plan görevlerini tetikler. Bu görevler, web sitesindeki kullanıcı isteklerine hizmet eden işlevlerden ayrı çalışır ve bu da yükü azaltır ve güvenilirliği artırır. Sistemler ayrıca veri temizleme, düzenli bakım ve yedekleme için arka plan görevlerini kullanır.
Birincil kullanıcı akışlarınızı değerlendirip iyileştirdikten sonra arka plan görevlerini göz önünde bulundurun. Zaten mevcut olan teknikleri ve altyapıyı kullanın ve arka plan görevleri için iyileştirmeler ekleyin.
Denetim noktasını uygula. Denetim noktası oluşturma, belirli noktalarda bir işlemin veya görevin durumunu kaydetmeye yönelik bir tekniktir. Denetim noktası oluşturma, ağ hataları veya sistem kilitlenmeleri gibi beklenmeyen sorunlar nedeniyle kesintiye uğrayabilecek uzun süre çalışan görevler veya işlemler için özellikle yararlıdır. İşlem yeniden başlatıldığında, son kaydedilen denetim noktasından devam edebilir ve bu da kesintilerin etkisini en aza indirir.
İşlemleri idempotent tutun. Bir görev başarısız olduğunda, başka bir örneğin görevi alıp sorunsuz bir şekilde işlemeye devam edebilmesi için arka plan işlemlerinde yinelemeli çalışmanın sağlandığından emin olun.
Tutarlılığı sağlayın. bir arka plan görevi işleme sırasında durursa sistemin tutarsız bir duruma girmesini engelleyin. Hem denetim noktası oluşturma hem de görev düzeyinde idempotentlik, arka plan görev işlemlerinde daha fazla tutarlılık sağlamak için kullanılan tekniklerdir. Her görevi atomik işlem olarak çalıştırın. Birden çok veri deposuna veya hizmete yayılan bir görev için, tamamlanmasını sağlamak amacıyla görev bazında idemponans veya telafi edici işlemleri kullanın.
Arka plan görevlerini izleme sisteminizle ve test uygulamalarınızla tümleştirin. Hataları algılayın ve işlevsel ve işlevsiz sonuçlara neden olabilecek beklenmeyen kesintileri önleyin. İzleme sisteminiz bu bileşenlerden veri yakalamalı, kesintiler için uyarılar ayarlamalı ve işlemi otomatik olarak yeniden denemek veya sürdürmek için tetikleyicileri kullanmalıdır. Bu varlıkları iş yükünün bir parçası olarak değerlendirin ve kritik bileşenlerde yaptığınız gibi otomatik test gerçekleştirin.
Azure, Azure İşlevleri ve Azure App Service Web İşleri gibi arka plan işleri için çeşitli hizmetler ve özellikler sağlar. Güvenilirlik odaklı akışlar uygularken en iyi yöntemlerini ve sınırlarını gözden geçirin.
sistemin yeni ve öngörülemeyen risklere karşı dayanıklı olmasını sağlayan iş yükü mimarisi geliştikçe dayanıklı kalın.
5. Düzey'de çözümünüzün güvenilirliğini geliştirme odağı teknik denetimleri uygulamaktan uzaklaşır. Altyapınız, uygulamalarınız ve işlemleriniz kesintilere dayanıklı olacak ve hedef kurtarma sürelerinde onlardan kurtarılacak kadar güvenilir olmalıdır.
verilerinizi ve gelecekteki iş hedeflerini kullanarak işletmenizin daha ileriye gitmesi gerekiyorsa mimari değişikliklerin gerekli olabileceğini kabul edin. İş yükünüz geliştikçe ve yeni özellikler eklendikçe, bu özelliklerle ilgili kesintileri en aza indirirken mevcut özellikler için kesintileri daha da azaltmaya çabalayın.
Temel stratejiler
✓ Mimari gelişimine yol göstermek için güvenilirlik içgörülerini kullanın
Bu düzeyde, iş paydaşlarıyla işbirliği içinde kararlar alın. Aşağıdaki etmenleri inceleyin:
Sisteminizin bir süre içinde güvenilirlik eşiklerini kaç kez geçtiğini ve bunun kabul edilebilir olup olmadığını gösteren ölçümleri analiz edin. Örneğin, bir yılda beş büyük kesinti yaşanması, sistem tasarımı ve işletim uygulamalarının yeniden değerlendirilmesini tetikleyebilir.
Sistemin iş açısından kritikliğini değerlendirin. Örneğin, görev açısından kritik iş akışlarını destekleyen bir hizmet, maliyeti veya karmaşıklığı artırma pahasına sıfır kesinti süreli dağıtımlar ve anında yük devretme sağlamak üzere yeniden tasarlanması gerekebilir. Buna karşılık, azaltılmış kullanımlı bir hizmet daha rahat hizmet düzeyi hedeflerinden yararlanabilir.
Diğer yapılardaki değişikliklerin güvenilirliği nasıl etkilediğini değerlendirin. Örneğin, artan güvenlik önlemleri ek güvenlik atlamaları için güvenilirlik azaltmaları gerektirebilir ve bu da olası hata noktalarına neden olabilir.
Güvenilirliği korumanın operasyonel maliyetlerini değerlendirin. Bu maliyetler bütçe kısıtlamalarını aşarsa, harcamaları iyileştirmek ve denetlemek için mimari değişiklikleri göz önünde bulundurun.
Paydaşların, mühendislerin ve ürün yöneticilerinin bilinçli kararlar almalarına yardımcı olmak için yukarıdaki veri noktalarını ve ek içgörüleri görselleştirmeyi göz önünde bulundurun. Bu yaklaşım, güvenilirliğin tam bir resmini sağlar.
✓ Üretimde kontrollü testler çalıştırma
Bu düzeyde, yalnızca iş yükü en yüksek dayanıklılık garantilerini gerektiriyorsa üretimde denetimli denemeleri göz önünde bulundurun. Bu test uygulamaları kaos mühendisliği olarak bilinir. Testler, sistemin düzgün bir şekilde kurtarılıp olumsuz koşullar altında çalışmaya devam ettiğini doğrular.
Aşağıdaki örnek kullanım örneklerini göz önünde bulundurun:
Bağımlılık akışı analizi: Yaygın kullanım örneklerinden biri, mikro hizmet olarak tasarlanmış uygulamaları test etmedir. Hataların kullanıcı deneyimini art arda veya kesintiye uğratmadığından emin olmak için rastgele mikro hizmet örneklerini kapatabilirsiniz. Aşağı akış sistemlerinin tepkisini analiz etmek için belirli bileşenleri devre dışı bırakarak bu yaklaşımı sistem akışlarına genişletebilirsiniz. Amaç, sıkı bağlama veya gizli bağımlılıkları belirlemek ve sistem yedeklilik planlarının performansını test etmektir.
Düzgün performans düşüşü testi: Hata sırasında sistemin daha az işlevsellikle nasıl çalıştığını değerlendirin. Örneğin, bir öneri altyapısı başarısız olursa kritik olmayan özellikleri gizleyebilirsiniz.
Üçüncü taraf hata benzetimi: Sisteminizin nasıl çalıştığını ve geri dönüşlerin veya yeniden denemelerin doğru uygulanıp uygulanmadığını görmek için dış API'lere çağrıları devre dışı bırakın veya kısıtlayın.
Kaos mühendisliği, dayanıklılığı test etmede altın standarttır. Ancak, bu uygulamayı olgun sistemler ve iş yükü ekipleri için ayırın. Patlama yarıçapını sınırlamak ve kullanıcı etkisini önlemek için korumaların sağlandığından emin olun.
Oyun günleri düzenleyerek hazırlanın. Yapay işlemlerle daha düşük riskli kurulumlar kullanarak gerçek dünya koşullarının simülasyonunu gerçekleştiren üretim dışı ortamlarda başlayın. Bu yaklaşım süreç boşluklarını, insan hata yollarını ve mimari kusurları belirlemeye yardımcı olur.
Üretim dışı test değerli içgörüler sağlamayı durdurduğunda, eminseniz üretim aşamasına geçmenin zamanı gelebilir. Geçiş yapmadan önce tüm endişeleri listelediğinizden, dayanıklılığı değerlendirdiğinizden ve sorunları çözdiğinizden emin olun.
Denemelerin kapsamını sınırlayın. Örneğin, yalnızca bir örneği kapatabilirsiniz. Testin amacını açıkça tanımlayın. Neyi ve neden test ettiğinizi anlayın.
Bu testler, önceden tanımlanmış sınırlar ve hata bütçeleri dahilinde çalışarak hizmet düzeyi sözleşmelerine uymalıdır. Bu denemeler için uygun zaman çerçevelerini seçin. Genellikle, bunları bir iş günü sırasında gerçekleştirmek, ekibin tam personele sahip olmasını ve oluşabilecek olaylara yanıt vermek için bol miktarda kaynağa sahip olmasını sağlar.
✓ Olağanüstü durum kurtarma tatbikatları gerçekleştirme
Kaos mühendisliği, teknik denetimlerin dayanıklılığını test eder. Olağanüstü durum kurtarma (DR) tatbikatları, işlem denetimlerinin dayanıklılığını değerlendirir. DR tatbikatlarının amacı, sisteminiz büyük hatalardan veya olağanüstü durumlardan kurtulduğunda yordamların, koordinasyonun ve insan eylemlerinin etkinliğini doğrulamaktır.
Mevzuat iş yükleri için uyumluluk gereksinimleri, efor kaydını sağlamak için DR tatbikatlarının sıklığını dikte edebilir. Diğer iş yükleri için bu tatbikatların düzenli olarak yapılması önerilir. Altı aylık bir aralık, iş yükü değişikliklerini yakalamak ve DR yordamlarını uygun şekilde güncelleştirmek için iyi bir fırsat sağlar.
DR tatbikatları rutin alıştırmalardan daha fazla olmalıdır. DR tatbikatları düzgün bir şekilde yapıldığında, yeni ekip üyelerinin eğitilmesine ve araçlar, iletişim ve tatbikatla ilgili diğer görevlerdeki boşlukların belirlenmesine yardımcı olur. Ayrıca, aksi takdirde göz ardı edilebilecek yeni perspektifleri vurgulayabilirler.
Her birinin risk ve pratiklik açısından farklılık gösteren DR tatbikatlarını yürütmek için aşağıdaki temel yöntemleri göz önünde bulundurun:
Tamamen simüle edilmiş: Bu alıştırmalar tamamen beyaz tahta tabanlıdır ve herhangi bir sistemi etkilemeden yordamlı kullanım kılavuzları içerir. Eğitim ve ilk doğrulama için uygundur. Ancak gerçek olaylarla ilgili içgörü sağlamaz.
Üretim dışı ortamlarda gerçek tatbikatlar: Bu tatbikatlar, iş riski olmadan otomasyon, betik ve işlemleri doğrulamanıza olanak sağlar.
Üretimde gerçek tatbikatlar: Bu tatbikatlar en yüksek güvenilirlik ve gerçekçilik düzeyini sağlar. Bu tatbikatları yalnızca önceki iki yöntemi test ettikten sonra gerçekleştirin. Riski en aza indirmek için kapsamlı planlama ve geri alma stratejileri gereklidir. Kesintilere neden olma ihtimaliniz varsa devam etmeyin.
DR tatbikatı türünden bağımsız olarak iş yükü kurtarma senaryolarını açıkça tanımlayın. Tatbikatları gerçek olaylar gibi gerçekleştirin. Bu yaklaşım, ekibin iyi anlaşılmış denetim listelerini izlemesini sağlar. Sürekli iyileştirme sağlamak için bulguları belgeleyin ve sınıflandırabilirsiniz. DR hazırlığınız aşağıdaki işlemleri içerebilir:
Olay yönetim sistemlerini anlayın ve ekibin yükseltme yolları üzerinde eğitildiğinden emin olun.
Birincil sistemlerin etkilenmesi durumunda alternatifler de dahil olmak üzere işbirliği ve durum güncelleştirmeleri için iletişim araçlarını listeleyin.
İş yükü için ilgili test senaryolarında beceri malzemeleri sağlayın.
Uygulama sırasında karşılaşılan sorunları yakalamak için tutarsızlıkları izleyin.
Taviz: Bu tatbikatlar genellikle kesintiye neden olmaz, ama zaman alıyor. Etkinliklerini en üst düzeye çıkarmak için önemli konulara odaklanın ve gereksiz görevlerden kaçının. Bu uygulama için iş listesinde zaman ayırdığınızdan emin olun.
DR planları oluştururken veya dr tatbikatları gerçekleştirdiğinizde, özellikle ilk birkaç tatbikat için özel uzmanlık dahil etmeyi göz önünde bulundurun. Çoklu bölge tasarımı, yük devretme ve geri yükleme stratejileri ve hizmetler veya araçlarla ilgili katkıları çok değerli olabilir. Kuruluşunuzun Bir Bulut Mükemmellik Merkezi ekibi varsa, bunları planlama sürecine dahil edin.
✓ Gerekirse veri modelinizi ve segmentinizi değerlendirin
Veriler dinamiktir ve sürekli gelişmektedir. Mimarinizdeki diğer bileşenlerin aksine, veriler genellikle kullanıcılar sisteminizle etkileşime geçtikçe büyür. Veri desenlerini zaman içinde izlemek ve mimarinizin diğer bölümleri üzerindeki etkilerini değerlendirmek çok önemlidir. Bu düzeyde, genel güvenilirliği artırmak için veri yönetimini basitleştiren ve performansı geliştiren teknikleri göz önünde bulundurun. Bölümleme, bu sonuçları elde etmek için önemli bir stratejidir.
Erişim şekillerine göre verileri ayıran ve farklı yerlerde depolayan sıcak-soğuk bölümleme gibi teknikleri keşfedin. Hangi bölümlerin bölümlendirileceğine karar vermek için, erişim sıklığı veya ilgililik gibi ölçütleri kullanın.
Sık erişimli-soğuk bölümleme, büyük bir veritabanını parçalar olarak adlandırılan daha küçük birimlere ayıran bir işlem olan parçalama ile birleştirilebilir. Her parça verilerin bir bölümünü tutar ve birlikte veri kümesinin tamamını oluşturur. Bu yaklaşım bağımsız veri yönetimi sağlar.
Ödünleşim: Parçaları dengelemek, operasyonel süreçlerin dağılımını değerlendirmesi ve onaylamasını gerektirir. Bu yaklaşım, bir bölümün aşırı kullanıldığı yoğun erişimli bölümleri önlemeye yardımcı olur. Ancak, dengeyi korumak için sürekli çaba ve kaynaklar da gerektirir.
Bir bölümleme tekniği seçtiğinizde aşağıdaki güvenilirlik avantajlarını göz önünde bulundurun:
Gelişmiş performans: İstekleri birden çok bölüme dağıtarak tek tek depolardaki yükü azaltabilirsiniz. Parçalama, etkili bir şekilde uygulandığında sistemin günde milyonlarca yazma isteğini işlemesini sağlar. Bu strateji performansı artırır ve gecikme süresini en aza indirir.
Bölümleme, yatay ölçeklendirmeyi basitleştirebilir. Örneğin parçalama, kullanıcıları veya müşterileri yaklaşık eşit boyutlu demetlere bölebilir.
Geliştirilmiş veri yönetimi: Sıcak-soğuk bölümleme, her depolama katmanına farklı düzeylerde veri yönetiminin uygulanmasını sağlar. Örneğin, arşiv verilerini ayrı bir depoya taşımak, işlemlerde ve yedeklemelerde yavaşlamaların önlenmesine yardımcı olur. Benzer şekilde, tüm günlük verilerinin ilişkisel veritabanında depolanması gerekli değildir. Etkin iş yükü verileri ilişkisel kalırken başka bir veri deposunda depolanabilir.
Uyarlanmış güvenilirlik ilkeleri: Her bölümün doğru direnç seviyesine sahip olduğunu ve tek bir deponun darboğaz haline gelmesini önlediğini sağlamak için farklı güvenilirlik ilkeleri uygulanabilir. Sık erişimli bölümler alanlar arası yedeklilik ve coğrafi olarak yedeklilik dahil olmak üzere tamamen yedekli olabilirken, soğuk bölümler yedeklemelere dayanır. Güvenilirlik avantajı, bazı hata türlerinin patlama yarıçapını azaltabilmenizdir. Örneğin, bir hata bir parçayı etkilerse, diğer parçaları etkilemeyebilir.
Denge: Farklı veri bölümleri arasındaki güçlü bağımlılıklar nedeniyle bölümleri korumak veya değiştirmek zor olabilir. Bu değişiklikler, özellikle tek bir veri deposuyla karşılaştırıldığında veri tutarlılığını ve bütünlüğünü doğrulama özelliğini etkileyebilir. Bölüm sayısı arttıkça, veri bütünlüğünü korumak için sağlam işlemlere duyulan ihtiyaç daha önemli hale gelir. Bu önlemler olmadan güvenilirlik tehlikeye girebilir.