Güvenilirlik testi stratejisi tasarlamaya yönelik mimari stratejileri

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

RE:08 Kaos mühendisliği ilkelerini uygulayarak dayanıklılık ve kullanılabilirlik senaryolarını test edin. İş yükünüzün hatalara dayanabildiğini, talep altında ölçeklenebildiğini ve tanımlanan hedefleriniz içinde kurtarabildiğini doğrulamak için güvenilirlik testini kullanın.

Güvenilirlik testi, kesintilere neden olmadan önce mimari zayıflıkları yakalar. Hata senaryolarına karşı kasıtlı test yapmadan, dayanıklılık desenlerinizin gerçekten çalışıp çalışmadığını veya iş yükünüzün tanımlı hedefleri içinde kurtarılıp kurtarılmadığını bilemezsiniz.

Kullanılabilirliği etkileyen güvenlik risklerini, sistemi kullanılamaz hale getiren performans sorunlarını ve olay yanıtınızı sınırlayan operasyonel boşlukları test ettiğinizde iş yükünüzün güvenilirliğini güçlendirirsiniz. İş yükünüzü hata modlarına karşı düzenli olarak doğrulayan bir test temposu oluşturmak için bu makaledeki stratejileri kullanın. Mimari değiştikçe ve olaylar yeni zayıflıkları ortaya çıkardıkça testlerinizi geliştirin. zaman içinde güvenilirlik duruşunuzu güçlendiren bir geri bildirim döngüsü oluştururken iş yükünüzün hatalara dayanabileceğine, talebi karşılayacak şekilde ölçeklenebileceğine ve RTO ve RPO hedeflerinizde kurtarabileceğine dair güven oluşturun.

Bu makaledeki temel stratejiler, test için OE:09 Mimari stratejileri bölümünde açıklanan temel test uygulamalarını temel alır. Önce bu makaleyi gözden geçirin. Bu kılavuzdaki öneriler güvenilirlikle sınırlıdır ve iş yükünüzün hatalara dayanabilmesi ve hedefleriniz içinde kurtarılabilmesi konusunda güven duymanızı sağlamaya odaklanır.

Aşağıdaki tabloda, bu makale boyunca kullanılan temel güvenilirlik terimleri tanımlenmektedir.

Tanımlar

Süre Tanım
Availability Bir uygulama iş yükünün önemli bir kapalı kalma süresi olmadan iyi durumda çalıştığı süre.
Kaos mühendisliği Sistem dayanıklılığına sürekli iyileştirme sağlamak için ekip kültürünüz, mühendislik uygulamalarınız ve geliştirme yaşam döngünüze kaos testini güvenli bir şekilde dahil eden uygulama.
Kaos testi bir iş yükünün kesintiye neden olan koşullar altında nasıl davranması gerektiğiyle ilgili belirli bir dayanıklılık hipotezini doğrulayan denetimli bir deneme.
Hata enjeksiyonu Bir bileşene, bağımlılıklara veya sistem yoluna kasıtlı olarak hata ekleme tekniği.
Kurtarılabilirlik Üzerinde anlaşmaya varılan kurtarma süresi (RTO) ve kurtarma noktası (RPO) hedefleri içinde bir kesintiden sonra normal işlemleri geri yükleyebilme.
Resiliency bir iş yükünün hatalara (geçici hatalar, altyapı kesintileri, talep artışları gibi) dayanabilmesi ve kabul edilebilir bir kullanıcı deneyimi içinde çalışmaya devam edebilmesi.
Hata toleransı Birincil bileşenin başarısız olması durumunda ikincil bir bileşene geçme işlemi.
Failback Kurtarıldıktan sonra birincil bölgedeki işlemleri geri yükleme işlemi.
Hata bütçesi Hizmet Düzeyi Hedeflerinden (SLO' lar) türetilen tanımlı bir süre boyunca bir sistem için kabul edilebilir en yüksek hata düzeyi.

Hizmet türlerine göre güvenilirlik testi kapsamı tanımlama

Güvenilirlik testinizin kapsamını tanımlarken, kullandığınız hizmetlerin paylaşılan sorumluluk modelini göz önünde bulundurun. Her hizmet türü (IaaS, PaaS, SaaS) farklı güvenilirlik garantileri ve hata işleme üzerinde farklı denetim düzeyleriyle birlikte gelir. Testinize sahip olduğunuz güvenilirlik özelliklerine odaklanın.

  • Test derinliğini sizin sorumluluğunuzla eşleştirin. Altyapı hizmetleri (IaaS) için ekibiniz en fazla güvenilirlik kararına sahip olduğundan kaos mühendisliği ve hata ekleme yoluyla kapsamlı doğrulamaya yatırım yapın. Platform (PaaS) ve yazılım (SaaS) hizmetleri için sağlayıcı temel alınan güvenilirliğin çoğunu yönetir. İş yükünüzün, PaaS'taki altyapı yük devralmaları, kısıtlama, hizmette performans düşüşü veya yük düzenlerindeki değişiklikler gibi durumlarda bu hizmetlerle nasıl etkileşime girdiğine odaklanın.

  • Karma hizmet iş yüklerini göz önünde bulundurun. İş yükünüz birden çok hizmet türüne yayıldığında, test sorumlulukları bileşenler arasında farklılık gösterir. Kullanılabilirlik alanı kesintisi sırasında VM tabanlı altyapı bileşenlerinizin yük devretmesini test edebilirsiniz, ancak yüksek kullanılabilirlik için tasarlanmış bir PaaS veritabanı için sağlayıcı garantilerini kullanırsınız. Bu sınırların nerede olduğunu belirleyin ve testinizin aralarındaki boşlukları kapsadığından emin olun.

Uçtan uca, güvenilirlik hedeflerinize göre test edin

SLO'lar, GPO'lar ve RPO'lar gibi güvenilirlik hedefleriniz, iş yükünüzün hata koşullarında nasıl davranması gerektiğini tanımlar. Bunları yalnızca tek tek bileşenlerde değil, tam kritik akışlarda geçiş ve başarısız ölçütleri olarak kullanın.

  • Kurtarma işlemini tüm akış boyunca doğrulayın. Tek bir bileşen RTO'sunun içinde geri yüklenebilir, ancak aşağı akış bağımlılıklarının da geri yüklenmesi gerektiğinde genel kurtarma süresi hedefinizi aşabilir. Sorunu algılama ve yanıtlama süresi de dahil olmak üzere akışın tamamında toplam kurtarma süresini hesaplayın.

  • SLO'lar ve hata bütçeleriyle test kapsamını tanımlayın. Hata bütçeniz, arıza enjeksiyonu için yapabileceğiniz yatırım miktarını ifade eder. SLO'larınızın içinde kalmak için kaos testini sınırlayın ve her testin sınırlarını tanımlamak için akış kurtarma hedeflerinizi kullanın.

Kritik akışlardan ve hata modlarından güvenilirlik senaryoları oluşturma

İş yükünüzdeki kritik akışlarla ve bunları etkileyebilecek hata modlarıyla başlayın. En etkili hata senaryolarını belirlemek ve dayanıklılık ve kurtarma stratejilerinizi doğrulayan testler oluşturmak için hata modu analizinizi kullanın.

Etki ve olasılıklara göre öncelik belirleyin. Her hata modu aynı test yatırımını garanti etmemektedir. Önce en yüksek olası kullanıcı etkisine ve gerçekleşme olasılığı en yüksek senaryolara odaklanın. Hata modu çözümlemenizin bu öncelik belirlemeyi yönlendirmesine izin verin.

Hataya dayanıklılık ve kurtarma mekanizmalarınızı doğrulama

Kesinti süresine yol açma veya kullanıcı deneyimini olumsuz etkileme olasılığı en yüksek olan senaryolara odaklanın. İş yükünüzün hataları işleme ve etkili bir şekilde kurtarma becerisini doğrulayan testler oluşturmak için bu bölümdeki stratejileri kullanın.

Yedekleme ve geri yükleme

Yedekleme ve geri yükleme testiniz, veri koruma yaklaşımınızın kurtarma hedeflerinizi karşıladığını doğrulamalıdır.

  • Bir test temposu oluşturun. Yedekleme yapılandırmanızın, veri şemanızın veya altyapınızın ne sıklıkta değiştiğine bağlı olarak geri yüklemeleri ne sıklıkta test etmeniz gerektiğini belirleyin. Daha sık yapılan değişiklikler daha sık geri yükleme testi gerektirir.

  • Kurtarma hedeflerini ayarlayın. Yedekleme stratejinizin kurtarma hedeflerinize uygun olduğunu onaylamak için RPO ve RTO hedeflerinize göre gerçek geri yükleme sürelerini ölçün.

  • Yedeklemenin eksiksiz olduğunu varsaymayın. Yedeklemeler, verilerinizin yalnızca bir alt kümesini yakalamak için yanlış yapılandırılabilir. Yalnızca geri yükleme işleminin başarılı olup olmadığını değil, veri bütünlüğünü ve eksiksizliğini doğrulayın.

  • Yalıtarak test edin. Canlı iş yüklerini kesintiye uğratmadan kapsamlı denetimler çalıştırabilmeniz için üretimden ayrı bir ortamda geri yüklemeleri doğrulayın.

Geçici hatalar

Anlık ağ kesintileri, kısa hizmet kullanılamazlığı ve bağlantı zaman aşımları gibi geçici hatalar yaygın güvenilirlik riskleridir. İş yükünüzün bu hataları kullanıcıları etkilemeden işlediğini doğrulayın. Daha fazla bilgi için bkz Geçici hataları ele alma önerileri.

  • Sahip olduğunuz şeylere odaklanın. SDK'larınız veya platform hizmetleriniz yeniden denemeleri ve devre kesme işlemlerini otomatik olarak ele alırsa, tüm yeniden denemelerin başarısız olduğu veya devre kesicinin açıldığı durumlar gibi yerleşik mekanizmalar tükendiğinde ne olacağını test edin.

  • Hata işleme yapılandırmalarını doğrulayın. İş yükünüzün hata işleme yapılandırmalarını değerlendirin. Yeniden deneme ilkelerinin, devre kesici eşiklerinin ve zaman aşımı değerlerinin gerçekçi hata koşullarında beklendiği gibi davrandığını doğrulayın.

  • Geçici ve kalıcı hata arasındaki sınırı test edin. Bir hata beklenen eşiklerin ötesine geçtiğinde iş yükünüzün yeniden deneme davranışından geri dönüşe veya düşüşe düzgün geçişini doğrulayın.

  • Dayanıklılık özelliklerinden kaynaklanan geçici hataların hesabını verin. Alanlar arası yedeklilik ve benzer tasarımlar genellikle normal yük devretme işlemleri sırasında geçici hatalar üretir. Örneğin, alanlar arası yedekli veritabanı, trafik kesinti sırasında iyi durumdaki bir bölgeye kaydıkça geçici bağlantı hatalarına neden olabilir. İş yükünüzün bu beklenen geçici hataları kullanıcı etkisi olmadan işleyip işleyemeyeceğini test edin.

Yük ve ölçeklendirme yanıtı

İş yükünüzün talep değişiklikleri sırasında hem ani ani artışlar hem de kademeli artışlar nedeniyle güvenilirliği koruduğunu doğrulayın. Daha fazla bilgi için bkz. ölçeklendirme stratejisi. Yük ve stres testi kılavuzu için bkz. Test önerileri.

  • Hem yatay ölçek genişletmeyi hem de yatay ölçek daraltmayı test edin. Yeni kapasitenin yeterince hızlı bir şekilde devreye girdiğini ve ölçeğin küçültülmesinin isteklerin düşmesine neden olmadığını veya sahipsiz kaynaklar bırakmadığını doğrulayın.

  • Ölçeklendirme gecikmesini hesaba katın. Ölçeklendirmeyi tetikleme koşullarının karşılanmasıyla yeni kapasitenin hazır olması arasında her zaman bir gecikme olur. İş yükünüzün bu boşluk sırasında talebi işleyip işleyemeyeceğini veya ek kapasiteyi önceden sağlamanız gerekip gerekmediğini belirleyin.

Bağımlılık başarısızlıkları

İş yükünüz büyük olasılıkla üçüncü taraf API'ler, yönetilen platform hizmetleri veya paylaşılan iç hizmetler gibi doğrudan denetiminizin dışındaki hizmetlere bağlıdır. İş yükünüzün, bu bağımlılıklardaki başarısızlıkları kullanıcılar için önemli bir kesintiye yol açmadan ele aldığını doğrulayın.

  • Bağımlılıkları kritikliğe göre kategorilere ayırın. Tüm bağımlılıklar aynı test yatırımını gerektirmez. Kritik akışlarınızda bulunan ve yerleşik yedeklilik veya geri dönüş yolları olmayan bağımlılıklar için testlerin önceliğini belirleyin.

  • Her bağımlılık için geri dönüş davranışını test edin. Bir bağımlılık kullanılamaz duruma geldiğinde, iş yükünüz tamamen başarısız olmak yerine alternatif bir yola veya davranışa geri dönmelidir. Her geri dönüşün doğru etkinleştirildiğini ve ilgisiz işlevselliğin çalışmaya devam ettiğini onaylayın.

  • Kısmi ve basamaklı hataların hesabını verin. Bağımlılıklar ikili yollarla nadiren başarısız olur. Yalnızca tam kesintileri test etmeyin. Gecikme süresi artışlarını, aralıklı hataları ve kısmi veri kullanılabilirliğini kapsar.

  • İzolasyonu ve etki alanının sınırlandırılmasını doğrulayın. Tek bir bağımlılık hatasının ilgisiz işlevlere zincirleme olarak yayılmadığını doğrulayın.

Kendini koruma ve iyileşme

Tam kurtarma anında olmadığında iş yükünüzün daha düşük bir kapasitede çalışmaya devam edip etmeyeceği dahil olmak üzere kendi kendini iyileştirme ve kendini koruma tasarımınızın arızalara nasıl yanıt verdiğini doğrulayın.

  • Otomatik kurtarmayı uçtan uca test edin. Doğru kontrolleri içerdiğinden emin olmak için sistem durumu modellerinizi değerlendirin. Bu denetimlerin hataları doğru algıladığını, beklendiği gibi otomatik düzeltme tetiklediğini ve kabul edilebilir zaman çerçeveleri içinde sistemi iyi durumda döndürdüğünü doğrulayın.

  • Manuel kurtarma runbook'larını doğrulayın. Otomatik kurtarma her senaryoya yönelik değildir. Operatörlerin baskı altında ve kurtarma süresi hedefleriniz içinde bunları uygulayabildiğinden emin olmak için manuel çalıştırma runbook'larını gerçekçi koşullar altında test edin.

  • Düzgün bir düşüş davranışını doğrulayın. Bir bileşen başarısız olduğunda, iş yükünüz tamamen başarısız olmak yerine düzgün bir şekilde düşürülmelidir. İstekleri manuel inceleme için kuyruğa almak gibi sınırlı bir modda çalışabildiğini ve bu bozulmuş deneyimin kullanıcılar tarafından kabul edilebilir olduğunu test edin. Ekibinizin iş yükünü bu durumda nasıl çalıştıracaklarını ve tam işlevselliği nasıl geri yükleyebileceklerini bildiğini onaylayın.

Olaylar ve olağanüstü durum kurtarma (DR)

Bir olay veya olağanüstü durum oluştuğunda, bunu hızla algılama ve etkili bir şekilde yanıt verme yeteneğiniz kritik önem taşır. Olağanüstü hataları ve önemli olayları ele aldıklarından emin olmak için planlarınızı ve süreçlerinizi test edin. Üretim iş yüklerini etkilememek için DR testi için ayrılmış bir ortam kullanın. Daha fazla bilgi için bkz. Olağanüstü durum kurtarma planı.

  • Olay algılama mekanizmalarını doğrulayın. İzleme günlüklerinin gerekli bilgileri yakaladığını ve uyarıların uygun şekilde tetiklendiğini doğrulamak için olayların simülasyonunu yapın. Örneğin, istek hata oranlarının ne kadar hızlı arttığını ve izleme verilerinin ne sıklıkta örneklendiğini test edin.

  • Olay yönetimi süreçlerini test edin. Ekibinizin olay yanıtı yordamlarını etkili bir şekilde izleyebildiğini onaylayın. Daha fazla bilgi için bkz. olay yanıtı.

  • Tam yük devretme ve yeniden çalışma test edin. Tek tek parçaların yalıtımlı olarak test edilmesi, yalnızca gerçek geçiş sırasında ortaya çıkan koordinasyon hatalarını kaçırabilir. DNS geçişi, yedeklerin geri yüklenmesi, veri çoğaltma tutarlılığının yeniden sağlanması ve istemcilerin yeniden bağlanması dahil olmak üzere, tam yük devretme sürecini doğrulayın. Ayrıca, çoğu zaman ilk geçiş işleminden daha karmaşık olan birincil dağıtım ortamına geri dönüşü de test edin.

  • Yük devretme ortamında kapasiteyi doğrulayın. Yük devretme ortamınızın, yük devretme gerçekleştiğinde trafiği anında kaldırabilecek ve yük altında çökmeyecek kadar önceden tahsis edilmiş kapasiteye sahip olduğundan emin olun. Ölçeklendirme mekanizmaları devreye girerken ortamın operasyonları sürdürebildiğini test edin ve ölçeklendirme yaklaşımınızı doğrulayın. Daha fazla bilgi için bkz. Yük ve ölçeklendirme yanıtı.

  • Hedeflerinize göre ölçün. Bir DR testi RTO veya RPO'nuzu karşılamıyorsa boşlukları analiz edin ve DR planınızı uygun şekilde güncelleştirin.

  • Kişileri ve işlemleri doğrulayın. DR testi iletişim kanallarını doğrulamalı, operatörlerin kurtarma yordamlarını yürütmek için gerekli erişim ve izinlere sahip olduğunu onaylamalı ve baskı altında DR'ye özgü runbook'ları hızla bulabildiklerinden emin olmalıdır.

Masa üstü alıştırmalarıyla planınızı test edin ve değerlendirin

Tabletop alıştırmaları, gerçek bir olay bunları ortaya çıkarmadan önce güvenilirlik testinizde boşluklar bulmanıza yardımcı olur. Ekibinizle hata senaryolarının benzetimini yaparak, test edilmemiş koşulları belirleyebilir ve yanıt yordamlarınızın beklendiği gibi çalıştığını doğrulayabilirsiniz.

  • Gerçekçi olayların simülasyonunu yapmak. Bölgesel kesinti veya bozuk dağıtım gibi bir hata senaryosunda adım adım ilerleyin ve ekibinizin bunu algılamak, yanıtlamak ve kurtarmak için atacakları adımları açıklamasını sağlayın. Bu tartışmalar genellikle test yoluyla doğrulanmamış sistem davranışıyla ilgili varsayımları ortaya koyuyor.

  • Bulguları test çalışmalarına dönüştürün. Yeni güvenilirlik testleri oluşturmak için alıştırma sırasında ortaya çıkar olan boşlukları ve bilinmeyenleri kullanın. Ekip, belirli bir bağımlılık başarısız olduğunda iş yükünün nasıl davrandığını kimsenin bilmediğini fark ederse bu, test stratejinize ekleyebileceğiniz bir senaryodur.

Planlı ve plansız kesintilerden yararlanın

İş yükünüz planlı bakım veya planlanmamış bir kesinti nedeniyle çevrimdışı olduğunda, iş yükünüzü test etmek ve anlayışınızı geliştirmek için benzersiz bir fırsatınız vardır.

Planlı bakım

Güncelleştirmeler veya düzeltme ekleri için bakım pencereleri sırasında, bakım çalışmalarına dahil olmayan bileşenleri ve akışları test edin. İş yükünü beklenmedik bir şekilde düşürme veya çevrimdışına alma riski olmadan testleri çalıştırabilirsiniz. Yeterli zaman varsa, iş tamamlandıktan sonra bakımda yer alan bileşenleri de test edin.

Planlanmamış kesinti

Planlanmamış her kesinti, güvenilirlik testi stratejinizi güçlendirmek için bir fırsattır. Hizmeti geri yükleyip olay sonrası incelemenizi tamamladıktan sonra, testlerinizi geliştirmek için bulgularınızı kullanın.

  • Risk azaltma ölçülerinizi test edin. Geçici bir çözüm veya geçici düzeltme uyguladıysanız, kalıcı düzeltme gerçekleşmeden önce beklenen yükü işleyebildiğini doğrulayın.

  • Benzer zayıflıkları tarayın. Kesintiye katkıda bulunan aynı yapılandırma veya tasarım desenlerine sahip diğer bileşenleri gözden geçirin. Bu bileşenler de aynı şekilde başarısız olmadan önce onlar için testler ekleyin.

Farklı test türlerini birleştirme

Farklı test türlerini birlikte çalıştırdığınızda, her test yalıtıldığında görünür olmayan güvenilirlik sorunlarını ortaya çıkarabilirsiniz. Bir iş yükü normal koşullar altında belirli bir yükü kaldırabilir, ancak aynı yük, bir arıza eklediğinizde başarısızlıklara yol açar.

  • Mevcut test altyapısını yeniden kullanma. Zaten yük testi için bir altyapınız ve test düzeneğiniz varsa, kaos testlerini eşzamanlı olarak yürütmek için bunları kullanın. Yük ve hata eklemeyi aynı test çalıştırmasında birleştirmek, talep ile arızaların aynı anda ortaya çıktığı gerçekçi koşullar altında iş yükünüzün nasıl davrandığını gösterir.

  • Üretim dışı ortamlarda başlayın. Hata modlarını güvenli bir şekilde keşfedebileceğiniz düşük riskli ortamlarda güvenilirlik testine başlayın. Yalnızca üretim dışı ortamlardaki içgörüleri tükettikten ve patlama yarıçapını sınırlamak ve hızla geri almak için korumalar sağladıktan sonra üretim testine geçin.

Arıza enjeksiyonu ve kaos mühendisliği kullanın

Hata enjeksiyonu ve kaos mühendisliği, kasıtlı olarak arızalar oluşturarak ve sistemin tepkisini gözlemleyerek iş yükünüzün dayanıklılığına ilişkin güven kazanmanıza yardımcı olur. Denemeleri çalıştırmadan önce risk azaltma stratejilerini kullandığınızdan emin olun.

  • Düzenli olarak kaos denemeleri çalıştırın. Test kapsamınızı değerlendirin. Güvenilir olduğunu varsaydığınız bileşenlere ve akışlara hata ekleme. Mimariniz değiştikçe yeni hata modları ortaya çıkar ve önceki varsayımlar artık tutmayabilir. Regresyonları yakalamak, yeni bağımlılıkları doğrulamak ve son değişikliklerin zayıflıklar oluşturmadığını onaylamak için düzenli bir tempo üzerinde denemeler çalıştırın.

  • Denemelere odaklanmak için hata modu analizinizi kullanın. Her deneme belirli bir hatayı veya hata kümesini hedeflemeli ve belirli bir akışın belirli bir bileşenin kaybına dayanabilme becerisini test etme gibi net bir varsayıma sahip olmalıdır. Denemeler yeni hata modlarını veya keşfedilmemiş bağımlılıkları ortaya çıkardıkça, güncel tutmak için hata modu analizinizi güncelleştirin.

  • Denemeler sırasında etki alanını sınırlayın. Hangi bileşenlerin hızla kurtarılabileceğini belirleyebilir ve her hata enjeksiyonunun etkisine ilişkin gerçekçi beklentiler oluşturabilirsiniz. Bir deneme kapsamın dışına çıkarsa veya beklenmeyen sonuçlar üretirse, bunu durdurun. Kullanıcılar üzerindeki etkiyi en aza indirerek anlamlı veri toplamayı dengeleyin.

  • Referans noktalarına göre ölçün. Her denemedeki akışlar ve bileşenler için tutarlı güvenilirlik ve performans ölçümleri oluşturun. Hatanın tam etkisini anlamak ve dayanıklılık tasarımınızın hedeflerine uygun olup olmadığını belirlemek için düzeyi düşürülmüş durum ölçümlerini bu temellerle karşılaştırın.

  • Sonuçları test stratejinize geri sağlayın. Yeni testleri yönlendirmek, kurtarma planlarını güncelleştirmek ve düzeltme kapsamı öğelerini bilgilendirmek için deneme sonuçlarını kullanın. Beklenmeyen davranışlar ortaya çıktıkça, bu davranışlara yönelik testler oluşturun ve düzeltme stratejileri tasarlayın.

Ödünleşim: Üretim ortamında hata enjeksiyonu testi yıkıcı olabilir ve hizmet kesintisine yol açabilir. Bu olasılık hakkında paydaşlarla şeffaf olun. Denemeleri durdurmak ve hızlı bir şekilde geri almak ve hassas dönemlerde testleri ne zaman çalıştıracağınız veya kaçınacağınız konusunda esnek kalabilmek için korumaları devreye alın. İstenmeyen kesintilere karşı korunmak için yeterli yedeklilik planlayın ve paydaşlarınızın bunun maliyet açısından getirdiği ödünleşimi anladığından emin olun.

Risk: Güvenilirlik testi, kapsamı birçok hata modu arasında genişletebilir, ancak artık anlamlı bir değer sağlamadıktan sonra durdurmalısınız. Bilinen güvenilirlik sorunlarıyla ilgili bir kapsamınız zaten varsa, daha fazla test eklemek yerine bu sorunları düzeltmeye öncelik sağlayın.

Azure kullanımının kolaylaştırılması

Azure Test Planları , planlı el ile test, kullanıcı kabul testi, keşif testi ve proje katılımcılarından geri bildirim toplama için gereken tüm özellikleri sağlayan tarayıcı tabanlı bir test yönetimi çözümüdür.

Azure Chaos Studio bulut uygulamanızın ve hizmet dayanıklılığınızı ölçmenize, anlamanıza ve geliştirmenize yardımcı olmak için kaos testi kullanan yönetilen bir hizmettir.

Azure Uygulama Testi, uygulamalarındaki sorunları belirlemek için Azure Yük Testi kullanarak Oyun Yazarı Çalışma Alanları ve performans testleri ile işlevsel testler çalıştırmanıza olanak tanıyan bir hizmettir.

Azure Hizmet Durumu, Azure portalında yaklaşan bakım etkinlikleri hakkında sizi bilgilendiren ayrılmış bir bölüm olan planlı bakım bölmesine sahiptir. Azure kaynaklarınızı etkileyebilecek olayları vurgular ve önceden hazırlanmanıza yardımcı olur.

Bağlantı izleyicisi , hem Azure hem de hibrit ortamlarda ağ bağlantısını yapay izleme ve gerçek zamanlı test için kullanabileceğiniz bir Azure Ağ İzleyicisi özelliğidir. Kaos mühendisliği senaryolarında bağlantı izleyicisi, hataları hedeflenen ağ bileşenlerine eklemek ve gecikme süresi ve paket kaybı gibi önemli ölçümleri sürekli ölçmek için kullanılabilir. Bu özellik, ekiplerin hem tek tek akış bileşenleri hem de uçtan uca ağ yollarında kesintilerin ağ güvenilirliğini nasıl etkilediğini gözlemlemesini sağlar. Hataların etkisini değerlendirmek ve iyileştirme alanlarını belirlemek için, bağlantı izleyicisi telemetrisini temel ölçümlerle karşılaştırın.

Güvenilirlik denetim listesi

Öneriler kümesinin tamamına bakın.

Güvenilirlik denetim listesi

  • Last updated on