1. GİRİŞ

Modern yazılım sistemlerinde güvenilirlik yalnızca teknik bir hedef değildir; aynı zamanda iş başarısının kritik bir parçasıdır. Hizmet düzeyi yönetimi (Service Level Management) kavramı bu nedenle hem mühendislik hem de iş ekipleri tarafından konuşulmaktadır. SLO (Service Level Objective), SLA (Service Level Agreement) ve SLI (Service Level Indicator) üçlüsü, hizmetin beklentilerini, ölçüm yöntemlerini ve taahhütleri açıkça ayıran terimlerdir. Bu makale; SLO, SLA ve SLI'leri derinlemesine ele alır, birbirlerine nasıl bağlı olduklarını, pratikte nasıl tanımlanıp uygulandıklarını ve operasyonel etkilerini teknik bir bakış açısıyla açıklar.

Neden bugün önemli?

• Bulut‑native, mikroservis ve sürekli dağıtım pratikleri sistem davranışını daha dinamik hale getirdi; güvenilirliği ölçülebilir kılmak hayati.
• İş paydaşları uptime, latency ve error rate gibi konularda net beklenti istiyor; SLO/SLA bu beklentileri standartlaştırır.
• Observability (metrics, logs, traces) olgunlaştıkça SLI tanımları teknik olarak uygulanabilir hâle geldi.

Kimler için önemli?

• SRE ve platform mühendisleri — servis güvenilirliğini ölçmek, error budget yönetmek ve incident süreçlerini SLO odaklı kılmak için.
• Ürün yöneticileri ve iş sahipleri — kullanıcı deneyimini nicel olarak tanımlamak ve ticarî taahhütlerle hizalamak için.
• Teknoloji yöneticileri — SLA sözleşmeleri, uyumluluk ve müşteri taahhütleri için risk ve maliyet yönetimi yapmak üzere.

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

• SLI (Service Level Indicator): Bir hizmetin performansını veya güvenilirliğini ölçen nicel metriktir. Örneğin: isteklerin %99.9'u için 200ms altında cevap verilmesi ya da hata oranı 0.1% altında olması.
• SLO (Service Level Objective): SLI için hedeflenen eşik veya performans değeridir. Örneğin: 30 günlük pencere içinde başarılı istek oranı %99.95 olması hedeflenir.
• SLA (Service Level Agreement): Genellikle müşteri ile yapılan resmi sözleşme; belirlenen SLO'lar ihlal edildiğinde uygulanacak tazminatlar, kredi veya yasal yaptırımları içerir.

2.2 İlişki ve hiyerarşi

SLI → SLO → SLA şeklinde bir hiyerarşi izlenir. SLI, ham veriyi verir; SLO bu veriye dayalı hedefler koyar; SLA ise bu hedeflerin işletme‑tarafından taahhüt edilen hukuki veya ticari versiyonudur. Pratikte SLO, SLA'nın teknik altyapısıdır — SLA'nın operasyonel uygulanabilir olması SLO'ların gerçekçi tanımlanmasına bağlıdır.

2.3 Terminoloji ile sık karışanlar

• Uptime: Service'in erişilebilir olduğu süre — çoğu kez bir SLI olarak kullanılabilir ama tek başına yeterli olmayabilir.
• Availability vs Reliability: Availability genelde erişilebilirlik yüzdesini, reliability ise daha geniş anlamda hatasız çalışma ve davranış tutarlılığını ifade eder.
• Error Budget: SLO tarafından izin verilen kabul edilebilir başarısızlık oranı; organizasyonun yenilik hızını ve risk toleransını yönetir.

3. NASIL ÇALIŞIR? — TEKNİK UYGULAMA VE MÜHENDİSLİK DETAYLARI

3.1 SLI seçimi: hangi metrikler kullanılmalı?

SLI seçimi iş etkisini doğrudan yansıtmalıdır. Yüksek cardinality, ölçüm maliyeti veya PII içermeme gibi pratik kısıtları göz önünde bulundurarak SLI seçilmelidir. Yaygın SLI türleri:

• Latency: P95, P99 gecikme süreleri — kullanıcı deneyimini doğrudan etkiler.
• Availability / Success rate: Başarılı istek yüzdesi (HTTP 2xx gibi).
• Error rate: Hata / toplam istek oranı.
• Throughput / Capacity: İşlem hacmi ve arıza toleransı eşiği.
• Durability / Data correctness: Veri kaybı veya tutarsızlık riskini ölçen metrikler.

3.2 SLO tanımı: pencere, hedef ve tolerans

Bir SLO üç bileşeni içerir: hedeflenen SLI eşiği, değerlendirme penceresi (rolling window) ve ölçüm yöntemi. Örnek: "30 günlük rolling window içinde isteklerin %99.95'inin 300ms altında cevaplanması". Değerlendirme penceresi SLO'nun anlamını belirler — kısa pencereler çok dalgalı, uzun pencereler ise olayı gizleyebilir.

3.3 Error budget ve burn rate yönetimi

Error budget = 1 − SLO. Örneğin SLO %99.9 ise error budget %0.1'dir. Burn rate, belli bir zamanda error budget'in ne kadar hızlı tüketildiğini gösterir. Eğer burn rate yüksekse otomatik veya operasyonel kısıtlar (feature rollout durdurma, kanaryaları durdurma) devreye alınmalıdır. Error budget, iş ve mühendislik arasında karar mekanizması sağlar: yüksek bütçe → daha hızlı deploy; düşük bütçe → stabilite öncelikli.

3.4 Ölçüm ve instrumentation

SLI'leri güvenilir şekilde ölçmek için uygulama katmanında doğru instrumentation gereklidir. OpenTelemetry, Prometheus, application logs ve traces birlikte kullanılarak tutarlı SLI hesapları yapılabilir. Önemli pratikler:

• Span/trace ve correlation id'leri loglara ekleyin; hata veya yüksek latency tetiklerinde ilgili trace'leri bulmak kolaylaşır.
• Metric aggregation için uygun bucketlar ve histogramlar kullanın; percentile hesaplarını client‑side değil server‑side yapmak daha güvenilirdir.
• Sampling stratejilerini SLI hesaplamasını bozmayacak şekilde tasarlayın (ör. errors için sampling oranını artırma).

3.5 SLO izleme ve alarm

SLO'lar doğrudan alert trigger'ı olmamalıdır; bunun yerine error budget burn rate veya SLO'nin yakınsamasına göre alarm kurmak doğru yaklaşımdır. Bu, gürültüyü azaltır ve on‑call ekibinin önem sırasına göre müdahale etmesini sağlar.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Netflix — SLO odaklı culture

Netflix benzeri organizasyonlarda SLO'lar operasyonların merkezinde yer alır. Error budget politikaları release süreçlerini doğrudan etkiler; örneğin hata bütçesi tükenirse yeni özelliklerin üretime alınması durdurulur. Bu sayede reliability ve hız arasında bilinçli trade‑off yönetimi sağlanır.

4.2 Fintech — SLA ve regülasyon

Finans sektöründe SLA'lar genellikle müşteri sözleşmeleriyle doğrudan ilişkilidir ve hukuki sonuçlar taşır. Bu yüzden SLO'ların gerçekçi tanımlanması ve SLI ölçümlerinin doğrulanması (auditability) kritik öneme sahiptir. Ayrıca veri korunması ve forensics gereksinimleri SLI seçimini etkiler.

4.3 SaaS ürünleri — tiered SLA'lar

Birçok SaaS sağlayıcısı farklı fiyat ve taahhüt seviyeleri için tiered SLA sunar. Örneğin ücretsiz katman için %99.5, kurumsal için %99.99 gibi farklı SLA'lar olabilir. Teknik olarak bu farklılıklar backend'de ayrı SLI hesaplama yolları, önceliklendirme ve destek SLA'ları gerektirir.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• SLO/SLI çerçevesi, güvenilirliği ölçülebilir ve yönetilebilir kılar.
• Error budget ile engineering ve ürün ekipleri arasında objektif karar mekanizması sağlanır.
• SLA'ların teknik uygulanabilirliği SLO'larla test edilerek müşteri taahhütleri güvence altına alınır.

Sınırlamalar

• SLI seçiminin yanlış yapılması, yanıltıcı SLO'lara ve yanlış operasyonel kararlara yol açabilir.
• Yüksek cardinality veya maliyetli ölçümler SLI uygulamasını zorlaştırır.
• SLA hukuki boyutu operasyonel esnekliği kısıtlayabilir ve cezai yaptırımlara yol açabilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

Production kullanımı

• 1–3 kritik SLO belirleyin ve bunları önceliklendirin; tüm ekiplerin bu SLO'ları anlamasını sağlayın.
• SLO'ları açık, test edilebilir ve audit edilebilir şekilde tanımlayın; ölçüm pipeline'ını (OTel, Prometheus vb.) doğrulayın.
• Error budget politikalarını yazılı hale getirip otomasyonla ilişkilendirin (ör. deployment gate'leri).

Performans optimizasyonu

• SLI hesaplamaları için sampling, aggregation ve downsampling stratejilerini dikkatle belirleyin.
• High cardinality etiket kullanımını sınırlayın; kullanıcı‑bazlı ID'leri metric label'ı yapmak yerine traces/logs içinde tutun.

Güvenlik ve uyumluluk

• SLA'lar ve SLO'lar için gerekli audit log'larını, kanıt ve raporlamayı sağlayın.
• PII içeren ölçümlerin toplanmasından kaçının; gerekiyorsa masking ve retention prosedürleri uygulayın.

8. SIK YAPILAN HATALAR

• SLO tanımlanmadan SLA imzalamak — operasyonel olarak sürdürülemez taahhütler oluşur.
• Yanlış SLI seçimi — iş etkisini yansıtmayan metriklerle yanlış güven hissi.
• Error budget'i göz ardı etmek — hız ve güvenilirlik dengesini kaybetme riski.
• İzleme pipeline'ını test etmemek — SLI verisinin güvenilmez olması.

9. GELECEK TRENDLER

1. AI‑destekli SLI ve anomaly detection: ML modelleri SLI verilerini analiz edip proaktif uyarılar ve root cause önerileri sağlayacak.
2. Policy as code ve otomatik SLO governance: SLO/SLA politikaları kodla yönetilip CI süreçlerine entegre edilecek.
3. Business‑aware SLO'lar: Kullanıcı davranışı ve gelir etkisini doğrudan ölçen SLI/SLO kombinasyonları yaygınlaşacak.
4. Cross‑service SLO orchestration: Microservice bağımlılıkları dikkate alan multi‑service SLO yönetimi artacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. SLO ile SLA arasındaki temel fark nedir?

   SLO, iç operasyon hedefidir; SLA ise genellikle müşteriyle yapılan sözleşmedir ve hukuki sonuçları olabilir. SLO, SLA'nın teknik temelini oluşturur.

2. 2. Hangi SLI'yi seçmeliyim?

   Kullanıcı deneyimini doğrudan etkileyen metrikleri seçin: latency (p95/p99), success rate ve error rate önceliklidir. İş etkisine göre özelleştirin.

3. 3. Error budget nasıl hesaplanır?

   Error budget = 1 − SLO. Örneğin SLO %99.9 ise error budget %0.1'dir; bu oran belirli bir zaman penceresinde izin verilen başarısızlık yüzdesini temsil eder.

4. 4. SLO penceresi nasıl seçilir?

   Genelde 30‑90 günlük rolling window tercih edilir. Kısa pencere dalgalanmayı artırır, uzun pencere kısa dönem sorunları gizleyebilir. İş ihtiyaçlarına göre dengeleyin.

5. 5. SLO'ları nasıl otomatikleştiririm?

   Monitoring pipeline'ı (OTel/Prometheus), error budget hesaplama ve otomatik deployment gating ile SLO kararlarını CI/CD süreçlerine bağlayın.

6. 6. SLA ihlali olduğunda ne olur?

   SLA sözleşmesine bağlı olarak tazminat, hizmet kredisi veya diğer yaptırımlar uygulanır. Bu nedenle SLA belirlenirken gerçekçi SLO'lar altyapı ve operasyonel kapasite göz önüne alınmalıdır.

7. 7. SLI ölçümlerinin doğruluğunu nasıl garanti ederim?

   Instrumentation testleri, e2e testler, synthetic monitoring ve data validation pipeline'ları ile SLI verisinin güvenilirliğini sağlayın.

8. 8. Çok sayıda SLO koymalı mıyım?

   Hayır. Başlangıçta 1–3 kritik SLO belirleyin. Çok fazla SLO yönetimi zorlaştırır ve önceliklendirmeyi belirsizleştirir.

Anahtar Kavramlar

SLI

Hizmet performansını ölçen metrik (örn. latency, success rate).

SLO

SLI için belirlenen hedef veya eşik (örn. %99.95 availability).

SLA

Müşteriyle yapılan resmi sözleşme; SLO'ların hukuki/ticari versiyonu.

Error Budget

SLO tarafından izin verilen başarısızlık oranı; risk‑hız trade‑off'unu yönetir.

Burn Rate

Error budget'in belirli bir dönemde ne hızda tüketildiğini gösteren metriktir.

Öğrenme Yol Haritası

1. 0–1 ay: SLI, SLO, SLA temel kavramlarını öğrenin; küçük bir servis için SLI tanımlayıp SLO belirleyin.
2. 1–3 ay: Instrumentation (OTel/Prometheus), error budget hesaplama ve basit alerting ile SLO monitoring kurun.
3. 3–6 ay: Error budget politikaları, deployment gating, SLO otomasyonu ve SLO bazlı incident response süreçlerini uygulayın.
4. 6–12 ay: Multi‑service SLO orchestration, business‑aware SLO'lar, AI‑destekli anomaly detection ve policy as code çalışmalarına başlayın.