Ürün yayınında hata bütçesi, “bir miktar hata yapabiliriz” şeklinde genel bir izin değildir. Kullanıcının önemli bir görevi ne ölçüde güvenilir biçimde tamamlayabilmesi gerektiği tanımlanır; gerçekleşen güvenilirlik bu hedefe göre izlenir. Bütçe, yeni özelliklerle kararlılık çalışması arasındaki öncelik kararını destekler.
Bu yazı küçük bir ürün ekibi için başlangıç çerçevesi önerir. Bir hizmetin güvenilirlik ölçümü yapılmış gibi sayı vermez. Veri kaybı, yetkisiz erişim veya yanlış finansal işlem gibi kritik olaylar genel kullanılabilirlik bütçesi içinde olağan kabul edilmemelidir.
Kullanıcı açısından başarılı görevi seçmek
Sadece sunucunun yanıt vermesini ölçmek yeterli olmayabilir. Sayfa açılıyor ama sipariş tamamlanamıyorsa kullanıcı için temel iş başarısızdır. Önce ürünün kritik akışları belirlenir: giriş, veri kaydetme, rapor oluşturma veya ödeme gibi.
Her akış için başarı koşulu ve gözlem yöntemi yazılır. Bir yanıtın hızlı olması, doğru sonuç taşıdığı anlamına gelmez. Gecikme ve doğruluk gibi boyutlar gerektiğinde ayrı hedeflerle izlenir. Ölçülemeyen hedef, yayın kararında güvenilir bir kontrol oluşturamaz.
Hedefi bağlamla belirlemek
Google’ın SRE rehberi, hizmet seviyesi hedefleriyle hata bütçesini ilişkilendirir ve bütçe tükendiğinde yapılacak eylemleri yazılı politikaya bağlar. SLO uygulama rehberi bu çerçevenin kaynağıdır. Oradaki örnek değerleri her ürüne doğrudan kopyalamam.
Kullanıcı beklentisi, görevin sıklığı, alternatif yol ve kesintinin etkisi değerlendirilir. Yeni bir pilotta başlangıç hedefi geçici olabilir; bunun varsayım olduğu ve ne zaman gözden geçirileceği kaydedilir. Hedefi tutturmak için kullanıcı açısından önemli hataları ölçümden çıkarmak doğru değildir.
Yayın kararını önceden tarif etmek
| Durum | Önerilen karar türü |
|---|---|
| Hedef içinde ve kritik sorun yok | Normal yayın sürecini sürdürmek |
| Bütçe hızlı tüketiliyor | Kapsamı daraltmak ve nedeni araştırmak |
| Hedef aşılmış | Güvenilirlik işlerine öncelik vermek |
| Kritik güvenlik veya veri sorunu | Ayrı olay yönetimi ve gerekli durdurma |
| Ölçüm güvenilmez | Durumu belirsiz kabul edip doğrulamak |
Bu kararlar olay çıktığında pazarlık edilmemesi için önceden konuşulur. Kimin durdurma kararı vereceği, hangi düzeltmelerin yine yayınlanabileceği ve yeniden açılış koşulu yazılır.
Küçük yayın ve geri dönüş düzeni
Değişikliği sınırlı kapsamda yayınlamak, etkisini daha kolay incelemeyi sağlayabilir. Ancak küçük kapsamda başarı bütün kullanıcı gruplarının temsil edildiğini garanti etmez. Temel akışlar ve önemli cihazlar yine doğrulanmalıdır.
Geri dönüş planında yalnız kod değil, veri değişikliği ve dış sistem etkisi de düşünülür. Eski sürüme dönmek yeni veri biçimini okuyamıyorsa basit bir geri alma mümkün olmayabilir. Bu bağımlılıklar yayın öncesinde görünür olmalıdır.
Olaydan sonra bütçeyi öğrenmeye bağlamak
Hedef kaçırıldığında yalnız oranı düzeltmekle yetinmem. Hangi koşulun sorunu doğurduğu, nasıl fark edildiği ve tekrarını azaltacak hangi değişikliğin yapılacağı yazılır. Aynı olayın tekrar tekrar bütçe tüketmesi, daha fazla inceleme gerektiğini gösterir.
Başarısız otomasyonu tekrar çalıştırmak kısmi sonuçların korunmasını; günlük kontrol düzeni ise sapmaların sahiplenilmesini tamamlıyor. Hata bütçesinin değeri bir yüzde göstermekten çok, kullanıcı güvenilirliği bozulduğunda ekibin ne yapacağını önceden netleştirmesidir.