SLO
Hizmet Seviyesi Hedefi
Kısaca
SLO, bir hizmetin ölçülebilir güvenilirlik hedefidir (örneğin 30 günde isteklerin %99,9'unun başarılı olması) ve yeterince güvenilirin ne olduğunu belirler.
SLO nedir?
Hizmet seviyesi hedefi ya da kısaca SLO, bir hizmetin ne kadar iyi performans göstermesi gerektiğine dair, bir zaman dilimi boyunca sayıyla ifade edilen dahili bir hedeftir. Tipik bir SLO şöyle okunur: ödeme isteklerinin %99,9'u 300 milisaniye içinde başarılı olacak; 30 günlük kayan pencere üzerinden ölçülür. SLO'lar site reliability engineering'den gelir ve ekiplere yeterince iyi güvenilirliğin ortak, nesnel bir tanımını verir.
Her SLO, gerçek ölçüm olan bir hizmet seviyesi göstergesine (SLI) dayanır; örneğin başarılı isteklerin tüm isteklere oranı ya da bir eşikten hızlı yanıtların payı. SLO bu gösterge için hedefi belirler ve %100'e kalan boşluk hata bütçesidir: %99,9 hedefiyle hizmet zamanın %0,1'inde başarısız olabilir; bu, 30 günde yaklaşık 43 dakikalık kesintiye denk gelir. Bütçe çok hızlı tükeniyorsa ekipler uyarı alır; tükenirse riskli sürümleri duraklatıp güvenilirlik çalışmasına yatırım yaparlar.
SLO, aylık bir harcama bütçesi gibi çalışır: hiçbir şey harcamamayı hedeflemezsiniz, bir sınır üzerinde anlaşır ve ona yaklaştığınızda ayar yaparsınız. %100'ü hedeflemek neredeyse hiçbir zaman doğru değildir; çünkü her ek dokuz çok daha fazla çaba gerektirir ve kullanıcılar, özellikle kendi ağları ve cihazları bundan daha sık başarısız olduğunda, farkı anlayamaz. SLO'lar oturum açma, arama ya da ödeme yapma gibi kullanıcıya dönük yolculuklar için belirlenir ve site yavaş hissettiriyor gibi belirsiz şikâyetleri bir ekibin takip edebileceği sayılara dönüştürür.
SLO'lar sıklıkla SLA'larla karıştırılır. Hizmet seviyesi sözleşmesi (SLA), müşterilere belirli bir hizmet seviyesini vaat eden ve tutulmazsa iade gibi yaptırımlar belirleyen bir sözleşmedir; SLO ise dahili bir hedeftir. SLO'lar genellikle herhangi bir SLA'dan daha katıdır; böylece ekip, sözleşmesel bir vaat çiğnenmeden önce sorunları fark edip düzeltir.
Önemli noktalar
- SLO, bir zaman penceresi boyunca bir güvenilirlik ölçümü için hedef değerdir.
- Ölçümün kendisine SLI denir; örneğin başarılı isteklerin payı.
- İzin verilen hata, yani %100 eksi SLO, hata bütçesidir.
- SLA yaptırımları olan harici bir sözleşmedir; SLO dahili ve genellikle daha katı bir hedeftir.
- %100 hedefleri gerçekçi değildir ve gereksiz yere pahalıdır.
Örnek
# SLO: 99.9% of requests succeed over a 30-day window
slo = 0.999
minutes_in_window = 30 * 24 * 60 # 43,200 minutes
error_budget = (1 - slo) * minutes_in_window
print(f"Allowed downtime: {error_budget:.1f} minutes") # 43.2 minutes
# 30 minutes of outages have already happened this month
remaining = error_budget - 30
print(f"Budget left: {remaining:.1f} minutes") # 13.2 minutes
if remaining < 0.5 * error_budget: # more than half is already spent
print("Freeze risky releases and focus on reliability")Sık sorulan sorular
SLI, SLO ve SLA arasındaki fark nedir?
SLI ölçümdür, örneğin başarılı isteklerin yüzdesi. SLO bu ölçüm için 30 günde %99,9 gibi bir hedeftir; SLA ise müşterilere belirli bir hizmet seviyesi vaat eden ve karşılanmazsa yaptırımlar belirleyen bir sözleşmedir.
Hata bütçesi (error budget) nedir?
Hata bütçesi, bir SLO'nun izin verdiği güvenilmezlik miktarıdır ve %100 eksi hedef olarak hesaplanır. %99,9'luk aylık bir erişilebilirlik SLO'su yaklaşık 43 dakikalık kesinti bütçesi verir; ekipler bunu riskli sürümlere ve deneylere harcayabilir.
Bir SLO kaç dokuz içermeli?
Bu, kullanıcıların neye ihtiyaç duyduğuna ve bağımlı olunan servislerin güvenilirliğine bağlıdır. Birçok web servisi %99,9 ya da %99,95 kullanır; %99,99 ise ayda yalnızca yaklaşık 4 dakikalık kesintiye izin verir ve yedeklilik ile otomasyona çok daha fazla yatırım gerektirir.
Sık karşılaştırılanlar
İlgili sayfalar
- Site Reliability EngineeringDevOps ve Bulut, s. 48Site reliability engineering, operasyona yazılım mühendisliğini uygulayan ve hizmetleri otomasyon ile ölçülebilir hedeflerle güvenilir tutan bir disiplindir.
- GözlemlenebilirlikDevOps ve Bulut, s. 22Gözlemlenebilirlik, çalışan bir yazılım sisteminin içinde olup biteni log, metrik ve trace verilerini toplayıp analiz ederek anlayabilme yeteneğidir.
- MetriklerDevOps ve Bulut, s. 33Metrikler, bir sistemden zamanla toplanan istek oranı, hata oranı ve CPU kullanımı gibi sayısal ölçümlerdir; panolar, uyarılar ve planlama için kullanılır.
- Yüksek ErişilebilirlikYazılım Mimarisi, s. 48Yüksek erişilebilirlik, bir sistemin, çoğunlukla yedeklilikle tek hata noktalarını ortadan kaldırarak neredeyse her zaman çalışır durumda kalabilmesidir.
- PostmortemDevOps ve Bulut, s. 40Postmortem, bir olaydan sonra yazılan; ne olduğunu, neden olduğunu ve tekrarlanmaması için ekibin neyi değiştireceğini açıklayan yazılı bir incelemedir.
- GecikmeAğlar, s. 9Gecikme, bir istek ile yanıtın başlaması arasında geçen süredir; genellikle milisaniyeyle ölçülür ve bir uygulamanın ne kadar hızlı hissettirdiğini belirler.
- SLADevOps ve Bulut, s. 49SLA (service level agreement), sağlayıcının müşterilerine %99,9 erişilebilirlik gibi hizmet seviyesi ve karşılanmazsa ne olacağına dair verdiği taahhüttür.
Bu sayfada bir hata ya da eksik mi gördünüz?Düzeltme önerin