Paylaşımlı bir sunucuda onlarca proje barınıyor. Mail trafiğini izlemek için kendi gözcü betiğimi yazmıştım: yarım saatte bir tur atıyor, kısıtlanmış hesapları, kuyruk uzunluğunu ve iade sayısını raporluyor.
Haftalarca “temiz tur” yazdı. Sonra bir hesapta gönderim durdu ve nedenini aradığımda ortaya çıkan sayı şuydu: 118.321 reddedilen deneme. Bir aydır sürüyordu.
Gözcü neden görmedi
Betiğim doğru çalışıyordu. Saydığı şey yanlıştı.
Bir SMTP oturumu aşamalı ilerliyor:
MAIL FROM: <gonderen@…> → 250 OK
RCPT TO: <alici@…> → 550 User unknown ← burada bitti
DATA ← buraya hiç gelmedi
Alıcı adresi geçersizse sunucu RCPT aşamasında reddediyor. Mesaj hiç aktarılmıyor, hiç kabul edilmiyor, dolayısıyla iade üretmiyor.
İade, kabul edilmiş bir mesajın sonradan teslim edilememesi. Benim ölçtüğüm buydu. Oysa sorun bir adım öncesindeydi.
Bir metrik sıfır gösteriyorsa iki ihtimal var: gerçekten sıfır, ya da yanlış şeyi sayıyor.
İkisini ayırt etmenin tek yolu metriği bilerek tetikleyip sayacın arttığını görmek. Ben bunu hiç yapmamıştım — sayaç doğduğu günden beri sıfırdı ve ben bunu iyi haber sanıyordum.
Betiği düzelttim: artık RCPT aşamasında reddedilen denemeler de sayılıyor. İlk turda sayı sıfırdan yüz binlere fırladı. Rakam değişmedi — görünürlük değişti.
Kök neden
Görünürlük gelince asıl iş başladı. Zincir şöyle çıktı:
- Uygulama bir bildirim listesine toplu mail gönderiyor.
- Listedeki birkaç adres bozuk — biçimi yanlış, alan adı yok.
- Gönderim başarısız oluyor; uygulama bunu geçici hata sayıp yeniden deniyor.
- Kalıcı bir hata olduğu için her deneme aynı şekilde başarısız.
- Kuyrukta takılı kalan dört mesaj, sonsuza kadar dönüyor.
Üçüncü adım asıl hata. 550 kalıcı bir reddir; yeniden denemek hiçbir zaman işe yaramaz. Geçici hatalar (4xx) yeniden denenir, kalıcı olanlar (5xx) denenmez. Uygulama ikisini ayırmıyordu.
Takılı dört mesajı temizledim, döngü kesildi.
Aynı hafta çıkan diğer kör noktalar
Bu olay bende bir şüphe uyandırdı: başka ne yanlış ölçülüyor? Sırayla baktım.
Bir aydır kimsenin okumadığı uyarı kutusu
Güvenlik duvarı uyarıları bir e-posta adresine gidiyordu. O kutuyu on beş aydır kimse açmamıştı: 129.954 uyarı, 686 MB.
Uyarılar çalışıyordu. Kimse bakmıyordu. Bu, uyarının hiç olmamasından farksız — hatta daha kötü, çünkü “uyarı sistemimiz var” diye bir yanlış güven üretiyor.
Sistem maili boşluğa gidiyordu
Sistem hesabının maili bir yönlendirme dosyası yüzünden dışarıdaki bir adrese gidiyor, orada filtreye takılıyordu. Yani sunucunun kendi kritik bildirimleri bir aydır kayboluyordu. Yerel kutuya alındı.
Kendi formülümdeki hata
Bir turda iade oranını hesaplayan formülün zaman filtresinin yanlış olduğunu buldum — son 30 dakika yerine daha geniş bir pencereye bakıyordu. Düzelttikten sonra ilk kez gerçek bir sıfır gördüm.
Ve aynı gün dört ayrı “alarmın” benim kendi ölçüm hatalarım olduğunu yazdım. Gözcünün kendisi de denetlenmesi gereken bir sistem.
Bir disiplin: her bulgu yazılır
Bu turların hepsi bir depoya yazılıyor:
nöbet 02:17: BULGU — uyarılar 15 aydır okunmayan kutuya yığılıyor
nöbet 00:40: temiz tur — dört sahte alarm kendi ölçüm hatalarımdı
DÜZELTME: döngü bugün başlamadı, en az bir aydır sürüyor
Üçüncü satır önemli. İlk teşhisim “bugün başladı” idi; kayıtlara bakınca yanlış olduğunu gördüm ve düzeltmeyi de kayda geçirdim. Bir teşhisin yanlış olduğunu yazmak, doğrusunu yazmak kadar değerli — bir sonraki sefer aynı yanlış teşhise atlamıyorsun.
Ne öğrendim
İzleme sistemleri güven verir. Ve o güven, sistemin doğru şeyi ölçtüğü varsayımına dayanır.
Artık her yeni metriğe bir soru soruyorum: bu sayının artmasını nasıl sağlarım? Bilerek tetikleyip sayacın hareket ettiğini göremiyorsam, o sayaca güvenmiyorum.
Hiç alarm vermemiş bir alarm sistemi, ya mükemmel bir sistemdir ya da hiç bağlı değildir. İkisini ayırt etmenin tek yolu denemektir.
Aynı soruyu oda ölçüm aracına sorduğumda da aynı cevabı almıştım.