Uptime ve SLA Garantilerinin Önemi Nedir

Uptime ve SLA gerçekte ne anlama gelir

Uptime (çalışma süresi), bir hizmetin erişilebilir ve çalışır durumda olduğu zamanın oranıdır. Hizmet seviyesi anlaşması (SLA) ise sağlayıcının erişilebilirliği nasıl ölçtüğünü, hangi seviyeyi taahhüt ettiğini ve bu seviyenin altına düşüldüğünde ne olacağını tanımlayan sözleşme belgesidir. Hosting firmaları, bulut platformları, DNS sağlayıcıları ve CDN’ler SLA yayımlar; %99,9 veya %99,99 gibi öne çıkan rakam da çoğu zaman fiyat sayfalarında belirgin biçimde yer alır.

Bu rakam faydalıdır, ancak yalnızca başlangıçtır. Aynı yüzdeyi duyuran iki sağlayıcı, erişilebilirliği nasıl ölçtüklerine, neleri hariç tuttuklarına ve tazminatı nasıl talep ettiğinize bağlı olarak çok farklı koruma sunabilir. Bu rehber rakamları ve dipnotları nasıl okuyacağınızı, SLA ne derse desin kendinizi nasıl koruyacağınızı açıklıyor.

Yüzdeleri kesinti süresine çevirmek

100’e yakın yüzdeler birbirine benzer görünür, ancak izin verdikleri kesinti süresi büyük ölçüde farklıdır. Aşağıdaki tablo yaygın uptime seviyelerini ortalama bir ayda (yaklaşık 30,4 gün) ve bir yılda (365,25 gün) izin verilen azami kesinti süresine çevirir. Değerler yuvarlanmıştır.

Herhangi bir değeri kendiniz hesaplayabilirsiniz: dönemdeki dakika sayısını, bir eksi uptime oranıyla çarpın. %99,9 için 30 günlük bir ayda bu, 43.200 × 0,001 = 43,2 dakikadır.

Ölçüm aralığının önemli olduğuna dikkat edin. Aylık bir SLA her ay sıfırlanır; dolayısıyla yılın başındaki tek bir uzun kesinti yıllık bir bütçeyi tüketmez. Buna karşılık yıllık ölçülen bir SLA, teoride tek seferde birkaç saatlik kesintiye izin verip yine de karşılanmış sayılabilir.

Sağlayıcılar erişilebilirliği nasıl ölçer

SLA’ların en çok farklılaştığı nokta “erişilebilir” kavramının tanımıdır. Ölçüm bölümünü dikkatle okuyun ve şu soruların yanıtlarını arayın:

• Ne ölçülüyor? Fiziksel sunucu mu, ağ mı, HTTP’ye yanıt veren web sunucusu mu, yoksa gerçek uygulamanız mı? Siteniz hata döndürürken firma bir ağ SLA’sını karşılıyor olabilir.
• Kim ölçüyor? SLA’ların çoğu sizin değil, sağlayıcının kendi izlemesine dayanır. Bazıları sizden kanıt ister.
• Kontroller ne sıklıkla yapılıyor? Beş dakikada bir yapılan bir kontrol kısa kesintileri tamamen kaçırabilir.
• Asgari kesinti süresi nedir? Bazı anlaşmalar yalnızca belirli bir dakika sayısından uzun süren olayları sayar.
• Kısmi bozulma sayılıyor mu? Çok yavaş yanıtlar veya isteklerin yalnızca bir kısmındaki hatalar kesinti olarak kabul edilmeyebilir.

Bileşen SLA’ları ve birleşik erişilebilirlik

Siteniz bir zincir halinde birkaç hizmete bağlıdır: alan adı kaydı, DNS, hosting, veritabanı, CDN ve üçüncü taraf API’ler. Her bileşen bağımsızsa ve her birinin çalışması gerekiyorsa, toplam erişilebilirlik kabaca tek tek değerlerin çarpımıdır. Her biri %99,9 olan iki bileşen birlikte yaklaşık %99,8 verir. İkincil bir DNS sağlayıcısı gibi yedeklilik eklemek sonucu iyileştirebilirken, daha fazla tekil arıza noktası eklemek onu düşürür.

Dipnotlardaki yaygın istisnalar

Neredeyse her SLA belirli olayları kesinti hesabının dışında tutar. Tipik istisnalar şunlardır:

• Önceden duyurulan, bazen tanımlı bir zaman aralığında yapılan planlı bakım.
• Müşterinin kendi kodu, yapılandırması veya aşılan kaynak limitlerinden kaynaklanan sorunlar.
• Sağlayıcıya bağlı olarak dağıtık hizmet reddi (DDoS) gibi saldırılar.
• Sağlayıcının kontrolü dışındaki üçüncü taraf ağların veya hizmetlerin arızaları.
• Doğal afetler gibi mücbir sebepler.
• Ödeme yapılmaması veya politika ihlali nedeniyle askıya alma.

İstisnalar mutlaka haksız değildir, ancak öne çıkarılan rakamın gerçek anlamını değiştirir. Örneğin geniş bir bakım istisnası, garantiye hiç yansımayan düzenli planlı kesintilere izin verebilir. Paylaşımlı hostingde hesabınızın CPU veya işlem limitlerini aşmak genellikle firmanın değil sizin sorununuz sayılır; paylaşımlı hosting yapılandırmaları rehberimizin kaynak limitlerine özel önem vermesinin bir nedeni de budur.

Hizmet kredileri ve neler talep edebilirsiniz

Sağlayıcı hedefini tutturamadığında olağan çözüm hizmet kredisidir: aylık ücretin bir yüzdesi, sonraki bir faturaya uygulanır. Kredi kademeleri çoğu zaman erişilebilirliğin ne kadar düştüğüne göre artar ve birçok SLA toplam krediyi, etkilenen hizmetin aylık ücretinin bir kısmıyla ya da en fazla tamamıyla sınırlar. Koşullar farklılık gösterir, sağlayıcınızın tam tablosunu mutlaka kontrol edin.

Bu yapıdan birkaç pratik sonuç çıkar:

1. Krediler, işletme kayıplarına göre küçüktür. Hostinginiz mütevazı bir aylık ücretle çalışıyorsa, bir kesinti size çok daha fazla satış kaybettirse bile azami kredi bu tutarla sınırlıdır.
2. Krediler nadiren otomatiktir. Birçok sağlayıcı, olaydan sonra belirli bir süre içinde, bazen günlük kayıtları veya izleme kanıtıyla birlikte destek talebi açmanızı ister.
3. Krediler genellikle dolaylı zararları kapsamaz. Standart hizmet şartları sorumluluğu çoğu zaman ödenen ücretlerle sınırlar.

Bu bir hukuki tavsiye değildir; sözleşme koşulları sağlayıcıya ve yargı bölgesine göre değişir. Yüksek değerli hizmetlerde büyük müşteriler bazen özel koşullar müzakere edebilir, ancak paylaşımlı ve VPS paketlerinin çoğu standart, pazarlığa kapalı sözleşmeler kullanır.

Uptime’ı kendiniz izlemek

Sağlayıcılar kendi performanslarını ölçtüğü için, ziyaretçilerinizin gerçekte ne yaşadığını bilmenin en iyi yolu bağımsız izlemedir. Harici bir izleyici, sitenizi hosting ağının dışından düzenli aralıklarla ister ve yanıt kodunu, yanıt süresini ve hataları kaydeder.

Komut satırından hızlı bir manuel kontrol, durum kodunu ve toplam yanıt süresini gösterir:

curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://example.com/

Sürekli izleme için barındırılan bir hizmet veya cron ile zamanlanmış küçük bir betik, manuel kontrollerden daha güvenilirdir. Faydalı uygulamalar şunlardır:

• Tek bir ağ yolundaki sorunun yanlış alarm üretmemesi için birden fazla konumdan kontrol edin.
• Yalnızca statik bir dosyayı değil, uygulamanızı ve veritabanınızı çalıştıran bir sayfayı izleyin.
• Bir hata sayfası da 200 durum kodu döndürebileceği için beklenen içeriği kontrol edin.
• Alarm geçmişini saklayın; SLA talebi açarken kanıtınız olur.

Hiçbir hosting SLA’sının kapsamadığı kesintiler

Kesintilerin en yaygın nedenlerinden bazıları teknik değil idaridir: süresi dolmuş bir alan adı, geçerliliğini yitirmiş bir SSL sertifikası veya ödenmemiş bir hosting faturası. Hiçbir hosting SLA’sı bunları tazmin etmez. TLDix burada alan adı, SSL ve hosting yenileme tarihlerini takip edip süre dolumu uyarıları göndererek yardımcı olur; varlıklarınızı alan adı panelinize ekleyebilir, süre dolumlarını önleme hakkında daha fazlasını alan adı süre dolumlarını önleme rehberimizde okuyabilirsiniz.

Kesinti olmadan önce hazırlanmak

İyi bir izleme, basit bir müdahale planıyla birleştiğinde en değerli halini alır. Alarmları kimin alacağını, firmanın desteğine nasıl hızla ulaşılacağını, sağlayıcının durum sayfasının nerede olduğunu ve site uzun süre erişilemez kalırsa müşterilere ne söyleyeceğinizi yazın. Kayıt firması, DNS sağlayıcısı ve hosting paneline ait giriş bilgilerini web sitesinin kendisine bağlı olmayan güvenli bir parola yöneticisinde tutun. Her olaydan sonra başlangıç ve bitiş saatlerini, sağlayıcının bildirdiği nedeni ve kredi talebinde bulunup bulunmadığınızı not edin. Aylar içinde bu kayıt, sağlayıcının sözlerini tutarlı biçimde yerine getirip getirmediğini gösterir ve başka bir firmaya geçmeye karar verirseniz size sağlam veriler sunar.

Durum sayfalarını doğru okumak

Birçok sağlayıcı herkese açık bir durum sayfası ve olay geçmişi yayımlar. Bu sayfalar faydalıdır, ancak genellikle sağlayıcının kendi değerlendirmesini yansıtır ve küçük, bölgesel ya da yalnızca bazı müşterileri etkileyen sorunları her zaman göstermeyebilir. Kendi izleme sonuçlarınızı durum sayfasıyla karşılaştırın; sizin gördüğünüz bir kesinti orada yer almıyorsa, destek talebinize zaman damgalı kayıtlarınızı ekleyin. Durum sayfasına e-posta veya RSS ile abone olmak, planlı bakımları önceden öğrenmenizi de kolaylaştırır.

Doğru uptime seviyesini seçmek

Daha yüksek garantiler genellikle daha pahalıdır ve çoğu zaman yalnızca farklı bir paket değil, mimari değişiklik gerektirir. Hedefi, kesintinin size gerçek maliyetiyle eşleştirin:

Bu aralıklar sektör kuralı değil, genel bir yol göstericidir. Doğru hedef, saatlik gelirinize, müşteri beklentilerine ve kendi müşterilerinizle yaptığınız sözleşmelere bağlıdır.

Basit bir hesapla başlayabilirsiniz: sitenizin bir saat erişilemez kalmasının size yaklaşık ne kadara mal olacağını tahmin edin ve bunu farklı uptime seviyelerinin izin verdiği yıllık kesinti süresiyle çarpın. Ortaya çıkan tutar, daha yüksek bir garanti veya ek yedeklilik için ödeyeceğiniz farkla karşılaştırıldığında, yatırımın mantıklı olup olmadığını genellikle açıkça gösterir. Bu hesabı yaparken itibar kaybı ve müşteri desteği yükü gibi ölçmesi zor maliyetleri de not etmeyi unutmayın.

İmzalamadan önce sorulacak sorular

Bir sağlayıcıya bağlanmadan önce şunları sorun veya araştırın:

• SLA aylık mı yoksa yıllık mı ölçülüyor ve tam olarak ne kesinti sayılıyor?
• Planlı bakım için ne kadar önceden bildirim yapılıyor ve bakım hariç tutuluyor mu?
• Krediler nasıl hesaplanıyor, nasıl sınırlanıyor ve hangi süre içinde talep ediliyor?
• Sağlayıcı herkese açık bir durum sayfası ve olay geçmişi yayımlıyor mu?
• Kesinti sırasında hangi destek yanıt süreleri geçerli?

Açık ve net bir SLA ile şeffaf bir durum sayfası, geniş istisnalarla çevrelenmiş çok yüksek bir yüzdeden genellikle daha iyi bir işarettir. Makul bir garantiyi kendi izlemeniz, harici yedekleriniz ve yenileme takibinizle birleştirirseniz, tek başına SLA’nın kapsadığından çok daha fazla arıza senaryosuna karşı korunmuş olursunuz.