Sözleşmeye "%99,99 uptime" yazmak kolaydır; arkasındaki maliyeti hesaplamak zor. Bu sayı bir pazarlama cümlesi değil, matematiksel bir taahhüddir: yılda 8.760 saatlik takvimde %99,99, toplam 52 dakikalık kesinti demektir. Yani yılda yaklaşık bir saatten az bozulma. Dokuz ekleyerek bu pencere yarıya iner, iner, iner; her basamak hata payını küçültür, ekip talebini büyütür.

Dokuzların matematik fiyatı

Tablo net: her dokuz, önceki aylık payın onda birine indirilmesini ister. %99,999 için bir ayda 26 saniyelik kesinti payı kalır; bu, tek bir yeniden başlatmanın bile taahhüdü bozabileceği anlamına gelir. Dolayısıyla soru "kaç dokuz" değil, "bu dokuzları gerçekten istiyor muyuz" sorusudur.

Neden her ürün %99,99'u hak etmez

İç aracı için dört dokuz hedefi koymak, ekibin gerisini frenler. %99,9 bir ekibin gündüz dikkatiyle korunabilir; %99,99 için gece nöbeti, yedekleme ve hata toleransı tasarımı gerekir. Ürünün ne sattığına bakın: e-ticarette bir saatlik kesinti gerçek para yakar; bir blog için aynı kesinti kaçırılmış birkaç okuma demektir. Hedefi ürünün fiyatına, kullanıcı sayısına ve iş modelinin riskine göre seçmek gerekir — tersi, mühendislik değil gösteriş olur.

# SLO tanımında dikkat edilmesi gereken: ölçüm penceresi ve hata bütçesi
slo:
  hedef: 99.9
  pencere: 30d
  hata_butcesi_dakika: 43
  belirtiler:
    - kullanilabilirlik
    - gecikme_p95

Hata bütçesi: dokuzların gerçek yönetimi

Site Güvenilirliği Mühendisliği'nin en değerli fikri budur: hata bütçesi. %99,9 hedefi, ayda 43 dakikalık kesinti izni anlamına gelir. Bu bütçeyi biriktirerek düşünün — kesinti bütçeyi eritir, bütçe tükendiğinde yeni özellik yerine güvenilirlik işi önceliklenir. Bütçe modeli uptime'ı bir tanrı gibi değil, bir denge unsuru gibi yönetir: her dağıtım bir risk taşır, her arıza bir bedel öder, ikisi görünür ölçülür.

Dokuzlar bedelsiz değildir; her biri bir mimari karar, bir nöbet düzeni, bir izleme yatırımını içerir. Doğru hedef, en yükseği değil, ürünün gerçek ihtiyacı ile ekibin taşıyabileceği bakımın kesişimidir. Ve bu kesişim çoğu zaman sandığımızdan birkaç dokuz aşağıda durur.

Bir de ölçümün kendisi hakkında dürüst olun: uptime, kullanıcının gördüğü tek gerçeklik değildir. Sayfa açıldı ama ödeme adımı üç denemede geçtiyse kaydedilen dakikalar başarı saymaz. Bu yüzden hedefi yalnız sunucu ayağa mı bakarak değil, kritik yolun uçtan uca başarı oranına bakarak da ölçün; ikisinin arasında uçurum varsa, asıl sorun pencerede değil mimaridedir. Son olarak hedefi yazılı hale getirin: neyin ölçüldüğü, hangi pencerede, kimin uyarılacağı — üç satırlık bir belge, tartışmayı bitirir. Dokuzlar bir itibar meselesi değil, üzerinde anlaşılmış bir mühendislik kararına dönüşür. Sayfa açılırken yaşanan sessiz yavaşlama hiçbir panoda görünmez ama kullanıcıda kesinti kadar iz bırakır; bu yüzden ölçtüğünüz tablonun kullanıcı gözüyle de bir kez bakılması gerekir.