1. SRE Nedir?
SRE (Site Reliability Engineering), yazılım ve operasyon disiplinlerini birleştirip hizmetin güvenilirliğini bakım sürecinde SLO ve reliability hedefleriyle yöneten yaklaşımdır. SRE’nin özü “daha az incident” demek değildir; kabul edilebilir risk seviyesini netleştirip buna göre hız–stabilite dengesini kurmaktır.
SRE’nin bakım açısından 3 ana katkısı
- •Ortak metrik dili (SLO, error budget)
- •Stabilite işlerinin planlanması (bakım blokları)
- •Release riskinin yönetilmesi (bütçe tüketimine göre fren/gaz)
Soru : SRE nedir, error budget ne anlama gelir?
Cevap: SRE, güvenilirliği SLO’larla yöneten yaklaşımdır. Error budget ise hedef SLO’ya göre belirli bir dönemde “tolerans” olarak kabul edilen kesinti/bozulma payıdır; bu bütçe tüketilirse stabilite işleri öncelik kazanır.
Ne yapmalıyım?
- • SRE’yi “ekip” değil “kültür” olarak ele al: hedef + ölçüm + aksiyon.
- • İlk adım: kritik servisler için SLO belirle.
- • Error budget’ı “fren/gaz” mekanizması gibi kullan.
2. Error Budget Kavramı (SLA/SLO ile İlişkisi)
Bu bölümde en sık karışan üç kavramı netleştiriyoruz: SLA SLO error budget farkı bakım kararlarında neden kritik, bunu sade bir çerçevede ele alıyoruz.
- •SLA (Service Level Agreement): müşteriyle verilen söz (daha resmi, kontratsal)
- •SLO (Service Level Objective): iç hedef (operasyonun yönetim hedefi)
- •Error budget: SLO’nun “tolerans payı” (bütçe)
Basit formül (zaman bazlı)
- •Error budget = (1 − hedef SLO) × dönem süresi
- •Örn. aylık 30 gün ≈ 43.200 dakika
- •SLO %99,9 ise bütçe ≈ 43,2 dakika “kabul edilebilir bozulma”
Not: Bu bir çerçevedir; ölçüm yöntemine (availability/latency/error rate) göre yorumlanır.
Soru : SLA, SLO ve error budget arasındaki farklar nelerdir?
Cevap: SLA dışa verilen taahhüttür; SLO iç hedefinizdir. Error budget, SLO’ya göre belirli dönemde tolerans edilen bozulma payıdır ve bakım/özellik kararlarında “risk bütçesi” olarak kullanılır.
Ne yapmalıyım?
- • Önce SLO’ları netleştir, SLA’yı bunun üstüne yerleştir.
- • Error budget’ı “aylık rapor”un parçası yap.
- • Budget tüketimine göre release kurallarını yazılı hale getir.
3. Yeni Özellik Hızı vs Stabilite Dengesi
Error budget’in gerçek değeri burada ortaya çıkar: bütçe “sağlıklı” ise kontrollü risk alabiliriz; bütçe “tükendiyse” stabiliteye dönmeliyiz. Bu, ekipler arası tartışmayı “kim haklı”dan “hangi sayı ne diyor”a çevirir ve stability vs velocity dengesini roadmap üstünde daha net kurmayı sağlar.
Bütçe durumuna göre aksiyon kuralları (pratik)
- •Green (bütçe bol): normal feature hızı + standart bakım
- •Yellow (bütçe azalıyor): riskli değişiklikleri azalt, bakım kapasitesini artır
- •Red (bütçe tükendi): feature freeze / sadece kritik hotfix + bakım/stabilite sprint’i
Key Statistics / Data Point (yumuşatılmış): Error budget yaklaşımını benimseyen ekiplerde, yeni özellik hızı ve stabilite arasındaki dengeyi daha bilinçli ve veri destekli kurmak daha kolay olur; çünkü kararlar bütçe sinyaline bağlanır.
Ne yapmalıyım?
- • Green/Yellow/Red kurallarını sprint planına bağla.
- • Red’de feature’ı frenle; teknik borç ve stabiliteye yüklen.
- • Budget tüketimini yönetim diliyle raporla: risk ve iş etkisi.
4. Otel ve B2B İçin Error Budget Örnekleri
SLO’lar servis bazında tanımlanmalıdır. Otelde rezervasyon/ödeme; B2B’de API/raporlama kritik servislerdir. Özellikle kritik akışlarda error budget ve AIOps sinyalleri birlikte takip edildiğinde incident oluşmadan önce riskleri görmek kolaylaşır.
Otel örnekleri (rezervasyon/ödeme SLO’ları)
- •Rezervasyon akışı availability SLO
- •Ödeme adımı hata oranı SLO
- •Arama/fiyat sayfası latency SLO
- •Not: Sezonda SLO daha kritik hale gelir; budget daha hızlı tükenebilir.
B2B örnekleri (API/raporlama SLO’ları)
- •API error rate / latency SLO (p95)
- •Rapor/export job başarı oranı SLO
- •Login/auth akışı SLO
Örnek Error Budget Tablosu (kopyalanabilir):
| Dönem | Servis | Hedef SLO | Budget (Zaman) | Kullanılan | Kalan | Durum | Aksiyon |
|---|---|---|---|---|---|---|---|
| Ay-1 | Rezervasyon | 99,9% | TBD | TBD | TBD | Yellow | riskli release azalt |
| Ay-1 | Ödeme | 99,95% | TBD | TBD | TBD | Green | normal plan |
| Ay-1 | API | 99,9% | TBD | TBD | TBD | Red | feature freeze + stabilite |
Ne yapmalıyım?
- • En kritik 2–3 servisle başla, sonra genişlet.
- • SLO’ları “ölçülebilir” yap (availability, error rate, latency).
- • Budget raporunu release takvimiyle ilişkilendir.
5. SLO & Error Budget Tanım ve Takip Şablonunu İndir
Şablon seçimi: Audit Sheet (SLO & budget tanımı + takip)
SLO & Error Budget Tanım ve Takip Şablonunu İndir — Yazılım / SRE (v1.0)
Bu şablon; servis bazında SLO hedeflerini tanımlamanızı, error budget’ı dönem bazlı hesaplamanızı ve budget tüketimine göre aksiyon kurallarını (feature yavaşlat, bakım hızlandır) standardize etmenizi sağlar. Otel (rezervasyon/ödeme) ve B2B (API/rapor) kritik servisleri için örnek alanlar içerir. Amaç; hız–stabilite kararlarını veriye bağlamaktır.
Kim Kullanır?
Ürün lideri + ops/tech lead + yönetim temsilcisi (ortak karar).
Nasıl Kullanılır?
- Kritik servisleri seç ve SLO metriklerini tanımla (availability/latency/error).
- Error budget’ı hesapla ve aylık tüketimi raporla.
- Green/Yellow/Red durumuna göre release ve bakım politikalarını uygula.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ SLO tanım netliği (servis bazlı): ___/5
- ▢ ✅ Ölçüm altyapısı (dashboard/alert): ___/5
- ▢ ✅ Budget aksiyon kuralları (Green/Yellow/Red): ___/5
- ▢ ✅ Ürün-bakım hizası (policy uygulanıyor mu?): ___/5
- ▢ ✅ İletişim (yönetim raporu): ___/5
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
6. Bakım ve Ürün Ekipleri Arasında Ortak Dil
SRE yaklaşımı, ürün ve bakım ekiplerini aynı masaya oturtan ortak metrik dili sağlar. “Bakım istiyoruz” demek yerine “budget kırmızı, risk alamayız” demek daha net bir çerçevedir.
Ortak toplantı ritmi (öneri)
- •Aylık SLO & error budget review
- •Red/Yellow durumda aksiyon planı (bakım sprint’i, freeze)
- •Postmortem → SLO güncelleme veya guardrail güçlendirme
Bütünsel konumlandırma için iç linkler
Bu ortak dili yalnızca teknik ekip içinde bırakmamak gerekir. Özellikle reliability’nin satış dönüşüm etkisi görünür hale geldiğinde, bakım ve ürün ekipleri aynı veriye bakarak öncelik kararı verebilir.
Aynı çerçeveyi operasyon tarafında SLO ve error budget raporlaması ile desteklemek ve teknik SEO ve reliability sinyalleri üzerinden hız, crawl ve görünürlük etkisini izlemek karar kalitesini artırır.
Soru : Error budget’ı bakım ve özellik geliştirme kararlarında nasıl kullanırım?
Cevap: Error budget tüketimi “fren/gaz” sinyalidir. Budget sağlıklıysa planlı feature devam eder; budget düşüyorsa riskli değişiklikler azaltılır; budget tükendiyse feature yavaşlatılır/ dondurulur ve bakım/stabilite işleri hızlandırılır. Bu kurallar önceden yazılı olmalıdır.
Ne yapmalıyım?
- • Budget raporunu yönetimle paylaş: risk ve gelir etkisi.
- • Red’de otomatik süreç: feature freeze + stabilite sprint.
- • Her incident sonrası SLO ve guardrail’leri gözden geçir.
7. Competitor Gap’i Kapatan “SRE-Temelli Bakım Modeli”
SRE/error budget modeli, özellikle ürün ve bakım ekiplerinin ayrıştığı organizasyonlarda “kimin haklı olduğu” tartışmasını veriye bağlar. Bu rehberin farkı; formül, tablo, otel/B2B örnekleri ve aksiyon kurallarıyla modeli uygulanabilir hale getirmesidir: sadece teori değil, operasyon politikası. Bakım ve Destek hizmetiyle SRE ve error budget modelinizi bakım sürecine uyarlayın.
Kapsam, destek modeli ve operasyon akışıyla ilgili ek sorular için Bakım ve Destek hakkında sık sorulan sorular sayfasına da göz atabilirsiniz.
Bir Sonraki Adım
Ürün hızını ve stabiliteyi ortak SLO/error budget diliyle yönetmek isteyen otel, SaaS ve B2B ekipleri için.
Sık Sorulan Sorular
SRE nedir, error budget ne anlama gelir?▾
SLA, SLO ve error budget arasındaki farklar nelerdir?▾
Otel ve B2B projeleri için hangi SLO’ları belirlemeliyim?▾
Error budget’ı bakım ve özellik geliştirme kararlarında nasıl kullanırım?▾
Error budget bittiğinde ne yapmalıyız?▾
İlgili İçerikler