Güvenilirlik hedeflerini tanımlama önerileri

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

RE:04

Bileşenler, akışlar ve genel çözüm için güvenilirlik ve kurtarma hedefleri tanımlayın. Anlaşma, fikir birliği sağlama, beklentileri belirleme ve ideal duruma ulaşmak için eylemler gerçekleştirme hedeflerini görselleştirin. Sistem durumu modelini oluşturmak için tanımlı hedefleri kullanın. Sistem durumu modeli sağlıklı, düzeyi düşürülmüş ve iyi durumda olmayan durumların nasıl göründüğünü tanımlar.

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. Güvenilirlik hedefleri, iş paydaşlarıyla atölye alıştırmaları aracılığıyla türetilir. Hedefler izleme ve test yoluyla geliştirilmiştir.

şirket içindeki paydaşlarınızla, paydaşların bu beklentileri sözleşmeler aracılığıyla müşterilere iletebilmesi için iş yükü güvenilirliğine yönelik gerçekçi beklentiler belirleyin. Gerçekçi beklentiler, proje katılımcılarının mimari tasarım kararlarınızı anlamasına ve desteklemesine ve üzerinde anlaştığınız hedefleri en uygun şekilde karşılamak için tasarladığınızı bilmesine de yardımcı olur.

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

Süre	Tanım
Hizmet düzeyi hedefi (SLO)	bir iş yükünün veya uygulamanın performansının ve güvenilirliğinin ölçüsü. SLO, belirli müşteri etkileşimleri için ayarlanan belirli, ölçülebilir bir hedeftir. Bu, kullanıcılarınızın almayı beklemesi gereken hizmet kalitesine göre uygulamadaki iş yükünüz için ayarladığınız bir hedeftir.
Hizmet düzeyi göstergesi (SLI)	Bir hizmet tarafından yayılan ölçüm. SLI ölçümleri bir SLO değerini ölçmek için toplanır.
Hizmet düzeyi sözleşmesi (SLA)	Hizmet sağlayıcısı ile hizmet müşterisi arasındaki sözleşme sözleşmesi. Sözleşmenin karşılanmaması hizmet sağlayıcısı için finansal sonuçlara neden olabilir.
Ortalama kurtarma süresi (MTTR)	Bir hata algılandıktan sonra bileşeni geri yüklemek için geçen süre.
Hata arasındaki ortalama süre (MTBF)	İş yükünün başarısız olana kadar beklenen işlevi kesintisiz olarak gerçekleştirebileceği süre.
Kurtarma süresi hedefi (RTO)	Bir uygulamanın bir olaydan sonra kullanılamayabileceği kabul edilebilir en uzun süre.
Kurtarma noktası hedefi (RPO)	Bir olay sırasında kabul edilebilir maksimum veri kaybı süresi.

Bu ölçümler için iş yükünün hedef değerlerini kullanıcı akışları ve sistem akışları bağlamında tanımlayın. Bu akışları gereksinimleriniz için ne kadar kritik olduğunu belirleyip puanlayın. İş yükünüzün tasarımını mimari, gözden geçirme, test ve olay yönetimi işlemleri açısından yönlendirmek için değerlerini kullanın. Hedeflerin karşılanmaması, işletmeyi tolerans düzeyinin ötesinde etkileyecektir.

Temel tasarım stratejileri

Teknik tartışmalar, kritik akışlarınız için güvenilirlik hedeflerini nasıl tanımladığınıza yol açmamalıdır. Bunun yerine, iş paydaşlarının bir iş yükünün gereksinimlerini tanımladıkları müşterilere odaklanması gerekir. Teknik uzmanlar, paydaşların bu gereksinimlerle ilişkili gerçekçi sayısal değerler atamasına yardımcı olur. Teknik uzmanlar, bilgi paylaştıkları için gerçekçi SLO'lar hakkında müzakere ve karşılıklı fikir birliği sağlar.

Gereksinimleri ölçülebilir sayısal değerlerle eşleme örneği düşünün. Proje katılımcıları, kritik bir kullanıcı akışı için normal iş saatlerinde bir saatlik kapalı kalma süresinin aylık gelirde X dolar kaybına neden olduğunu tahmin eder. Bu dolar miktarı, yüzde 99,9 yerine yüzde 99,95 kullanılabilirlik SLO'su olan bir akış tasarlamanın tahmini maliyetiyle karşılaştırılır. Karar alıcıların, bu gelir kaybı riskinin buna karşı korumak için gereken ek maliyetlerden ve yönetim yükünden daha ağır basıp basmadığını tartışması gerekir. Akışları incelediğinizde ve hedeflerin tam listesini oluştururken bu deseni izleyin.

Güvenilirlik hedeflerinin performans hedeflerinden farklı olduğunu unutmayın. Güvenilirlik hedefleri kullanılabilirlik ve kurtarmaya odaklanır. Güvenilirlik hedeflerini ayarlamak için en geniş gereksinimleri tanımlayarak başlayın ve üst düzey gereksinimleri karşılamak için daha belirli ölçümler tanımlayın.

En üst düzey güvenilirlik ve kurtarma gereksinimleri ile bağıntılı ölçümler, örneğin tüm bölgeler için yüzde 99,9 uygulama kullanılabilirliği veya Amerika bölgesi için 5 saatlik hedef RTO olabilir. Bu tür hedefleri tanımlamak, bu hedeflere hangi kritik akışların dahil olduğunu belirlemenize yardımcı olur. Ardından bileşen düzeyi hedefleri göz önünde bulundurabilirsiniz.

Denge: İş yükünüzün bileşenlerinin teknik sınırlamaları ile bunun işletme için ne anlama geldiğinin (örneğin, saniye başına megabit cinsinden aktarım hızı ile saniyedeki işlemler arasında) kavramsal bir boşluk olabilir. Bu iki görünüm arasında model oluşturmak zor olabilir. Çözüme aşırı kaynak sağlamak yerine, ekonomik ama anlamlı bir şekilde yaklaşmaya çalışın.

Kullanılabilirlik ölçümleri

SLO'lar ve SLA'lar

SLO, bir iş yükünün veya uygulamanın performansının ve güvenilirliğinin ölçüsüdür. SLO, belirli müşteri etkileşimleri için ayarlanan belirli, ölçülebilir bir hedeftir. Bu, iş yükünüz veya uygulamanız için kullanıcılarınızın almayı beklemesi gereken hizmet kalitesine göre ayarladığınız bir hedeftir.

SLO kullanılabilirlik, yanıt süresi, aktarım hızı, başarı oranı ve diğerleri gibi çeşitli ölçümler açısından tanımlanabilir. Örneğin, bir web hizmetinin SLO'sunun belirli bir ay içinde kullanıcıların %99,9'unu kullanabilecek olması veya isteklerin %95'ini 500 milisaniye içinde yanıtlaması olabilir.

Uygulamanız veya iş yükünüz için SLO'ları tanımlamadan önce, uygulamanızın veya iş yükünüzün barındırdığı temel hizmetler için Microsoft tarafından yayımlanan SLA'ları gözden geçirin.

Not

Microsoft hizmeti SLA'ları platform SLI'leri veya SLO'lar değildir

Her hizmet için SLA'yı gözden geçirirken, yüksek SLA'ları karşılamak için ne kadar yedekliliğe ihtiyacınız olduğunu dikkate alın. Örneğin Microsoft, Azure Cosmos DB'nin çok bölgeli dağıtımları için tek bölgeli dağıtımlarda garanti edenden daha yüksek SLA'ları garanti eder.

Not

Azure SLA'ları her zaman hizmetin tüm yönlerini kapsamaz. Örneğin, Azure Uygulaması lication Gateway kullanılabilirlik SLA'sına sahiptir, ancak Azure Web Uygulaması Güvenlik Duvarı işlevi kötü amaçlı trafiğin geçişini durdurma garantisi sunmaz. SLA'larınızı ve SLO'larınızı geliştirirken bu sınırlamayı göz önünde bulundurun.

Tek tek iş yükü bileşenleri için SLA'ları topladıktan sonra bileşik bir SLA hesaplayın. Bileşik SLA, iş yükünün hedef SLO'sunun eşleşmesi gerekir. Bileşik SLA'nın hesaplanması, mimari tasarımınıza bağlı olarak çeşitli faktörler içerir. Aşağıdaki örnekleri göz önünde bulundurun.

Not

Aşağıdaki örneklerde yer alan SLA değerleri varsayımsaldır ve yalnızca gösterim amaçlıdır. Bunlar, Microsoft tarafından desteklenen geçerli değerleri temsil etmeye yönelik değildir.

Bileşik SLA'lar, farklı kullanılabilirlik düzeylerine sahip bir uygulamayı destekleyen birden çok hizmet içerir. Örneğin, Azure SQL Veritabanı yazan bir Azure Uygulaması Service web uygulaması düşünün. Varsayımsal olarak, bu SLA'lar şunlar olabilir:

• App Service web uygulamaları = yüzde 99,95
• SQL Veritabanı = yüzde 99,99

Bu uygulama için bekleyebileceğiniz maksimum kapalı kalma süresi nedir? Hizmetlerin herhangi biri başarısız olursa tüm uygulama başarısız olur. Her hizmetin başarısız olma olasılığı bağımsızdır, bu nedenle bu uygulamanın bileşik SLA'sı yüzde 99,95 × yüzde 99,99 = yüzde 99,94'tür. Bu değer tek tek SLA'lardan daha düşüktür. Birden çok hizmete dayalı bir uygulamanın daha fazla olası hata noktası olduğundan bu sonuç kesin değildir.

Bağımsız geri dönüş yolları oluşturarak bileşik SLA'yı geliştirebilirsiniz. Örneğin, SQL Veritabanı kullanılamıyorsa işlemleri daha sonra işlenecek bir kuyruğa yerleştirin:

Bu tasarımda, veritabanına bağlanamıyor olsa bile uygulama kullanılabilir durumdadır. Ancak, veritabanı ve kuyruk aynı anda başarısız olursa başarısız olur. Eşzamanlı hata için beklenen zaman yüzdesi 0,0001 × 0,001'dir, bu nedenle bu birleşik yolun bileşik SLA'sı aşağıdadır:

Veritabanı veya kuyruk = 1,0 − (0,0001 × 0,001) = yüzde 99,999999

Toplam bileşik SLA:

Web uygulaması ve (veritabanı veya kuyruk) = yüzde 99,95 × yüzde 99,99999 = yüzde ~99,95

Bu yaklaşımda dengeler vardır:

• Uygulama mantığı daha karmaşıktır.
• Kuyruk için ödemeniz gerekir.
• Veri tutarlılığı sorunlarını göz önünde bulundurmanız gerekir.

Çok bölgeli dağıtımlar için bileşik SLA aşağıdaki gibi hesaplanır:

• N , tek bir bölgede dağıtılan uygulamanın bileşik SLA'sıdır.

• R , uygulamanın dağıtıldığı bölge sayısıdır.

Uygulamanın tüm bölgelerde aynı anda başarısız olma olasılığı ((1 − N) ^ R'dir. Örneğin, varsayımsal tek bölgeli SLA yüzde 99,95 ise:

• İki bölge için birleşik SLA = (1 − (1 − 0,9995) ^ 2) = yüzde 99,999975

• Dört bölge için birleşik SLA = (1 − (1 − 0,9995) ^ 4) = yüzde 99,9999999

Doğru SLO'ları tanımlamak zaman alır ve dikkatli bir şekilde dikkate alınır. İş paydaşları, önemli müşterilerin uygulamayı nasıl kullandığını anlamalıdır. Ayrıca güvenilirlik toleransını da anlamaları gerekir. Bu geri bildirim, hedefleri bilgilendirmelidir.

SLA değerleri

Aşağıdaki tablo, ortak SLA değerlerini tanımlar.

SLA	Haftalık kapalı kalma süresi	Aylık kapalı kalma süresi	Yıllık kapalı kalma süresi
%99	1,68 saat	7,2 saat	3,65 gün
%99,9	10,1 dakika	43,2 dakika	8,76 saat
%99,95	5 dakika	21,6 dakika	4,38 saat
%99,99	1,01 dakika	4,32 dakika	52,56 dakika
%99,999	6 saniye	25,9 saniye	5,26 dakika

Bileşik SLA'ları akışlar bağlamında düşündüğünüzde, farklı akışların farklı kritiklik tanımlarına sahip olduğunu unutmayın. Bileşik SLA'larınızı oluştururken bu farkları göz önünde bulundurun. Kritik olmayan akışlar, kısa süre kullanılamayan müşteri deneyimini etkilemediğinden hesaplamalarınızdan atlamanız gereken bileşenlere sahip olabilir.

Not

Müşteriye yönelik iş yükleri ve dahili kullanım iş yükleri farklı SLO'lara sahiptir. Genellikle iç kullanım iş yükleri, müşteriye yönelik iş yüklerine kıyasla çok daha az kısıtlayıcı kullanılabilirlik SLO'larına sahip olabilir.

SLI'ler

SLI'leri bir SLO'ya katkıda bulunabilecek bileşen düzeyinde ölçümler olarak düşünün. En önemli SLI'ler, kritik akışlarınızı müşterileriniz açısından etkileyenlerdir. Birçok akış için SLI'ler gecikme süresi, aktarım hızı, hata hızı ve kullanılabilirlik içerir. İyi bir SLI, bir SLO'nun ihlal edilme riski altında olduğunu belirlemenize yardımcı olur. Mümkün olduğunda SLI'yi belirli müşterilerle ilişkilendirin.

Gereksiz ölçümlerin toplanmaması için her akış için SLI sayısını sınırlayın. Mümkünse akış başına üç SLI hedefleyin.

Kurtarma ölçümleri

Kurtarma hedefleri RTO, RPO, MTTR ve MTBF ölçümlerine karşılık gelir. Kullanılabilirlik hedeflerinin aksine, bu ölçümler için kurtarma hedefleri büyük ölçüde Microsoft SLA'larına bağımlı değildir. Microsoft, RTO ve RPO garantilerini yalnızca SQL Veritabanı gibi bazı ürünler için yayımlar.

Gerçekçi kurtarma hedeflerine yönelik 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 ç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. Müşteriler eklendikçe veya müşteri deneyimini geliştirmek için yeni teknolojiler benimsedikçe iş yükü daha karmaşık hale gelebilir. Bu değişiklikler kurtarma ölçümlerinizi artırabilir veya azaltabilir.

Not

MTBF'nin tanımlanması ve garanti edilmesi zor olabilir. Hizmet olarak platformlar (PaaS) veya hizmet olarak yazılım (SaaS) bulut sağlayıcısından herhangi bir bildirim almadan başarısız olabilir ve kurtarılabilir ve işlem sizin veya müşterileriniz için tamamen şeffaf olabilir. Bu ölçüm için hedefler tanımlarsanız, yalnızca sizin denetiminizde olan bileşenleri kapsar.

Kurtarma hedeflerini tanımlarken, kurtarma başlatmaya yönelik eşikler tanımlayın. Örneğin, bir web düğümü 5 dakikadan uzun süre kullanılamıyorsa, havuza otomatik olarak yeni bir düğüm eklenir. Diğer bileşenler ve bağımlılıklar üzerindeki etki de dahil olmak üzere belirli bir bileşen için kurtarmanın neleri içerdiğini göz önünde bulundurarak tüm bileşenler için eşikler tanımlayın. 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.

Sistem durumu modeli oluşturma

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. Eyaletler uygun operasyonel öncelik belirlemeyi sağlar. Bu model trafik ışığı modeli olarak da bilinir. Model sağlıklı için yeşil, düzeyi düşürülmüş için sarı ve iyi durumda olmayanlar için kırmızı atar. Sistem durumu modeli, bir akışın durumunun iyi durumdan düzeyi düşürülmüş veya iyi durumda olmayan duruma ne zaman değiştiğini bilmenizi sağlar.

İyi durumda, düzeyi düşürülmüş ve iyi durumda olmayan durumları nasıl tanımladığınız güvenilirlik hedeflerinize bağlıdır. Durumları tanımlamanın bazı örnekleri aşağıda verilmiştir:

• Yeşil veya sağlıklı durum, önemli işlevsiz gereksinimlerin ve hedeflerin tam olarak karşılandığını ve kaynakların en iyi şekilde kullanıldığını gösterir. Örneğin, isteklerin yüzde 95'i Azure Kubernetes Service (AKS) düğümü kullanımı X yüzdesiyle =500 ms cinsinden <işlenir.

• Sarı veya düzeyi düşürülmüş durum, akışın bir veya daha fazla bileşeninin tanımlı eşiklerine karşı uyarıda bulunduğunu ancak akışın çalışır durumda olduğunu gösterir. Örneğin, depolama azaltma algılandı.

• Kırmızı veya iyi durumda olmayan bir durum, güvenilirlik hedefleriniz tarafından izin verilebilenden daha uzun süre bozulmanın devam ettiğini veya akışın kullanılamaz hale geldiğini gösterir.

Not

Sistem durumu modeli tüm hataları aynı şekilde ele almamalıdır. Sistem durumu modeli, geçici ve geçici olmayan hatalar arasında ayrım yapmalıdır. Beklenen-geçici ancak kurtarılabilir hatalar ile gerçek bir olağanüstü durum arasında net bir şekilde ayrım yapmalıdır.

Bu model, sürekli iyileştirme ilkeleriyle geliştirilen ve çalıştırılan bir izleme ve uyarı stratejisi kullanarak çalışır. İş yükleriniz geliştikçe, sistem durumu modellerinizin de onlarla birlikte gelişmesi gerekir.

Katmanlı uygulama sistem durumu modeliyle ilgili ayrıntılı tasarım konuları ve önerileri için görev açısından kritik iş yükü tasarım alanlarında bulunan sistem durumu modelleme kılavuzuna bakın. İzleme ve uyarı yapılandırmaları hakkında ayrıntılı yönergeler için sistem durumu izleme kılavuzuna bakın.

Görselleştirme

operasyon ekiplerinizin ve iş yükü paydaşlarınızın iş yükü sistem durumu modelinin gerçek zamanlı durumu ve genel eğilimleri hakkında bilgi sahibi olmasını sağlamak için izleme çözümünüzde panolar oluşturmayı göz önünde bulundurun. Değer verdikleri ve kullanımı kolay bilgileri sağladığından emin olmak için görselleştirme çözümlerini paydaşlarla 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 SKU'lar farklı SLA'lara sahiptir. Daha fazla bilgi için bkz. çevrimiçi hizmetler için hizmet düzeyi sözleşmeleri.

Azure SLA, SLA karşılanmadıysa hizmet kredisi alma yordamlarının yanı sıra her hizmet için kullanılabilirlik tanımlarını içerir. SLA’nın bu yönü bir yaptırım ilkesi görevini görür.

İlgili bağlantılar

• Sistem durumu modellemesi için iyi Tasarlanmış Çerçeve görev açısından kritik rehberlik: 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.

Güvenilirlik denetim listesi