İçeriğe geç
Saha Orta 8 dk okuma

Router Cevap Vermediğinde — ISP'nin 02:17'si

3.000 aboneyi etkileyen bir ağ arızası, bir gece yarısı acil müdahalesi ve yolda öğrendiklerim. Saha notu.

Erdem Özyurt

Saat 02:17’ydi.

Telefon çaldı. Ekranda müşteri numarası. Uyku sisi henüz dağılmadan kaldırdım.

“Ağ çöktü. Hiç kimse bağlanamıyor.”

Kaç abone? diye sormak için bile tam uyanamamıştım. Ancak cevabı zaten biliyordum — bu müşterinin ağında 3.000’e yakın son kullanıcı vardı. Bir router cevap vermiyorsa, o router’ın arkasındaki her ev, her işyeri, her kamera sistemi aynı anda karanlığa düşüyordu.

Bilgisayarı açtım. Zabbix ekranı yüklendi. Kırmızı.


Sahaya Çıkmadan Önce: 7 Dakikalık Protokol

Araçlara atlayıp sahaya koşmak cazip gelir. Gece yarısı, adrenalin yüksek, müşteri bekliyor. Ne var ki sahaya çıkmadan önce 7 dakika harcanan analiz, saatlerce körü körüne arama yapmaktan değerlidir.

Şu sorulara cevap bulmaya çalışıyorum:

  1. Etki alanı ne kadar geniş? Tek bir nokta mı, yoksa backbone mı?
  2. Son değişiklik ne zaman yapıldı? Bir yapılandırma değişikliği mi başlattı bunu?
  3. Log’lar ne diyor? RouterOS’ta /log print genellikle her şeyi söyler.
  4. OOB erişim var mı? Cihaza ağ olmadan ulaşabilecek miyim?

Bu gece Zabbix haritası bir şeyi açıkça gösteriyordu — arıza backbone’dan değil, dağıtım katmanından geliyordu. Ana router ayaktaydı. Onun altındaki bir dağıtım anahtarı değildi — ama o anahtardan beslenen bir aggregation cihazı sessizleşmişti.

Fiziksel mi, yazılım mı?

SSH denedim. Cevap yok. Ping yok. SNMP yok.

Fiziksel. Saha gerekiyor.


Yolda: Asıl Düşünce Burada Olur

Gece yarısı boş yolda araç sürerken aklım cihazın geçmişinde geziniyordu.

Bu aggregation switch’in son 6 ayda iki kez restart atmış olduğunu hatırladım. Her seferinde “açıklanamayan” bir sebep. Log’larda memory usage yüksekmiş — not almıştık, ama birikimli etkiyi ciddiye almamıştık.

“Her açıklanamayan olay açıklanmamış bir sorundur. Sadece henüz bulamamışsınızdır.”

— Ağ mühendisleri arasında dolaşan bir söz

Cihazın firmware versiyonu 3 major release geriydi. Üretici o sürüm için bilinen bir memory leak raporlamıştı. Yamayı ertelemiştik — “stabil çalışıyor” diye.

Stabil çalışıyor en tehlikeli yanılsamadır. Sistem çökmeden önce genellikle aylarca “stabil çalışır.”


Sahada: Ne Buldum

Cihaz fiziksel olarak açıktı — LED’ler yanıyordu, fan dönüyordu. Console kablosuyla bağlandığımda beni karşılayan şey donmuş bir ekrandı. Kernel panic. Watchdog tetiklenmişti ama otomatik restart çalışmamıştı.

Manuel restart verdim. 90 saniye bekledim — sistem ayağa kalktı.

Gerçi bu arızanın gerçek çözümü değildi — sadece acil müdahalesiydi.

Asıl sorun şuydu: cihaz 47 gündür kesintisiz çalışıyordu ve memory kullanımı giderek artmıştı. Bir process birikimli memory tutuyordu, serbest bırakmıyordu. 47. günün sonunda sistem artık yeni paket işleyemez hale geldi.


Teknik Not: Memory Leak’i Nasıl İzlersiniz

MikroTik RouterOS’ta bu tür sorunları erken tespit etmek için:

# Anlık kaynak durumu
/system resource print

# Uzun süreli izleme için Zabbix OID:
# 1.3.6.1.4.1.14988.1.1.1.4 — memory kullanımı
# Eşik: %80 üzeri 15 dakika sürede alarm

# Problematic process'i tespit
/system resource monitor

Kritik eşikler belirleyin:

  • %70 → Uyarı seviyesi
  • %85 → Kritik, müdahale planı tetikle
  • %95 → Otomatik scheduled restart (mesai dışı saatler için)

Asıl Çözüm: Ertelenen Bakım

Sabah ekibi sahaya gönderdiğimde görevleri netti:

  • Firmware güncellemesi (bilinen memory leak yaması)
  • Scheduled restart politikası (pazar 03:00)
  • SNMP memory threshold alert eklenmesi
  • Yedek cihaz hazırlanması (bu sınıf cihaz için elde yedek bulunmuyor — tedarik başlatıldı)

Arızayı çözmek 90 saniye sürdü.

Önlemek? 6 ay önce 20 dakika yeterliydi.


Sonuç: Gece Yarısı Öğretir

Her gece yarısı araması bir şey öğretir. Bu gece öğrendiğim:

Stabil görünen sistem güvenli değildir. Sadece henüz çökmemiştir.

İzleme sistemleri trend analizi yapmalı — yalnızca “açık/kapalı” değil, “açıksa nasıl açık” sorusunu sormalı. Memory kullanımı artıyor mu? CPU spike’ları var mı? Bu trendler hafta önce, ay önce neredeydi?

Saha deneyiminin bana verdiği en değerli şey bu: Log’ları okumak bir alışkanlık olmalı, kriz anında değil, her sabah.

Artık 04:30’du. Kahve soğumuştu. Bağlantı geri gelmişti.

3.000 abone uyuyordu — ve muhtemelen hiç fark etmemişlerdi.


Kendin Uygula

Bu arızadan öğrenilen üç pratik adım:

  • Zabbix/PRTG’de memory trend grafiği kur — son 7/30 günü karşılaştır
  • Kritik cihazlar için scheduled maintenance window belirle
  • Firmware güncellemelerini “stabil çalışıyor” gerekçesiyle erteleme
#isp #ariza-yonetimi #mikrotik #network #saha
Paylaş: 𝕏 Twitter LinkedIn

Sıkça Sorulan Sorular

ISP ağ arızalarında ilk yapılması gereken nedir?

İlk adım etki alanını belirlemektir — kaç abone, hangi bölge, hangi ekipman. Panik yapmadan önce log'lara bakın ve son yapılan değişikliği sorgulayın. Çoğu arızanın arkasında yapılandırma hatası ya da fiziksel bağlantı sorunu yatar.

MikroTik router'da ani erişim kaybı neden olur?

En yaygın sebepler şunlardır — yanlış yapılandırılmış routing table, BGP session düşmesi, bellek dolması (memory leak), ve fiziksel hat arızası. RouterOS logları ile SNMP trap'leri bu arızaları erken tespit etmenizi sağlar.

Gece arızalarına karşı nasıl hazırlıklı olunur?

Monitoring sistemi (Zabbix/PRTG) için SMS alert kurulumu, kritik cihazlar için offline yedek config, OOB (Out-of-Band) yönetim erişimi ve anlaşılır bir eskalasyon protokolü — bu dört şey gece arızalarını tolere edilebilir kılar.

Erdem Özyurt

IT Danışmanı · ISP Altyapı · Siber Güvenlik

Kablo döşemekten kod yazmaya, ağ tasarımından web geliştirmeye — Layer 1'den Layer 7'ye bütünlük içinde çalışıyorum.

Hakkımda daha fazla →