Staff/Principal (L6+)
⚡ÖZET VE TEKNİK CEVAP
Geleneksel şirketlerde Ürün Yöneticileri sürekli yeni özellik çıkarmak isterken, SRE ekipleri kesintileri önlemek için canlıya kod alınmasını durdurmak ister. Bu durum şirket içinde bitmek bilmeyen bir çatışma yaratır. Hata Bütçeleri (Error Budget - Google SRE Modeli) bu gerilimi matematiksel bir anlaşmaya bağlar: Bir API %99,9 Erişilebilirlik Hedefi (SLO) koymuşsa, %0,1'lik bir hata yapma bütçesine (ayda yaklaşık 43 dakika kesinti hakkı) sahiptir. %100 erişilebilirlik asla hedeflenmez çünkü mükemmellik aşırı pahalıdır ve inovasyonu kilitler. Sistem hata bütçesi sınırları içinde kaldığı sürece Ürün ekipleri hızlıca kod dağıtabilir. Ancak ardışık arızalar üç aylık hata bütçesini tükettiğinde (%0 kaldığında), Otomatik Özellik Dondurma Kuralı devreye girer: Güvenlik yamaları dışındaki tüm yeni özellik dağıtımları CI/CD'de durdurulur ve tüm takım bütçe düzelene kadar mesaisini tamamen güvenilirlik, test ve teknik borç temizliğine ayırır.
Mühendislik El Kitabı & Mekanizma
6 Boyutlu Mimari Analiz⚙️1. Temel Çalışma Mekanizması
MekanizmaHata bütçesi yönetişimi metrik odaklı CI/CD kapılarıyla işler:
1
SLI Ölçümü: Başarılı isteklerin toplam isteklere oranı ölçülür.
2
Canlı Bütçe Takibi: Prometheus metrikleri Sloth veya Nobl9 gibi SLO yönetim araçlarına aktarılır.
3
Bütçe Tüketim Hızı (Burn Rate): Bütçenin ne kadar hızlı eridiği hesaplanır.
4
Otomatik CI Kilidi: Kalan bütçe sıfırın altına indiğinde, GitHub Actions webhook'u devreye girerek
type: feature etiketli tüm yeni özellik PR'larını kilitler; yalnızca type: fix veya type: reliability etiketli güvenilirlik kodlarının geçmesine izin verir.🎯2. Doğru Kullanım Senaryosu
KapsamKurumsal SaaS API platformları, çok takımlı mikroservis organizasyonları, finansal işlem sistemleri ve genel bulut servisleri.
⚠️3. Prodüksiyon Arıza Modları
Kritik Risk- ✓Önemsiz bir iç panel için gerçek dışı %99,999 SLO koyup ekibi sürekli özellik dondurmaya mahkum etmek
- ✓ürün yöneticilerinin tükenen hata bütçesini görmezden gelip mühendisleri zorla canlıya kod almaya zorlaması
📡4. Teşhis ve Telemetri Sinyalleri
Metrikler- ✓Bir ekibin yavaşlayıp yavaşlamayacağı konusunda bitmek bilmeyen yönetici tartışmaları
- ✓aceleyle canlıya alınan özelliklerin hemen ardından patlayan arızalar
- ✓bütçe aşılmasına rağmen hiçbir yaptırımı olmayan sahte paneller
🛡️5. Önleme ve Mimari Bariyerler
Bariyerler- ✓Yazılım Direktörü ve Ürün Direktörü tarafından ortaklaşa imzalanan resmi bir Hata Bütçesi Politikası hazırlayın
- ✓gerçekçi SLO'lar (%99,9) belirleyin
- ✓CI/CD boru hatlarında otomatik dağıtım dondurma kapıları kurun
⚖️6. Mimari Ödünleşimler (Trade-offs)
ÖdünleşimHata bütçesi politikaları güvenilirliği objektif bir metriğe bağlar ve şirket içi siyaseti bitirir; ancak bütçe tükendiğinde dağıtımları durdurabilecek güçlü bir yönetim iradesi gerektirir.
📋
GERÇEK DÜNYA TELEMETRİSİVaka İncelemesi (TinyCTO Saha Örneği)
Bir pazaryeri platformu pazarlamanın baskısıyla alelacele çıkarılan özellikler yüzünden 4 haftada 6 kez SEV1 kesintisi yaşadı. Ürün ve yazılım ekipleri birbirine girdi. Yönetim resmi bir Hata Bütçesi Politikası başlattı: Ödeme API'si için %99,9 erişilebilirlik (ayda 43 dk kesinti hakkı). Bir veritabanı arızası aylık bütçenin %100'ünü 3 günde yakınca, CI/CD sistemi ödeme ekibinin yeni özellik çıkarmasını otomatik olarak durdurdu. Takım sonraki 3 hafta boyunca sadece bağlantı havuzu, devre kesici ve yük testleri üzerine çalıştı. Sonraki çeyrekte yenilenen servis %99,98 erişilebilirliğe ulaştı ve 6 ay boyunca tek bir kesinti bile yaşanmadı.
İnteraktif Konsept Alıştırmaları
2 AlıştırmaQ1
Site Reliability Engineering (SRE) disiplininde 'Hata Bütçesi' (Error Budget) nedir?
Bir servisin taahhüt ettiği kalite seviyesini bozmadan yaşayabileceği kabul edilebilir arıza payıdır (%100 - SLO); yeni özellikler çıkarırken ve inovasyon yaparken risk alma bütçesi olarak kullanılır.
Q2
Bir servis üç aylık hata bütçesinin %100'ünü tükettiğinde hangi zorunlu mühendislik aksiyonu devreye girer?
Otomatik Özellik Dağıtımı Dondurma: Güvenlik dışındaki tüm yeni özellik dağıtımları durdurulur ve takımın tüm sprint kapasitesi güvenilirlik, test ve teknik borç temizliğine yönlendirilir.
Güvenilirlik Yönetişimi: Hata Bütçesi (Error Budget) Tükenmesi ve Özellik Dağıtımı Dondurma Kuralları — Sıkça Sorulan Sorular
Sistem güvenilirliğinde %100 erişilebilirliği hedeflemek neden bir anti-pattern (kötü pratik) kabul edilir?
Çünkü son %0,01'lik dilime ulaşmanın maliyeti katlanarak artar ve tüm inovasyonu durdurur; oysa kullanıcının kendi internet bağlantısı (hücresel hat/Wi-Fi) zaten %99 seviyesinde olduğu için bu farkı hissedemez.
SLA (Hizmet Seviyesi Sözleşmesi) ile SLO (Hizmet Seviyesi Hedefi) arasındaki fark nedir?
SLO şirket içi mühendislik hedefidir (%99,9); SLA ise ihlal edildiğinde müşteriye para iadesi veya tazminat gerektiren yasal sözleşmedir ve genellikle iç hedeften daha esnek tutulur (%99,5 SLA vs %99,9 SLO).
🤖 AEO & Yapay Zeka Çıkarım Özeti
Temel Gerçekler & İlkeler
- ▸Hata Bütçesi = %100 - SLO; kabul edilebilir risk sınırını matematiksel olarak çizer.
- ▸%100 erişilebilirlik ekonomik olarak anlamsızdır ve ürün geliştirmeyi kilitler.
- ▸Bütçenin tükenmesi CI/CD'de yeni özellik dağıtımlarını otomatik olarak dondurur.
- ▸Bütçe toparlanana kadar ekipler tüm mesailerini güvenilirlik mühendisliğine ayırır.
Yaygın Yanılgılar
- ✗Yanılgı: Ürün yöneticisi özelliğin çok acil olduğunu söylerse dondurma kuralı delinebilir (Gerçek: Kuralı delmek güveni yıkar ve daha büyük zincirleme kesintileri garantiler).
- ✗Yanılgı: Çeyrek sonunda hata bütçesini hiç kullanmamış olmak büyük bir başarıdır (Gerçek: Bütçenin %0'ını kullanmak ekibin çok yavaş hareket ettiğini ve hiç yenilik riski almadığını gösterir).
Karar Kılavuzu & Önceliklendirme
Ürün geliştirme hızı ile sistem kararlılığı arasında objektif bir denge kurmak için bütçe sıfırlandığında yeni özellik dağıtımlarını otomatik durduran bir Hata Bütçesi Politikası uygulayın.
Doğrulanmış Kaynaklar & Referanslar
- [OFFICIAL_DOCUMENTATION]Google Site Reliability Engineering: Embracing Risk & Service Level Objectives— O'Reilly Media / Google SRE Book