Kurumsal ağlarda kapasite problemi çoğu zaman bağlantı doygunluğundan önce görünmez bir davranış değişimi olarak başlar. Yedek hat devreye girer, east-west akışları farklı yollara kayar, backup penceresi uzar ve latency önce küçük sıçramalar üretir. Buna rağmen birçok ekip backbone kapasitesini hâlâ “arayüz kullanım yüzdesi” seviyesinde izler. Oysa omurga planlaması yalnızca bant genişliği değil, trafik sınıfı, büyüme paterni ve dayanıklılık senaryosu birlikte okunarak yapılmalıdır.
Neden klasik yüzde bazlı izleme yetersiz?
Çünkü omurga hatları çoğu zaman düzenli ve tek biçimli trafik taşımaz. Gündüz saatlerinde uygulama trafiği, gece backup ve replikasyon, kriz anında ise failover akışları dominant hâle gelir. Aynı ortalama kullanım değeri üç farklı risk anlamına gelebilir.
Bu yüzden kapasite planlamasının ilk adımı, trafikteki ana sınıfları ayırmaktır:
- Kullanıcı ve uygulama trafiği
- Veri replikasyonu ve batch kopyalama
- Yönetim ve gözlemlenebilirlik akışı
- Felaket anında devreye girecek yedekleme yolları
Sadece toplam Mbps bakıldığında bu katmanlar birbirini gizler.
Sağlıklı model hangi girdilerle kurulur?
Ben omurga kapasite planlamasında dört veri kaynağını birlikte okumayı faydalı buluyorum:
- P95 ve P99 arayüz kullanımı
- Trafik sınıfı bazında zaman dilimi deseni
- Failover veya bakım anındaki alternatif yol yükü
- İş büyümesiyle ilişkili hacim sürücüleri
Özellikle üçüncü madde kritiktir. Çünkü birçok ağ tasarımı normal koşulda rahat görünür ama tek uplink kaybında bir anda darboğaz üretir. Omurga planlaması yalnızca mutlu gün grafiğiyle yapılamaz.
Kapasite eşiği nasıl tanımlanmalı?
Kurumlar genelde yüzde 70 veya yüzde 80 gibi tek eşiklerle hareket eder. Bu pratik ama eksiktir. Daha iyi yöntem, trafik sınıfına göre üç eşik tanımlamaktır:
- Normal çalışma eşiği
- Bakım ve yeniden yönlenme eşiği
- Acil durum taşıma eşiği
Örneğin veri merkezi omurgasında gündelik kullanım yüzde 45 iken, tek spine kaybında yüzde 78’e çıkılıyorsa sistem bugün sağlıklı ama büyüme açısından kırılgandır. Bu ayrım yapılmadığında yatırım hep geç kalır.
Observability katmanı neden doğrudan etkili?
Çünkü kapasite planlaması geçmişin raporu değil, geleceğin uyarısıdır. NetFlow, sFlow, queue drop, interface error ve latency ölçümleri tek tabloda okunmuyorsa, problem ancak kullanıcı etkisi oluştuğunda görünür. Özellikle şu sinyaller birlikte ele alınmalıdır:
- Aynı yol üzerinde büyüyen mikroburst davranışı
- Queue discard ile artan uygulama timeout ilişkisi
- Failover testleri sırasında route değişimi ve throughput farkı
- Backup ve observability akışlarının çakıştığı saatler
Bu görünürlük yoksa kapasite sorunu ağ ekibinin değil tüm platformun geç fark ettiği bir darboğaza dönüşür.
Kurumsal mimaride karar anı nasıl gelir?
Yatırım kararı vermek için portun tam dolması beklenmemelidir. Daha doğru yaklaşım, belirli senaryolarda taşıma emniyet payının nereye indiğini görmek ve bunun üzerine karar vermektir. Ben şu soruları etkili buluyorum:
- Tek uplink kaybında hangi iş yükü ilk önce bozulur?
- Önümüzdeki iki çeyrekte hangi proje trafiği kalıcı artırır?
- QoS tanımı gerçekten kritik akışları koruyor mu?
- Yeni kapasite mi, daha iyi trafik ayrıştırması mı daha doğru yatırım?
Bu sorular omurga planlamasını cihaz sayısından çıkarıp mimari karar seviyesine taşır.
Sonuç
Kurumsal ağlarda backbone kapasite planlama modeli, yalnızca arayüz grafiği okumak değildir. Trafik sınıflarını, failover davranışını, iş büyümesini ve observability sinyallerini aynı çerçevede topladığınızda yatırım kararları daha erken ve daha savunulabilir hâle gelir. Omurga tasarımında gerçek dayanıklılık, link dolduktan sonra değil dolmadan önce doğru modeli kurduğunuz anda başlar.