Sunucu donanım yenilemesi ne zaman yapılmalı? Net kontrol listesi

Sunucu donanım yenilemesi “ne zaman değiştirsem iyi olur?” sorusuna tek bir tarih vermez. Doğru zaman; uygulamanın kaynak kullanımı, disk performansı, ağ gecikmesi, yedekleme pencereleri ve toplam maliyeti birlikte değerlendirilince netleşir. Bu rehberde, mevcut sunucunuzda somut ölçüm yaparak yenileme ihtiyacını belirleyeceğiniz kriterleri ve uygulanabilir aksiyon adımlarını bulacaksınız.

Donanım yenilemesi gerekip gerekmediğini ölçen 6 sinyal

Donanım yenilemesini belirlemek için tek bir göstergeye değil, birbirini doğrulayan sinyallere bakın. Aşağıdaki kontrolleri tek tek uyguladığınızda “beklemek mi, plan yapmak mı, hemen upgrade mi?” ayrımı netleşir.

1) CPU kullanımında dalgalı yükseliş ve darboğaz

Sadece ortalama CPU kullanımına bakmayın. Uygulama dönemsel olarak pik yapıyorsa ve bu piki yönetemiyorsa yenileme gerekir.

Kontrol kriterleri (genel): - Son 30 günde CPU kullanımının sık şekilde %70-%90 bandına çıkması - CPU pikleri sırasında uygulama yanıt sürelerinde (latency) belirgin artış - “Run queue / load average” değerinin çekirdek sayısına göre sürekli yüksek kalması

Net yorum: - CPU tamamen doygunsa (sürekli yüksek) yalnızca yazılım ayarlarıyla çözüm kısa vadeli kalır. - CPU doygunluğu disk veya ağ darboğazını da maskeleyebilir; sonraki sinyallerle doğrulayın.

2) RAM yetersizliği: swap (takas) artışı ve performans dalgalanması

RAM yetersizliği en pahalı semptomlardan biridir. Linux’ta swap’a düşüş, disk IOPS’a yük bindirir ve uygulama gecikmelerini büyütür.

Kontrol kriterleri: - Swap (takas) kullanımı sürekli aktif - Swap kullanımının artmasıyla birlikte yanıt sürelerinde salınım - Yüksek sayıda OOM (Out Of Memory) olayı veya uygulama restartları

Net yorum: - Swap’a düşen sistemde “küçük ayar” çoğu zaman yetmez; RAM artırımı veya bellek ihtiyacını azaltan optimizasyon gerekir. - RAM yetersizliği varsa disk yenilemesi tek başına sorunu çözmez.

3) Disk IOPS ve gecikme: en sık gözden kaçan yenileme sebebi

Uygulama için en kritik kaynak çoğu zaman depolamadır: veritabanı, log yazımı, cache invalidation ve yedekleme aynı diski kullanır.

Özellikle şu sorunlarda donanım yenileme konuşulur: - Veritabanı sorguları sırasında disk latency artışı - Log ve index işlemleri nedeniyle yoğun yazma - “Disk IOPS” tavanına dayanma

Net ölçüm yaklaşımı: - IOPS ölçümü için iostat, performans için ioping benzeri araçlar kullanın. - Cloud / sanallaştırılmış ortamlarda bile “disk bekleme” (await) metriği yön gösterir.

4) Depolama kapasitesi değil, kapasite artış hızı

Kapasite doluyor olmak yenileme için güçlü bir tetikleyicidir; ama daha önemlisi dolma hızıdır.

Kontrol kriterleri: - Mevcut trend ile 3-6 ay içinde disk dolum riski - Log rotasyonu yetersizliği: günlük log birikimi beklenenden hızlı - Veritabanında büyüme eğrisi kontrol edilemiyor (index + bloat)

Net yorum: - “Hemen yenile” kararı için dolum tahminini görmeniz gerekir. - Disk dolmadan yenilemek genellikle daha maliyet-etkindir; çünkü performans düşmeden plan yapılır.

5) Ağ performansı: bant genişliği kadar gecikme (latency)

Ağ sorunları çoğu zaman CPU veya disk gibi görünür. Özellikle CDN, mail, sync, replikasyon ve yük dengeleme kullanan sistemlerde ortaya çıkar.

Kontrol kriterleri: - Paket kaybı (packet loss) ve yüksek retransmit - TLS el sıkışması ve veri aktarımı sırasında gecikme artışı - 1 Gbit link üzerinde bile “çok daha düşük efektif hız”

Net yorum: - Ağ tıkanıklığı “daha hızlı NIC” ile çözülebilir ama çoğu zaman upstream, switch, veri merkezi altyapısı veya hat kontrolleri gerekir. - Yenileme kararı vermeden önce ağ trafiğini ölçün.

6) İşletme riski: yedekleme penceresi ve kurtarma süreleri (RTO/RPO)

Donanım yenilemesinin en güçlü gerekçelerinden biri güvenlik değil, kurtarma kabiliyetidir.

Kontrol kriterleri: - Yedekleme süresi her ay uzuyor ve pencereyi aşıyor - Kurtarma testi yapılmadı veya kurtarma (restore) süresi hedefin üstünde - Restore sırasında disk I/O darboğazı yaşanıyor

Net yorum: - “Çalışıyor” olması donanım yenilemesini gereksiz yapmaz. - RTO/RPO hedefleri tutmuyorsa yenileme (veya mimari değişiklik) zorunlu hale gelir.

Yenileme zamanını belirlemek için 30 günlük ölçüm planı

Aşağıdaki plan, veri toplamayı hızlandırır ve kararınızı ölçülebilir hale getirir.

Adım adım: ölçüm ve kayıt

1. Hedef sistemleri seçin: DB, uygulama web katmanı, dosya depolama, log toplama, mesajlaşma.
2. 30 gün boyunca günlük şu metrikleri kaydedin: - CPU: ortalama + en yüksek (peak) - RAM: swap kullanımı, OOM sayısı - Disk: IOPS, await/latency - Ağ: packet loss, aktarım süresi, retransmit - Yedekleme: süre, başarısızlık sayısı
3. Her metrik için aynı zaman dilimlerini karşılaştırın: - Gün sonu batch işleri - Yoğun saatlerde pikler - Yedekleme penceresi

Yenileme eşiği: “tek bir gün” yerine trend

Tek bir gün hata aldı diye yenileme kararı vermeyin. Net eşiği trend belirler: - 2-3 hafta boyunca aynı aralıkta piklerin tekrarlanması - Yedekleme süresinin düzenli uzaması - Swap kullanımının düzenli artması

Donanım yenilemesi yerine önce ne yapılmalı?

Her performans sorunu “donanım” değildir. Aşağıdaki optimizasyonlar çoğu zaman yenileme ihtiyacını geciktirir ya da tamamen ortadan kaldırır.

H3) Veritabanı ve disk yazımı kaynaklı tıkanmaları düzeltin

• Index eksikleri veya gereksiz index şişkinliği (bloat)
• Sık çalışan sorgularda yanlış execution plan
• Log yazımı ve yedekleme için aynı disk üzerinden aşırı I/O

Net aksiyon: DB ölçümleri (slow query), index incelemesi ve sorgu plan analizi yapın. Bu adım sonuç vermiyorsa disk/IOPS yenileme planı gündeme gelir.

H3) RAM ve cache stratejisini netleştirin

• Gereksiz cache flush döngüleri
• Uygulama düzeyi cache boyutunun düşük kalması
• Swap’a düşüşün kök sebebini tespit edin

Net aksiyon: Swap artışı düzenliyse önce bellek optimizasyonu; düzelmiyorsa RAM artırımı veya doğru instance boyutu planlayın.

H3) Yedekleme mimarisini yeniden kurun

• Full backup yerine incremental / differential
• Yedekleri farklı diske veya farklı depolama katmanına alma
• Restore testini periyodik hale getirme

Net aksiyon: Yedekleme penceresi aşımı devam ediyorsa donanım hızlanması veya depolama/IOPS artırımı gerekir.

Yenileme türleri: upgrade mi, yeni sunucu mu?

Donanım yenilemesi tek bir formda değildir. Kararı doğru türleştirmek için aşağıdaki tabloyu kullanın.

En pratik karar çerçevesi: “Şu durumda yenileyin”

Aşağıdaki maddeler net karar üretir. Kuralları kendi sisteminizin metriğiyle eşleştirin.

Aşağıdakiler varsa donanım yenilemesini planlayın

• Yedekleme penceresi düzenli olarak aşılıyor ve hedef restore süresi (RTO) tutmuyor
• Swap kullanımı kalıcı ve performans dalgalanması yaratıyor
• Disk gecikmesi ve I/O bekleme (await) yoğun saatlerde belirgin biçimde yükseliyor
• CPU pikleriyle birlikte uygulama yanıt süreleri arasında doğrudan ilişki var ve trend 30 günde azalmıyor
• Disk dolma riski 3-6 ay içinde gerçek (büyüme trendi ölçüldü)

Aşağıdakiler varsa önce optimizasyonla başlayın

• Ortalama CPU yüksek ama pik saatleri sınırlı ve disk/ram swap temiz
• Yedekleme aralığı doğru ama bir gün/iki gün anlık sorunlar yaşanıyor
• Ağ sorunları ölçümlerde görünmüyor; yalnızca uygulama tarafında hatalar var

Uygulama planı: yenilemeden sonra kesintiyi nasıl sıfıra yaklaştırın

Donanım değişimi yapılınca risk oluşur. Bu riski yönetmek için aşağıdaki sırayı izleyin.

H3) Kesintisiz geçiş için temel kontrol listesi

• Mevcut sistemden yedek (backup) alın ve mutlaka restore testi yapın
• Uygulama için sürüm ve konfigürasyon dokümantasyonu çıkarın
• Yeni sistemde metrikleri (CPU/RAM/disk/network) aynı yük senaryosuyla doğrulayın
• Veri tabanı geçişinde migrasyon süresini hesaplayın
• Geçiş sonrası ilk 24 saat gözlem planı oluşturun

H3) Başarı kriterleri

Yenileme sonrası şu hedefleri tutturmaya çalışın: - Aynı iş yükünde disk latency belirgin şekilde düşmeli - Yedekleme süresi hedef pencereye dönmeli - Restore işlemi daha kısa sürede tamamlanmalı - Uygulama yanıt sürelerinde pik saatlerindeki iyileşme ölçülmeli

Sonuç: Bugün aksiyon alın, 30 gün içinde kararınızı netleştirin

Sunucu donanım yenilemesi için “tahmin” değil, 30 günlük ölçüm temel alın. CPU/RAM/disk/ ağ ve özellikle yedekleme-RTO/RPO trendlerine bakarak yenileme eşiğini belirleyin. Eğer swap kalıcı, disk I/O bekleme yüksek veya yedekleme penceresi düzenli aşımı yaşıyorsanız yenileme planını bugün başlatın; önce kısa optimizasyonlarla birlikte ilerleyin ve geçişten sonra aynı metriklerle doğrulayın.

Kararı hızlandırmak için: Mevcut sisteminizde son 30 gün metriklerini (CPU, swap, disk IOPS/await, yedekleme süresi) çıkarın ve bu rehberdeki tabloya göre eşleştirin.