Problem çıkmasını istemem doğrusu ama şu bir gerçek ki problem çözme, konuları öğrenmenin en iyi yollarından biri. Bu yüzden gerçek bir sistem üzerinde tecrübe kazanmak önemli. İnsan kendi kendine çalışırken bu problemlerle karşılaşma ihtimali düşük oluyor.
Sorunun ne olduğunu anlama ilk aşama oluyor. Eğer problemi başka bir kişi bildirdi ise onun anlatım şekli kafanızda hiç bir şey canlandırmayabiliyor. Mecburen soru sorarak anlamaya çalışıyorsunuz. Anlama aşamasında hata mesajları da çok önemlidir. Bazı mesajlar size direk problemi söyleyebilir. Log tutmak bu açıdan çok önemli. Mesaj anlamsız gelse bile o mesaj üzerinden arama yaparak ipuçları yakalanabilir. Anlamlı mesaj deyince hemen aklıma setroubleshoot programı geliyor. RHEL ve türevlerinde SELinux aktif durumdayken yetki ile ilgili bir hata alınca hemen setroubleshoot loglarına bakıyorum. Çoğu zaman problemi tarif ediyor ve çözüm önerileri de sunuyor.
Bir sistem üzerinde çıkan problemi giderebilmek o sistemi iyi tanımayı gerektiriyor. Zamanla tecrübe kazandıkça çözüm üretmek kolaylaşıyor. Çözümü bulamadığımız bazı zamanlarda denemeler yapıp sonuçlarını görmek gerekiyor. Problemi tekrar üretebilmek deneme yapabilmek için bize bir ortam sağlıyor. Deneme amaçlı kullanılabilecek farklı bir sistem de çok işe yarıyor. Gerçek sistemde yapılacak denemeler telafisi olmayan başka hasarlar oluşturabilir.
En zor problemler düzensiz bir şekilde ortaya çıkan ve tekrar ne zaman çıkacağı belirsiz olanlar. Bir kaç hafta önce bu tür bir problem ile karşılaşmıştım. İki SMTP sunucu arasında e-posta gönderilirken zaman zaman “Connection refused” hataları oluyordu. Hatalar seyrek geliyor ve ne zaman geleceği belli olmuyordu. Tek belirgin nokta e-posta sayısı çok olduğunda ortaya çıkmasıydı. Ama her zaman olmuyordu. Önce Postfix kaynaklı olduğunu düşünüp detaylı loglar tutturdum. Hiç bir şey bulamadım. Artık ağ trafiğini izlemeye karar verdim ama hatanın zamanı belli olmadığı için uzun süreli veri toplamam gerekiyordu. Veri miktarını göze alıp toplamaya başladım. Loglarda hatayı görünce toplama işlemini durdurdum ve incelemeye başladım. TCP connection (ağ bağlantısı) için active close işlemini server yapıyordu. Bu yüzden connection, server tarafında TIME_WAIT state içinde bekliyordu. Client tarafında port boşa çıkıyordu. Eğer client TIME_WAIT süresi dolmadan aynı port üzerinden server’a yeni bir connection kurmaya çalışırsa, server hemen reset paketi ile cevap veriyordu. Bu durum client loglarına “Connection refused” hatası olarak yazılıyordu. Hata aslında çok kritik değildi. Kuyrukta bekleyen e-posta bir süre sonra gönderiliyordu. Ama nedenini anlayabilmek için bir kaç gün uğraşmak zorunda kalmıştım. Kalıcı bir çözüm için connection sayısını azaltmak gerekiyordu. Bir SMTP connection içinde tek bir kişiye e-posta gönderen uygulama da değişiklik yapıldı. Artık tek bir connection içinde bir çok kişiye e-posta gönderiliyor.
Bazı problemlerde sorunu anlarsınız, çözümü bilirsiniz ama uygulamak çok uzun sürebilir. Kullanıcı e-posta klasörlerinin olduğu bir sunucu çalışmaz hale gelmişti. Yedek sunucuyu devreye aldık ama yedek sunucunun kapasitesi düşük olunca performans problemleri yaşanmaya başladı. Tekrar daha iyi bir sunucuya e-postaları aktarmak zaman aldı. Bu süre içinde gelen şikayetler de moral bozucu oluyordu. Bu problemden sonra yapıyı değiştirmiştik.
Problem çıkmasın diye ne kadar önlem alırsak alalım bir şekilde problem çıkıyor. Bu noktadan sonra mümkün olan en kısa sürede çözüm bulmak gerekiyor.