"Ağ Yavaş" Bir Teşhis Değildir

Kullanıcıdan gelen "internet yavaş" bildirimi bir semptomdur, teşhis değil. Aynı cümlenin arkasında birbirinden bağımsız en az dört farklı sorun olabilir ve her birinin çözümü diğerini hiç etkilemez. Ölçmeden yapılan müdahale, en iyi ihtimalle işe yaramaz; çoğu zaman yeni sorun üretir.

Önce ayrıştırın

Sorunu dört başlıkta ayırmak, çözüm alanını dramatik biçimde daraltır:

• Gecikme (latency) — paket gidip geliyor ama geç geliyor. Mesafe, yönlendirme yolu veya cihaz üzerindeki işleme süresi kaynaklı olabilir.
• Paket kaybı — paket hiç ulaşmıyor. Fiziksel katman, doygunluk veya hatalı yapılandırma işaretidir.
• Doygunluk (congestion) — hat kapasitesi doluyor, kuyruklar büyüyor. Gecikme ve kayıp birlikte artar.
• Uygulama katmanı — ağ sağlıklı, sorun sunucu, DNS çözümlemesi veya uygulamanın kendisindedir.

Arayüz sayaçları ilk bakılacak yerdir

Pahalı bir araç kurmadan önce, cihazlarınızın zaten topladığı veriye bakın. Arayüz üzerindeki hata sayaçları çoğu fiziksel sorunu doğrudan gösterir:

# Cisco IOS
show interfaces | include (^[A-Z]|error|drops|CRC|resets)

# Juniper JunOS
show interfaces extensive | match "Physical|Errors|Drops|CRC"

# Linux
ip -s -s link show dev eth0

Artan CRC hataları neredeyse her zaman fiziksel bir sorunu işaret eder: kötü bir kablo, kirli bir fiber konnektörü ya da uyumsuz optik. Input drops kuyruk taşmasını, output drops ise çıkış hattının dolduğunu gösterir. Bu üçünü ayırt etmek, sorunu doğru katmana taşımanızı sağlar.

Gecikmeyi doğru ölçmek

Tek bir ping çıktısı yanıltıcıdır. Anlamlı olan, zaman içindeki dağılımdır: ortalama gecikme kabul edilebilirken jitter yüksekse, ses ve görüntü trafiği bozulur ama dosya transferi normal görünür — kullanıcı da haklı olarak "bazen yavaş" der.

Uçtan uca ölçüm için hop bazlı kayıp ve gecikme veren araçlar kullanın:

# Hop bazli surekli olcum
mtr --report --report-cycles 200 hedef.example.com

# Jitter ve kayip icin uzun sureli ornek
ping -i 0.2 -c 1000 hedef.example.com | tail -3

Trafiğin kim tarafından üretildiğini görün

Hat doluysa asıl soru şudur: neyle dolu? NetFlow, sFlow veya IPFIX ile akış verisi toplamak, bant genişliğini hangi kaynağın, hangi hedefe, hangi uygulama için tükettiğini gösterir. Bu veri olmadan yapılan kapasite artırımı, çoğu zaman aynı sorunun daha pahalı hâlini satın almaktır.

Pratikte sık karşılaştığımız tablo: hattın yarısını yedekleme trafiği ya da kontrolsüz bir güncelleme dağıtımı tüketiyordur. Bu durumda çözüm kapasite değil, zamanlama ve QoS politikasıdır.

Ölçmeden önce ve sonra

Her müdahalenin öncesinde referans ölçüm alın. Değişiklikten sonra aynı ölçümü tekrarlayın. "Daha iyi oldu" ifadesi bir sonuç değildir; "p95 gecikme 84 ms'den 31 ms'ye indi, paket kaybı %1.2'den %0'a düştü" bir sonuçtur. Bu disiplin hem doğru çalıştığınızı kanıtlar hem de bir sonraki sorunda elinizde karşılaştırma noktası bulunmasını sağlar.