Çağrıda olan mühendislerin %62'si 12 ay içinde tükenmiş olur (PagerDuty 2026). Bu bir insan problemi değil, bir mühendislik tasarımı problemidir. Tükenmiş her nöbetin üç kök nedeni: 1. Belirtiler yerine nedenlere yönelik uyarılar CPU sıçramaları, kuyruk derinliği, istek oranı – bunların hiçbiri olay değildir. Hepsi insanları sabah 3'te uyanıtır. 2. Eski runbook'lar Bir yangın çıkar. Runbook, adı değiştirilmiş bir hizmete işaret eder. Mühendis, adrenalinle ve uyku olmadan sistemi tersine mühendislik yoluyla çözer. 3. Asimetrik yük için simetrik nöbetler Hafta sonları Super Bowl'dur. Hafta içi bir sprinttir. Aynı nöbet her ikisini de aynı şekilde ele alır. En iyi takımların uyguladığı dört çözüm: 1. Hata bütçesi Planlanmamış çağrıda çalışma süresini haftanın %25'ine kadar sınırlayın. Bu sınırın üzerindeyse, özellik çalışması durdurulur. Google SRE bu rehberi yazdı. 2. SLO'lara bağlı uyarılar Kullanıcı tarafından gözlemlenebilir bir SLO ihlaline karşılık gelmiyorsa, bu gürültüdür. Çağrıda geçen zamanın %23'ü yanlış pozitiftir (Blameless 2026). 3. Runbook ya da sil Her üretim uyarısı, güncel bir runbook ile birlikte gönderilir ya da uyarı silinir. Uyarılarınızın yarısını kaybedeceksiniz. İşte amaç budur. 4. Yük bilinçli nöbetler Zirve dönemleri daha yoğun kapasite veya daha kısa nöbetler gerektirir. Tümü için aynı boyut, zirveyi çeken kişiyi cezalandırır. Mühendislik lideriyseniz, çağrı tasarımı sizin işinizdir. HR değil. EM'niz değil. Siz. Bu hafta: panoyu açın, çağrı sayısını sayın ve bunların kaç tanesinin insan yerine platform tarafından çözülmesi gerektiğini sorun. #MühendislikLiderliği #Çağrıda #SRE