SLI, SLO ve hata bütçesi belirleme: kullanıcı beklentisinden hedefe

SLI, SLO ve SLA: her kavramın ayrı işi

SLI, hizmetin seviyesini ölçen titizlikle tanımlanmış bir göstergedir: istek gecikmesi, hata oranı, işlem hacmi gibi. SLO, bu göstergenin hedef değeri ya da aralığıdır. SLA ise hedefin tutulup tutulmamasının sonuçlarını içeren, kullanıcıyla yapılan açık ya da örtük sözleşmedir; sonuçlar çoğunlukla mali olur, örneğin iade ya da ceza. Google SRE kitabının pratik ayrımı şudur: hedefi kaçırmanın açık bir sonucu yoksa elinizde bir SLO vardır, SLA değil.

Hata bütçesi bu kavramların çalışma biçimidir. Mükemmelliği hedeflemek gerçekçi değildir ve yeniliği yavaşlatır. Bu yüzden SLO'nun izin verdiği, hedefin tutulamama payı hata bütçesi olarak ele alınır. Bütçe yeterince doluysa yeni sürüm çıkılır; hızla tükeniyorsa ekip özellik yerine güvenilirliğe yönelir. SRE ekipleri genelde SLA'nın iş koşullarını belirlemez, ama SLA'nın dayandığı SLO'ların ölçülebilir olmasına yardım eder.

SLI seçmek: kullanıcının fark ettiği şeyi ölç

En sağlam başlangıç noktası, kolay ölçülebilen değil kullanıcının önem verdiği şeydir. Önce hizmetin kritik kullanıcı yolculuklarını listeleyin: bir ödeme akışı, bir arama, bir dosya yükleme. Sonra her yolculuk için kullanıcıyı mutsuz eden başarısızlık biçimini adlandırın: yavaş yanıt, hata, eksik ya da yanlış veri.

Hizmet türüne göre tipik göstergeler şöyle eşleşir:

• Kullanıcıya hizmet veren sistemler: erişilebilirlik, gecikme, işlem hacmi.
• Depolama sistemleri: gecikme, erişilebilirlik, dayanıklılık.
• Büyük veri hatları: işlem hacmi ve uçtan uca gecikme.
• Tüm sistemler: doğruluk.

Göstergelerin sayısı az tutulur; çok gösterge dikkati dağıtır, çok az gösterge ise bazı davranışları denetimsiz bırakır. Erişilebilirlik için yaygın biçim, geçerli isteklerin içinde başarıyla yanıtlananların oranıdır: iyi olay sayısı bölü geçerli olay sayısı. Gecikme için ortalama yerine yüzdelik dilimler (örneğin ortanca ile kuyruk) kullanılır, çünkü ortalama ani yükselmeleri ve uzun kuyruğu gizler.

Ölçüm noktasını ve tanımı netleştirmek

Aynı gösterge, nerede ölçüldüğüne göre farklı sonuç verir. Sunucu tarafında izleme sistemleriyle ya da günlük analiziyle ölçmek yaygındır; ama istemci tarafı yavaş betikler gibi sorunlar yalnızca kullanıcı cihazından görülebilir. Bir göstergeyi tanımlarken şunları yazın: hangi istekler sayılır, hangi bölgeler dahildir, toplama aralığı nedir, veri hangi kaynaktan gelir, gecikme hangi anda sona erer sayılır (örneğin son baytın alınması).

Bu bilgiler bir şablonda toplanırsa her yeni hizmette sıfırdan düşünme gerekmez ve ekipler aynı ölçüyü aynı biçimde okur. Tanımın belirsiz kalması, SLO toplantılarında hedefin tutulup tutulmadığı tartışmasına yol açar; ölçüm kuralı baştan yazılırsa bu tartışma ortadan kalkar.

Hedef koymak: mevcut performansı değil ihtiyacı esas al

SLO belirlerken sık yapılan hata, bugünkü performansı hedef olarak kilitlemektir. Bu, ekibi gerekmeyen kahramanlıklara ya da yeniden tasarıma zorlayabilir. Doğrusu, kullanıcı ihtiyacından geriye doğru çalışmaktır: kullanıcı hangi gecikmeye kadar fark etmeden devam eder, hangi hata oranında güvenini kaybeder?

Google'ın önerileri: SLO sayısını küçük tutun, her biri öncelik tartışmasında savunmaya değer olsun. Mutlak değerlerden kaçının; sınırsız ölçeklenme ya da kusursuz erişilebilirlik hem gerçekçi değil hem pahalıdır. Hedefi gevşek başlatıp zamanla sıkılaştırın, çünkü ulaşılamayan bir hedefi sonradan gevşetmek, temkinli bir hedefle başlamaktan daha zararlıdır. İş yüklerini ayırın: toplu işlem istemcilerinin işlem hacmi, etkileşimli istemcilerin gecikme hedefi farklı olabilir. Dış söze verilen SLA için içeride daha sıkı bir hedef tutmak, sorunları erken düzeltme payı bırakır.

Hata bütçesini hesaplamak ve kullanmak

Hata bütçesi, hedefin tamamlayıcısıdır: izin verilen başarısızlık payı = bir eksi hedef oranı. Örneğin hedef bir ay içinde başarılı isteklerin belirli bir oranı ise, geri kalan oran o ay harcayabileceğiniz bütçedir. Hesap, SLI'ı tanımladığınız aynı olay sayılarıyla yapılır: bütçe, geçerli olay sayısı çarpı izin verilen hata oranıdır.

Bütçe kısa pencerelerde (günlük ya da haftalık) izlenir, yönetim değerlendirmeleri ise daha uzun dönemlerde yapılır. Karar kuralları önceden yazılırsa çatışma çıkmaz. Örneğin: bütçe sağlıklıysa özellik sürümleri sürer; bütçe tükeniyorsa yeni özellik yayını durdurulur, güvenilirlik işleri öne alınır. Bu kurallar SRE ve ürün geliştirme ekibinin ortak mutabakatıyla belirlenir; kural tek taraflı konursa ilk tartışmada işlemez. Hedefin çok üzerinde performans da sorun olabilir: kullanıcılar bu seviyeye güvenip yedeksiz bağımlılık kurabilir.

Örnek akış ve kontrol listesi

Kurgusal bir örnek: bir e-ticaret şirketi ödeme hizmeti için kullanıcı yolculuğunu çıkarır. Kritik adım ödemenin başarıyla tamamlanmasıdır. SLI olarak ödeme isteklerinin başarıyla yanıtlanma oranı ile yanıtın verilme süresinin kuyruk yüzdelik dilimi seçilir. Ölçüm, yük dengeleyici günlüklerinden yapılır ve sağlık kontrolü istekleri dışarıda bırakılır. Ekip, geçmiş verilere bakıp ama onlara kilitlenmeden, kullanıcı şikâyetlerinin başladığı eşiğin üzerinde bir SLO yazar. Bütçe tükenme hızı panoda izlenir ve ilgili uyarılar bu hıza bağlanır.

Kontrol listesi:

• Her SLI bir kullanıcı yolculuğuna bağlı mı?
• Ölçüm kaynağı, kapsam ve hesap formülü yazılı mı?
• SLO'nun gerekçesi (kullanıcı ihtiyacı) yazılı mı?
• Bütçe tükenince ne olacağı kuralı ürün tarafıyla birlikte onaylandı mı?
• SLO'lar belirli aralıklarla gözden geçiriliyor mu?

Sık yapılan hatalar

En sık görülen hata, çok sayıda SLO koyup hiçbirini kararlarda kullanmamaktır. Diğeri, ortalama gecikmeye güvenip kuyruk gecikmesini görmemektir. Bir başka hata, SLO ile SLA'yı karıştırıp içeride kullanılan hedefi dışarıya taahhüt etmektir; yaygın yayımlanmış anlaşmaları değiştirmek zordur, bu yüzden dış taahhütler temkinli olmalıdır.

İzleme uyarılarını doğrudan SLO'ya bağlamamak da yaygındır. Çağrı sistemi, kullanıcı gördüğü semptomlar SLO'yu tehdit ettiğinde çalmalıdır; her altyapı dalgalanmasında çalan uyarılar nöbet kalitesini düşürür. Son olarak, SLO'yu bir kez yazıp bırakmak: ürün, trafik ve kullanıcı beklentisi değiştikçe hedefler de yeniden değerlendirilmelidir.

Bu beceri Mindset programlarında nerede çalışılır

Site Reliability Engineering (SRE) Pratikleri programında SLI SLO SLA Çerçevesi modülü, SRE Kültürü programında ise Servis Düzeyi Hedefleri ve Göstergeleri ile Hata Bütçesi ve Risk Yönetimi modülleri bu konuya ayrılmıştır. İçerik, altyapı ve platform mühendisleri, ürün yöneticileri ve güvenilirlik hedefini yönetim düzeyinde konuşması gereken ekip liderleri için uygundur; kurumsal ekipler ürün ve operasyon tarafını aynı ölçü dilinde buluşturmak için bu çerçeveyi ortak çalışabilir.