SLO Hata Bütçesi Tüketim Politikaları ve Otomatik Canlıya Çıkış Durdurma (Feature Freeze)

Staff/Principal (L6+)

⚡ÖZET VE TEKNİK CEVAP

Hizmet Seviyesi Hedefleri (SLO) ve Hata Bütçeleri (Error Budget), Google SRE tarafından ürün hızı ile sistem güvenilirliğini dengelemek için tasarlanmış temel mekanizmadır. %99,9 erişilebilirlik hedefi, aylık %0,1'lik bir 'Hata Bütçesi' (ayda yaklaşık 43 dakikalık izin verilen kesinti) sağlar. Hata bütçesi pozitif olduğu sürece ürün ekipleri son hızla yeni özellik çıkar. Ancak bir kriz patlamadan ÖNCE Mühendislik ve Ürün Direktörlerinin imzaladığı bağlayıcı bir Hata Bütçesi Politikası yoksa, sistem çökse bile ürün yöneticileri yeni özellik baskısı yapmaya devam eder. Hata bütçesi %100 tükendiğinde otomatik 'Özellik Dondurma' (Feature Freeze) devreye girer: Güvenlik yamaları hariç tüm yeni özellik çıkışları durdurulur ve bütçe toparlanana kadar tüm sprint kapasitesi sistem dayanıklılığına ve teknik borç temizliğine ayrılır.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Bir Hata Bütçesi Politikası 4 kademeli uygulama seviyesi tanımlar:

Yeşil Bölge (%0-50 bütçe tüketimi): Normal durum; tam özellik çıkarma hızı.

Sarı Bölge (%50-80 tüketim): Uyarı durumu; ekipler kapasitelerinin en az %30'unu güvenilirlik işlerine ayırmak zorundadır.

Kırmızı Bölge (%80-100 tüketim): Sıkı kalkanlar; canary bekleme süreleri 2 katına çıkarılır, özellik çıkışları direktör onayı gerektirir.

Siyah Bölge (>%100 bütçe bitti): Tam Özellik Dondurma (Feature Freeze); CI/CD hatları acil güvenlik yamaları dışındaki PR'ları otomatik kilitler; 30 günlük kayan SLO hedefi toparlanana kadar ekibin %100'ü postmortem aksiyonlarına ve mimari iyileştirmelere odaklanır.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Canlı mikroservisler, kritik müşteri API'leri ve SaaS platformları yöneten; ürün yol haritası ile sistem güvenilirliğini dengelemek isteyen tüm mühendislik organizasyonları.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

✓
Hafta içinde 3 büyük veritabanı kesintisi yaşanmışken ürün yöneticilerinin 'lansman yetişmeli' diyerek yeni özellik çıkışını zorlaması ve 4. büyük kesintiyle kurumsal sözleşmeli SLA'in delinip yüz binlerce liralık tazminat ödenmesi
✓
panolarda duran ama kimsenin takmadığı süs SLO'lar

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

✓
SLO panolarının aylardır kıpkırmızı yanmasına rağmen mühendislerin sürekli yeni pazarlama özellikleri yazmaya devam etmesi
✓
her postmortem toplantısında Ürün Yöneticileri ile Mühendisler arasında kavga çıkması

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

✓
Mühendislik ve Ürün Başkan Yardımcılarının ortaklaşa imzaladığı resmi bir 'Hata Bütçesi Politikası' yayınlayın
✓
CI/CD yayınlama sistemlerine otomatik hata bütçesi kalkanları koyun
✓
30 günlük ve 90 günlük kayan hata bütçesi tüketim hızını gerçek zamanlı izleyin

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Özellik dondurma kararı uygulamak ürün paydaşlarıyla kısa vadeli sürtüşme yaratır; ancak platformun çöküşünü engellemenin ve müşteri güvenini korumanın kanıtlanmış tek matematiksel yoludur.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir SaaS analitik platformunda yaşanan Kafka veri kaybı kesintisi, ekibin aylık SLO hata bütçesinin %140'ını tüketti. Önceden imzalanan Hata Bütçesi Politikası gereği CI/CD hatları tüm yeni özellik çıkışlarını kilitledi. 2 hafta boyunca tüm ekip Kafka katmanlı depolama, partition dengeleme ve otomatik küme kurtarma işlerine odaklandı. 30 günlük kayan bütçe %99,95'e çıktığında özellik çıkışları yeniden açıldı ve sağlamlaştırılan altyapı sonraki 9 ay boyunca sıfır kesintiyle çalıştı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma

Google SRE metodolojisinde Hata Bütçesi (Error Budget) nedir?

1 eksi SLO değeri (ör. %99,9'luk bir SLO hedefi, %0,1'lik izin verilen kesinti/hata bütçesi bırakır).

Standart bir politikaya göre Hata Bütçesi %100 tükendiğinde ne olur?

Yeni özellik çıkışları dondurulur ve mühendislik kapasitesinin %100'ü sistem dayanıklılığına, teknik borca ve kriz aksiyonlarına ayrılır.

SLO Hata Bütçesi Tüketim Politikaları ve Otomatik Canlıya Çıkış Durdurma (Feature Freeze) — Sıkça Sorulan Sorular

Hata Bütçesi Politikasının geçerli ve bağlayıcı olabilmesi için kimler tarafından onaylanıp imzalanması gerekir?

Hem Mühendislik Direktörü hem de Ürün Direktörü (ve üst yönetim); krizler yaşanmadan önce peşinen ortak imzalamalıdır.

Hata Bütçesi Özellik Dondurması (Feature Freeze) sırasında kritik güvenlik yamaları da engellenir mi?

Hayır. Kritik güvenlik açıkları, yasal uyumluluk zorunlulukları ve doğrudan sistem güvenilirliğini artıran hata düzeltmeleri muaftır.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

▸
Error Budget = 100% minus the target Service Level Objective (SLO).
▸
Error Budget Policies balance feature delivery velocity against platform reliability.
▸
Exhausting 100% of the budget triggers an automated Feature Freeze.
▸
Both Product and Engineering leadership must sign the policy in advance to prevent disputes.

Yaygın Yanılgılar

✗
Yanılgı: 100% uptime is the ideal goal (Gerçek: 100% uptime is economically impossible and halts all innovation; 99.9% provides room to move fast).
✗
Yanılgı: Error budgets are an engineering-only concept (Gerçek: It is a joint business agreement with Product).

Karar Kılavuzu & Önceliklendirme

Draft a formal Error Budget Policy co-signed by Product and Engineering leadership. Automate deployment gates based on real-time 30-day rolling error budget burn rates.

Doğrulanmış Kaynaklar & Referanslar

[OFFICIAL_DOCUMENTATION]Google Site Reliability Engineering: Implementing Error Budget Policies— Google SRE Book

Bu sayfadaki teknik terimler

Sprint