SLI vs SLO vs SLA: farklar ve nasıl kurulur

Kısaca: SLI ne ölçtüğünüzdür, SLO hangi hedefe ulaşmak istediğinizdir, SLA sözleşmesel taahhüttür. Google SRE kitabındaki bu terimler, web servisi işletmesinde en çok kullanılan ifadeler arasındadır - ve sıkça karıştırılır.

SLI - Service Level Indicator

Servis güvenilirliğini ölçtüğünüz somut metrik. Örnekler:

• son 30 günde HTTP 2xx veya 3xx ile biten isteklerin %'si
• 500 ms altında response time olan isteklerin %'si
• doğru teslim edilen emaillerin (delivered, bounced değil) %'si
• başarılı ödeme işlemlerinin tüm denemelere oranı

İyi bir SLI'nin temel özellikleri:

• Ölçülebilir - somut bir veri toplama yöntemi vardır
• Kullanıcı için ilgili - iç teknik bir metrik değil, gerçek müşteri deneyimini yansıtır
• Spesifik - "uptime" çok belirsiz; "5 dakikalık pencerede /api/v1/orders'a başarılı isteklerin %'si" bir SLI'dır

SLO - Service Level Objective

İç hedef, SLI'nin hangi değere ulaşması gerektiği. Bir zaman penceresi üzerinde yüzde olarak ifade edilir.

Örnekler:

• "/api/orders'a isteklerin %99,9'u 30 gün içinde HTTP 2xx ile bitmeli"
• "İsteklerin %95'i 7 gün içinde 200 ms altında response time'a sahip olmalı"
• "Takvim ayında ödeme işlemlerinin %99,5'i başarıyla geçer"

SLO SLA'dan yüksektir, böylece bir buffer'ınız olur. SLA %99,9 diyorsa, iç SLO örneğin %99,95 olmalı - beklenmedik olaylar için rezervi olsun diye.

SLA - Service Level Agreement

Müşterilere karşı sözleşmesel taahhüt. SLO'yu tutmadığınızda ne olacağını tanımlar - tipik olarak:

• Service credits - aylık ücretin bir kısmını iade edersiniz (ihlalin büyüklüğüne göre %10-50)
• Termination rights - müşteri sözleşmeyi yaptırımsız feshedebilir
• Reporting yükümlülüğü - postmortem ve uptime raporlarını yayınlamalısınız

SLA'nın yasal sonuçları vardır. SLO bir iç hedeftir.

Error budget

SRE'nin temel kavramı: SLO'yu ihlal etmeden karşılayabileceğiniz downtime.

Örnek: SLO = 30 günde %99,9 uptime. Bu %0,1 izin verilen downtime demek. 30 günün %0,1'i = ayda 43 dakika. Bu sizin error budget'ınız.

Pratik sonuçlar:

• Ayda zaten 35 dakika downtime varsa, "SLO ihlali"ne 8 dakika kalır. Ekip sonraki deploylar için muhafazakar olmalı.
• 5 dakika downtime varsa, riskler için 38 dakika budget'ınız var - daha agresif değişiklikler, A/B testler, deneyler yapabilirsiniz.
• Error budget inovasyon hızı (dev team) ile stabilite (ops team) arasındaki çatışmayı çözer. Her ikisi de aynı sayıyı takip eder.

Pratik örnek: e-ticaret API

SLI: Son 30 günde 1 dakikalık bucket'larda ölçülen POST /api/checkout'a 2xx ile biten HTTP isteklerinin %'si.

SLO: Rolling 30 günlük pencerede ≥ %99,9 başarılı istek.

SLA (Enterprise müşterileri için):

• Takvim ayında ≥ %99,5 uptime
• %99,0-99,5'te = aylık ücretten %10 credit
• %95,0-99,0'da = %25 credit
• < %95,0'te = %50 credit + sözleşmeyi feshetme hakkı

Error budget: %99,9 SLO ay başına 43 dakika downtime budget anlamına gelir. SLA ekonomik cezadan önce daha büyük buffer sağlar.

Özet: tablo

Pratik hatalar

• Çok iddialı SLO. %99,99, birden fazla bölgede active-active redundancy gerektirir. Küçük bir şirket için gerçekçi değil.
• Sadece uptime SLO. Web "up" olabilir ve hâlâ kullanılamaz. Latency SLO ve error rate SLO ekleyin.
• Otomatik ölçüm olmadan SLA. Manuel hesaplanmış SLA raporu güvenilir değildir. Otomatikleştirilmiş uptime tracking'e yatırım yapın.
• Sonuç olmadan SLO. SLO ihlali kimseyi ilgilendirmiyorsa, kimse umursamaz. Deploy freeze, on-call escalation vb. bağlayın.

Sonuç

SLI/SLO/SLA framework'ü kağıt bürokrasi değildir - engineering ekibinin business stakeholder'lar ile güvenilirlik hakkında konuştuğu dildir. Bu terimler olmadan stabilite tartışması öznel hale gelir ("webimiz dengesiz"). Onlarla sayısaldır ("son 30 günde %99,87 SLI'ya ulaştık, bu %99,9 SLO'muzun altında - işte aksiyon planı").

SLI'yı gerçek zamanlı ölçün

ePulz.io 30/90/365 günlük rollup ile tarihsel uptime kaydı sağlar. SLO reporting'in temeli.

İzlemeyi başlat →