Birçok teknik ekip alert yorgunluğunu izleme sisteminin doğal yan etkisi gibi kabul eder. Oysa konu çoğu zaman araç değil, liderlik tasarımı problemidir. Gürültülü alarm akışı; sahipliği belirsiz servisler, zayıf olay sınıflandırması, eksik geri besleme döngüsü ve ölçülmeyen nöbet yükünün birleşiminden çıkar. Teknik lider için asıl görev, alert sayısını düşürmekten önce bu sinyal akışını ekip öğrenmesine bağlayacak işletim modelini kurmaktır.
Alert yorgunluğu neden kültürel bir semptomdur?
Alert yorgunluğu genellikle şu cümleyle başlar: “Bu alarmı da susturalım.” Kısa vadede rahatlatıcı görünür; fakat uzun vadede sistem davranışını daha da opak hâle getirir. Çünkü aynı gürültüyü üreten asıl sorular masada kalır:
- Hangi alarm gerçekten kullanıcı etkisini temsil ediyor?
- Hangi alarm yalnızca teknik semptomu tekrar ediyor?
- Hangi alarmın net bir sahibi var?
- Hangi alarm kapanınca öğrenme döngüsü gerçekten tamamlanmış oluyor?
Bu soruların cevabı yoksa sorun yalnızca eşik değeri değildir. Sorun, gözlem sinyallerinin işletim modeline bağlanmamış olmasıdır.
Doğru soru: kaç alarm var değil, alarmdan sonra ne değişiyor?
Benzer ekiplerde faydalı olan yaklaşım şudur: alarm hacmini ana metrik yapmamak. Çünkü bazı dönemlerde alarm artışı sağlıklı bile olabilir; yeni servis açılmıştır, yeni hata sınıfı görünmüştür, yeni SLO izlenmeye başlanmıştır. Önemli olan alarmın ardından ne olduğudur.
İyi bir teknik lider, her alarm sınıfı için şu akışı zorunlu kılar:
- Alarm görüldü mü?
- Doğru ekip devreye girdi mi?
- Etki seviyesi doğru sınıflandı mı?
- Kalıcı iyileştirme kaydı açıldı mı?
- Aynı alarm tekrarlandığında ekip daha az bilişsel yük taşıdı mı?
Bu akış yoksa alarm kapansa bile organizasyon öğrenmemiş olur.
Alert portföyünü üç sepete ayırın
Tüm alarm kurallarına aynı yönetişim uygulanırsa sonuç ya aşırı bürokrasi ya da kontrolsüz çoğalmadır. Pratikte şu üç sepet yeterli olur:
- Aksiyon alarmı: Nöbetçi ekipten belirli sürede müdahale beklenir.
- Farkındalık alarmı: Aynı anda müdahale gerektirmez ama ekip ritmine veri sağlar.
- Mühendislik alarmı: Trend, kalite veya kapasite sorunu işaret eder; çalışma planına girmelidir.
Bu ayrım kritik bir rahatlık sağlar. Çünkü her sinyali gece yarısı çağrısına dönüştürmek zorunda kalmazsınız. Aynı zamanda üretim davranışını görünmez hâle de getirmezsiniz.
Nöbet yükünü servis başına değil hata sınıfı başına görün
Çoğu ekip nöbet yükünü kişi başına gelen çağrı sayısıyla ölçer. Bu yetersizdir. Aynı sayıda çağrı alan iki ekipten biri daha fazla tükenebilir; çünkü çağrıların bağlamı zayıftır, çözüm yolları parçalıdır veya aynı kök neden farklı alarmlarla tekrar eder.
Daha işe yarayan model, alarmı şu başlıklarda sınıflamaktır:
- Bilinen ve runbook’u olan
- Bilinen ama aksiyonu manuel olan
- Bilinmeyen ve araştırma gerektiren
- Yanlış pozitif veya düşük değerli
Bu görünürlük oluştuğunda teknik lider hangi yatırımın nöbet yükünü gerçekten düşüreceğini daha net görür. Bazen yeni araç gerekmez; iki alarmı birleştirmek, bir alanı standardize etmek veya karar ağacını sadeleştirmek yeterlidir.
Öğrenme döngüsü nasıl işletilir?
Alert yorgunluğunu azaltan ekipler alarm review toplantısı yapmaz; alarm öğrenme ritmi kurar. Fark önemlidir. Review çoğu zaman geçmişi denetler. Öğrenme ritmi ise gelecekteki bilişsel yükü düşürür.
Benim önerdiğim çerçeve şu şekilde:
- Haftalık olarak en çok tekrarlanan ilk 10 alarm incelenir.
- Her alarm için kullanıcı etkisi, müdahale süresi ve tekrar sebebi işaretlenir.
- Kalıcı aksiyonlar üç sınıfa ayrılır: kaldır, birleştir, güçlendir.
- Sonraki hafta gerçekten neyin değiştiği ölçülür.
Burada amaç kusur aramak değildir. Amaç, gürültüyü kurumsal öğrenmeye çevirmektir.
Teknik lider hangi metrikleri izlemeli?
Alarm sayısı tek başına yanıltıcıdır. Daha iyi gösterge seti şöyledir:
- Aksiyon alarmı başına yanlış pozitif oranı
- Alarmdan ilk anlamlı aksiyona kadar geçen süre
- Aynı kök nedenden türeyen tekrar alarm oranı
- Runbook’u güncellenmiş alarm yüzdesi
- Nöbet devri sonrası kişi başı taşınan açık aksiyon sayısı
Bu metrikler ekibin yalnızca operasyonu sürdürüp sürdürmediğini değil, operasyonu öğrenip öğrenmediğini gösterir.
Ürün ve platform ekipleri arasında gerilim nerede çıkar?
Alert yorgunluğu çoğu zaman platform takımının gürültüyü, ürün takımının ise etkisizliği hissetmesiyle büyür. Platform tarafı “çok çağrı geliyor” der; ürün tarafı “ama sorunlar gerçek” diye cevap verir. İki taraf da haklı olabilir. Liderin görevi bu gerilimi ortak bir risk diline çevirmektir.
Örneğin yüksek gecikme alarmı için şu ayrım netleştirilebilir:
- Müşteri etkisi varsa aksiyon alarmı
- Sadece iç servis kuyruğu büyüyorsa mühendislik alarmı
- Deploy sırasında beklenen dalgalanmaysa farkındalık alarmı
Aynı sinyal, bağlamına göre farklı işletim yoluna girebilir. Bunu kuran şey teknik liderliğin tasarım kalitesidir.
Sonuç
Alert yorgunluğu bir observability aracı problemi gibi görünse de gerçekte ekip öğrenme ekonomisinin problemidir. Teknik lider, alarm portföyünü risk, aksiyon ve öğrenme açısından yeniden düzenlediğinde hem nöbet sağlığı iyileşir hem incident kalitesi yükselir. Asıl başarı, daha sessiz sistem değil; daha anlamlı sinyal üreten ve her olaydan sonra biraz daha hafif çalışan ekip düzenidir.