VPS Kesintisine Ne Sebep Olur? Kontrol Edilmesi Gereken 9 Arıza
11 Kasım 2026 tarihinde yayımlandı
Bir VPS, birbirinden oldukça farklı çeşitli nedenlerle çalışmıyor gibi görünebilir. İlk yapılması gereken, gerçek bir sunucu arızasını uygulama, ağ veya DNS sorunundan ayırmaktır. VPS kesintisine genellikle tek ve büyük bir olay neden olmaz. Çoğu zaman küçük bir uyarı gözden kaçmıştır: disk alanı gece dolmuştur, bir veritabanı kullanılabilir belleğin tamamını tüketmiştir, bir güvenlik duvarı kuralı trafiği engellemiştir ya da üst ağdaki bir rota yanıt vermeyi kesmiştir.
En sağlıklı yaklaşım, hizmeti dışarıdan kontrol etmek, sunucu durumunu içeriden incelemek ve her ikisini de izleme geçmişiyle karşılaştırmaktır. Böylece biri yeniden başlatma düğmesine uzanmadan önce elinizde somut bilgiler olur. Yeniden başlatmanın yeri vardır ama kanıtları da ortadan kaldırabilir.
Uygulamada VPS Kesintisine Ne Sebep Olur?
Kesinti, kullanıcıların ihtiyaç duyduğu bir hizmetin kullanılamaması veya kullanılamayacak kadar yavaş olması demektir. Web sitesi, API, e-posta hizmeti veya veritabanı çalışmıyor olsa bile VPS'nin kendisi çalışmaya devam ediyor olabilir. Benzer şekilde, sunucu sağlıklı olabilir ancak ağ yolu veya DNS sorunu nedeniyle erişilemez durumda kalabilir.
Bu ayrım, bir olay sırasında önem taşır. Ana makine düğümü sağlıklıysa ve sanal makine konsolu üzerinden yanıt veriyor ancak genel internetten erişilemiyorsa, araştırılması gereken konu ağ ve güvenlik duvarı politikasıdır. Bellek tükendiği için makine süreçleri zamanlayamıyorsa suçlu genel ağ değildir. Doğru soruyu sorduğunuzda, günlükler de artık aynı şeyi anlatıyor olur.
1. Sanal makinede kaynakların tükenmesi
CPU, RAM, disk alanı, inode kapasitesi ve disk G/Ç kaynakları sınırlıdır. Ani trafik artışı, verimsiz bir sorgu, kontrolden çıkan bir arka plan işçisi veya boyutu kötü ayarlanmış bir önbellek bunlardan birini beklenenden daha hızlı tüketebilir.
Bellek baskısı özellikle yaygın bir sorundur. Linux, sistemi çalışır durumda tutmak için bellek yetersizliği sonlandırıcısını devreye sokup bir veritabanı veya uygulama sürecini sonlandırabilir. Müşteri açısından bu, kesinti gibi görünür. Takas alanı olmayan veya boyutu yetersiz bir sunucuda kısa süreli bir yük artışı tam kapsamlı bir kesintiye dönüşebilir.
Diskin dolması da benzer şekilde kafa karıştırıcı davranışlara yol açar. Günlükler yazılamaz, veritabanları değişiklikleri kabul etmeyi durdurabilir ve hizmetler yeniden başlatılırken başarısız olabilir. Inode'ları da kontrol etmek gerekir: milyonlarca küçük önbellek veya oturum dosyası, `df -h` kullanılabilir disk alanı gösterse bile yeni dosyaların oluşturulmasını engelleyebilir.
Çözüm her zaman “daha fazla kaynak satın almak” değildir. Daha fazla RAM doğru çözüm olabilir ama önce hangi iş yükünün neden büyüdüğünü belirleyin. Kapasite yalnızca sakin bir salı sabahına göre değil; olağan kullanıma, en yüksek kullanıma ve kurtarma payına göre belirlenmelidir.
2. Uygulama ve veritabanı arızaları
VPS'nin çalışıyor olması, uygulamanın da çalışacağını garanti etmez. Web sunucularında çalışan işçi süreçleri tükenebilir, PHP havuzları takılabilir, kapsayıcılar sürekli çöküp yeniden başlayabilir ve veritabanı bağlantıları tükenebilir. Bir dağıtım da sözdizimi hatasına, uyumsuz bağımlılığa veya yoğun kullanılan bir tabloyu kilitleyen bir veri geçişine yol açabilir.
Bu tür olaylar genellikle tek bir hizmetle sınırlıdır. SSH çalışabilir ve izleme aracısı normal sistem yükü bildirebilir; ancak site 502, 503 veya 500 hataları döndürebilir. Her şeyi aynı anda yeniden başlatmadan önce uygulama günlüklerini, hizmet durumunu, son dağıtımları, veritabanı hata günlüklerini ve yanıt sürelerini kontrol edin.
İyi bir kurtarma planlamasına, test edilmiş geri alma adımları da dahildir. Hızlı bir geri alma, baskı altında canlı ortamda yeni kodda hata ayıklamaktan daha çabuk gelir kaybını önleyebilir. E-ticaret ve SaaS ekipleri için veritabanı geçişlerini uygulama sürümüyle aynı değişiklik planına dahil edin. Kod kolayca geri alınabilir; değiştirilmiş veriler o kadar uyumlu değildir.
3. Ağ, yönlendirme ve güvenlik duvarı sorunları
Genel erişilebilirlik yalnızca VPS'ye bağlı değildir. Üst ağdaki bir yönlendirme sorunu, internet değişim noktası sorunu, paket kaybı, yanlış yapılandırılmış bir güvenlik grubu veya güvenlik duvarındaki bir değişiklik, sanal makine normal şekilde çalışmayı sürdürürken erişimi kesebilir.
Sunucu içindeki yaygın nedenler arasında yanlış varsayılan ağ geçidi, ağ arayüzü yapılandırmasında yanlışlıkla yapılan değişiklikler, 80 veya 443 numaralı bağlantı noktalarını engelleyen güvenlik duvarı politikası ya da meşru trafiği yakalayan fail2ban kuralları bulunur. Hız sınırlama ve dağıtık hizmet reddi saldırılarına karşı azaltım önlemleri de olağan dışı yüksek trafik sırasında davranışı etkileyebilir.
Ağ olayları katmanlı test gerektirir. Birden fazla coğrafi konumdan test edin, yalnızca ICMP'ye bilerek izin verilmişse IP'nin ICMP'ye yanıt verip vermediğini doğrulayın ve gerçek hizmet bağlantı noktasını test edin. Ping'in başarılı olması web sitesinin erişilebilir olduğunu kanıtlamaz; ping'in başarısız olması da sunucunun çalışmadığını kanıtlamaz.
4. Kesinti gibi görünen DNS ve sertifika sorunları
DNS, VPS'nizin içinde çalışmaz; ancak hatalı bir DNS kaydı çalışan bir hizmeti erişilemez gösterebilir. Yaygın örnekler arasında eski bir IP adresini gösteren A kaydı, süresi dolmuş bir alan adı, geçiş sonrasında eksik kalan bir kayıt veya amaçlanan DNS sağlayıcısıyla eşleşmeyen ad sunucuları bulunur.
TLS sertifikası hataları müşteriler açısından benzer bir deneyim yaratır. Sunucu siteyi sunuyor olabilir ancak sertifikanın süresi dolduğu, ana makine adı eşleşmediği veya yenileme işlemi başarısız olduğu için tarayıcılar kullanıcıları uyarıp siteden uzaklaştırır. Teknik açıdan bu, VPS kesintisi değildir. Operasyonel açıdan ziyaretçiler siteyi yine de kullanamaz; bu nedenle aynı aciliyetle ele alınmalıdır.
Alan adı yenileme tarihlerini, DNS değişikliklerini ve sertifika süre sonlarını altyapı uyarılarıyla birlikte takip edin. Web trafiğine bağlı bir işletme için bunlar az çabayla yapılabilecek, değeri yüksek kontrollerdir.
5. Ana makine düğümü veya depolama platformu arızaları
Bir VPS fiziksel altyapı üzerinde çalışır. Donanım arızaları, ana makine işletim sistemi sorunları, hipervizör sorunları veya depolama birimindeki bozulmalar, aynı düğümdeki bir sanal makineyi ya da birden fazla sanal makineyi etkileyebilir. Profesyonel platformlar bu riski azaltmak için yedeklilik, izleme ve bakım prosedürlerinden yararlanır; ancak hiçbir dürüst sağlayıcı fiziksel bileşenlerin asla arızalanmayacağını garanti edemez.
Depolama olayları özellikle kesintiye yol açabilir; çünkü uygulamalar okuma ve yazma işlemlerini bekler. Yüksek G/Ç bekleme süresi, veritabanı zaman aşımı, yavaş sayfalar veya donmuş gibi görünen bir sanal makineyle karşılaşabilirsiniz. Uygun eylem platforma bağlıdır: mühendisler sanal makineyi taşıyabilir, alttaki düğümü onarabilir veya hizmetleri bilinen iyi bir durumdan geri yükleyebilir.
Sağlayıcınıza bakım bildirimlerinin, ana makine düzeyinde izlemenin ve destek için üst kademeye iletmenin hizmete dahil olup olmadığını sorun. Tek sunucu arızasını tolere edemeyen iş yükleri için çözüm mimaridir: çoğaltma, yük dengeleme, sunucu dışı yedekler ve test edilmiş bir kurtarma yolu. Tek bir VPS güvenilir olabilir ama sonuçta yine de tek bir VPS'dir.
6. Bakım ve yapılandırma değişiklikleri
Planlı bakım, acil onarımdan daha güvenlidir; yine de değişiklikler kesintilerin başlıca nedenlerinden biri olmaya devam eder. Çekirdek güncellemeleri yeniden başlatma gerektirebilir. Bir kontrol paneli güncellemesi web sunucusu yapılandırmasını değiştirebilir. PHP sürümlerini, veritabanı ayarlarını, güvenlik duvarı kurallarını veya ağ arayüzlerini değiştirmek, hiç belgelenmemiş bir varsayımı bozabilir.
Çözüm, küçük ekiplerde bile kontrollü değişiklik yönetimi uygulamaktır. Uygun olduğunda yedek veya anlık görüntü alın, geçerli yapılandırmayı kaydedin, değişiklikleri en yoğun dönemin dışında planlayın ve ardından gerçek kullanıcı akışını doğrulayın. “Hizmet başladı” demek, “müşteriler giriş yapıp ödeme işlemini tamamlayabiliyor” demek değildir.
Yönetilen VPS müşterileri için riskli bir değişiklik öncesinde ve sonrasında uygulamalı inceleme yapmak belirsizliği büyük ölçüde azaltabilir. Kodu.cloud'da izleme ve operasyonel destek, sıradan arızaları heyecanlı bir öğleden sonraya dönüşmeden yakalamak üzere tasarlanmıştır.
7. Güvenlik olayları ve kötüye kullanım müdahalesi
Ele geçirilmiş kimlik bilgileri, savunmasız eklentiler, kötü amaçlı yazılımlar, kaba kuvvet saldırıları ve kaynakların kötüye kullanımı kesintiye yol açabilir. Bir saldırgan kripto para madenciliğiyle CPU'yu tüketebilir, bir hizmeti istek yağmuruna tutabilir, dosyaları silebilir veya DNS ve uygulama ayarlarını değiştirebilir. Bazen bir sağlayıcının, başkalarına saldıran veya zararlı trafik oluşturan VPS'yi geçici olarak kısıtlaması gerekir.
Önlem almak gizemli değil, pratiktir: güvenlik güncellemelerini uygulayın, SSH anahtarlarını ve kullanılabiliyorsa çok faktörlü kimlik doğrulamayı kullanın, yönetici erişimini sınırlandırın, kullanılmayan yazılımları kaldırın ve yedekleri VPS dışında tutun. Kimlik doğrulama günlüklerini ve olağan dışı giden trafiği inceleyin. Sunucu birdenbire işletmenizin mü şteri sayısından fazla e-posta göndermeye başlarsa bu, pazarlama alanında büyük bir atılım değildir.
8. İzleme eksiklikleri ve geç tespit
Kesinti küçük bir arızayla başlayabilir ama kimse fark etmediğinde işletmeye etkisi büyür. Temel bir çalışma süresi kontrolü, bir bağlantı noktasının yanıt verip vermediğini bildirebilir. Daha iyi izleme; CPU, bellek, disk kullanımı, G/Ç bekleme süresi, hizmet süreçleri, SSL süre sonu, yedekleme başarısı ve önemli uygulama işlemlerini de takip eder.
Uyarılar, harekete geçebilecek bir kişiye ulaşmalıdır. Gereğinden fazla ve gürültülü uyarı, ekipleri tüm uyarıları görmezden gelmeye alıştırır; çok az uyarı ise sizi olup bitenden habersiz bırakır. Anlamlı eşikler belirleyin, devam eden arızalar için üst kademeye iletme mekanizması kullanın ve olaylardan sonra uyarıları gözden geçirin. FASTCARE tarzı izleme faydalıdır; çünkü yalnızca her şeyin durduğu anı değil, erken bozulma belirtilerini de izler.
VPS Kesintisi Başlamadan Önce Nasıl Azaltılır
Kurtarma için temel adımlarla başlayın. Doğrulanmış yedekler bulundurun, geri yüklemeyi düzenli olarak test edin ve en az bir yedeği VPS'nin kendisinden ayrı bir yerde saklayın. Hiç geri yüklenmemiş bir yedek, henüz bir kurtarma planı değil, umut vadeden bir dosyadır.
Ardından kapasite için temel değerleri belirleyin. Olağan ve en yüksek CPU, bellek, depolama ve veritabanı kullanımını izleyin. Disk kullanımı, günlüklerin ve hizmetlerin başarısız olacağı düzeye ulaşmadan önce uyarılar ayarlayın. Kritik hizmetlerde veritabanını web katmanından ayırın veya kesinti maliyetinin haklı çıkardığı durumlarda yedeklilik sağlayın.
Son olarak değişikliklerin izlenebilir olmasını sağlayın. Dağıtımları, altyapı düzenlemelerini, DNS değişikliklerini ve bakım zaman aralıklarını kaydedin. Bir olay sırasında zaman damgalı bir değişiklik günlüğü, teşhis süresini çoğu zaman saatlerden dakikalara indirir.
Sakin bir olay müdahale süreci tahmin yürütmekten iyidir: kapsamı doğrulayın, verileri koruyun, müşterilerin kullandığı hizmeti geri yükleyin, ardından kanıtlar hâlâ mevcutken temel nedeni araştırın. Hizmet yeniden istikrara kavuşabilir ve bir sonraki kesinti bir öncekinden daha küçük olabilir.
Andres Saar Müşteri Destek Mühendisi