Ağ Sorun Giderme Metodolojisi - Sistematik Yaklaşım
Ağ Sorun Giderme Metodolojisi: Sistematik Yaklaşım
Metodoloji Neden Önemlidir?
Sorun:Bir veritabanı uygulaması "yavaştır." Ağ ekibi sunucu ekibini suçluyor. Sunucu ekibi ağı suçluyor. Bu arada kullanıcılar hayal kırıklığına uğruyor ve döngüsel hata ayıklama işlemleriyle saatler harcanıyor.
Çözüm:Temel nedenleri belirlemek için varsayımları değil kanıtları kullanan, sorun gidermeye yönelik sistematik, bilimsel bir yaklaşım.
Gelişigüzel Sorun Gidermenin Maliyeti:Zaman kaybı, gerçek sorunları maskeleyen hatalı düzeltmeler, ekipler arasında parmakla işaret etme ve kötüleşen kullanıcı deneyimi.
Giriş: Ağ Oluşturmada Uygulanan Bilimsel Yöntem
Ağ sorunlarını giderme temel olarak bilimsel yöntemin bir alıştırmasıdır:
- Gözlemlemekbelirtiler ve veri toplama
- Bir hipotez oluşturuntemel neden hakkında
- Hipotezi test edinteşhis araçlarıyla
- Sonuçları analiz edinve hipotezi onaylayın veya reddedin
- Bir düzeltme uygulayındoğrulanmış temel nedene dayalı
- Doğrulamaksorun çözüldü
Bu makale, ağ sorunlarını gidermeye yönelik olarak aşağıdaki gibi yaygın karşılaşılan tehlikeleri önleyen yapılandırılmış bir çerçeve sunmaktadır:
- Doğrulama yanlılığı (yalnızca ilk tahmininizi destekleyen kanıtları aramak)
- Teşhis konulmadan rastgele değişiklikler ("püskürt ve dua et" yaklaşımı)
- Temel nedenler yerine semptomları düzeltmek
- Neyin denendiğini belgelemeden döngüsel hata ayıklama
Beş Anahtar Soru
Teknik teşhise geçmeden önce araştırma kapsamınızı daraltmak için şu beş kritik soruyu yanıtlayın:
Yapılandırma değişiklikleri mi? Yeni donanım mı? Yazılım güncellemeleri? Topoloji değişiklikleri?
- Değişiklik yönetimi günlüklerini kontrol edin
- Konfigürasyon yönetimi sistemlerindeki son taahhütleri inceleyin
- Şunu sorun: "Dün çalışıyor muydu?"
Bir kullanıcı mı? Bir bina mı? Herkes? Yalnızca belirli bir uygulama mı?
- Bir cihaz:Büyük olasılıkla yerel bir sorun (NIC, kablo, yapılandırma)
- Bir alt ağ:Ağ geçidi, DHCP veya anahtar sorunu
- Herkes:Temel altyapı, İSS veya yaygın sorun
- Belirli uygulama:Uygulama sunucusu, güvenlik duvarı kuralı veya DNS
Her zaman mı oluyor? Sadece belirli saatlerde mi? Rastgele olaylar mı?
- Devamlı:Sert arıza (kablo kesilmesi, yanlış yapılandırma, servis kesintisi)
- Zamana dayalı:Mesai saatlerinde yoğunluk, planlanmış süreçler
- Aralıklı/Rastgele:Çift yönlü uyumsuzluk, arızalı donanım, aralıklı bağlantı
Sorunu talep üzerine tetikleyebilir misiniz?
- Evet:Teşhis etmek çok daha kolay (hipotezleri test edebilir)
- HAYIR:İzlemeyi/günlüğe kaydetmeyi ayarlayın ve yinelenmeyi bekleyin
Bağlantının her iki ucunu da kontrol edin
- İstemci perspektifi ve sunucu perspektifi
- Kaynakta ve hedefte paket yakalama
- Asimetrik yönlendirme? Gönderme ve alma için farklı yollar mı var?
OSI Modeline Dayalı Teşhis Yaklaşımı
OSI modeli sorun giderme için yapılandırılmış bir çerçeve sağlar. Semptomlara bağlı olarak Katman 1'den (Fiziksel) yukarıya doğru veya Katman 7'den (Uygulama) aşağıya doğru çalışın.
Aşağıdan Yukarıya Yaklaşım (Katman 1 → Katman 7)
Ne zaman kullanılır:Tam bağlantı kaybı, bağlantı ışığı yok veya fiziksel katman belirtileri
- Kontrol edin: Kablo bağlı mı? Bağlantı ışıkları açık mı? Fiber temiz mi?
- Komutlar:
show interfaces,ethtool eth0 - Şunları arayın: CRC hataları, çarpışmalar, geç çarpışmalar, runt'lar, devler
- Kontrol edin: VLAN doğru mu? Bağlantı noktası etkin mi? STP engelleniyor mu?
- Komutlar:
show mac address-table,show spanning-tree - Şunları arayın: MAC dalgalanması, STP topolojisi değişiklikleri, VLAN uyumsuzlukları
- Kontrol edin: Varsayılan ağ geçidine ping atılabilir mi? Yönlendirme tablosu doğru mu?
- Komutlar:
ping,traceroute,show ip route - Şunları arayın: Eksik rotalar, hatalı sonraki atlama, yönlendirme döngüleri
- Kontrol edin: TCP bağlantısı kurulabiliyor mu? Güvenlik duvarı bağlantı noktasını engelliyor mu?
- Komutlar:
telnet host port,netstat -an, paket yakalama - Şunları arayın: TCP yeniden iletimleri, sıfır pencere, RST paketleri
- Kontrol edin: DNS çözümleniyor mu? Uygulama yanıt veriyor mu? Kimlik doğrulama çalışıyor mu?
- Komutlar:
nslookup,dig,curl -v - Şunları arayın: DNS hataları, uygulama hataları, zaman aşımı sorunları
Yukarıdan Aşağıya Yaklaşım (Katman 7 → Katman 1)
Ne zaman kullanılır:Temel bağlantının mevcut olduğu uygulamaya özel sorunlar
Katman 7'den başlayın (SharePoint hizmeti çalışıyor mu? IP'yi düzeltmek için DNS çözümleniyor mu?) ve yalnızca gerekirse çalışın.
Karar Ağacı: Katman 1, 2 veya 3 mü?
Hangi katmanın başarısız olduğunu belirlemek için bu hızlı tanılama ağacını kullanın:
TCP/IP yığını çalışmıyor. İşletim sistemi hizmetlerini kontrol edin, ağ sürücülerini yeniden yükleyin.
NIC devre dışı, yanlış sürücü, kablo takılı değil. Kontrol etmek:ip link showveya Aygıt Yöneticisi
Kontrol edin: Fiziksel kablo, anahtar bağlantı noktası durumu, VLAN ataması, ARP tablosu
Kontrol edin: Yönlendirme tablosu, güvenlik duvarı kuralları, ACL'ler. Kullanmaktraceroutepaketlerin nerede durduğunu bulmak için
Kontrol edin: DNS sunucusu ayarları, DNS sunucusu kullanılabilirliği, güvenlik duvarı engelleme bağlantı noktası 53
Kontrol edin: Güvenlik duvarı kuralları, güvenlik grupları, bağlantı noktasında hizmet dinleme
Sorun uygulamanın kendisinde, kimlik doğrulamasında veya uygulama yapılandırmasındadır
İzolasyon Teknikleri
Temel neden hakkında bir hipoteziniz olduğunda, bunu onaylamak veya reddetmek için şu izolasyon tekniklerini kullanın:
1. Bileşenleri Sistematik Olarak Değiştirin
- Yama kablosunu, çalıştığı bilinen bir kabloyla değiştirin
- Farklı anahtar bağlantı noktasında test edin
- Farklı NIC (veya USB ağ bağdaştırıcısı) deneyin
- Farklı istemci cihazından test edin
- Farklı VLAN/alt ağa geç
2. Birden Fazla Noktada Paket Yakalama
Paketlerin nerede bırakıldığını veya değiştirildiğini belirlemek için trafiği kaynakta, ara noktalarda ve hedefte yakalayın:
# Capture on client
tcpdump -i eth0 -w client.pcap host server.example.com
# Capture on server
tcpdump -i eth0 -w server.pcap host client.example.com
# Compare:
# - Do packets leave client? (check client.pcap)
# - Do packets arrive at server? (check server.pcap)
# - If yes/no: problem is in the path between
# - If yes/yes but server doesn't respond: server-side issue
3. Geri Döngü Testi
Tek bir cihazdaki bağlantıyı test ederek harici değişkenleri ortadan kaldırın:
# Test TCP stack without network
ping 127.0.0.1
# Test application listening locally
telnet localhost 80
# Test loopback on network interface (if supported)
# Some NICs support physical loopback for Layer 1 testing
4. Bilinen-İyi Temel Karşılaştırmalar
Yapılandırmayı ve davranışı çalışan bir sistemle karşılaştırın:
# Compare interface settings
diff <(ssh working-switch "show run int gi1/0/1") \
<(ssh broken-switch "show run int gi1/0/1")
# Compare routing tables
diff <(ssh router1 "show ip route") \
<(ssh router2 "show ip route")
Sorun Giderme Esnasında Dokümantasyon
Doğru dokümantasyon, aynı şeyi farkında olmadan birden çok kez denediğiniz döngüsel hata ayıklamayı önler.
Sorun Giderme Şablonu
Sorun kimliği: TICKET-12345
Tarih/Saat: 2026-02-02 14:30 UTC
Bildiren: Jane Smith (jane.smith@company.com)
Etkilenen Kullanıcılar: ~50 users in Building A, 3rd floor
Belirti: Cannot access file server \\fileserver01
İlk Gözlemler:
- Issue started around 14:00 UTC
- Only affects Building A, 3rd floor
- Other buildings can access fileserver01
- Ping to fileserver01 (10.1.50.10) times out from affected users
- Ping to default gateway (10.1.30.1) succeeds
Yapılan Testler:
1. [14:35] Checked switch port status: gi1/0/15 is UP/UP
2. [14:38] Checked VLAN assignment: Port is in VLAN 30 (correct)
3. [14:42] Checked interface errors: 1,234 CRC errors on gi1/0/15
4. [14:45] Replaced patch cable - still seeing CRC errors
5. [14:50] Moved uplink to different port (gi1/0/16) - errors persist
6. [14:55] Checked fiber cleanliness - dirty connector found
Ana neden:
Dirty fiber connector on uplink between Building A floor switch
and distribution switch causing CRC errors and packet loss
Çözünürlük:
Cleaned fiber connector with proper cleaning kit. CRC errors
dropped to zero. File server access restored.
Doğrulama:
Users confirmed file server accessible. Monitored for 15 minutes
with no errors.
Çözüme Kadar Süre: 25 minutes
Gerçek Dünyadan Örnek Olay Çalışmaları
Örnek Olay 1: "Ağ Yavaş" (Aslında: TCP Penceresinin Tükenmesi)
Belirti
Veritabanı uygulaması yanıt süreleri <100 ms'den 5+ saniyeye düştü. Uygulama ekibi "ağ gecikmesini" suçladı.
İlk Varsayımlar (Yanlış)
- Ağ tıkanıklığı
- WAN bağlantısı doygun
- Güvenlik duvarı darboğazı
Teşhis Süreci
- Ping testi:RTT = 2 ms (mükemmel, Katman 3 gecikmesini hariç tutar)
- Bant genişliği testi (iperf):1 Gbps bağlantıda 950 Mbps (tıkanıklık yok)
- Paket yakalama:Veritabanı sunucusundan TCP Sıfır Pencere paketleri ortaya çıktı
- Sunucu denetimi:Veritabanı sunucusu alma arabellekleri = 64KB (minik!)
Ana neden
Veritabanı sunucusu işletim sistemi arabellekleri, yüksek bant genişliği x gecikmeli ürünler için çok küçüktü. TCP penceresi doluyor ve göndereni beklemeye zorluyordu.
Çözünürlük
# Increased TCP receive buffers on Linux database server
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.core.rmem_max=16777216
Öğrenilen Ders
Şunu varsaymayın:"Yavaş" her zaman "ağ gecikmesi" anlamına gelmez. Bir sonuca varmadan önce daima kanıt toplayın (gecikme için ping, davranış için paket yakalama).
Örnek Olay 2: Aralıklı Bağlantı (Aslında: Çift Yönlü Uyuşmazlığı)
Belirti
Sunucu bağlantısı özellikle yük altında rastgele kesiliyordu. Bazen iyi çalıştı, bazen tamamen tepkisiz.
İlk Varsayımlar (Yanlış)
- Başarısız NIC
- Kötü kablo
- Donanım sorununu değiştir
Teşhis Süreci
- Arayüz denetimi:Sunucu NIC = 1000/Tam, Anahtar bağlantı noktası = 1000/Yarım (uyumsuzluk!)
- Hata sayaçları:Anahtar bağlantı noktasında büyük çarpışma sayısı
- Geç çarpışmalar:Çift yönlü uyumsuzluk göstergesi
Ana neden
Otomatik anlaşma başarısız oldu. Sunucu tam çift yönlü anlaşmaya vardı, anahtar yarı çift yönlüye geri döndü. Çarpışmalar yalnızca yük altında her iki taraf da aynı anda iletim yapmaya çalıştığında meydana geldi.
Çözünürlük
! Cisco switch - force full duplex
interface GigabitEthernet1/0/10
speed 1000
duplex full
Öğrenilen Ders
Her iki ucu da kontrol edin:Arayüz durumu, üzerinde anlaşılan ayarları gösterir. Uyumsuzluk, otomatik anlaşmanın başarısız olduğu anlamına gelir. Sunucular için her zaman sabit kod hızı/çift yönlü.
Örnek Olay 3: "Bazı Web Sitelerine Ulaşılamıyor" (Aslında: MTU/PMTUD Black Hole)
Belirti
Kullanıcılar bazı web sitelerine (Google, Yahoo) göz atabilirken diğerlerine (banka web sitesi, şirket portalı) göz atamaz. Küçük HTTP istekleri işe yaradı, büyük sayfalar zaman aşımına uğradı.
İlk Varsayımlar (Yanlış)
- DNS sorunu
- Belirli siteleri engelleyen güvenlik duvarı
- İSS yönlendirme sorunu
Teşhis Süreci
- DNS çözünürlüğü:Tüm siteler için iyi çalışıyor
- Ping testi:"Ulaşılamaz" sitelere ping atabilir
- Küçük HTTP isteği (kıvrılma):Küçük sayfalar için çalışır
- Büyük indirme:TCP anlaşmasından sonra duruyor
-
MTU testi:
ping -M do -s 1472başarılı,ping -M do -s 1473başarısız - ICMP izleme:"Parçalanma Gerekli" (Tip 3 Kod 4) mesajı alınmadı
Ana neden
VPN tüneli MTU'yu 1400'e düşürdü, ancak güvenlik duvarı ICMP "Parçalanma Gerekli" mesajlarını engelliyordu. Path MTU Discovery (PMTUD) çalışamadı ve bir MTU kara deliği yarattı. Küçük paketler sığar, DF bit seti olan büyük paketler sessizce bırakılır.
Çözünürlük
! Implemented TCP MSS clamping on router
interface Tunnel0
ip tcp adjust-mss 1360
! Alternative: Allow ICMP Type 3 Code 4 through firewall
access-list 101 permit icmp any any packet-too-big
Öğrenilen Ders
Boyut önemlidir:Küçük istekler işe yarıyor ancak büyük aktarımlar başarısız oluyorsa MTU/parçalanma sorunlarından şüphelenin. MTU yolunu test etmek için DF bitiyle ping kullanın.
Örnek Olay 4: VoIP Kalite Sorunları (Aslında: QoS Yanlış Yapılandırması)
Belirti
Sesli aramalarda ses kesintileri ve aralıklı kesintiler vardı. Yalnızca mesai saatlerinde (sabah 9'dan akşam 5'e kadar) meydana geldi.
İlk Varsayımlar (Yanlış)
- Yetersiz bant genişliği
- VoIP sunucusu aşırı yüklendi
- İSS bağlantı kalitesi
Teşhis Süreci
- Bant genişliği testi:Bağlantının yalnızca %40'ı yoğun saatlerde kullanılıyor
- QoS denetimi:Ses trafiği DSCP EF (46) ile doğru şekilde işaretlendi
- Kuyruk denetimi:Ses kuyruğunda yalnızca %5 bant genişliği tahsisi vardı (%33 olmalıdır)
- Paket yakalama:Tıkanıklık sırasında ses paketleri kesiliyor
Ana neden
QoS politikası mevcuttu ancak bant genişliği tahsisi geriye doğruydu: en iyi çaba %60'ı aldı, ses ise %5'i aldı. Veri trafiğinin arttığı iş saatlerinde kuyruk taşması nedeniyle ses paketleri düşürüldü.
Çözünürlük
! Corrected QoS policy
policy-map WAN-QOS
class VOICE
priority percent 33
class VIDEO
bandwidth percent 25
class CRITICAL-DATA
bandwidth percent 20
class class-default
bandwidth percent 22
Öğrenilen Ders
Zamana dayalı sorunlar = kapasite:Sorunlar yalnızca yoğun saatlerde ortaya çıkıyorsa, bu ciddi bir arıza değil, kapasite/QoS sorunudur. Yalnızca toplam bant genişliğini değil, kuyruk istatistiklerini de kontrol edin.
Belirtiye Göre Komut Referansı
| Belirti | Katman | Çalıştırılacak Komutlar | Nelere Bakılmalı? |
|---|---|---|---|
| Bağlantı ışığı yok | Katman 1 | show interfaces |
Durum: çalışmıyor, taşıyıcı yok, kablo takılı değil |
| Paket kaybı | Katman 1/2 | show interfaces |
CRC hataları, runtlar, devler, çarpışmalar, geç çarpışmalar |
| Ağ geçidine ping işlemi yapılamıyor | Katman 2 | arp -a |
ARP girişi yok, MAC öğrenilmedi, STP engelleniyor |
| Uzak alt ağa erişilemiyor | Katman 3 | traceroute |
Eksik rota, yanlış sonraki atlama, yönlendirme döngüsü |
| bağlantı reddedildi | Katman 4 | telnet host port |
Hizmet dinlemiyor, güvenlik duvarı engelleniyor, TCP RST |
| Yavaş performans | Katman 4+ | ping (RTT) |
Yüksek gecikme, bant genişliği sınırı, TCP yeniden iletimleri, sıfır pencere |
| Ana makine adı çözülemiyor | Katman 7 | nslookup |
DNS sunucusuna erişilemiyor, yanlış DNS yapılandırması, NXDOMAIN |
| Aralıklı düşüşler | Katman 1/2 | ping -f (flood) |
Çift yönlü uyumsuzluk, arızalı kablo, STP yeniden yakınsaması |
| Bazen çalışıyor, diğerleri çalışmıyor | Çoklu | Extended ping |
Yük dengeleme sorunu, ECMP asimetrisi, durum tablosu taşması |
Ne Zaman Yükseltilmeli
Satıcı TAC'ye veya kıdemli mühendislere ne zaman ileteceğinizi bilin. Şu durumlarda üst kademeye iletin:
- Bilgi tabanınızdaki tüm sorun giderme adımlarını tükettiniz
- Sorun, sahip olmadığınız erişim/izinleri gerektiriyor
- Sorun, satıcının yazılım hatası veya donanım kusurunu içeriyor
- İş etkisi kritiktir ve zamana duyarlıdır
- Birden fazla ekibin işbirliği yapması gerekiyor (uygulama + ağ + sunucu)
- Tam semptom açıklaması
- Sorunun başladığı zamanı gösteren zaman çizelgesi
- Tanılama komutları çalıştırılır ve çıktıları
- Yapılandırma yedekleri
- Paket yakalamaları (ilgiliyse)
- Zaten denediğiniz şey
Kişisel Bilgi Tabanınızı Oluşturmak
Her sorun giderme oturumu bir öğrenme fırsatıdır. Kişisel bir bilgi tabanı oluşturun:
1. Sorun Giderme Günlüğü Oluşturun
# Example structure
~/troubleshooting-journal/
├── 2026-01-15-duplex-mismatch.md
├── 2026-01-22-mtu-black-hole.md
├── 2026-02-02-tcp-window-exhaustion.md
└── README.md # Index of all issues
# Each file contains:
# - Symptom
# - Diagnostic steps
# - Root cause
# - Resolution
# - Lessons learned
# - Related tickets/documentation
2. Bir Komut Kopya Kağıdı Oluşturun
Sorun giderme sırasında hızlı başvuru için sık kullanılan komutları senaryoya göre düzenleyin.
3. Ağınızı Belgeleyin
- Topoloji diyagramları (Katman 2 ve Katman 3)
- IP adresi şeması belgeleri
- VLAN atamaları
- Standart konfigürasyonlar (şablonlar)
- Bilinen iyi temeller (sorunlardan önceki arayüz istatistikleri)
Kaçınılması Gereken Yaygın Anti-Desenler
❌ YAPMAYIN: Teşhis koymadan rastgele değişiklikler yapmayın
Sorunu anlamadan konfigürasyonları değiştirmek çoğu zaman işleri daha da kötüleştirir veya asıl sorunu maskeler.
❌ YAPMAYIN: Ağın her zaman hatalı olduğunu varsaymayın
Genellikle "ağ sorunları" uygulama, sunucu veya istemci tarafı sorunlarıdır. Suçlamayı kabul etmeden önce kanıt toplayın.
❌ YAPMAYIN: Sorun giderme adımlarınızı belgelemeyi atlayın
Daha önce yaptığınız testleri tekrarlayarak zaman kaybedeceksiniz veya meslektaşlarınıza ne denediğinizi açıklayamayacaksınız.
❌ YAPMAYIN: Aralıklı sorunları görmezden gelin
Aralıklı sorunlar genellikle yaklaşan arızanın erken uyarı işaretleridir. Kritik hale gelmeden önce bunları araştırın.
❌ YAPMAYIN: Temel nedenler yerine semptomları düzeltin
Bir cihazı yeniden başlatmak hizmeti geri yükleyebilir, ancak NEDEN yeniden başlatılması gerektiğini öğrenmezseniz sorun tekrarlanacaktır.
Özet: Sistematik Sorun Giderme Kontrol Listesi
✓ Başlamadan Önce
- Beş temel soruyu yanıtlayın (Ne değişti? Kim etkilendi? Sürekli mi yoksa aralıklı mı? Tekrarlanabilir mi? Karşı taraf ne görüyor?)
- İlk belirtileri ve kullanıcı raporlarını toplayın
- Son değişiklikleri veya bakımı kontrol edin
✓ Sorun Giderme Sırasında
- OSI katmanları aracılığıyla metodik olarak çalışın (aşağıdan yukarıya veya yukarıdan aşağıya)
- Test sırasında bir seferde BİR değişkeni değiştirin
- Her testi ve sonucunu belgeleyin
- Gerçek trafik davranışını görmek için paket yakalamaları kullanın
- Bilinen iyi temellerle karşılaştırın
✓ Çözümden Sonra
- Düzeltmenin sorunu gerçekten çözdüğünü doğrulayın
- Belgenin temel nedeni ve çözümü
- Bilgi tabanınızı güncelleyin
- Yapılandırma değiştiyse belgeleri güncelleyin
- Şunu düşünün: İzleme bunu daha önce yakalayabilir miydi?
Çözüm
Ağ sorun giderme hem bilim hem de sanattır. Bilim sistematik bir metodoloji izliyor, teşhis araçlarını doğru kullanıyor ve protokolleri anlıyor. Sanat, semptomlara dayanarak ilk önce hangi testlerin yapılacağını bilmek, deneyimlerden gelen kalıpları tanımak ve ne zaman tırmandırılacağını bilmektir.
Bu makalede özetlenen sistematik yaklaşımı takip ederek (doğru soruları sorarak, OSI modeliyle metodik olarak çalışarak, adımlarınızı belgeleyerek ve her sorundan öğrenerek) sorun gidermede daha verimli hale gelecek ve zaman kaybına ve yanlış düzeltmelere yol açan yaygın tuzaklardan kaçınacaksınız.
Hatırlamak:Amaç yalnızca hizmeti geri yüklemek değil, aynı zamanda NEDEN başarısız olduğunu anlamak ve böylece bunun tekrar olmasını önlemektir.
Son Güncelleme: 2 Şubat 2026 | Yazar: Baud9600 Teknik Ekibi