Gece yarısı telefona düşen bir alarm, ekibin hemen harekete geçmesini gerektiren bir durum olmalıdır. Ancak birçok yazılım ekibinde gerçeklik farklıdır: Günde onlarca uyarı gelir, çoğu kendiliğinden düzelir, bir kısmı aynı sorunun farklı yansımalarıdır. Zamanla ekip uyarıları okumadan kapatmaya başlar. Asıl önemli uyarı geldiğinde de o diğerlerinin arasında kaybolur. Bu duruma alarm yorgunluğu denir ve gözlemlenebilirlik yatırımlarının değerini sessizce eritir.
Belirti ile neden arasındaki fark
Alarm yorgunluğunun en yaygın kaynağı, uyarıların nedenlere göre yazılmasıdır. "Sunucunun işlemci kullanımı yükseldi" bir nedendir; kullanıcıyı etkileyip etkilemediği belli değildir. "Teklif sorgularının başarı oranı düştü" ise bir belirtidir; doğrudan kullanıcı deneyimini anlatır.
Etkili bir yaklaşım, uyanma gerektiren alarmları belirtilere, yani kullanıcı tarafından hissedilen sorunlara bağlamaktır. Neden göstergeleri ise inceleme sırasında bakılacak panellerde yer alır ama kimseyi gece uyandırmaz.
İyi bir uyarının dört özelliği
- Aksiyon gerektirir: Uyarıyı alan kişi bir şey yapmalıdır. Yapılacak bir şey yoksa bu bir uyarı değil, bilgidir.
- Acildir: Sabaha kadar beklemesinde sakınca olmayan bir durum için anlık bildirim gönderilmez; bunun yerine iş saatlerinde bakılacak bir kayıt oluşturulur.
- Kullanıcıyı etkiler: Ya şu anda etkiliyor ya da kısa süre içinde etkileyecek.
- Anlaşılırdır: Uyarı mesajı neyin bozulduğunu, ne zamandan beri sürdüğünü ve ilk bakılması gereken yeri söyler.
Önceliklendirme: herkes her şeyi bilmek zorunda değil
Uyarıları seviyelere ayırmak, gürültüyü önemli ölçüde azaltır. Örnek bir sınıflandırma şöyle olabilir:
- Kritik: Kullanıcıların önemli bir kısmı temel bir işi yapamıyor; oturum açılamıyor ya da hiçbir branşta teklif başlatılamıyor. Nöbetçiye anlık bildirim gider.
- Yüksek: Belirli bir akış ya da şirket entegrasyonu sorunlu; örneğin yalnızca DASK sorgularında hata oranı yükselmiş. Mesai içinde hızlı müdahale, mesai dışında ise etkiye göre değerlendirme.
- Bilgi: Eğilim değişiklikleri, kapasite uyarıları, yaklaşan sertifika süreleri. Ekip kanalına düşer, planlı işlere dönüştürülür.
Gürültüyü azaltan teknikler
Süre koşulu eklemek
Tek bir anlık sıçrama için alarm üretmek yerine, durumun belirli bir süre boyunca devam etmesini şart koşmak, kendiliğinden düzelen dalgalanmaları eler.
Hata bütçesi tüketim hızını kullanmak
Sabit eşikler yerine, güvenilirlik hedefine göre hata bütçesinin ne hızla tükendiğine bakan uyarılar daha anlamlıdır. Kısa sürede hızlı tüketim acil müdahale, uzun sürede yavaş tüketim ise planlı inceleme gerektirir.
İlişkili uyarıları gruplamak
Bir veritabanı sorunu, ona bağlı onlarca servisin ayrı ayrı alarm vermesine neden olabilir. Uyarıların bağımlılık ilişkisine göre gruplanması, ekibin tek bir kök soruna odaklanmasını sağlar.
Dış servisleri ayrı ele almak
Bir sigorta şirketinin servisinde yaşanan kesinti, yazılım ekibinin düzeltebileceği bir sorun değildir. Bu tür durumlar için ayrı bir uyarı türü tanımlanır: Ekip bilgilendirilir, kullanıcı ekranında ilgili şirket için açıklayıcı bir durum gösterilir, ancak nöbetçi gereksiz yere uyandırılmaz.
Her uyarının bir el kitabı olmalı
Bir uyarının anlamlı olup olmadığını test etmenin basit bir yolu, ona ait kısa bir müdahale notu yazmaya çalışmaktır. "Bu uyarı geldiğinde önce şu paneli aç, şu iki olası nedeni kontrol et, şu durumda şu ekibe haber ver." Bu notu yazamıyorsanız, uyarının ne işe yaradığı da muhtemelen belirsizdir.
Düzenli temizlik
Uyarı kuralları da kod gibi bakım ister. Belirli aralıklarla şu sorular sorulmalıdır:
- Son dönemde hangi uyarılar hiçbir aksiyon alınmadan kapatıldı?
- Hangi gerçek sorunlar hiçbir uyarı tetiklenmeden kullanıcı bildirimiyle fark edildi?
- Hangi uyarılar her zaman bir başkasıyla birlikte geliyor?
İlk sorunun cevabı silinecek ya da seviyesi düşürülecek kuralları, ikincisi eksik kuralları, üçüncüsü ise gruplanması gerekenleri gösterir.
Acente kullanıcısına etkisi
Alarm yorgunluğu yaşamayan bir ekip, gerçek sorunlara daha hızlı tepki verir. Bu, acentenin teklif ekranında ya da mobil uygulamada yaşadığı aksaklığın daha kısa sürmesi anlamına gelir. Aynı zamanda dış servis kaynaklı sorunların doğru sınıflandırılması, kullanıcıya "şu şirketin servisinde geçici bir yavaşlık var" gibi net bilgiler verilebilmesini sağlar.
Nöbet düzeni ve devir teslim
En iyi yazılmış uyarı kuralları bile, onları karşılayacak sağlıklı bir nöbet düzeni olmadan işe yaramaz. Alarm yorgunluğu yalnızca kural sayısından değil, yükün nasıl paylaşıldığından da kaynaklanır.
- Dönüşümlü nöbet: Sorumluluk ekip içinde düzenli aralıklarla el değiştirir; aynı kişi sürekli uyandırılmaz.
- İkincil nöbetçi: Birincil nöbetçi belirli süre içinde yanıt vermezse uyarı otomatik olarak bir sonraki kişiye iletilir.
- Devir teslim notu: Nöbet biterken, dönem içinde gelen uyarılar, alınan aksiyonlar ve açık kalan konular kısa bir notla bir sonraki kişiye aktarılır.
- Nöbet sonrası değerlendirme: Gereksiz bulunan her uyarı, kural temizliği listesine eklenir.
Bu düzen, uyarıların kişisel bir yük olmaktan çıkıp ekibin ortak sorumluluğu hâline gelmesini sağlar. Nöbet notları aynı zamanda hangi kuralların gerçekten değer ürettiğini gösteren en dürüst veri kaynağıdır.
Yeni bir uyarı eklemeden önce
Gürültünün önemli bir kısmı, bir olaydan sonra iyi niyetle eklenen yeni kurallardan gelir. Bir kesinti yaşandığında "bunun için de alarm koyalım" demek doğal bir tepkidir; ancak her yeni kural, mevcut uyarı yükünü artırır. Yeni bir kural eklemeden önce şu sorular sorulabilir: Bu durum mevcut belirti tabanlı uyarılardan biriyle zaten yakalanıyor mu? Uyarı geldiğinde nöbetçinin yapacağı somut bir şey var mı? Bu kural ayda kaç kez tetiklenebilir? Bu soruların yanıtı netse kural eklenir; değilse durum bir panel göstergesi olarak izlenir.
Sonuç
Daha çok alarm daha iyi izleme demek değildir. Belirtiye dayalı, aksiyon gerektiren, önceliklendirilmiş ve düzenli olarak gözden geçirilen az sayıda uyarı, ekibin dikkatini korur ve gerçek sorunların gözden kaçmasını önler.