Google SRE Bölüm 3 — Riski Kucaklamak

Part II ile birlikte Google kitapta artık altyapı sözlüğünden çıkıp SRE'nin gerçek felsefi çekirdeğine giriyor. Chapter 3, bana göre kitabın en net fikirlerinden birini içeriyor: %100 güvenilirlik yanlış bir hedeftir.

Neden %100 Güvenilirlik Yanlış Bir Hedef?

Sezgilerimize aykırı geliyor ama Google bunu net bir şekilde savunuyor: bir servisi %99.999'dan %100'e çıkarmaya çalışmak hem neredeyse imkansız hem de ekonomik olarak anlamsız. Sebep basit, güvenilirliği artırmanın maliyeti doğrusal değil, üstel artıyor. %99'dan %99.9'a çıkmak nispeten ucuzken, %99.99'dan %99.999'a çıkmak inanılmaz pahalı olabiliyor: Fazladan redundancy, fazladan altyapı ve fazladan mühendislik zamanı.

Bunun bir de kullanıcı tarafı var: Çoğu kullanıcı zaten %100 ile %99.999 arasındaki farkı hissetmiyor, çünkü kendi cihazı ve interneti zaten bu hassasiyette değil. Yani o son binde birlik dilimi satın almak, gerçek dünyada kimseye somut bir fark yaratmayan bir yatırıma dönüşüyor.

Risk Toleransı Bir Mühendislik Sorusu Değil

Google'ın burada attığı en önemli adım şu: "Bu servis ne kadar güvenilir olmalı?" sorusu aslında bir mühendislik sorusu değil, bir iş (business) sorusu. Bunu belirlerken sorulması gereken sorular şöyle sıralanıyor:

• Bu servis için kabul edilebilir kesinti seviyesi ne?
• Farklı hata türlerinin (Kısa süreli yavaşlama mı? Tam kesinti mi?) maliyeti birbirine eşit mi?
• Bu maliyet nasıl ölçülüyor? Gelir kaybı mı? Kullanıcı memnuniyeti mi? İtibar mı?

Error Budget'ın Doğuşu

Burası Google'ın bu bölüm için kalbi. Madem %100 hedeflemek yanlış, o zaman somut bir hedef (SLO) belirlenir. Mesela %99.9. Bu hedef otomatik olarak bir error budget (hata bütçesi) yaratır: Kalan %0.1'lik dilim, bilinçli olarak izin verilen bir risk alanı.

Bunun pratik sonucu güçlü: Bu bütçe tükenmediği sürece geliştirici ekip istediği hızda yeni özellik çıkarabilir, risk alabilir, deney yapabilir. Bütçe tükenirse, yeni özellik yayınlama durur, tüm odak güvenilirliği geri kazanmaya kayar. Bu mekanizma, ilk bölümde konuştuğumuz Dev vs Ops gerilimini, kimsenin "hissine" değil ortak kabul edilmiş bir sayıya dayanan tarafsız bir hakeme dönüştürüyor.

Sonuç

Chapter 3, SRE'nin en somut ve en çok alıntılanan katkısını ortaya koyuyor: Güvenilirlik artık soyut bir "iyi olsun" hedefi değil, ölçülebilir, üzerinde pazarlık yapılabilir, ve dev / ops geriliminin çözümüne dönüştürülebilir bir bütçe. Bu tek fikir, kitabın geri kalanındaki SLO, monitoring ve alerting bölümlerinin de temelini oluşturuyor.

2026 Merceğinden: Error Budget Regüle Sektörlerde Ne Kadar İşliyor?

Bu bölümü okurken benim için en çarpıcı nokta, Fintech ve Bankacılık tarafındaki deneyimimle doğrudan çelişen bir kültürle kıyaslama yapmak oldu. Regüle sektörlerde çoğu zaman "Hiç kesinti olmasın" baskısı gerçek ve somut. Düzenleyici kurumlar, SLA'lar, itibar riski hepsi bir arada "Sıfır Hata" beklentisini besliyor.

Peki error budget mantığı burada hiç işlemiyor mu? On yıllık pratikten çıkan cevap şu: işliyor, ama katmanlı uygulanıyor. Regüle bir bankada tüm sistemler aynı SLO'ya tabi değil. Ödeme onayı veren core sistem %99.99+ hedefiyle çalışırken, dahili bir raporlama paneli çok daha gevşek bir bütçeyle çalışabilir. Yani Error Budget kavramı ortadan kalkmıyor, her sistemin kritiklik seviyesine göre farklılaşıyor. Bu da aslında kitabın kendi tezini doğruluyor: Risk Toleransı bir mühendislik kararı değil, bir iş kararı ve regüle sektörde bu kararı büyük ölçüde düzenleyici verirken, düzenlenmemiş alanlarda (iç araçlar, deneysel özellikler) mühendislik ekibi kendi bütçesini belirleyebiliyor.

2026'da bunun bir adım ötesi de var: gözlemlenebilirlik (observability) araçlarının olgunlaşması sayesinde Error Budget'ı artık gerçek zamanlı, granüler şekilde izlemek çok daha kolay. On yıl önce error budget aylık/üç aylık bir muhasebe kalemi gibiydi; bugün Prometheus/Grafana tabanlı SLO dashboard'ları, Error Budget tükenme hızını (Burn Rate) dakikalar içinde alarm üretecek şekilde izleyebiliyor. Bu, bütçenin tükenmesini beklemek yerine tükenme trendini erken görüp müdahale etmeyi mümkün kılıyor. Google'ın kitabı yayınladığı dönemde bu kadar erişilebilir değildi.

Bir sonraki yazımda Chapter 4'e geçiyoruz: Service Level Objectives — Error Budget'ın matematiksel temelini oluşturan SLI/SLO/SLA üçlüsü. Teşekkür ederim.