Kesintisiz Hosting Nedir? Gerçek Erişilebilirlik Nasıl Değerlendirilir?

Kesintisiz hosting, bir web sitesinin arıza, bakım veya tek bir sunucu bileşenindeki sorun sırasında erişilebilir kalmasını hedefleyen barındırma yaklaşımıdır. Bu ifade tek başına hiç kesinti olmayacağını kanıtlamaz. Doğru değerlendirme için hizmetin yedeklilik mimarisine, planlı bakım politikasına, SLA kapsamına ve arıza anında trafiğin nasıl taşındığına birlikte bakmak gerekir.

Kesintisiz hosting hangi mekanizmayla çalışır?

Geleneksel bir barındırmada site dosyaları, veritabanı ve ağ bağlantısı çoğunlukla tek bir sunucuya veya aynı arıza alanına bağlı olabilir. Bu yapı basit ve bazı küçük siteler için yeterli olsa da disk, güç, işletim sistemi ya da sunucu donanımı arızalandığında hizmet etkilenebilir. Yüksek erişilebilirlik yaklaşımında ise kritik bileşenlerin en azından bir bölümü yedekli tasarlanır.

Yedeklilik; ikinci bir sunucu, birden fazla ağ yolu, çoğaltılmış depolama veya arızalı düğümü devreden çıkaran yük dengeleme katmanı şeklinde uygulanabilir. Ancak her hizmet aynı düzeyde yedeklilik sunmaz. Web sunucuları yedekli olup veritabanı tek noktada kalıyorsa, veritabanı arızası yine siteyi durdurabilir. Bu nedenle yalnızca “yedek sunucu var” ifadesi yerine hangi bileşenin, hangi arıza türüne karşı korunduğu sorulmalıdır.

Bir hizmeti seçerken hangi sorulara yanıt aramalısınız?

Önce sitenin kesintiye duyarlılığını belirleyin. Tanıtım sitesi kısa süreli erişim sorununun daha sonra telafi edilebildiği bir yapıdaysa, karmaşık yüksek erişilebilirlik mimarisi yerine düzenli yedekleme ve kolay geri yükleme daha anlamlı olabilir. Sipariş, ödeme veya canlı kullanıcı işlemleri yürüten bir uygulamada ise veri kaybı ve bağlantı kopması daha kritik olduğundan, veritabanı çoğaltması, otomatik geçiş ve geri dönüş prosedürü ayrıca incelenmelidir.

Karar şu şekilde daraltılabilir: Site yalnızca bilgi sunuyor ve kısa bakım penceresi kabul edilebiliyorsa, kanıtlanabilir yedekleme ile açık bakım politikasını önceliklendirin. Site işlem alıyor ve tek bir sunucu arızasında iş kaybı oluşacaksa, trafiğin başka düğüme taşınmasını ve yazma işlemlerinin nasıl korunduğunu açıklayan bir mimari arayın. Sağlayıcı bu iki noktayı açıklayamıyorsa, “kesintisiz” ifadesini teknik bir garanti olarak kabul etmeyin.

SLA ile gerçek mimariyi birbirinden ayırın

SLA, sağlayıcının belirli bir erişilebilirlik hedefini ve bu hedef tutmazsa uygulanabilecek koşulları açıklayan sözleşmesel çerçevedir. SLA yüzdesi tek başına sitenizin her isteğe yanıt vereceği anlamına gelmez; DNS sağlayıcısı, uygulama kodu, üçüncü taraf ödeme servisi veya hatalı bir güncelleme kapsam dışında kalabilir. Planlı bakımların hesaplamaya dahil edilip edilmediğini, ölçümün hangi noktadan yapıldığını ve telafinin teknik bir onarım mı yoksa sözleşmesel bir hüküm mü olduğunu okuyun.

Yüksek erişilebilirliği ilk kullanımda nasıl doğrularsınız?

Sağlayıcının sunduğu mimari açıklamasını ve SLA metnini birlikte inceleyerek başlayın. “Yedekli” denilen bileşenlerin web katmanıyla mı, veritabanıyla mı, yoksa yalnızca güç ve ağ altyapısıyla mı ilgili olduğunu not edin. Kabul edilebilir sonuç, tek bir arızanın hangi katmanda tolere edildiğini açıkça gösteren bir açıklamadır; yalnızca genel bir çalışma süresi yüzdesi verilmesi eksik kanıttır.

1. Arıza kapsamını belirleyin: Tek sunucu, disk, ağ bağlantısı ve veri merkezi senaryolarından hangilerinde otomatik geçiş olduğunu sorun. Yalnızca donanım değişimi gerekiyorsa bu, otomatik kesintisiz geçiş değil, hızlı kurtarma yaklaşımıdır.
2. Veri tutarlılığını inceleyin: Veritabanı çoğaltmasının eş zamanlı mı yoksa gecikmeli mi olduğunu ve yazma işlemi sırasında düğüm değişirse ne olacağını öğrenin. Eş zamanlı olmayan çoğaltmada son işlemler kaybolabilecekse, ödeme veya sipariş kayıtları için ek uygulama önlemleri gerekir.
3. Bakım ve geçiş politikasını okuyun: Planlı bakımda trafik önceden başka düğüme alınabiliyor mu, yoksa kısa bir duraklama mı bekleniyor kontrol edin. Beklenen sonuç, bakım türüne göre uygulanacak işlemin ve olası etki süresinin tanımlanmasıdır.
4. Kendi uygulamanızla sınırlı bir prova planlayın: Üretim verisine zarar vermeden, önceden kararlaştırılmış bir bakım penceresinde sağlık kontrolü, oturum devamlılığı ve veritabanı yazma davranışını izleyin. Bir istek yeni düğüme geçtiğinde oturum ve kayıt davranışı beklediğiniz gibi değilse, bunu mimarinin uygulamanızla uyumsuzluğu olarak ele alın; plansız arıza testi başlatmayın.

Diyelim ki bir rezervasyon uygulaması için iki barındırma seçeneği değerlendiriyorsunuz. İlk seçenek web sunucularını yedekli tutuyor ancak veritabanı tek düğümde; ikinci seçenek daha sınırlı web kaynaklarına sahip olsa da veritabanı geçiş prosedürünü ve kayıt tutarlılığı sınırlarını açıklıyor. Rezervasyon kaybı temel riskse, ikinci seçenek daha uygun olabilir. Buna karşılık uygulama yalnızca statik içerik sunuyorsa, veritabanı yedekliliği için daha karmaşık yapı seçmek gereksiz maliyet ve yönetim yükü oluşturabilir.

Hangi bağımlılıklar kesintisizlik hedefini sınırlar?

Hosting altyapısı sağlam olsa bile alan adı DNS kayıtları, CDN, harici API'ler, ödeme kuruluşu, e-posta servisi ve uygulamanın kendi kodu ayrı hata noktalarıdır. Bu yüzden “sunucu ayakta” bilgisi sitenin tamamının kullanılabilir olduğu anlamına gelmez. Kullanıcıların yaptığı işlemi baştan sona izlemek; yalnızca ana sayfanın açılıp açılmadığını kontrol etmekten daha gerçekçi bir değerlendirme sağlar.

Örneğin statik dosyalar açılıyor fakat ödeme adımı harici servis yanıt vermediği için tamamlanmıyorsa, hosting sağlayıcısını değiştirmek tek başına sorunu çözmez. Önce hatanın hangi bağımlılıkta oluştuğunu ayırın; sağlayıcı altyapısında otomatik geçiş eksikse mimariyi, harici serviste arıza varsa uygulamanın bekleme ve yeniden deneme davranışını ele alın.

İhtiyaca göre güvenli seçim

Kesinti maliyeti düşük bir içerik sitesi için düzenli, doğrulanmış yedekler; açık bakım bildirimi ve kolay geri yükleme çoğu zaman yeterli bir temel oluşturur. Kesinti doğrudan gelir veya veri kaybı yaratıyorsa, otomatik geçişin kapsamı, veritabanı davranışı, gözlemlenebilirlik ve kurtarma süresi hedefleri yazılı olarak netleştirilmelidir. Sağlayıcının yanıtları belirsiz kalırsa, hizmeti “kesintisiz” diye değil, yalnızca belirli bir kurtarma ve yedeklilik düzeyi sunan barındırma olarak değerlendirin.

Sunucu seçeneğini daha ayrıntılı incelemek istiyorsanız, mimari açıklamalarını kendi veri kaybı ve kesinti toleransınızla karşılaştırarak Türkiye VDS sunucu paketleri sayfasındaki seçenekleri değerlendirebilirsiniz. İlk somut adım, mevcut siteniz için tek hata noktalarını listelemek ve her biri için kabul edilebilir kurtarma süresini yazmaktır.