Güvenilirlik hedeflerini tanımlama önerileri

Bu Azure İyi Tasarlanmış Çerçeve Güvenilirliği denetim listesi önerisi için geçerlidir:

Bu kılavuzda, kritik iş yükleri ve akışlar için kullanılabilirlik ve kurtarma hedefi ölçümlerini tanımlama önerileri açıklanmaktadır. İş paydaşlarıyla yapılan atölye alıştırmalarından güvenilirlik hedefleri türetmelisiniz. Ardından iş yüklerinizi izleyerek ve test ederek bu hedefleri iyileştirin.

İç paydaşlarınızla iş yükü güvenilirliği hakkında gerçekçi beklentiler belirleyin. Böylece müşterilere bu beklentileri iletmek için sözleşme sözleşmelerini kullanabilirler. Gerçekçi beklentiler, proje katılımcılarının mimari tasarım kararlarınızı anlamasına ve desteklemesine ve üzerinde anlaşmaya vardığınız hedeflere en uygun şekilde uymayı tasarladığınızı bilmesine de yardımcı olur.

İş gereksinimlerinizi ölçmek için aşağıdaki ölçümleri kullanmayı göz önünde bulundurun.

Temel tasarım stratejileri

Güvenilirlik hedefleri, kullanıcılarına ve iş paydaşlarına söz verdiği gibi bir iş yükünün istenen kalite hedefini temsil eder. Bu hedef, iş yükünün hem kullanılabilirliğini hem de kurtarılabilirliğini içerir. Güvenilirlik hedeflerinin performans hedeflerinden farklı olduğunu, ancak güvenilirlik hedeflerine performans hedefleri eklemeniz gerektiğini unutmayın. Aşağıdaki güvenilirlik hedeflerini göz önünde bulundurun:

• Kullanılabilirlik hedefleri , sistemin erişilebilir ve işlevsel kalması için kalite standartlarını tanımlar. Bu standartları karşılamıyorsa sistem güvenilmez olarak kabul edilir. Sisteminizin bu standartlara uygun olup olmadığını denetlemeye yardımcı olması için SLO'ları kullanın. İş ve teknik paydaşlar gerçekçi SLO'lar ayarlamak ve karşılaştırmalı analiz, kullanıcı deneyimi ve iş yükü profili gibi faktörleri dikkate almak için işbirliği gerçekleştirir.

• Doğruluk hedefleri , iş yükünün işlevlerini tutarlı kalitede düzgün bir şekilde gerçekleştirmesini sağlar. Doğruluğu ölçmek için, iş yükünün göstergelerini birleştirilmiş, hedef puan olarak birleştirebilmeniz için ölçün.

• Kurtarma hedefleri RTO, RPO, MTTR ve MTBF ölçümlerine karşılık gelir. Bu ölçümler, planlarınızın etkinliğini ve iş sürekliliği ve olağanüstü durum kurtarma için test etmelerini sağlar.

Güvenilirlik hedeflerini belirlemek için iş paydaşları geniş gereksinimleri tanımlar. Daha sonra teknik uzmanlar iş yükünün geçerli durumunu değerlendirir ve izleme ve uyarılar aracılığıyla hedeflere ulaşmak ve bunları korumak için çalışır. Her iki taraf da gerçekçi hedefler üzerinde anlaşmalıdır.

Kullanıcı ve sistem akışlarını iş gereksinimleriniz açısından önem derecesine göre belirleyin ve puanlayın. İş yükünüzün tasarımına, gözden geçirilmesine, test edilmesine ve olay yönetimine yol göstermek için bu puanları kullanın. Bu akışlar için güvenilirlik hedefleri ayarlayın ve bu hedeflere uymamanızın işinizi önemli ölçüde etkileyebileceğini anlayın.

Denge: Sisteminizin teknik sınırları ile aktarım hızı ve saniyedeki işlemler gibi iş etkisi arasında bir boşluk olabilir. Bu boşluğu köprüleme zor olabilir. Overengineering yerine pratik ve uygun maliyetli bir çözüm hedefleyin.

Kullanılabilirlik hedeflerini ayarlama

Bir iş yükünün genel SLO'sunun tüm bağımlılıkları dahil olmak üzere bütünsel kalitesi yansıtılıyor. SLO'nun olgun bir bildirimi, yalnızca bu bağımlılıkların bir bileşimini değil, söz konusu iş yükü için genel iş hedefini göstermelidir. Örneğin müşteriler %99,99 kullanılabilirlik bekliyorsa, bir kısmı yalnızca %99,80'e ulaşsa bile genel SLO bu hedefi hedeflemelidir.

Paydaşlar müşteri deneyimini değerlendirir ve kapalı kalma süresinin geliri nasıl etkilediğini değerlendirir. Bu kaybı iş akışını tasarlama ve çalıştırma maliyetiyle karşılaştırır. Daha sonra karar alıcılar, gelir kaybını önlemek ve itibarını korumak için güvenilirlik için daha fazla para harcamaları gerekip gerekmediğini karar verir.

İş yükü sahipleri , hedefleri belirlemek için finansal hedefleri kullanır. İş gereksinimleri ölçülebilir ölçümlerle eşlenebilir. Amaç, müşteri deneyiminin kalitesini etkileyen bir dizi faktörü belirlemektir.

İş yükü mimarları SLO'ları temel alarak birçok teknik karar alır. SLO'lar:

• Diğer bağımlılıkları göz önünde bulundurarak mimari kararlara kritik giriş görevi görür.

• Hedef tartışmaları etkinleştirmek için iş yükünün durumunu neredeyse gerçek zamanlı bir görünüm ve paylaşılan bir şekilde anlamayı sağlayın. Ayrıca iş yükü ekibinin güvenilirliği artırma ve yeni özellikler geliştirme çabalarını önceliklendirmesine de yardımcı olur.

• Dağıtım işlemleri için birincil sinyal olarak davranarak sorun oluşması durumunda otomatik geri alma işlemini destekler ve değişikliklerin müşteri deneyiminde beklenen iyileştirmelere ulaştığını doğrulamasını sağlar.

• Hedeflere odaklanarak düzeltmeyi ve kurtarmayı hızlandırın, müşterilere sorunların otomatik olarak bildirilmesine yol açın ve kuruluşunuzdaki ekipler arasında güven oluşturun.

Yaygın SLO'ları ve etkileyen faktörleri göz önünde bulundurun

Her SLO belirli bir kalite ölçütünü hedefler. Güvenilirlik için bu yaygın SLO'ları göz önünde bulundurun. Bu liste kapsamlı değil. İş gereksinimlerinize göre SLO'lar ekleyin.

• Başarı oranı , hata döndüren veya görevlerini başarısız yapan istek ve işlemlerin başarısını ölçer.

• Gecikme süresi , bir işlem isteğinin ne zaman başlatıldığı ile sonucun kullanılabilir olması veya işlemin tamamlanması arasındaki süreyi ölçer.

• Kapasite , azaltma tabanlı yanıt sayısı gibi eşzamanlı kullanımı ölçer.

• Kullanılabilirlik , müşterilerin bakış açısından çalışma süresini ölçer.

• Aktarım hızı , belirli bir süre boyunca en düşük veri aktarım hızını ölçer. Aktarım hızı, saniye başına işlemler (TPS) veya saniye başına istekler (RPS) gibi bir veri hızı birimi olarak ölçülür.

Azure'da iş yükünüz için senaryoları ve toleransları anlayın. Hem Azure hizmetleri hem de uygulama bileşenleri iş yükü SLO'sunu etkiler. Genel SLO'dan türetmek için aşağıdaki tablodan gelen yanıtları birleştirin. İş yükü bileşeninin yardımcı programını değerlendirmek için örnek olarak bu soruları kullanın.

SLO kapsamını belirleme

SLO'ları sisteminizdeki her uygulama, iş yükü veya belirli bir akış gibi çeşitli düzeylerde ayarlayabilirsiniz. SLO'ları her bileşenin önemine göre özelleştirebilmeniz için düzeye özgü SLO'lar ayarlayın.

Hizmet olarak yazılım (SaaS) çözümlerinde, her müşterinin deneyimini iyileştirmek için müşteri başına SLO'ları ölçün. Müşterilerin segmentlerinde farklı altyapı kaynakları olabilir. Bu gibi durumlarda, müşteri segmentlerindeki tüm kaynakları toplayan sistem genelindeki bir SLO mantıklı olmayabilir. Bunun yerine, her müşterinin belirli bağlamıyla uyumlu SLO'ları ölçün. Daha fazla bilgi için bkz . Çok kiracılı çözüm için kiracı modelleri.

Bileşik SLO hedeflerini tanımlama

SLO'lar bir gözlemlenebilirlik penceresinde ölçülebilir ve ölçülebilir olmalıdır.

SLO'lar genellikle %99,90 gibi yüzdeler olsa da deyimler de olabilir. Tüm faktörleri içeren sayısal bir değer almak için her iki yöntemi de kullanın.

SLO, kabul edilebilir faktörleri tanımlayan ölçülebilir SLI'lerden oluşur. SLI'ler, uyarılabilen belirli bir eşiğe sahip ölçümlerdir. Bunları bir platformdan veya uygulamadan toplayabilirsiniz. Farklı bileşenler ilgili SLI'leri yayar. SLI'leri seçtiğinizde SLO'ları etkileyen faktörleri göz önünde bulundurun.

Örneğin, yanıt ve istek API'sini kullanan bir akışın SLO'su hesaplamak için sunucu gecikme süresini ve istek işleme süresini ölçün. Aktarım hızı ve hata hızları sanal makineler (VM' ler), ölçek kümeleri veya Azure Batch gibi sürekli işlem ortamları için geçerli değildir.

Denetim düzlemi erişimi için API yanıtları ve kaynak oluşturma gibi uzun süre çalışan işlemler için hata oranlarını ve gecikme süresini göz önünde bulundurun. Veri düzlemi erişimi, her biri kendi SLO hedeflerine sahip olan kullanılan API'lere bağlıdır.

İyi bir SLI, bir SLO'nun ne zaman ihlal edebileceğinizi gösterir. Genellikle yüzdebirlik olarak ölçülür. Aşağıda yaygın olarak kullanılan yüzdebirlik dilimler ve beklenen kullanılabilirliğe uyumsuzluk tahmini süresi yer alır.

Microsoft SLA'larının etkisini değerlendirme

Microsoft SLA'sı, Microsoft'un taahhütte bulunduğu alanların kullanılabilirliği hakkında içgörü sağlar. SLA'lar bir bütün olarak bir teklifi garanti etmemektedir. SLA'ları değerlendirirken, yayımlanan yüzdebirlik dilimde sağlanan kapsamı iyi anlamış olursunuz.

Azure Uygulaması Hizmeti'nin bir özelliği olan Web Apps'i göz önünde bulundurun. Özellik, belirli bir kullanım örneğinde 200 Tamam durumu döndürdüğünde kullanılabilir olarak kabul edilir. Bu belirli bağlam ve zaman çerçevesi içinde, Easy Auth veya yuva değiştirme gibi özelliklerin kullanılabilirliği konusunda mali olarak yedeklenmiş bir garantiyi kapsamaz. Sözleşmede açıkça belirtilmeyen alanları platformun en iyi çabasıyla kullanılabilir olarak dikkate almanız gerekir.

Bu nedenle, iş yükünüz dağıtım yuvalarına bağlıysa SLO'nuzu yalnızca App Service SLA'sından türetemezsiniz. bir iş yükü ekibi olarak, çalışma süresi kullanılabilirliğini hedge etmeniz ve tahmin etmeniz gerekir. Ancak, bu tahmin belirsiz olabilir, bu nedenle SLO'nuzu platformun SLA'sına yakından bağlama sorun olabilir.

Başka bir örnek düşünün. Azure Front Door%99,99 kullanılabilirliğe sahipse tasarımınızın sözleşmede yayımlanan belirli ölçütlere uyması gerekir. Örneğin, arka ucunuz depolama alanı içermelidir, boyutu en az 50 KB olan bir dosyayı alabilen bir GET işleme ihtiyacınız vardır ve aracıları coğrafi olarak farklı en az beş konumda birden çok yere dağıtmanız gerekir. Azure Front Door'un bu dar kullanım örneği önbelleğe alma, yönlendirme kuralları veya web uygulaması güvenlik duvarı gibi özellikleri garanti etmez. Bu özellikler SLA kapsamının dışındadır.

Çok bölgeli hedefleri uygulama

Güvenilirlik açısından bakıldığında çoklu bölge dağıtımı, yedeklilik ilkesinin bir uygulamasıdır. Amaç, bölgesel bir kesinti veya düşük performans riskini azaltmaktır. Bu strateji, düzgün tasarlandığında, yük devretme amacıyla ikincil bir bölge eklediğinden SLO'ları geliştirebilir.

İki ana kullanım örneği vardır:

• Daha fazla kapasite için bir yükü bölgeler arasında dağıtabileceğiniz yüksek kullanılabilirlik düzeni. Yüksek kullanılabilirlik, iş yükü kullanıcılarını bir bölgeyle kısıtlamaz ve sistemin tüm performansı SLO'ya katkıda bulunur.

• Müşterileri segmentlere ayırmak için belirli bölgelere kısıtladığınız bölme düzeni. Böyle durumlarda, çok bölgeli dağıtımları her bölgede ayrı dağıtımlar veya damgalar olarak değerlendirin. İş yükünüz için uygun SLI'lerle her damganın durumunu ayrı ayrı ölçün. Her damganın durumuna göre iş yükünüzün genel SLO'sunu göz önünde bulundurun. Damga damgaları arasında yük devretme yapabilirseniz, bir damgadaki bir hata başka bir damgaya yük devretme yoluyla kurtarılabilir olduğundan genel iş yükü SLO'nuz daha yüksek olur.

Denge: Risk azaltmanın eklenen karmaşıklık düzeyine değip değmeyeceğini belirleyin. Çoklu bölge hedefleri ayrıca dağıtımları koordine etme, veri tutarlılığını sağlama ve gecikme süresini işleme gibi operasyonel karmaşıklıkları da ortaya çıkarmaktadır. Bu işlemler kurtarma sırasında önemlidir. Ekibiniz bu karmaşıklıkları artan dayanıklılıkla karşılaştırmalıdır.

Yüksek SLO'ları karşılamak için ne kadar yedekliliğe ihtiyaç duyduğunuza dikkat edin. Örneğin Microsoft, Azure Cosmos DB'nin çoklu bölge dağıtımları için tek bölgeli dağıtımlar için garanti edenden daha yüksek SLA'ları garanti eder.

Kurtarma ölçümlerini tanımlama

RTO, RPO, MTTR ve MTBF ölçümleri gibi gerçekçi kurtarma hedeflerinin tanımları, hata modu analizinize, iş sürekliliği ve olağanüstü durum kurtarma için planlarınıza ve testlerinize dayanır. Bu hedefleri tanımlarken platform tarafından sağlanan kurtarma garantilerini dikkate alırsınız. Microsoft, RTO ve RPO garantilerini yalnızca Azure SQL Veritabanı gibi bazı ürünler için yayımlar.

Bu çalışmayı tamamlamadan önce proje katılımcılarıyla hedeflerinizi tartışın ve mimari tasarımınızın kurtarma hedeflerini en iyi şekilde desteklediğinden emin olun. Kurtarma ölçümleri için kapsamlı olarak test edilmemiş akışların veya iş yüklerinin tamamının garantili SLA'lara sahip olmaması gerektiğini paydaşlara açıkça iletin. Paydaşların, iş yükleri güncelleştirildikçe kurtarma hedeflerinin zaman içinde değişebileceğini anladığınızdan emin olun. Siz müşteri ekledikçe veya müşteri deneyimini geliştirmek için yeni teknolojileri benimsedikçe iş yükü daha karmaşık hale gelebilir. Bu değişiklikler kurtarma ölçümlerinizi artırabilir veya azaltabilir.

Kurtarma hedeflerini tanımlarken, kurtarmayı başlatmak için eşikleri tanımlayın. Örneğin, bir web düğümü beş dakikadan uzun süre kullanılamıyorsa havuza otomatik olarak yeni bir düğüm ekleyin. Tüm bileşenler için eşikler tanımlayın ve belirli bir bileşen için kurtarmanın diğer bileşenler ve bağımlılıklar üzerindeki etkisi de dahil olmak üzere neler içerdiğini göz önünde bulundurun. Kurtarma eylemlerini çok hızlı başlatmadığınızdan emin olmak için eşiklerinizin geçici hataları da hesaba eklemesi gerekir. Müşteriler için veri kaybı veya oturum kesintileri gibi kurtarma işlemlerinin olası risklerini belgeleyin ve paydaşlarla paylaşın.

Hedefleri izleme ve görselleştirme

Güvenilirlik hedefleriniz için topladığınız verileri kullanarak her iş yükü ve ilişkili kritik akışlar için sistem durumu modelinizi oluşturun. Sistem durumu modeli, akışlar ve iş yükleri için iyi durumda, düzeyi düşürülmüş ve iyi durumda olmayan durumları tanımlar. Durum değiştiğinde, modelin sorumlu tarafları uyarması gerekir. Tasarımla ilgili ayrıntılı konular ve öneriler için bkz . Sistem durumu modelleme kılavuzu.

Operasyon ekiplerinizi ve iş yükü paydaşlarınızı bilgilendirmek için iş yükü sistem durumu modelinin gerçek zamanlı durumunu ve genel eğilimlerini yansıtan bir görselleştirme oluşturun. Değer verdikleri ve kullanımı kolay bilgiler sağladığından emin olmak için görselleştirme çözümlerini proje katılımcılarıyla tartışın. Ayrıca oluşturulan raporları haftalık, aylık veya üç aylık olarak görmek isteyebilirler.

Azure kolaylaştırma

Azure SLA'ları, çalışma süresi ve bağlantı için Microsoft taahhütlerini sağlar. Farklı hizmetlerin farklı SLA'ları vardır ve bazen bir hizmet içindeki ürünler farklı SLA'lara sahiptir. Daha fazla bilgi için bkz. çevrimiçi hizmetler için SLA'lar.

Azure SLA, iş yükünüz SLA'yı karşılamıyorsa hizmet kredisi alma yordamlarının yanı sıra her hizmetin kullanılabilirlik tanımlarını içerir. SLA’nın bu yönü bir yaptırım ilkesi görevini görür.

Görselleştirme sisteminiz için Azure İzleyici panolarını keşfedin.

Örnek

Contoso, Ltd. etkinlik bilet sistemi için yeni bir mobil deneyim tasarlar. Üst düzey mimari aşağıdadır.

Grafana logosu, ilgili şirketinin ticari markasıdır. Bu işaretin kullanılması herhangi bir onay anlamına gelmez.

Bileşenler

SLO tanımı kavramını gösteren bazı bileşenler aşağıdadır. Bu mimaride aşağıdaki listeye dahil olmayan bileşenler vardır. Örneğin Key Vault kritik istek akışının bir parçası olsa da yanıt kullanım örneğinin bir parçası değildir. Key Vault kullanılamıyorsa, uygulama başlatma sırasında yüklenen gizli dizileri kullanarak çalışmaya devam eder. Ancak uygulamanın ölçeklendirilmesi gerekiyorsa, yeni düğümlerin gizli dizilerle yüklenmesi gerektiğinden Key Vault kullanılabilirliği kritik hale gelir. Bu örnekte ölçeklendirme işlemleri dikkate alınmaz. Diğer bileşenler kısa süre için atlanır.

• Azure Front Door , müşterilerin istek göndermek için kullandığı bir API'yi kullanıma sunan tek giriş noktasıdır.

• Azure Container Apps , iş yükü ekibinin sahip olduğu ve uygulama için iş mantığını çalıştırmak için kullandığı ortamdır.

• SQL Yönetilen Örneği başka bir takıma aittir ve yönetilir ve iş yükünün kritik bir bağımlılığıdır.

• Azure Özel Bağlantı, Azure Front Door ile Container Apps dağıtımları arasında özel bağlantı sağlar. SQL Yönetilen Örneği, özel uç nokta üzerinden uygulamaya da sunulur.

Bu mimaride API ekibi, uygulamadaki kritik akışlar için ilk SLO hedefini tanımlar. SLO'ları etkileyen faktörler bölümünde açıklanan stratejiyi benimser. Ek özellikleri fazla vurgulamadan temel işlevselliği kapsayan hedefler tanımlamayı hedefler. Tüm temel bulut işlevlerini içeren ve dağıtımlar arasında kod yürüten üç kritik kullanıcı akışının durumunu ölçer. Ancak bu akışlar tüm kod veya veri erişimini kapsamaz. İşte etkileyen faktörler.

Bileşik SLO hesaplama

• Azure kullanılabilirlik SLO'si: Azure için finansal taahhüt SLA'sı, platform güvenilirliğini değerlendirmek için bir ara sunucu görevi görür.

  Azure bileşeni	Geçerli SLA kapsamı	SLA kapsamında değil	Düzeltilmiş SLO
  Azure Front Door	Başarılı HTTP GET işlemleri için %99,99	Önbelleğe alma, kural altyapısı	99.98%
  Container Apps	Yerleşik giriş tarafından erişilebilen dağıtılan uygulamalara göre %99,95	Otomatik ölçeklendirme, belirteç deposu özellikleri	%99,95
  SQL Yönetilen Örnek	SQL Server örneğine bağlantı temelinde %99,99	Performans, veri saklama	99.80%
  Özel Bağlantı	Özel uç nokta ağının trafiği kabul etmediğinden veya uç nokta ile Özel Bağlantı hizmeti arasında trafiğin akmadığı dakikaların tamamına göre %99,99	Bir dakikadan kısa süren tek tek hatalar	%99,99

  Ayarlama, iş yükü ekibinin hedeflerine verdiği söze bağlı olan çeşitli faktörlere dayanır. Bir faktör, önceki deneyime göre platformun özelliğinde güvenilirlik olabilir. Örneğin, Container Apps ve Özel Bağlantı için ekip, SLA değerini olduğu gibi rahatça alır.

  Ayrıca nüanslı faktörler de vardır. Örneğin ekip, şema değişiklikleri ve yedek alma gibi veri işlemlerinde olası hataları hesaba katmak için SQL Yönetilen Örneği için SLO değerini %99,80'e düşürür.

  Ekip, tek tek, ayarlanmış SLO değerlerinin etkisini hesaplayarak bileşik SLO'ları ayarlar. Bu değer %99,72'dir.

  Katkıda bulunan başka faktörler de vardır. Mimari, yayımlanmış SLA'sı olmayan sanal ağlar ve ağ güvenlik grupları (NSG) gibi Azure ağ bileşenlerine dayanır. İş yükü ekibi, her bileşen için %99,99 kullanılabilirlik ile bu faktörleri göz önünde bulundurmaya karar verir.

  Tahmin edilen platform kullanılabilirliğine dayalı bileşik SLO: Ayda %99,68.

• Uygulama kodu SLO: Ekip, uygulama kodundaki veya saklı yordamlardaki hataların sistem kullanılabilirliğini etkileyebileceğini kabul eder ve kodla ilgili hataları hesaba eklemek için aylık bir saatlik kapalı kalma süresi ayırır.

  Kod hataları, ölçeklendirme sorunları ve kodla ilgili diğer önemli noktalar gibi tek tek faktörlerin SLO'sunu tahmin etmek için yaygın kapalı kalma yüzdebirlik dilimlerini kullanır.

  Kod ve veri kullanılabilirliğine dayalı bileşik SLO: ayda %99,86.

• Kaynak ve uygulama yapılandırması SLO: Ekip, bulut kaynaklarının ve uygulama kodunun düzgün yapılandırılması gerektiğini kabul eder. Bu hedef otomatik ölçeklendirme kurallarını ayarlamayı, NSG kurallarını dağıtmayı ve SKU'ların doğru boyutunu seçmeyi içerir. Yapılandırma hatalarını hesaba eklemek için yaklaşık %99,98 kullanılabilirlik olan aylık kapalı kalma süresinin 10 dakikasını bütçeler.

  Yapılandırma kullanılabilirliğine dayalı bileşik SLO: Ayda %99,95.

• operations SLO: İş yükü ekibi, Operasyonel Mükemmellik için İyi Tasarlanmış Çerçeve ilkelerini izleyerek iyi Bir DevOps kültürü geliştirir. Bulut kaynaklarını, yapılandırmayı ve her sprint'i kodlar.

  Ekip, çalışan bir sistemin istikrarını bozabildiğinden dağıtımları bir risk olarak kabul eder. TLS sertifika güncelleştirmeleri, DNS değişiklikleri veya araç hataları sonucunda hatalar olabilir. Ekip ayrıca acil durum düzeltmelerinden kaynaklanan olası kapalı kalma sürelerini de dikkate alır. Yaklaşık %99,95 kullanılabilirlik olan aylık kapalı kalma süresinin toplam 20 dakikasını bütçeler.

  Bakım pencereleri, sistem bakımının veya güncelleştirmelerin gerçekleştiği zaman aralıklarıdır. API çoğunlukla her gün yaklaşık dört saat boyunca kullanılmaz. Ekip, kullanılamama riskini azaltmak için bu daha az etkin olan saatlerde bakım görevleri zamanlayabilir. Bu yaklaşım daha yüksek bir SLO'ya yol açar, ancak ekip bakım penceresini SLO'nun bir parçası olarak eklememeye karar verir.

  İşlem kullanılabilirliğine dayalı bileşik SLO: ayda %99,95.

• Dış bağımlılıklar SLO: Ekip, SQL Yönetilen Örneği birincil bağımlılık olarak kabul eder ve bu bağımlılık, genel platform kullanılabilirliğine %99,80 oranında kullanılabilirlik katsayısına sahiptir. Başka hiçbir dış bağımlılık dikkate alınmaz.

  Dış bağımlılıkları temel alan bileşik SLO: Uygulanamaz.

Genel bileşik SLO sonucunu belirleme

Toplam bileşik SLO hedefi %99,45 olarak ayarlanır ve bu da ayda yaklaşık dört saatlik kapalı kalma süresine eşdeğerdir.

İş yükü ekibi, ayda yalnızca dört saatlik kullanım dışı SLO hedefini karşılamak için bir arama rotasyonu oluşturur. Hem müşteri desteği hem de yapay işlem izleme, SLO sorunlarını çözmek için kurtarma adımlarını hemen başlatmak için arama sitesi güvenilirlik mühendisliği (SRE) desteğini çağırabilir.

İş yükü SLA'sını ayarlama

İş yükü için SLA aylık %99,90 kullanılabilirliktir.

İş yükü ekibinin yasal ve finans departmanları, iş yükü için SLA'yı aylık %99,90 kullanılabilirlik düzeyinde ayarlayarak %99,45 SLO hedefini aşıyor. Bu kararı, finansal ödemeleri ve cazip bir SLA'ya göre öngörülen müşteri büyümesini analiz ettikten sonra alır. SLA iki temel kullanıcı akışını kapsar ve yalnızca kullanılabilirliği değil performansla ilgili dikkat edilmesi gerekenleri de içerir. Bu, iş ekibinin işletmeye fayda sağlamak için aldığı hesaplanan bir risktir ve mühendislik ekibi taahhüdün farkındadır.

Doğruluğu ayarlama SLO

Uygulamanın temel kullanıcı akışları kullanılabilir ve kullanılabilir, hatta rekabetçi ve duyarlı olmalıdır. Ekip, istemci işleme süresi ve İnternet ağ geçişi hariç olmak üzere API için özel olarak bir yanıt süresi SLO'sunu ayarlar. Bu SLO'nun değerlendirmesini yalnızca kullanılabilirlik dönemlerinde yaparlar. Hem SLO hedefi hem de performans ölçümü olarak 75. yüzdebirliği seçer ve bu da tipik müşteri deneyimini yakalar ve en kötü senaryoları dışlar.

İlgili bağlantılar

Azure'da görev açısından kritik iş yüklerinin sistem durumu modellemesi ve gözlemlenebilirliği

Güvenilirlik denetim listesi

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