Bulut izleme hizmet düzeyi hedefleri

Bu makale, bulut izleme kılavuzundaki bir serinin parçasıdır.

Aşağıdaki bölümlerde hizmet düzeyi hedeflerinin temel ilkeleri ve bunların nasıl uygulanacağı ve uygulanacağı hakkında bilgi ediniyorsunuz.

Genel Bakış

Hizmet düzeyi hedefleri (SLO'lar), müşteri odaklı hizmet düzeyi göstergeleri (SLI) için ölçülebilir hedeflerdir. Müşterinizin iş veya altyapı iş yükü deneyimini ölçer ve işletmenin hizmet sağlayıcısının resmi olarak müzakere edilmiş bir hizmet düzeyi sözleşmesinde (SLA) veya tüm taraflar arasındaki resmi olmayan anlaşmada verilen sözleri karşılayıp karşılamadığını belirler.

Hizmet aracısı olarak, Microsoft'un Azure hizmetleri için hizmet düzeyi sözleşmelerinde tanımlandığı şekilde hizmetlerin güvenilirliğine olan bağlılığını kullanırsınız. Bu sayede yapay izleme, ağ bağlantısı ve güvenlik ve uyumluluk gibi hizmet zincirindeki sorumluluklarınıza odaklanabilirsiniz.

Terminoloji

Aşağıda bu terimlerin her birinin tanımları ve kısa bir açıklama yer almaktadır. Bu tanımlar Google'ın SRE El Kitabı'ndan alınmıştır.

Süre	Açıklama
Hizmet düzeyi sözleşmesi (SLA)	Genellikle bir hizmet sağlayıcısı ile müşteri arasındaki bağlama taahhüdü. Anlaşma genellikle SLO hedeflerini kaçırmanın sonuçlarını içerir. Hizmetin belirli yönleri, hizmet sağlayıcısı ile hizmet tüketicisi arasında kararlaştırılan kalite, kullanılabilirlik ve sorumluluklardır.
İzleme	Hizmetler ve sistemler hakkında nicel gerçek zamanlı veri toplama uygulaması.
Ölçümler	İlgili hizmet davranışını ölçer ve hizmetin geçerli işletim durumunu ölçmek ve davranışını ölçmek için işlenen ve toplanan hizmet düzeyi göstergelerine (SLI) toplanabilir. SLI'ler, bir hizmetin geçerli durumunun ana ve gerçek zamanlı göstergeleridir.
Günlükler	Kodla başlar ve bir kod yolunun veya gizli olayın tek tek yürütülmesiyle ilgili bilgileri raporlar. SLI'ler/SLO'lar tarafından ölçülen müşteri deneyimini ve hizmet güvenilirliğini etkileyen kök neden sorunlarını gidermeye ve belirlemeye yardımcı olmak için bu bilgileri kullanın.
Hizmet düzeyi hedefi (SLO)	Hizmet düzeyi göstergelerine (SLI) göre ölçülen ve bir hizmetin ne kadar iyi performans sergilediğiyle ilgili beklentileri ayarlayan hizmet düzeyi için bir hedef değer. SLO'lar özellikle uçtan uca müşteri deneyimini izler. İyi SLO'lar oluşturmak için genellikle istenen deneyimi tanımlayıp hizmet kodunu izleyerek bu deneyimi ölçer (ilgili SLI'leri toplar) ve müşteri beklentilerini nasıl karşılayıp karşılamayacağınız hedefini belirlersiniz.
Hizmet düzeyi göstergesi (SLI)	Hizmetin kalitesini veya güvenilirliğini ölçen ölçüm. En az dört yaygın SLI değerlendirilir: kullanılabilirlik, gecikme süresi, aktarım hızı ve hata oranı.
Kullanılabilirlik	Genellikle sistemin çalışır durumda ve işlevsel olduğu zamanların ölçülebilir veya gözlemlenebilir yüzdesini ifade eder. Kullanılabilirliği, bir veya daha fazla güvenilirlik sorunundan (ve yapılandırma değişiklikleri, uygulanan güncelleştirmeler ve daha fazlası ile ilgili diğer hata modlarından) etkilenen deneyimin sürekliliği için müşteriye yönelik bir hedef olarak ölçersiniz.
Hata bütçesi	SLO'nuzla ilgili kalan arabellek yüzdesi. Hata bütçeleri DevOps aracıdır ve BT, hizmet güvenilirliğini yenilik hızıyla dengelemek için kullanır.

SLO'ların amacı

SLO'lar, bulut iş yüklerinin geliştirme ve operasyonlarında aşağıdakiler dahil olmak üzere birçok temel amaca hizmet eder:

• Neredeyse gerçek zamanlı (NRT): Müşterinin deneyimlediği bir hizmetin durumunu NRT görünümüne sunmak.
• Bildirim alma süresini (TTN) azaltma: Müşterilere hizmet sorunlarının otomatik bildirimini sağlayarak bildirim alma süresini (TTN) önemli ölçüde kısaltın.
• Müşterilere birincil sinyal: Dağıtım işlemleri için birincil sinyal olarak davranarak sorun oluşması durumunda otomatik geri alma işlemi gerçekleştirerek daha az müşteriyi olası sorunlara maruz bırakarak.
• Değişiklik doğrulama: Değişikliklerin beklenen müşteri deneyimi iyileştirmesine ulaştığını doğrulamayı sağlayın.
• Öncelikleri belirleme: Ekiplerin özellik oluşturup oluşturmayacağını veya güvenilirlik üzerinde çalışıp çalışmayacağını anlamasına yardımcı olun.
• Hizmet durumu içgörüler: Hizmet durumuyla ilgili hedef ve müşteri odaklı tartışmaları etkinleştirin.
• Analiz süresini kısaltın: Odaklanmayı sorumlu hizmete yönlendirerek müşteri sorunlarını azaltma ve kök neden analizini (RCA) hızlandırın.
• Mimari bağımlılıklar: Hizmetler bağımlılıkları aldığında mimari kararlara önemli bir giriş görevi görür.
• Güven oluşturur: Ekipler arasında güven oluşturan sistem durumu ölçüleri hakkında paylaşılan bir anlayış sağlar.
• Saydamlığı getirin: İşlerimizi yürütmek için kullandığımız SLI'leri müşterilerimizin kullanımına sunun, böylece kendi SLI'lerini çalıştırabilir.
• Tek bölmeli cam: Hizmetler ve bağımlılıkları ve döküm siloları için yatay tek bir cam bölmesi etkinleştirin.

DevOps ve BT, mühendislik sürecinizi yönlendirmek için SLO'ları kullanarak Azure'da derledikleri veya geçirdikleri uygulama veya altyapı hizmetinin durumunu erken anlayabilir. Bu, daha sonra bu hizmetlerin güvenilirliği hakkında alınması gereken hem insan hem de otomatik kararları yönlendirmek için kullanılabilir. Mühendislik uygulamalarında bu dönüşüm, yakın dönemde bu hizmetlerin güvenilirliğini önemli ölçüde etkileyecektir.

SLO'ları tanımlama

SLO'nun amacı, müşteri açısından kaliteyi doğru ölçen net sinyaller elde etmektir. Her hizmet ekibi, hizmetin en önemli ölçülebilir ölçümleri için hizmet tüketicisi tarafından deneyimlenebilen izin verilebilen aralığı tanımlayan küçük bir Hizmet Düzeyi Hedefleri (SLO) kümesi oluşturur. SLO, bir hizmet tarafından yayılan ölçüm için tanımlanmış bir sayısal hedeftir. Hizmetin iyi durumda olup olmadığını belirlemek için bu hedefle ilişkili ölçümler izlenebilir.

Örneğin, iç zaman izleme web tabanlı uygulama için basitleştirilmiş bir SLO örneği aşağıda verilmiştir: Son 5 dakikadaki istekler 99. yüzdebirlik dilimde 1000 milisaniyenin altında sunulur.

Ölçümler, Hizmet Düzeyi Göstergeleri (SLI) olarak adlandırılan zaman serisi verilerinin toplamalarıdır. SLI'lerin toplandığı yer çok önemlidir. Yukarıdaki örnekte müşteri api kullanarak hizmetle etkileşime geçiyorsa sistem gecikme süresini ve istekleri işleme süresini ölçmek doğru SLI'lerdir. Bununla birlikte, müşteri bir web portalı kullanarak hizmetle etkileşimde bulunursa, isteğin toplam hizmet süresi web sayfasının JavaScript performansını da içermelidir.

Hizmet sahipleri için odak, aşağıdakileri belirlemektir:

• Hangi senaryolar müşteri açısından hizmet durumunun kritik göstergeleridir,
• Müşteri deneyimine mümkün olduğunca yakın olmaları için SLI'lerin nerede toplandığı ve
• Bu SLO'lar için SLO'lar ne olmalıdır?

SLO'lar, başarıyı yönlendirmek için aşamalı bir yaklaşımla tanımlanabilir veya doğrudan işletme tarafından belirlenir. Bir hizmet tarafından tanımlanan SLO'ları kullanarak bunları nasıl oluşturduğunuza ilişkin mimari kararlar alırsınız. Bu nedenle, hangi senaryoların ölçüleceğini ve hangi zaman diliminin ölçüleceğini dikkatle seçmek önemlidir. Özetlemek gerekirse, SLO aşağıdaki değerlerden oluşur:

• Bir SLI. Örneğin, yük dengeleyiciden ölçülen yeterince hızlı isteklerin oranı 400 ms'den azdır.
• Bir süre. Ölçümün ölçüldiği zaman aralığı.
• Bir hedef. Örneğin, belirli bir süre boyunca karşılamayı beklediğiniz toplam isteklere yönelik hızlı isteklerin hedef yüzdesi (%90 gibi).

SLO türleri

Sektörün farklı yerlerine bakarsanız iki tür SLO vardır:

• Hizmet odaklı SLO'lar - Bu SLO'lar, ekiplerin zaman içinde hizmet kalitesini kademeli olarak geliştirmek için tanımladıkları taktiksel hedeflerdir. Bunlar, mühendislik kilometre taşında ulaşılabilir pragmatik hedefler olacak şekilde tasarlanmıştır. Örneğin, bir hizmet şu anda %99,7 kullanılabilirliğe ulaşıyorsa, ekip bir sonraki çeyrekte %99,9 kullanılabilirliğe ulaşma hedefi belirleyebilir.

• Müşteri odaklı SLO'lar - Bu SLO'lar gelecekteki ideal durumu veya hedefi tanımlar. Bu noktada, müşterilerin beklentilerini tam olarak karşıladığınız için kaliteye daha fazla yatırım yapmak gereksiz kabul edilir.

Örneğin, müşteriniz çalıştırdığınız bir iş veya altyapı hizmetinin %99,99 kullanılabilirlik sağlamasını bekliyorsa ve hizmet şu anda yalnızca %99,8 kullanılabilirlik sağlıyorsa müşteri merkezli SLO hala %99,99'dur.

Doğru SLO'ları tanımlamak zaman alır. İlk adım, müşterilerinizle konuşmak ve kullanıcılarınızın hizmetten ne istediğini anlamak ve küçük bir gösterge seçimi türetmek ve belge oluşturmaktır. Hizmetinizi nasıl kullandıklarına ilişkin senaryoları ve toleransları ve işlerini başarıyla yürütmek için hizmetinizin neler sunması gerektiğini öğrenin. Bu genellikle yinelemeli bir deneyimdir ve beklentileri her koşulda %100 kullanılabilirlik istiyorum ve müşteri segmentleri arasındaki değişken beklentileri yöneterek gelir akışımızı etkilemez.

Yalnızca hizmet (veya hizmet örneği) durumuyla ilgili izleme yaklaşımları, spektrumun her iki ucundaki eksik müşteri deneyimi sorunlarına karşı savunmasızdır; hizmet durumu her zaman müşteri deneyiminin kalitesiyle bağıntılı değildir. Bunun nedeni, bir Azure PaaS ile SaaS hizmeti arasında farklı davranış özellikleri olması, bu Azure hizmetlerinin yapılandırması, kaynaklarının nasıl ve nerede (hangi bölge) dağıtıldığı ve özel kodunuzun/mantığınızın eklenmesidir ve bu da karmaşıklığı artırır.

SLO tanımlarken, bulut sağlayıcılarınızın SLA'nıza bağımlı olduğunu unutmamanız önemlidir. Hizmetlerinin her biri için belirtilen hizmet düzeyi sözleşmelerini hesaba katın. Azure için bkz . Çevrimiçi Hizmetler için Hizmet Düzeyi Sözleşmeleri (SLA)

SLI'leri nasıl tanımlarsınız?

SLI belirtimi, kullanıcılarınızın hizmetiniz için gecikme süresi veya kullanılabilirlik gibi belirli bir güvenilirlik boyutuyla ilgili beklentilerinin resmi bir bildirimidir.

Ölçüp toplamak için doğru ölçümleri seçerek basit bir başlangıç yapın ve anlamlı olmayan çok fazla ölçüm toplayarak bunu fazla karmaşık hale getirin. Tanımladığınız SLI'lerin müşteri deneyimiyle doğrudan bir ilişkisi olduğundan emin olun. Bu nedenle, yalnızca birkaç göstergeyle başlamak için kullanıcıların perspektifini anlamak önemlidir.

Hizmetiniz bellek veya CPU gibi bir şekilde kısıtlanmış bir kaynaksa, doygunluğu da mükemmel bir SLI olabilir. Ancak, kötü bir kullanıcı deneyimine doğrudan karşılık gelemediğinden doygunluk SLO olarak kullanılmamalıdır (bir hizmet yüksek bellek kullanımına sahip olabilir, ancak kullanıcılar etkilenmez).

En fazla üç gösterge oluşturmanızı öneririz. Üçten fazla gösterge nadiren önemli bir değer ekler. Çoğu zaman, çok fazla sayıda gösterge, birincil göstergelerin belirtilerini dahil ettiğiniz anlamına gelebilir. Trafik ve doygunluk, hizmet yükünü ve diğer hizmet göstergelerinin yorumlanmasını desteklediğinden bu üç ana göstergeye ek olmalıdır.

SLO'ları nasıl uygularsınız?

En önemli SLI'ler, müşterinizin bakış açısından hizmetinizi en net şekilde etkileyenlerdir. Birçok hizmet için gecikme süresi, aktarım hızı, hata hızı ve kullanılabilirlik dahildir. Hizmetinizde müşteri deneyimini etkileyen önemli noktalar varsa bu alanların SLI'leri de ölçülmelidir. Örneğin, bir mesajlaşma hizmetinin uçtan uca işleme gecikme süresi, müşteri deneyiminin doğrudan bir göstergesidir ve bir SLI kapsamında olmalıdır.

SLO örnekleri

İnsan Kaynakları, şirket içi zaman izleme web tabanlı uygulamasını modernleştirmek ve kurumsal BT yardımıyla Azure bulutunda barındırmakla ilgileniyor. Hizmetin kuruluştaki tüm kullanıcılara erişmeye devam etmesi için aşağıdakilerle ilgilenmelerini isterler:

• Kullanım raporları ve hizmeti zaman içinde kaç kullanıcının kullandığı.
• Kullanılabilirlik, performans, güvenlik ve uyumluluk (hizmet garantisi) gibi düzenli sistem durumu izleme.
• Hizmetin aylık maliyeti gibi maliyet.
• Siber güvenlik, Sıfır Güven bir güvenlik stratejisi izleyerek kaynaklara ve verilere erişimi denetleme açısından.

Yukarıdaki örneklerden gördüğümüz gibi, hizmet tasarımının erken aşamalarında tanımlamak için SLO/SLI kategorileri ve örnekleri gereklidir. Bu, oluşturduğunuz şirket içi hizmetlerden hiçbir farkı yok.

SLO Tabloları/SLI kategorileri

Aşağıdaki örnekler hiçbir şekilde kapsamlı bir liste değildir. Güvenilirlik ve bakım SLO'ları onlarca yıldır sistemlerin önemli bir özelliği olsa da siber güvenlik, kalite ve kullanıcı deneyimi ve maliyet için ölçüler içeren SLO'lar tanımlayabilirsiniz.

Hizmetler

Bir hizmet veya sistemin tipik üst düzey ölçüleri genellikle hizmet sözleşmelerinde birleştirilmiştir. Modern sözleşmelerin çoğu kullanılabilirliği anahtar SLO olarak ölçer ve kimlik doğrulama belirteçleri, posta kutuları veya depolama hesapları gibi önemli iş yükü öğelerine veya üretim birimlerine göre basit kapalı kalma sürelerini kullanır.

Kategori	Açıklama	Örnek
Kullanılabilirlik	Basit kapalı kalma süresi veya Bakım veya operasyonel kullanılabilirlik arasındaki ortalama süre (MTBM/(MTBM+MDT))	Aylık dönemde %99,99
Kapasite	Yeterli, maksimum veya en iyi iş ve hizmet performansı, aktarım hızı, depolama, kişiler, bant genişliği, talep, kaynaklar ve hizmet işlevleri sağlayın. Tetikleyici olarak görev yapmak için iş gücü ve zaman sınırlarını içerir.	Kullanım Yüzdesi (CPU, depolama, bellek, gecikme süresi, aktarım hızı, ölçeklendirme)
Güvenlik	İşletmeye, varlıklara ve verilere zarar verebilecek veya zarar verebilecek etkin tehditler ve güvenlik açıkları (iç ve dış).	HAFNIUM Tehdidinin Algılanması
Uyumluluk	Güncelleştirmeler, hizmet düzeyleri, sağlamlaştırma uyumluluğu, istenen yapılandırma kayması	Tüm varlıklarda %99,5 hizmet güncelleştirmeleri
Süreklilik	Büyük olağanüstü durumlara ve dış olaylara karşı hayatta kalma ve kurtarma olanağı.	Zaman (yeniden değişim)
Hizmet Kalitesi (QoS)	Kullanıcıların zaman içindeki gerçek deneyiminin özellikleri.	Teams arama kalitesi - alınan paket kaybı < %2

Güvenilirlik

Güvenilirlik, klasik SLO, işletim süresini veya kullanılabilirliği artırmak için sistem, hizmet, kaynak veya bileşenlerin hataya ve yük devretmeye karşı güvenilirlik, dayanıklılık ve kalite derecesini ifade eder ve yönetim çabası hataya (daha fazla yedeklilik oluşturma veya içerik teslim ağı ekleme gibi) uygulanır. Bu, SLO'ları ölçmek için kullanılan verilerin doğruluğu, doğruluğu, bütünlüğü ve güvenilirliği anlamına da gelebilir. Bu, bir sistemin istenen işlevi sıcaklık stresi gibi belirli koşullar altında gerçekleştirmesi için klasik olasılık anlamına gelebilir. Dayanıklılık ayrıca ölçeklendirme, soğutma, yük dengeleme, kurtarma, öngörülemeyen talep, ciddi stres altında düşük performans ve daha büyük felaketlerde süreklilik için tasarım (genellikle ayrı bir SLO) gibi uyarlanabilirlik sağlayan yerleşik tasarım faktörleri veya özellikleri içerir.

Kategori	Açıklama	Örnek
Hata Oranı	Toplam çalışma saatleri içindeki hata sayısı	973 saat içinde 5 hata .00514
Hata Arasındaki Ortalama Süre (MTBF)	MTBF, hata oranının tersidir	194,6 saat

Devamlılık

Kullanılabilirlik ölçümüne ulaşılabilmesi için olay ve sorun yönetimi gibi BT hizmet yönetimi süreçleri için destek SLO'larını ve güvenilirlik SLO'larını birleştirin.

Kategori	Açıklama	Örnek
Hizmet Olayı Performansı	Kategoriye, ürüne veya önceliğe göre.	Olay yaşam döngüsünün her aşaması için zaman ve maliyet ölçümleri.
Güvenlik Olayı Performansı	Kategoriye, ürüne veya önceliğe göre.	Olay yaşam döngüsünün her aşaması için zaman ve maliyet ölçümleri.
Bileşen Ortalama Onarım Süresi (MTTR)	Olay algılamadan geri yükleme veya düzeltmeye kadar.
Bakım Arasındaki Ortalama Süre (MTBM)	Normal üretim çalışmalarının gerçekleştiği önleyici eylemler de dahil olmak üzere tüm bakım eylemleri arasındaki ortalama veya ortalama süre.	Bkz. Bakım Gecikme Süresi
Bakım Gecikme Süresi (MDT)	Lojistik ve idari gecikme dahil olmak üzere algılamadan kurtarmaya kadar olan toplam süre.	Donanımı sipariş, sevkiyat ve kurulum içerecek şekilde değiştirme zamanı.

Müşteri deneyimi

Kategori	Açıklama	Örnek
Aktarım hızı	Bir sisteme zaman içinde yerleştirilen iş yükünün veya üretken yükün miktarı, hızı veya hızı.	Zaman birimi başına işlemler.
Hata oranı	Yüzde olarak toplam hata sayısı.	Güvenlik olayları yüzdesi
Gecikme süresi	Girişten çıkışa, işin bir işlem üzerinden veya uygulamadan kullanıcıya doğru hareket etme zamanı veya gecikmesi ölçüsü.	Ortalama saniye.

Diğer

Kategori	Açıklama	Örnek
Maliyet	Hizmet, bileşen veya zamana göre harcamaları, faturalamayı ve faturaları ölçün.	Sermaye Gideri veya işletme gideri
Kapsam	Yönetim altındaki bileşenlerin, sistemlerin ve hizmetlerin yüzdesi (uyumluluk)	Uyumluluk
Akış güvenilirliği	Sinyal hataları, bağlayıcılar, değişiklikler ve daha fazlası.	Görev açısından kritik şirket verilerindeki değişiklikleri izleme.
Üretkenlik	Görevleri verimli bir şekilde gerçekleştirmek için verimlilik	İş gücü, çalışana göre zaman, analist üretkenliği.

Dikkat edilmesi gereken noktalar

• Erişimin sağlanmasını sağlayın. Kuruluştaki yöneticilere ve diğer kişilere, çoğaltmayı önlemek için Azure İzleyici'de veya azure saas ve PaaS başta olmak üzere diğer Azure hizmetlerinden sağlanan görselleştirmelere erişim izni verildiğinden emin olun.

• İzleme kapsamının veya toplam varlık görünürlüğünün sağlanmasını sağlayın. Yönetilen ve güvenli hale getirilmesi gereken tüm varlıklar için aracıların, yayılan günlüklerin, tabloların ve sorguların yanı sıra SLO'larda gerçekçilik sağlamak için kapsam içindeki "kör noktaları" veya boşlukları belirleyin.

• Doğru tüketicilerin önünde doğru verileri alın. SLO'ların ve SLI'lerin tüketicilerinin, verilerden elde edilen bilgileri kullanarak güven oluşturmak ve kararlara yol göstermek için temel alınan verileri yorumlayabildiğinden emin olun.

• Makul sözler ver. Özellikle maliyet yönetimi gerekli olduğunda SLO'ları hedef olarak ayarlarken, gerçek sistem performansının fazla performans göstermediğinden veya yetersiz teslim olmadığından emin olun veya müşteri beklentilerini yönetmek için hedefi ayarlayın.

• Öngörülemeyen dış olayları hesaba ekleyin. Hava durumu, güç kesintileri veya olağanüstü durumlar gibi denetiminiz altında olmayan olayları hesaba katmak için süreklilik planları ve risk değerlendirmeleri geliştirin.

• Değişiklik Hesabı. SLO'ların hizmette yapılan değişiklikleri veya destek personelindeki azalmalar gibi teknik güvenilirlik, aktarım hızı, kalite ve bakım değişikliklerinin hesaba katdığından emin olun.

• Dengeli bir SLO kümesi sağlayın. Hizmet veya sistem üzerinde dengeli veya 360 derecelik bir perspektif ve güvenilirlik odaklı bir dizi SLO olduğundan emin olun.

Sonraki adımlar

Doğru verileri toplama