SRE Error Budget: SLO, SLI Tanimi ve Pratik Rehber 2026

Error budget nedir sorusunun pratik cevabı şudur: bir servisin belirli bir zaman penceresinde (genellikle 28 veya 30 gün) tolere edebileceği maksimum hata oranıdır ve doğrudan SLO’dan türetilir. SLO yüzde 99.9 ise error budget yüzde 0.1, yani 30 günlük pencerede yaklaşık 43 dakika 12 saniyelik aksaklık hakkı demektir. Bu rakam, ürün ekibinin yeni özellik göndermek için kullanabileceği “risk parası”dır. Google SRE Workbook’a göre error budget tükendiğinde release dondurulur, kalan bütçe varken hızlı iterasyon serbesttir; bu denge mühendislik kültürünü hız ve güvenilirlik arasında nesnel bir hakeme bağlar.

2026 itibarıyla CNCF’in yıllık DevOps anketi, üretim ortamlarında SLO temelli operasyonu benimseyen ekiplerin yüzde 67’sinin incident MTTR’ında ortalama yüzde 30-45 düşüş raporladığını gösteriyor. Buna karşın SLI (Service Level Indicator) tanımının yanlış kurgulanması en sık görülen hata; ölçüm pencereniz, success kriteriniz ve event kümeniz net değilse hesapladığınız error budget kağıt üstünde kalır. Bu rehber SLO, SLI ve error budget üçlüsünü pratik formüllerle, gerçek bütçe hesaplama tablolarıyla, burn rate alarmlarıyla ve canlı sistemde gözlemlenen anti-pattern’lerle bir arada açıklar. Hedef, bir hafta içinde ilk SLO’nuzu yayına alacak teknik temele oturtmaktır.

SLI, SLO ve Error Budget Üçgeni: Tanımların Net Sınırı

SLI ölçülen bir gerçekliktir: “son 5 dakikada gelen istekler arasında HTTP 2xx/3xx yanıt veranlerin oranı yüzde 99.94”. SLO bu SLI’a karar verilmiş hedefin koyulmasıdır: “request success ratio ≥ yüzde 99.9 (28 gün)”. Error budget ise SLO’nun tamamlayıcısıdır: yüzde 100 eksi SLO. Bu üç kavramı karıştıran ekipler genellikle SLA ile de örtüşmeli zorlar; oysa SLA müşteri sözleşmesindeki dış vaattir ve hemen her zaman SLO’dan daha gevşek olmak zorundadır. Aksi halde tek bir kötü saat dahi kredi geri ödemesine yol açar.

Google’ın 2016’da yayımlanan SRE kitabı ve sonraki SRE Workbook’u bu ayrımı ilk standardize eden kaynaktır; bugün AWS Well-Architected Reliability Pillar, Azure Architecture Center ve Microsoft Reliability Workbook aynı tanımları benimser. Aşağıdaki tablo dört kavramı uçtan uca karşılaştırır.

Kavram	Ne Ölçer	Kim Sahibi	Tipik Pencere	Örnek Değer
SLI	Ham ölçüm (success ratio, p99 latency)	SRE / Platform	1 dk – 5 dk	%99.94 success
SLO	Hedef SLI değeri	SRE + Ürün	28-30 gün rolling	≥ %99.9
Error Budget	1 – SLO (izin verilen başarısızlık)	Ortak (Dev+SRE)	SLO penceresiyle aynı	%0.1 = 43m12s/30g
SLA	Müşteri sözleşmesi vaadi	Hukuk + Ürün	Aylık / yıllık	≥ %99.5 (kredi cezası)

Pratikte SLO seviyesinin SLA’dan en az iki “dokuz” yukarıda olması önerilir: SLA yüzde 99.5 ise SLO yüzde 99.9, SLA yüzde 99.9 ise SLO yüzde 99.99. Bu marj, bir incident sırasında SLA’yı kırmadan SLO’nun erkenden bütçeyi tüketmesini sağlar; yani SRE ekibi SLA ihlali olmadan önce alarm alır. Google’ın orijinal SRE kitabı Service Level Objectives bölümü bu üç katmanlı kurguyu detaylı örneklerle açıklar.

SLI Tanımlarken Doğru Sorular: Event, Success, Window

SLI tanımı üç parça gerektirir: Event (neyi sayıyoruz), Success kriteri (hangi event başarı sayılır), Pencere (hangi zaman aralığında ölçüyoruz). “HTTP istekleri için 5 dakikalık rolling pencerede, code 5xx olmayan ve client_timeout etiketi taşımayan response’ların toplam request’e oranı” tipik bir Availability SLI tanımıdır. Bu cümleyi PromQL’e çevirmek, ekibinizin gözlenebilirlik olgunluğunu belirleyen ana mihver iştir.

Google SRE Workbook dört temel SLI türünü “RED + USE” çerçevesinde toplar: Request rate, Errors, Duration, Utilization, Saturation, Errors (resource side). Kullanıcı yolculuğu (Critical User Journey) başına bir SLI seçmek, monitoring noise’unu yüzde 70’e kadar düşürür çünkü “her metriğe alarm” anti-pattern’inden kurtulursunuz.

• Availability SLI: Başarılı response / toplam response. Ne zaman seç: stateless REST API’leri, ödeme endpoint’leri. Avantaj: hesabı basit, eşik sezgisel. Dezavantaj: kısmen başarılı (slow ama 200) yanıtları yakalamaz.
• Latency SLI: p95 veya p99 yanıt süresinin eşiğin altında kalma oranı. Ne zaman seç: kullanıcı-yüzlü web, arama, feed. Avantaj: gerçek kullanıcı algısını yansıtır. Dezavantaj: histogram bucket’larının iyi ayarlanması gerekir.
• Freshness SLI: Veri kaynağı son güncellenmeden bu yana geçen süre. Ne zaman seç: ETL, materialized view, kataloğu cache’leyen servisler. Avantaj: data team ile ortak dil. Dezavantaj: upstream gecikmesi karıştırılabilir.
• Correctness SLI: Output doğruluğu (örnek: checksum doğru oran). Ne zaman seç: billing, fraud, ML inference. Avantaj: kritik veri sınıfında ihlal sızdırmaz. Dezavantaj: ground truth elde etmek pahalı.

Error Budget Hesaplama: Pencere, Format ve Formüller

Error budget hesaplama iki şekilde yapılır: zaman tabanlı (allowed downtime minutes) ve olay tabanlı (allowed failed requests). Zaman tabanlı yaklaşım operasyonel raporlamada anlaşılır; olay tabanlı yaklaşım yüksek RPS sistemlerde gerçek user-impact’a daha yakındır. Bir SaaS API’si saniyede 5.000 istek alıyorsa yüzde 99.9 SLO altında 30 gün penceresinde yaklaşık 12.96 milyon hata izninine sahiptir.

Aşağıdaki tablo “dokuz” sayısına göre standart bütçeleri 28 günlük rolling pencerede gösterir (Google Sre Workbook standart referansı):

SLO Seviyesi	Error Budget %	28 Gün Izin Edilen Aksaklık	Anlamı	Tipik Use-Case
99.0%	1.000%	~6 saat 43 dakika	“Iki dokuz”	Dev/staging, internal tool
99.5%	0.500%	~3 saat 21 dakika	“Iki buçuk dokuz”	B2B admin paneli
99.9%	0.100%	~40 dakika 19 saniye	“Üç dokuz”	SaaS API, e-ticaret çekirdek
99.95%	0.050%	~20 dakika 9 saniye	“Üç buçuk dokuz”	Fintech, sağlık
99.99%	0.010%	~4 dakika 2 saniye	“Dört dokuz”	Ödeme rail, borsa
99.999%	0.001%	~24 saniye	“Beş dokuz”	Telekom çekirdek, kritik altyapı

Bu rakamlara bakıldığında bir gerçek netleşir: yüzde 99.99 SLO bir ay içinde dört dakika izin verirken yüzde 99.999 yalnızca 24 saniye verir. Her ekstra “dokuz” altyapı maliyetini ortalama 3-10 kat artırır; AWS Well-Architected Reliability Pillar bu tradeoff’u “marginal cost of nines” başlığı altında belgeleyen referans dokümandır. Bu yüzden SLO yi pazarlama hedefine göre değil, kullanıcının gerçek toleransına göre seçmek gerekir.

Olay tabanlı bütçe formülü şudur: budget_events = total_events * (1 - SLO). Eğer 30 günlük pencerede 1 milyar istek alan bir servisiniz yüzde 99.95 SLO’ya bağlıysa bütçeniz 500.000 başarısız isteğe denktir. Bu rakam abartı görünse de PR’a “bu sprint’te 480.000 hata ürettik, bütçenin yüzde 96’sını yaktık” şeklinde girdiğinde anlamı çok somutlaşır.

Burn Rate Alarmları: Bütçe Tükenmeden Önce Uyan

Bütçe sonunda biten bir alarm operasyonel açıdan geç kalmış demektir. Modern SRE pratiği multi-window burn rate alarmlarını standartlaştırdı: aynı SLO için iki farklı zaman penceresinde aynı anda burn rate eşiğin üstündeyse alarm üretilir. Bu yaklaşım hem hızlı yanan ufak incident’leri (kısa pencere) hem de yavaş sürünen sızıntıları (uzun pencere) yakalar. Google SRE Workbook bu konuyu “Alerting on SLOs” bölümünde detaylandırır.

Burn rate, mevcut hata oranının SLO bütçesini “kaç katı hızında” yaktığını gösterir. Burn rate 1 ise tam tahminlenen hızdasınız; 10 ise bütçeyi 10x hızlı tüketiyorsunuz ve aksiyon almazsanız bütçe penceresinin 1/10’unda biter. Tipik dört-eşik tablosu aşağıdadır:

Önem	Burn Rate	Kısa Pencere	Uzun Pencere	Tükenme Süresi (30g bütçe)	Aksiyon
Critical / Page	14.4x	5 dk	1 saat	~2 saat	On-call hemen page
High	6x	30 dk	6 saat	~5 saat	On-call ticket, slack
Slow burn	3x	2 saat	1 gün	~10 saat (kümülatif)	Slack, ekip kuyruğu
Drip	1x	6 saat	3 gün	30 gün (planlı)	Sadece dashboard

Bu eşikler hem PagerDuty hem Opsgenie hem Grafana OnCall şablonlarına gömülü gelir. Önemli olan iki pencere birden geçmedikçe alarm ateşlememesi; tek dakikalık spike’ın page çalmasını engelleyen mekanizma budur. AWS CloudWatch, Datadog ve New Relic’in “SLO Manager” özellikleri 2024 sonundan itibaren multi-window burn rate’i UI’de hazır sunuyor; manuel PromQL yazmak isteyenler için Sloth (GitHub’da yaklaşık 2.1k yıldız) ve Pyrra (yaklaşık 1.3k yıldız) açık kaynak generator’lar pratik bir başlangıçtır.

Error Budget Policy: Bütçe Bitince Ne Olur?

SLO’yu tanımlamak yetmez; bütçe tükendiğinde tetiklenecek politika yazılı olmalıdır. Bu politika ürün ve mühendislik liderliği tarafından ortak imzalanır ve genellikle dört kademe içerir. Aşağıdaki tablo Google’ın açıkladığı referans politikayı sektör uygulamasıyla birleştirir:

Bütçe Durumu	Eşik	Release Politikası	Operasyonel Aksiyon	Geri Dönüş Şartı
Sağlıklı	>%50 kalan	Normal velocity	Standart deployment	—
İzleme	%25-50 kalan	Risk review zorunlu	Canary süresi 2x	Burn rate < 2x
Kısıtlı	%10-25 kalan	Sadece bug fix + reliability	Feature freeze, sadece roll-back hazır PR’lar	Bütçe %30 üzerine çıkana kadar
Tükendi	≤ 0	Tam freeze	RCA + post-mortem zorunlu	Reliability work tamamlanana kadar

Politikanın yazılı ve önceden onaylanmış olması anlaşmazlığı önler. “Bütçe bitti, freeze” cümlesi tek başına ürün ekibi nezdinde gerilim üretir; ama imzalı politika dokümanı bunu nesnel kurala dönüştürür. Bizim DevSecOps shift-left rehberinde gösterdiğimiz gibi, otomatik kontrolün yazılı politikaya dayanması ekip içi pazarlığı ortadan kaldırır.

Bütçe tükendiğinde release pipeline’ı durdurmak yalnız bir yöntem; ikinci popüler yaklaşım reliability taxtır: ekip sprint kapasitesinin yüzde 20-30’unu güvenilirlik iyileştirmesine ayırmak zorunda kalır. Üçüncü yaklaşım chaos engineering boost: bütçe sağlıklıyken planlı chaos eylemleri (örnek: Gremlin veya Chaos Mesh ile pod kill, network partition) tetiklenir; bu sayede gerçek incident öncesi kırılma noktaları bulunur.

SLO Toolchain 2026: Open Source ve SaaS Karşılaştırması

SLO yönetimi için seçim büyük ölçüde mevcut gözlemlenebilirlik stack’inize bağlıdır. Prometheus + Grafana ekosistemindeyseniz açık kaynak generator’lar maliyetsiz başlangıç sunar; Datadog veya New Relic gibi uçtan-uca SaaS kullanıyorsanız native SLO modülleri daha düşük operasyonel yüktür. Google’ın resmi Implementing SLOs dökümanı mimari tercih için temel referanstır.

Araç	Tip	Backend	Multi-window Burn Rate	Fiyat (yaklaşık 2026)	Ne Zaman Seç
Sloth	OSS generator	Prometheus	Evet (templated)	Ücretsiz	Prom-native, GitOps
Pyrra	OSS UI + generator	Prometheus	Evet	Ücretsiz	UI ihtiyacı + OSS
OpenSLO + Nobl9	Spec + SaaS	Multi (Prom, DD, NR)	Evet	~$30-50/SLO/ay	Çok-backend, dedikan SLO platformu
Datadog SLO	SaaS native	Datadog metrics	Evet	Pro+ plan dahil	DD stack zaten kullanımda
New Relic SLM	SaaS native	NRDB	Evet	Standard+ dahil	NR stack + APM odaklı
Grafana SLO	SaaS / Self-host	Mimir, Prom, Loki	Evet	Cloud Pro $25/active user	Grafana ekosistemi
Google Cloud SLO Monitoring	SaaS	Cloud Operations	Evet	GCP fatura içinde	GKE / GCP native

OpenSLO 2022’de CNCF Sandbox’ına alınan, Nobl9 öncülüğünde yazılan deklaratif SLO spec’idir; YAML şablonu sayesinde aynı tanımı Prometheus, Datadog veya New Relic’e tek dosyayla deploy edebilirsiniz. GitHub repo‘su 2026 başında yaklaşık 800 yıldıza ulaştı; multi-backend ekipler için pratik bir abstraction katmanıdır. Servislerinizi GitOps modeliyle yönetiyorsanız OpenSLO dosyalarınızı da aynı reposunda versiyonlamak doğal akışıdır.

Pratik SLI/SLO Tasarımı: 6 Adımlı Çerçeve

İlk SLO’sunu yayına alacak bir ekip için izlenecek sıra aşağıdadır. Bu çerçeveyi 30 farklı projede uyguladığımız bir Ömer Önal danışmanlık oturumunda standartlaştırdık; her adım yarım iş günü ile bir hafta arasında değişebilir.

1. Critical User Journey’leri listele: “Kullanıcı login olur”, “ödeme yapar”, “search sonucu görür” gibi 3-7 yol seç. Avantaj: tüm endpoint’ler için SLO yazma tuzağından kurtulur, alarm noise düşer.
2. Her CUJ için 1-2 SLI tanımla: availability + latency çoğu durumda yeterlidir. Freshness ve correctness yalnız ihtiyaç olan domain’lerde eklenir.
3. Tarihsel veriyi 90 gün geriye al: mevcut SLI dağılımını ölç. Ortalama p99’unuz 240 ms ise SLO’yu 250 ms yapmak gerçekçi değil; gerçekçi başlangıç 350-400 ms. Anti-pattern: arzu edilen değer ile gerçek değer arasında çuval dolusu bütçe açığı.
4. Stakeholder onayı al: ürün, müşteri başarı, mühendislik liderlik üçlüsünden imza. Ne zaman seç: kritik müşteri sözleşmesi varsa SLA-2-dokuz kuralına dikkat.
5. Burn rate alarmlarını kur: 14.4x ve 6x iki-pencere alarmı tipik başlangıç. PagerDuty / Opsgenie entegrasyonunu test et (sentetik fail simülasyonu).
6. Error budget policy yaz ve imzala: dört kademeli (sağlıklı / izleme / kısıtlı / tükendi) politika dokümanını Confluence veya repo Markdown’unda yayımla.

Bu çerçeve CI/CD pipeline kurulumu ile entegre olduğunda asıl değerini üretir; çünkü release otomasyonunun “geçer / geçmez” kararı doğrudan error budget durumuna bağlanır ve manuel onay sürtünmesi ortadan kalkar.

SLO Anti-Pattern’leri: Saha Notları

Bir SLO programının ilk altı ayında sık görülen tuzaklar şunlardır. Microsoft’un Azure Reliability Workbook‘unda da benzer örnekler belgelenmiştir.

• “Her endpoint için SLO” anti-pattern’i: 200 endpoint, 200 SLO, 800 alarm. Sonuç: alarm fatigue, yüzde 60’tan fazla snooze’lanır. Çözüm: CUJ bazlı 5-10 SLO tut.
• Aspirational SLO: mevcut performans yüzde 99.2 iken hedef yüzde 99.95 koymak. Sonuç: her hafta bütçe biter, alarm güvenilirliğini yitirir. Çözüm: tarihsel veriden +0.1-0.2 dokuz yukarı çık.
• Tek pencere alarmı: sadece 5 dk burn rate alarmı; flaky network bir kez page çalar. Çözüm: multi-window iki-eşik şart.
• Synthetic-only SLI: dışarıdan probing yapmak yeterli sanılır; oysa kullanıcının deneyimi backend latency’yi yakalamaz. Çözüm: real user monitoring (RUM) + server-side SLI birlikte.
• Bütçe pencere reset: “ay sonu geliyor, bütçe sıfırlanacak” mantığı. Sonuç: ay sonu freeze pazarlığı. Çözüm: 28-30 gün rolling pencere kullan, takvim ayı değil.
• SRE silosunda kalmış SLO: ürün ekibi haberdar değil, error budget kavramına yabancı. Çözüm: sprint review’lerde bütçe durumu standart slide.

2025 yılında Stack Overflow Developer Survey’i, SRE pratiğini benimseyen ekiplerin yüzde 41’inin “SLO tanımlarını çok karmaşık tuttuk” yanıtını verdiğini gösteriyor. Basit ve az SLO, çok ve karmaşık SLO’dan her zaman daha etkindir. Net’flix’in açık tech-blog yazılarında ve LinkedIn engineering blog’unda da aynı vurgu mevcuttur: SLI dilini sade tut, SLO sayısını az tut, error budget policy’yi yazılı tut.

Maliyet ve ROI: SLO Programının Finansal Tarafı

SLO programının ROI’sini ölçmek için iki metrik en pratiktir: downtime cost avoided (önlenen aksaklık maliyeti) ve release velocity gain (sağlıklı bütçe altında artan deploy hızı). AWS Well-Architected Reliability Pillar ve Gartner’in 2024 IT Cost Optimization raporlarına göre orta ölçekli SaaS şirketlerinde bir dakika kritik servis aksaklığı ortalama $5.600-$9.000 arası maliyet üretir; e-ticaret cuma puanlarında bu rakam $40.000’i geçer. Bu eğri “cost of additional nines” başlığı altında belgelenir.

Şirket Tipi	Aksaklık Maliyeti / dk	Tipik SLO	30 Gün Bütçe	Yıllık Tasarruf Potansiyeli (1 Major Incident Önlemek)
Internal IT, mid-market	~$1.000	%99.5	~218 dk	~$200K-300K
B2B SaaS, mid-market	~$5.600	%99.9	~43 dk	~$1.2M-1.8M
E-ticaret büyük	~$15.000	%99.95	~22 dk	~$3M-5M
Ödeme rail / Fintech	~$30.000-50.000	%99.99	~4 dk	~$8M-15M

Bu rakamların yarısı dahi reel olsa, SLO platformuna yıllık $50K-$150K bütçe ayırmak finansal olarak kolay savunulur. Daha kritik olan, sağlıklı bütçe altında release velocity’nin yüzde 30-50 artmasıdır; CNCF anketi yüksek olgunluktaki SRE ekiplerinde deploy frekansının haftada birden günde 3-5’e çıktığını raporluyor. Bu hız, error budget policy sayesinde “her gece deploy” ile “ay sonu freeze” arasındaki ekip içi pazarlığı ortadan kaldırdığı için elde edilir.

FinOps açısından SLO maliyetinin büyük kısmı yedeklilik (multi-AZ, multi-region) ve gözlemlenebilirlik (metric cardinality, log retention) tarafındadır. FinOps disipliniyle entegre çalıştığında SLO seviyesinin gereğinden yüksek tutulmasının marjinal maliyetini fark eder ve doğru “dokuz” sayısını seçersiniz; çoğu B2B SaaS için yüzde 99.9 yeter, yüzde 99.99 hedeflemek 5-8x altyapı maliyeti ekler.

Sıkça Sorulan Sorular (SSS)

Error budget ile SLA arasındaki fark nedir?

SLA müşteriyle imzalanan sözleşmedeki dış vaat ve genelde kredi geri ödemesiyle bağlıdır; SLO bu SLA’yı kırmadan içeride tutulan daha sıkı hedeftir; error budget ise SLO’nun tamamlayıcısı (yüzde 100 eksi SLO) yani izin verilen aksaklık miktarıdır. SLO’yu SLA’dan en az iki “dokuz” daha sıkı tutmak ihlal öncesi alarm sağlar.

SLO penceresi 7, 28 yoksa 30 gün mü olmalı?

Google SRE Workbook’un önerisi 28 günlük rolling penceredir; takvim ayı yerine sabit gün sayısı kullanmak haftalık deploy ritmiyle uyumludur ve “ay sonunda bütçe sıfırlanır” pazarlığını engeller. 7 gün çok dalgalı, 30 gün takvim ayına bağlanır; 28 gün sektör standardı haline gelmiştir.

Synthetic monitoring SLO için yeterli mi?

Tek başına yeterli değildir. Synthetic prob dışarıdan birkaç dakikada bir test eder, gerçek kullanıcı trafiğinin patern’ini ve coğrafi dağılımını yakalamaz. Doğru yaklaşım server-side SLI (Prometheus / OTel) + RUM (real user monitoring) kombinasyonudur; synthetic yalnız “yokuş aşağı dependency canlı mı” sorusunu yanıtlar.

Yeni başlayan ekipler kaç SLO ile başlamalı?

3-5 SLO ideal başlangıçtır. Her kritik kullanıcı yolculuğu için tek availability ve tek latency SLO, toplamda 6-10 metrik üretir; bu hem yönetilebilir alarm hacmidir hem de ürün ekibinin error budget kavramını öğrenmesine zaman tanır. İkinci çeyrekten itibaren freshness/correctness SLO’ları gerektiğinde eklenir.

Error budget bittiğinde tüm release durmalı mı?

Yazılı politika dört kademeli olduğunda tam freeze yalnız “bütçe tükendi” durumunda uygulanır; kısıtlı kademede bug fix ve reliability iyileştirmesi serbestir. Mutlak freeze yerine “reliability tax” (sprint kapasitesinin yüzde 20-30’u güvenilirliğe ayırılır) modeli ürün ekibiyle daha az gerilim üretir ve uzun vadede aynı sonucu verir.

Sonuç

SLO, SLI ve error budget üçlüsü modern SRE pratiğinin temel para birimidir; ekiplerin “hızlı gönder” ve “güvenilir kal” pazarlığını nesnel bir hakeme bağlar. 2026 itibarıyla doğru kurgulanmış bir SLO programı yalnız incident MTTR’ını yüzde 30-45 düşürmekle kalmıyor, aynı zamanda release velocity’yi yüzde 30-50 artırıyor; bu rakamlar Google SRE Workbook’un on yıllık deneyimini ve CNCF endüstri anketlerini doğruluyor. Karar çerçevesi şöyledir: kritik kullanıcı yolculuğu başına 1-2 SLI, gerçekçi tarihsel veriden türetilen SLO, 28 günlük rolling pencere, multi-window burn rate alarmları ve yazılı dört kademeli error budget policy.

Stack seçiminizde Prometheus-native ekosistemde Sloth veya Pyrra ile başlamak maliyetsiz; Datadog, New Relic veya Grafana Cloud zaten kullanımdaysa native SLO modülleri en az sürtünmeli yoldur. Multi-backend kompleks ortamlarda OpenSLO + Nobl9 deklaratif spec’inin tek dosyayla farklı backend’lere yayımlanabilen yapısı operasyonel disiplini artırır. Mimari karar verirken cloud-native mimari prensiplerini ve service mesh gözlemlenebilirlik entegrasyonunu birlikte düşünmek zaman tasarrufu sağlar.

Eğer kendi ekibinizde ilk SLO’sunu yayına almak ya da mevcut programınızda alarm fatigue’ı azaltmak için pratik bir audit istiyorsanız iletişim sayfası üzerinden CUJ tabanlı kısa bir keşif görüşmesi planlayabiliriz; çıktısı genelde 6-8 SLO’luk öncelik haritası ve burn rate alarm şablonlarıdır.