Uptime ve SLA Nedir Yüzde 99.9 Ne Anlama Gelir

Bir hosting firmasının reklamında "%99.9 uptime garantisi" gördüğünüzde çoğunlukla bunu "site hiç kapanmaz" diye okursunuz. Oysa bu iki cümle aynı şey değil. Yüzde 99.9 gibi masum görünen bir oran, yılda saatlerce erişilemezliğe izin verir ve çoğu zaman bu erişilemezlik en kritik anlarda, yani ziyaretçinizin en yoğun olduğu saatlerde gerçekleşir. Uptime rakamlarını doğru yorumlamak, hangi hosting planına para vereceğinizi ve bir kesinti yaşandığında haklarınızın ne olduğunu belirler.

Bu rehberde uptime kavramının teknik olarak ne ölçtüğünü, SLA belgesinin size ne taahhüt ettiğini ve aralarındaki farkı netleştireceğiz. Ardından %99.9, %99.95 ve %99.99 oranlarının yıllık, aylık ve haftalık dakika karşılıklarını bir tabloyla göstereceğiz. SLA tazminatının pratikte nasıl işlediğine, planlı bakımın neden garantinin dışında tutulduğuna ve kendi sitenizin gerçek erişilebilirliğini bağımsız olarak nasıl ölçebileceğinize dair somut örneklerle ilerleyeceğiz. Amaç, pazarlama diliyle mühendislik gerçeğini ayırt edebilmeniz.

Uptime Nedir ve Neden Önemlidir#

Uptime, bir sunucunun veya hizmetin belirli bir zaman diliminde erişilebilir ve çalışır durumda olduğu sürenin yüzde olarak ifadesidir. Basitçe toplam süreden kesinti süresini çıkarır, kalanı toplam süreye böler ve yüzdeye çevirirsiniz. Karşıtı olan downtime ise hizmetin ulaşılamadığı süredir. Bir sitenin açılmaması, veritabanına bağlanamaması, sayfanın 500 hatası vermesi veya sunucunun ping'e cevap vermemesi downtime olarak sayılır.

Uptime'ın önemi doğrudan gelir ve itibarla ilişkilidir. Bir e-ticaret sitesi kampanya günü on beş dakika kapalı kalırsa, o dilimde alışveriş yapacak müşteriler kaybedilir ve çoğu geri dönmez. Arama motorları da erişilemeyen siteleri düzenli olarak tarayamaz; tekrarlayan kesintiler sıralamanızı olumsuz etkileyebilir. Bu yüzden erişilebilirlik yalnızca teknik bir metrik değil, iş sürekliliğinin doğrudan ölçüsüdür. Farklı hosting tiplerinin bu konudaki davranışını web hosting türleri rehberinde ayrıntılı ele alıyoruz.

Kesintinin yüzdesi kadar dağılımı da önemlidir. Yılda toplam bir saatlik kesinti, tek seferde koca bir saat olarak yaşanırsa dramatiktir; ama saniyeler süren yüzlerce kısa kesintiye bölünürse çoğu ziyaretçi hiç fark etmez. Bu nedenle uptime rakamına bakarken "ne kadar" sorusunun yanında "nasıl dağıldığı" sorusunu da sormak gerekir.

SLA Nedir ve Uptime'dan Farkı#

SLA, yani Hizmet Seviyesi Anlaşması (Service Level Agreement), sağlayıcının size vermeyi taahhüt ettiği hizmet kalitesini ve bu taahhüt tutulmadığında ne olacağını yazılı olarak tanımlayan sözleşmedir. Uptime bir ölçüm, SLA ise bir sözdür. Uptime "geçen ay sitem %99.7 çalıştı" der; SLA "ayda en az %99.9 çalışacağını garanti ediyorum, altına düşersem şu tazminatı öderim" der. İkisini karıştırmak, garanti sanılan bir rakamın aslında yalnızca bir istatistik olduğunu gözden kaçırmanıza yol açar.

İyi yazılmış bir SLA belgesi şu bileşenleri net biçimde içerir. Öncelikle garanti edilen erişilebilirlik oranı ve bunun hangi zaman penceresinde (aylık mı yıllık mı) ölçüleceği belirtilir. İkinci olarak, kesintinin nasıl tespit ve ispat edileceği tanımlanır; sağlayıcının kendi izleme sistemi mi geçerlidir, yoksa müşterinin bağımsız kaydı da kabul edilir mi? Üçüncü olarak, tazminatın hesaplanma yöntemi ve tavanı yazılır. Son olarak, garantinin kapsamadığı istisnalar (planlı bakım, müşteri hatası, mücbir sebep) listelenir.

Burada dikkat edilmesi gereken nokta, "yıllık %99.9" ile "aylık %99.9" ifadelerinin çok farklı sıkılıkta olduğudur. Yıllık pencerede bir ayın tamamen kötü geçmesi, diğer on bir ayın iyiliğiyle telafi edilerek ortalama içinde erir. Aylık pencerede ise her ay ayrı ayrı değerlendirildiği için sağlayıcı çok daha sık taahhüt riski taşır. Sözleşmenizde hangi pencerenin kullanıldığını mutlaka kontrol edin.

Yüzde 99.9 Yıllık Ne Kadar Kesinti Demek#

Uptime oranlarını somutlaştırmanın en iyi yolu, yüzdeleri gerçek zamana çevirmektir. Aşağıdaki tablo, yaygın erişilebilirlik seviyelerinin yıllık, aylık, haftalık ve günlük olarak izin verdiği azami kesinti süresini gösteriyor. Sektörde bu seviyeler genellikle "dokuzların sayısı" ile anılır; "üç dokuz" %99.9, "dört dokuz" %99.99 demektir.

Tablodaki en çarpıcı satır %99.9'dur çünkü pazarlamada en çok kullanılan seviyedir ve kulağa neredeyse kusursuz gelir. Oysa yılda 8 saat 45 dakika, tek bir kötü akşamda tamamı tükenebilecek bir bütçedir. Bir e-ticaret sitesi için bu, indirim gecesinde birkaç saat kapalı kalmak demek olabilir. %99.99'a çıktığınızda yıllık pay 53 dakikaya iner; bu ciddi bir sıçramadır ve genellikle daha güçlü altyapı, yedekli mimari ve daha yüksek maliyet gerektirir.

Bu farkı hesaplamak istediğinizde formül basittir. Yıllık dakika sayısı sabittir ve şöyle bulunur.

# Bir yıldaki toplam dakika
echo $((365 * 24 * 60))      # 525600 dakika

# %99.9 uptime'ın izin verdiği yıllık kesinti (dakika)
python3 -c "print(525600 * (1 - 0.999))"   # 525.6 dakika ≈ 8s 45dk

# %99.99 için
python3 -c "print(525600 * (1 - 0.9999))"  # 52.56 dakika

Bu hesabı kendi sözleşmenize uygulayın. Sağlayıcı hangi oranı hangi pencerede veriyor, o pencerede kaç dakikaya karşılık geliyor ve bu süre sizin işiniz için tolere edilebilir mi? Cevap hayır ise, tek bir hosting hesabı yerine yedekli bir kurulum veya daha yüksek SLA'lı bir plan düşünmelisiniz. Paylaşımlı ve VPS mimarilerinin bu konudaki farkını shared ve VPS hosting karşılaştırması yazısında bulabilirsiniz.

SLA Tazminatı Nasıl İşler#

SLA ihlali gerçekleştiğinde, yani gerçek uptime taahhüt edilenin altına düştüğünde, sağlayıcı genellikle nakit iade yerine hesap kredisi (service credit) verir. Bu kredi bir sonraki faturanızdan düşülür ve tutarı, ihlalin büyüklüğüne göre kademeli bir tabloyla belirlenir. Tipik bir kredi şeması aşağıdakine benzer; oran düştükçe kredi yüzdesi artar.

Bu modelin pratikteki en önemli özelliği, tazminatın zararınızı değil aboneliğinizi baz almasıdır. Yani ayda 100 lira ödediğiniz bir plan bütün gün kapalı kalıp binlerce liralık satış kaybettirse bile, alacağınız kredi o 100 liranın bir yüzdesiyle sınırlıdır. SLA tazminatı bir sigorta değildir; sağlayıcının kaliteye bağlılığını gösteren sembolik bir taahhüttür. Kritik iş yükleri için gerçek koruma, tazminat maddesinde değil, mimarinizin dayanıklılığındadır.

Tazminatı almanın da bir prosedürü vardır ve bu genellikle otomatik değildir. Çoğu SLA, ihlali fark ettikten sonra belirli bir süre içinde (örneğin 30 gün) resmi bir talep açmanızı şart koşar. Talebinizde kesintinin başlangıç ve bitiş zamanını, etkilenen hizmeti ve mümkünse bağımsız izleme kanıtınızı sunmanız beklenir. Bu yüzden kendi izleme kayıtlarınızı tutmak yalnızca teknik merak değil, hakkınızı ararken kullanacağınız delildir. Clou.TR panelindeki uptime uyarıları özelliği bu kayıtları sizin adınıza tutmanıza yardımcı olur; yönetimli hizmetlerde ise sunucu yönetimi ekibi süreci takip eder.

Planlı Bakım Neden SLA Dışında Tutulur#

Hemen her SLA belgesinde "planlı bakım süreleri erişilebilirlik hesabına dahil edilmez" benzeri bir madde bulunur ve bu ilk bakışta haksız görünebilir. Ancak bunun teknik bir gerekçesi vardır. Sunucu işletim sistemi güncellemeleri, güvenlik yamaları, donanım değişimleri ve altyapı yükseltmeleri, hizmetin kısa süreli olarak durdurulmasını gerektirebilir. Bu kesinti önceden planlanır, düşük trafikli saatlere alınır ve size önceden bildirilir; dolayısıyla beklenmedik bir arıza değil, kontrollü bir işlemdir.

Adil bir SLA, planlı bakımı sınırsız bir kaçış kapısı olarak bırakmaz. İyi yazılmış maddeler şu güvenceleri içerir. Bakım en az belirli bir süre önceden (örneğin 48 saat) duyurulur. Bakım penceresi düşük trafik saatlerine (genellikle gece yarısı ile sabah arası) çekilir. Her ay için toplam planlı bakım süresine bir üst sınır konur. Bu koşullar yoksa, sağlayıcı teorik olarak "her kesinti planlıydı" diyerek garantiyi anlamsızlaştırabilir; bu yüzden sözleşmede bakım tanımının nasıl sınırlandığına bakın.

Planlı bakımın etkisini en aza indirmenin yolu, mimaride yedeklilik kurmaktır. İki uygulama sunucusunu bir yük dengeleyici arkasına koyarsanız, biri bakıma alınırken diğeri trafiği taşır ve ziyaretçi hiçbir kesinti görmez. Aşağıdaki basit Nginx yapılandırması bu mantığı gösterir; backup işaretli sunucu yalnızca birincil düğüm devre dışıyken devreye girer.

upstream uygulama {
    server 10.0.0.11:80 max_fails=2 fail_timeout=10s;
    server 10.0.0.12:80 backup;
}

server {
    listen 80;
    server_name ornek.com.tr;

    location / {
        proxy_pass http://uygulama;
        proxy_next_upstream error timeout http_502 http_503;
        proxy_connect_timeout 3s;
    }
}

Bu tür yedekli kurulumlar için tek bir paylaşımlı hesap yerine VDS veya sanal sunucu tercih etmek gerekir; kaynakların size ayrılmış olması, bakım ve ölçekleme kararlarını sizin kontrolünüze verir.

Gerçek Uptime'ı Nasıl Ölçersiniz#

Sağlayıcının açıkladığı uptime, kendi ölçüm noktalarından bakan bir rakamdır ve iyi niyetli olsa bile sizin ziyaretçinizin deneyimiyle her zaman birebir örtüşmez. Bağımsız ölçüm yapmanın en temel yolu, siteyi düzenli aralıklarla dış bir noktadan yoklamak ve sonuçları loglamaktır. Aşağıdaki bash betiği her dakika sitenizi yoklar, HTTP durum kodunu ve yanıt süresini kaydeder; bir dakikalık çözünürlükte basit ama güvenilir bir kanıt üretir.

#!/usr/bin/env bash
URL="https://ornek.com.tr/saglik"
LOG="/var/log/uptime-kontrol.log"

kod=$(curl -o /dev/null -s -w "%{http_code} %{time_total}" \
      --max-time 10 "$URL")

zaman=$(date '+%Y-%m-%d %H:%M:%S')
echo "$zaman $kod" >> "$LOG"

# 200 dışındaki her cevabı "kesinti" say
durum=$(echo "$kod" | cut -d' ' -f1)
if [ "$durum" != "200" ]; then
    echo "$zaman UYARI: durum=$durum" >> "$LOG"
fi

Bu betiği bir cron görevine bağlayarak sürekli çalıştırabilirsiniz. Aşağıdaki satır betiği her dakika tetikler; toplanan log dosyası, ay sonunda gerçek erişilebilirlik oranınızı hesaplamak için yeterli veriyi verir.

# crontab -e ile ekleyin
* * * * * /usr/local/bin/uptime-kontrol.sh

Ölçümü tek bir noktadan yapmak yeterli değildir; çünkü sizin sunucunuzla ölçüm noktanız arasındaki ağ da arızalanabilir ve bu sizin sitenizin suçu değildir. Gerçekçi bir sonuç için farklı coğrafi konumlardan, tercihen üçüncü taraf bir izleme servisiyle yoklama yapın ve yalnızca birden fazla noktanın aynı anda "erişilemez" dediği anları gerçek kesinti sayın. Tek noktanın hatalı ölçümü, aslında çalışan bir siteyi haksız yere "düşük uptime" göstererek yanıltır.

Toplanan verileri saklamak ve raporlamak için basit bir tablo yeterlidir. Aşağıdaki SQL şeması, her yoklamayı zaman damgasıyla kaydeder ve ay sonunda tek bir sorguyla erişilebilirlik oranını çıkarmanıza olanak tanır.

CREATE TABLE uptime_kayit (
    id        BIGINT AUTO_INCREMENT PRIMARY KEY,
    olculdu   DATETIME NOT NULL,
    durum_kod SMALLINT NOT NULL,
    yanit_ms  INT NOT NULL
);

-- Bir aylık gerçek uptime yüzdesi
SELECT
    ROUND(100 * SUM(durum_kod = 200) / COUNT(*), 3) AS uptime_yuzde
FROM uptime_kayit
WHERE olculdu >= '2026-07-01' AND olculdu < '2026-08-01';

Bu ölçüm disiplini yalnızca sağlayıcıyı denetlemek için değil, kendi altyapınızdaki eğilimleri erken görmek için de değerlidir. Yanıt sürelerinin haftalar içinde yavaşça artması, bir kesintiden önce gelen erken uyarıdır ve genellikle kaynak yetersizliğine işaret eder.

Uptime'ı Artırmak İçin Pratik Adımlar#

Yüksek uptime tek bir ayarın değil, birbirini tamamlayan birkaç kararın sonucudur. İlk ve en etkili adım yedekliliktir. Tek sunucu, tek disk, tek güç kaynağı olan her nokta bir "tek arıza noktası"dır ve o nokta çökünce siteniz çöker. Kritik bileşenleri (uygulama sunucusu, veritabanı, yük dengeleyici) çiftlemek, tek bir arızanın hizmeti tamamen durdurmasını engeller. Bu yüzden ciddi projeler için ayrılmış kaynak sunan sunucu çözümlerini tercih etmek mantıklıdır.

İkinci adım, düzenli ve test edilmiş yedeklemedir. Yedeğiniz varsa bir arıza saatlerce değil dakikalarca sürer; çünkü bozulan sistemi sıfırdan kurmak yerine son sağlam duruma geri dönersiniz. Yedekleme hizmetini otomatik ve dışarıda saklanacak biçimde kurmak, felaket senaryolarında uptime'ınızı kurtaran en ucuz sigortadır. Yedeklemenin işe yaradığını yalnızca gerçek bir geri yükleme denemesiyle bilebilirsiniz; hiç test edilmemiş yedek, olmayan yedektir.

Üçüncü adım, saldırılara ve trafik dalgalanmalarına karşı direnç kazandırmaktır. Bir DDoS saldırısı sunucunuzu boğarak dışarıdan bir "kesinti" gibi görünmesine yol açar; oysa sunucunuz sağlamdır, sadece meşru trafiğe cevap veremez hale gelmiştir. DDoS koruma ve WAF katmanları, bu tür yapay kesintileri filtreleyerek gerçek uptime'ınızı korur. Aşağıdaki gibi basit bir hız sınırlama (rate limit) yapılandırması bile, tek bir kaynaktan gelen aşırı isteklerin sunucuyu meşgul etmesini azaltır.

# İstek hızını IP başına saniyede 10 ile sınırla
limit_req_zone $binary_remote_addr zone=istekler:10m rate=10r/s;

server {
    location / {
        limit_req zone=istekler burst=20 nodelay;
        proxy_pass http://uygulama;
    }
}

Son olarak, izleme ve alarm kurun. Bir kesintiyi müşteriniz aramadan önce sizin öğrenmeniz gerekir. Erişilebilirlik düştüğü anda size e-posta veya anlık bildirim gönderen bir izleme sistemi, ortalama onarım süresini kısaltarak toplam kesintiyi doğrudan azaltır. Bu araçların bir kısmına ve DNS, SSL gibi ilgili kontrollere ücretsiz araçlar sayfasından ulaşabilirsiniz.

Sıkça Sorulan Sorular#

Yüzde 100 uptime garantisi mümkün mü?#

Pratikte hiçbir dürüst sağlayıcı %100 uptime garanti edemez, çünkü donanım arızası, ağ kesintisi, güç kaybı ve insan hatası gibi risklerin tamamını sıfırlamak fiziksel olarak imkânsızdır. "%100 garanti" ifadesini gördüğünüzde bunun genellikle bir pazarlama cümlesi olduğunu ve ince yazıyla planlı bakım, mücbir sebep ve müşteri hatası gibi geniş istisnalarla sınırlandığını varsayın. Gerçekçi ve iyi bir hedef, mimariye bağlı olarak %99.9 ile %99.99 arasıdır.

Uptime ile yanıt süresi aynı şey mi?#

Hayır, bunlar farklı iki metriktir ve ikisini birlikte değerlendirmek gerekir. Uptime sitenizin erişilebilir olup olmadığını, yani çalışıp çalışmadığını ölçer; yanıt süresi ise erişilebilir olduğunda ne kadar hızlı cevap verdiğini ölçer. Bir site %99.99 uptime'a sahip olabilir ama her sayfa on saniyede açılıyorsa kullanıcı deneyimi yine kötüdür. Sağlıklı bir izleme, hem "açık mı" hem de "hızlı mı" sorusunu aynı anda takip eder.

SLA ihlalinde tazminatı otomatik mi alırım?#

Genellikle hayır, tazminat çoğu sözleşmede talep üzerine verilir ve otomatik yansıtılmaz. İhlali fark ettiğinizde, sözleşmede belirtilen süre içinde (sıklıkla 30 gün) kesintinin zamanını ve etkisini belgeleyen bir başvuru açmanız beklenir. Bu yüzden kendi bağımsız izleme kayıtlarınızı tutmanız önemlidir; hem ihlali fark etmenizi sağlar hem de talebinizde kanıt olarak işe yarar. Başvuru yapılmazsa çoğu sağlayıcı krediyi kendiliğinden vermez.

Paylaşımlı hostingde yüksek uptime alabilir miyim?#

Kaliteli bir paylaşımlı hosting sağlayıcısı %99.9 civarı uptime sunabilir ve küçük siteler için bu genellikle yeterlidir. Ancak paylaşımlı ortamda sunucuyu başka müşterilerle bölüştüğünüz için, aynı makinedeki bir başka sitenin ani yük artışı sizin performansınızı da etkileyebilir. Trafiğiniz büyüdükçe ve kesinti maliyetiniz arttıkça, kaynakların size ayrıldığı VPS veya VDS gibi seçeneklere geçmek daha öngörülebilir bir uptime sağlar. İki modelin farkını ilgili karşılaştırma yazımızda ele alıyoruz.

Planlı bakım SLA süremi düşürür mü?#

Hayır, doğru tanımlanmış planlı bakım süreleri SLA erişilebilirlik hesabına dahil edilmez ve garantinizi düşürmez. Bunun koşulu, bakımın önceden duyurulması, düşük trafik saatlerine alınması ve makul bir süreyle sınırlandırılmasıdır. Sözleşmenizde planlı bakımın nasıl tanımlandığını ve aylık toplam bakım süresine bir üst sınır konulup konulmadığını kontrol edin; bu sınır yoksa madde kötüye kullanılabilir. Yedekli mimari kurarak planlı bakımı ziyaretçilerinizin hiç fark etmeyeceği hale getirmek de mümkündür.

Uptime düşükse hangi ilk adımları atmalıyım?#

Öncelikle sorunun gerçekten sunucunuzda mı yoksa ağ yolunda mı olduğunu bağımsız ölçümle netleştirin; birden fazla konumdan yapılan yoklama bunu ayırt eder. Kesinti sunucu kaynaklıysa loglara bakarak nedenini (bellek tükenmesi, disk dolması, çöken servis) tespit edin ve yedekli bir mimariyle tek arıza noktalarını kaldırın. Ardından otomatik yedekleme ve anlık alarmlı izleme kurarak hem onarım süresini kısaltın hem de bir sonraki kesintiyi erken yakalayın. Yönetimli bir hizmet kullanıyorsanız bu adımları destek ekibiyle birlikte planlamak süreci hızlandırır.

Kapanış#

Uptime ve SLA, hosting seçiminde en çok yanlış anlaşılan iki kavramdır. Uptime sitenizin gerçekte ne kadar erişilebilir olduğunu ölçen bir istatistik, SLA ise sağlayıcının bu erişilebilirliği taahhüt ettiği ve tutmadığında ne yapacağını yazdığı sözleşmedir. Yüzde 99.9 gibi rakamların yıllık saatlere karşılık geldiğini gördükten sonra, artık pazarlama diliyle mühendislik gerçeğini ayırt edebilir, hangi oranın işiniz için yeterli olduğuna bilinçli karar verebilirsiniz. Unutmayın ki gerçek koruma tazminat maddesinde değil, yedekli mimaride, test edilmiş yedeklerde ve sürekli izlemededir.

Clou.TR olarak, ölçülebilir erişilebilirlik ve şeffaf SLA anlayışıyla hizmet veriyoruz. Küçük bir proje için web hosting ve WordPress hosting planlarımız, büyüyen iş yükleri için ise VDS ve sanal sunucu çözümlerimiz kaynakları size ayırarak öngörülebilir bir uptime sunar. Yönetimli desteğe ihtiyaç duyarsanız sunucu yönetimi ekibimiz altyapınızı sizin adınıza izler; erişilebilirliğinizi ilk günden güvence altına almak için bugün doğru planı seçin.