İşimiz Gücümüz Sorun Çözme (Troubleshooting)

Yazılım geliştirme uzman yardımcısından, teknik liderine, işimizin her daim bir parçası olan hata ayıklama, sorun çözme (Troubleshooting) faaliyetini gerçekleştirirken, aşağı yukarı uyguladığımız taktikler aynıdır. İşte bu taktikleri biraz derleyip toparlamaya çalıştım.

Orijinal Sorunu Anlamak

Sorunu sahibinden dinle, anladığına emin ol. Mümkünse kendi gözlerinle gör. Sorunu bir müşteri bildiriyor ise onu ön yargılardan uzakta ve çok iyi dinlememiz gerekir. Söylediği herhangi bir kelime bizi ipucu verebilir. Onu dinler gibi yaparken, ona nasıl cevap vereceğimizi düşünürsek veya kafamızda kod yazmaya başlarsak, müşterinin kelimeleri arasında geçen hayati ipuçlarını kaçırabiliriz.

Ayrıca, “sorunun bizim bilgisayarımızda” alınmıyor olması, “senelerdir o modülden hata gelmiyor olması” gibi mevcut sorunun çözümüne faydası olmayan gereksiz ayrıntıları müşteriye aktararak vakit kaybetmeyelim. Unutmayalım, müşterimizin vakti en az bizimki kadar değerlidir.

Ekip içinden veya müşteriden, “Bana şöyle çelikten, büyükçe bir çekiç lazım. Nereden bulurum” gibi, bir çözümün uygulamasına dair bir soru ve danışmanlık isteği geldiğinde, ona hemen Koçtaş’ı tarif etmeden önce, bu çekiçle ne yapmak istediğini sorun (Asıl problemi anlayın). Belki bu sorun, o duvarda zaten olmaması gereken çiviyi tekrar çakarak değil, ufak bir pense ile oradan alınarak çözülmelidir. Asıl sorunu anlamayı başarırsanız hem bu konudaki fikrinizi söyleme şansını bulmuş, hem de yanlış bir uygulamanın akıl hocalığını yapmamış olursunuz.

Aynı şekilde; 10 MB’dan büyük EXCEL dosyasını nasıl UPLOAD ederim? CONFIG hatası veriyor dendiğinde, neden bu şekilde bir dosya UPLOAD edilecek önce anlamaya çalışın (aslında çaktırmadan sorgulayın). Belki o bilgilerin girildiği, kopyala yapıştır yapılabilen bir ekran vardır. UPLOAD işlemine gerek yoktur.

Hata Kayıtlarını İncelemek

Her zaman en başta hata kayıtlarını kontrol edelim. En büyük bilgi oradan gelecektir. (ELMAH/LOG4NET/LOG ANALYTICS/…) Bazen ortalık karışabilir, acilen hatayı çözeceğiz diye bu en basit adımı atlayabiliriz.

Bunun yanında elinizin altındaki diğer iz kayıtlarından (LOG) faydalanmayı unutmayalım. (Reporting Service Logs, Projenize özel İşlem/Transaction İz Kayıtları, Özel İz kayıtları (Faks sunucu, Smtp sunucu), EventLogs kayıtları da iş görecektir.)

Her Testte Tek Bileşen Değiştirmek

Klasöre yazma hatası alıyoruz. Hem klasöre everyone verip, hem kod içinde impersonate (Kodu başka bir kullanıcı gibi çalıştırma işlemini) yapıp tekrar denersek sorunu neyin çözdüğünü bilemeyiz. Sorun tespitini, dar kapsamdan geniş kapsama değişiklikler yaparak, yani önce kod değişikliği (BiztalkUser’i ile ilgilidir gibi), çözmedi ise everyone deneyerek yapmalıyız.

Einstein’ın Notu — Kod içinde veya ortamda herhangi bir değişiklik yapmadan hata senaryosunu tekrar tekrar çalıştırıp hata alıp vakit kaybetmeyelim.

Sadece Çözüm İçin Gereken Değişikliği Yapmak

Sorun, yapılan bir dizi değişiklikten (denemeden) sonra en sonunda çözüldü ise. Yapılan tüm değişiklikler (kod veya yapılandırma ayarı) geri alınıp, orijinal soruna geri dönüp, burada gerçekten sorunlu senaryo tekrar çalıştırılmalıdır. Sonra asıl çözüm olan değişikliği yapıp tekrar test edilmelidir. Bunu yapmaz isek çözüm ile alakalı olmayan değişiklikleri sisteme yansıtmış neyin nasıl çözdüğünü kendimize anlatamıyor oluruz.

Örnek: Sorun nedeniyle PRODUCTION kodunda değiştirdiğimiz her şeyi geri alıp (UNDO), sorunu tekrar edip, sadece çözen değişikliği yapıp (test edip) CI yapmalıyız.

Hata Ortamındaki Bileşenleri Tanımlamak

Birden fazla bileşenin olduğu karmaşık süreçlerde, bileşenlerin tamamının çalıştığına emin olalım. Sorun bu bileşenlerin birinde olabilir.

Uygulamamızdan faks gitmiyor diyelim. Sorun uygulamadan, faks Sunucusundan, faks olarak giden PDF in yazıldığı dosya sunucudan veya gönderilen faks numarasından kaynaklanıyor olabilir. İlk başta sorunu nokta atışı tespit edemediysek, hata kayıtlarından da bir ipucu elde edemediysek bu bileşenlerden her seferinde birini değiştirip deneyerek sorunu tespit etmeye çalışırız. (Başka faks numarasına gönderme, başka programdan aynı faks sunucusuna gönderme, dosya sunucu ip değiştirme gibi)

Neyi Nasıl Çözdüğümüzün Farkında Olmak

İnternet’ten bulunan kodlar başa bela açabilir. Aldığımız kodun ne iş yaptığını %100 anlamamız ve değerlendirmemiz gerekir (Check-In yaptığımız diğer tüm kodlar gibi).

Çözüm sunan “entry” lerin altındaki yorumları mutlaka okuyalım. Orada paylaşılan risklerin farkında olalım. Eklenen — değişen kodu mutlaka test edelim.

(Rick Strahl’ın blog’undan da alsak) CI yaptığımız her kod bize aittir. O kodun -ne pahasına- ne iş yaptığına emin olmamız gerekir.

Yapıştırdığımız kodun etkisi anlamak, testinin hakkıyla yapılmasını sağlamak gerekir.

Çalışan Örnek İle Karşılaştırmak

Problem yaşanan işlem başka bir ekrandan, başka bir sunucudan, başka bir “local” makinede çalışıyor ise, burada bileşenler karşılaştırılabilir. Sizin WCF servisiniz patlıyor ise, çalışan wcf servisi ile, webserver1 deki application pool çatlıyor ise, webserver2’deki apppool ile karşılaştırırız. Çalışan örneği yakalamak çok önemlidir. “Pis Hataların” çoğu bu şekilde çözülür.

BONUS:

Yazılım projemizdeki hatanın çözümü uzayacak gibiyse, deneysel işler yapacağımız bir sorun ile uğraşıyorsak, hatayı alabileceğimiz en sade proje solution’unu üzerinden çalışmak gerekir. (Tüm projelerin ekli olduğu .sln dosyasını açmak yerine)

Hele ki (Telerik, Dynatrace, Microsoft gibi) bir firmadan “Ticket” açma gibi süreçler işin içine girecek ise, en güzeli sadece hatayı alacak kadar bileşen ve kodun olduğu örnek bir projede hazırlamaktır. Bu genelde düşünülenden daha az zaman alır. Sorun bu projede çözüldükten sonra asıl problemli ortam düzeltilebilir.