99.9% Uptime Ne Anlama Gelir? Hosting SLA Sözleşmelerini Okuma Rehberi

99.9% uptime gerçekten ne kadar kesinti demek?

Hosting seçerken neredeyse her yerde benzer ifadeler görüyorsunuz: “%99.9 uptime”, “yüksek erişilebilirlik”, “7/24 kesintisiz hizmet”… Peki bu rakamların arkasında tam olarak ne var? %99.9 uptime denildiğinde, gerçekte ne kadar kesinti riski alıyorsunuz ve bu, işiniz için kabul edilebilir mi? Özellikle e‑ticaret, SaaS veya kritik kurumsal uygulamalar çalıştırıyorsanız, bu sorunun cevabı doğrudan ciroya ve itibarınıza dokunuyor.

Bu yazıda pazarlama cümlelerini bir kenara bırakıp, rakamların ve sözleşme metinlerinin içine gireceğiz. %99.9 uptime’ın matematiksel karşılığını, tipik bir hosting SLA (Service Level Agreement – Hizmet Düzeyi Sözleşmesi) dokümanının satır aralarını ve hangi maddelere özellikle dikkat etmeniz gerektiğini adım adım anlatacağız. DCHost tarafında altyapı tasarlarken ve SLA kurgularken yaşadığımız gerçek deneyimlerden yola çıkarak, sadece teorik değil pratikte işe yarayan bir okuma rehberi hazırladık.

Eğer bugüne kadar uptime garantilerini “zaten hepsi aynı” diye düşünüyorsanız, muhtemelen telafi koşulları, istisnalar ve ölçüm yöntemleri kısmını hiç detaylı okumamışsınızdır. Hedefimiz, bir sonraki hosting veya sunucu kararınızda SLA metnini elinize alıp, birkaç dakika içinde “benim için yeterli mi, değil mi” diyebileceğiniz net bir çerçeve vermek.

Uptime kavramı ve %99.9’un çıplak matematiği

Uptime, en basit tanımıyla bir sistemin belirli bir dönem boyunca çalışır ve erişilebilir olduğu sürenin, toplam süreye oranıdır. %100 uptime teorik bir hayal; gerçek dünyada her sistem, planlı bakım, donanım arızası, ağ kesintisi veya yazılım hatası nedeniyle zaman zaman erişilemez hale gelir.

Konuyu temelden hatırlamak isterseniz, uptime’ın ne olduğunu, nasıl ölçüldüğünü ve nasıl iyileştirilebileceğini detaylı anlattığımız uptime kavramını temelden anlattığımız rehberimize mutlaka göz atın. Bu yazıda ise doğrudan %99.9 ve benzeri seviyelerin pratik karşılığına odaklanacağız.

%99.9, %99.99, %99.5… Aylık ve yıllık kesinti süreleri

Varsayım: 1 ayı 30 gün kabul edelim.

• 30 gün = 30 × 24 = 720 saat = 43.200 dakika
• 1 yıl ≈ 365 gün = 8.760 saat = 525.600 dakika

Şimdi farklı uptime seviyelerinin izin verdiği maksimum kesintiyi hesaplayalım:

Yani bir sağlayıcı %99.9 uptime garantisi veriyorsa, bu şu anlama gelir:

• Bir ay içinde yaklaşık 43 dakikaya kadar kesinti yaşanabilir ve SLA hâlâ ihlal edilmiş sayılmaz.
• Bir yılda yaklaşık 9 saatlik toplam kesinti, sözleşmeye göre “normal” kabul edilir.

Örneğin yüksek cirolu bir e‑ticaret sitesinde, yoğun kampanya dönemlerinde 30–40 dakikalık bir kesintinin yaratacağı kaybı düşünün. Sizin için bu rakam kabul edilebilir olabilir de, olmayabilir de. Önemli olan, bu matematiği bilerek karar vermeniz.

SLA (Service Level Agreement) nedir ve neden kritiktir?

SLA, bir hizmet sağlayıcının size hangi seviyede hizmet sunacağını resmi olarak taahhüt ettiği dokümandır. Yani “%99.9 uptime veriyoruz” cümlesinin pazarlama sloganı olmaktan çıkıp, somut kurallara dönüştüğü yerdir. DCHost olarak biz de tüm altyapı planlamasını, ağ ve donanım yedekliliğini ve operasyonel süreçleri bu SLA hedefleri etrafında kurguluyoruz.

Hosting SLA’larında genelde neler olur?

Tipik bir hosting SLA dokümanında şu başlıkları görürsünüz:

• Hizmet kapsamı: Hangi servisler (paylaşımlı hosting, VPS, dedicated, ağ, güç vb.) bu SLA’ye dahil?
• Uptime garantisi: Yüzde kaç? Aylık mı yıllık mı hesaplanıyor?
• Ölçüm yöntemi: Hangi izleme sistemine, hangi zaman dilimine göre ölçülüyor?
• İstisnalar: Bakım, DDoS saldırıları, müşteri kaynaklı hatalar gibi hangi durumlar uptime hesabı dışına alınıyor?
• Telafi modeli: Uptime hedefi tutturulamazsa nasıl bir hizmet kredisi veriliyor?
• Bildirim ve talep süreci: Müşteri bu krediyi talep etmek için ne kadar süre içinde, nasıl başvuru yapmalı?
• Destek SLA’sı: Yanıt süresi, çözüm süresi, 7/24 destek gibi ek operasyonel taahhütler.

Bu başlıklar kağıt üzerinde “standart” görünse de, her sağlayıcı detaylarda farklı davranır. Aynı %99.9 uptime ibaresi, iki farklı SLA’de bambaşka bir gerçeklik anlamına gelebilir. İşte asıl kritik nokta burada başlıyor.

%99.9 uptime nasıl hesaplanır? Adım adım yaklaşım

%99.9 uptime hesabında temel formül basit:

Uptime (%) = (Toplam süre – Kesinti süresi) / Toplam süre × 100

Buradan kesinti süresini bulmak için:

Kesinti süresi = Toplam süre × (1 – Uptime oranı)

Örnek 1: Aylık SLA

Toplam süre: 30 gün = 43.200 dakika

%99.9 uptime için:

• Kesinti oranı = 1 – 0.999 = 0.001
• Kesinti süresi = 43.200 × 0.001 = 43.2 dakika

Bu 43.2 dakika, ay boyunca bölünmüş birçok kısa kesinti şeklinde de olabilir, tek seferde yaşanan uzun bir kesinti şeklinde de. SLA metninde genelde “5 dakikadan uzun kesintiler sayılır” gibi alt tanımlar da yer alır; bu yüzden sadece toplam süre değil, “ne zaman kesinti sayılıyor” kısmı da önemlidir.

Örnek 2: Gerçek bir senaryo

Diyelim ki bir ay içinde şu kesintileri yaşadınız:

• Planlanmamış sunucu hatası: 12 dakika
• Ağ tarafında kısa kesintiler: 3 × 4 dakika = 12 dakika
• Disk arızası sonrası manuel müdahale: 18 dakika

Toplam: 42 dakika kesinti.

Bu durumda sağlayıcınızın SLA’sı %99.9 ise, teknik olarak hâlâ sözünü tutmuş sayılır. Siz tarafında kayıp büyük olsa bile, telafi hakkınız doğmayabilir. İşte bu yüzden salt yüzdeye değil, telafi eşiğine ve telafi modeline de bakmak gerekiyor.

SLA dokümanında özellikle bakmanız gereken kritik maddeler

Şimdi işin en pratik kısmına gelelim: %99.9 uptime yazan bir SLA dokümanını elinize aldığınızda nerelere bakmalısınız?

1. Kapsam: Hangi “uptime” ölçülüyor?

SLA’de geçen uptime ifadesi her zaman tüm resmi kapsamaz. Çoğu zaman şu ayrımlar vardır:

• Ağ (network) uptime: Veri merkezinin internet çıkışının erişilebilir olması.
• Güç (power) uptime: Veri merkezinde elektrik sürekliliği (şebeke + UPS + jeneratör).
• Sunucu (compute) uptime: Fiziksel sunucu veya sanallaştırma katmanının çalışır olması.
• Uygulama uptime’ı: Web siteniz veya özel yazılımınızın ayakta olması (çoğu klasik hosting SLA’sında yer almaz).

Bir sağlayıcı sadece “network uptime” için %99.99 sözü verip, sunucu tarafında ayrı (ve daha düşük) bir hedef belirlemiş olabilir. Veya sadece veri merkezine kadar olan kısmı garanti edip, firewall/CDN gibi diğer katmanları kapsam dışında bırakabilir. DCHost olarak biz SLA tasarlarken, müşterinin algıladığı toplam erişilebilirliğe etki eden katmanları bütünüyle düşünmeye çalışıyoruz; yine de hangi katmanın garanti edildiğini sözleşmede net yazmak kritik.

2. Ölçüm yöntemi: Hangi saate, hangi araca göre?

SLA’de mutlaka şu soruların cevabını arayın:

• Uptime neye göre hesaplanıyor? Sağlayıcının kendi izleme sistemine mi göre?
• Zaman dilimi (time zone) ne? UTC mi, yerel saat mi?
• Ölçüm periyodu ne kadar? Aylık mı, yıllık mı?

Örneğin aylık SLA’de, bir ay içindeki birkaç saatlik büyük bir kesinti, yıllık SLA perspektifinde “kabul edilebilir” görünebilir. Ayrıca sadece sağlayıcının izleme araçlarına dayanmak yerine, siz de mutlaka harici izleme sistemleri kurmalısınız. Prometheus, Grafana veya harici uptime izleme servisleri ile ilgili başlangıç seviyesinde bir çözüm arıyorsanız, VPS izleme ve alarm kurulumuna dair rehberimizi inceleyebilirsiniz.

3. İstisnalar: Hangi kesintiler sayılmıyor?

İstisnalar bölümü, uptime yüzdesini anlamak kadar önemli. Genellikle şu durumlar SLA kapsamı dışındadır:

• Planlı bakım çalışmaları: Önceden belirli bir süre önce duyurulan ve genellikle gece saatlerine konan bakım pencereleri.
• Force majeure: Deprem, sel, büyük çaplı altyapı arızaları gibi öngörülemeyen olağanüstü durumlar.
• DDoS ve güvenlik saldırıları: Özellikle ağa yönelik büyük hacimli saldırılar, çoğu SLA’de istisna olarak belirtilir.
• Müşteri kaynaklı hatalar: Yanlış yapılandırma, hatalı kod dağıtımı, aşırı kaynak tüketen sorgular gibi.

SLA’de “bakım çalışmaları”nın nasıl tanımlandığına dikkat edin. Örneğin sağlayıcınız, ayda birkaç saatlik bakım yapma hakkını saklı tutuyor olabilir. DCHost tarafında bakım pencerelerini mümkün olduğunca kısa, şeffaf ve müşteri trafiğini en az etkileyecek saatlere yerleştirmeye çalışıyoruz; ayrıca kritik iş yüklerinde bakımın etkisini azaltmak için yedekli mimariler öneriyoruz.

4. Telafi modeli: Kaç dakika kesinti kaç kredi demek?

%99.9 uptime garantisi verilmesi, hedefin tutturulamaması halinde mutlaka para iadesi alacağınız anlamına gelmez. Çoğu SLA şu şekilde işler:

• Belirli eşiklerin altında kalındığında, hizmet kredisi (bir sonraki faturadan indirim) tanımlanır.
• Bu kredi genelde ilgili ayın hizmet bedeli üzerinden %5, %10, %25, %50 gibi oranlarla hesaplanır.

Örneğin şöyle bir tablo görebilirsiniz:

• Uptime %99.9 – %99.0 arası: %10 hizmet kredisi
• Uptime %99.0 – %95.0 arası: %25 hizmet kredisi
• Uptime %95.0 altı: %50 hizmet kredisi

Burada dikkat edilmesi gereken:

• Bu kredi genelde otomatik tanımlanmaz; sizin destek talebi açmanız gerekir.
• Hizmet kredisi nakit iade değil, sonraki dönemde kullanabileceğiniz bir indirimdir.
• Çoğu SLA’de “kredi, toplam yıllık fatura tutarınızın %X’ini aşamaz” gibi üst limitler de yer alır.

5. Bildirim ve talep süreleri

Birçok işletme, aslında hakkı olduğu halde telafi alamaz; çünkü SLA’nin son sayfasındaki küçük bir maddeyi kaçırmıştır. Örneğin:

• “Kesintinin yaşandığı tarihten itibaren 7 gün içinde yazılı başvuru yapılmalıdır.”
• “Sadece bizim destek sistemimizde kayıtlı kesintiler esas alınır.”

Bu yüzden sistemlerinizde ciddi bir kesinti yaşadığınızda, sadece teknik çözümle uğraşmayıp, aynı zamanda bu olayı tarih-saat bilgisiyle birlikte kayda almak ve gerekiyorsa SLA’ye göre talepte bulunmak önemli. DCHost olarak bizim yaklaşımımız, büyük olaylarda zaten proaktif bilgilendirme yapmak; yine de yazılı SLA metni her iki taraf için de referans noktası olmaya devam ediyor.

%99.9 uptime yeterli mi? Farklı senaryolar için doğrusu ne?

Herkes için tek bir “doğru” uptime seviyesi yok. İhtiyacınız, iş modelinize ve risk iştahınıza bağlı. Birkaç tipik senaryo üzerinden gidelim.

Kişisel blog, hobi projeleri

Bu tür projelerde birkaç dakikalık, hatta zaman zaman bir saatlik kesinti genelde ciddi bir problem yaratmaz. Burada bütçe ve basitlik daha ön plandadır. %99–%99.5 uptime sunan standart bir hosting planı çoğu zaman yeterli olabilir. Yine de arka planda düzenli yedek almayı ve basit izleme kurmayı ihmal etmemek önemli.

Küçük ve orta ölçekli işletme siteleri

Kurumsal kurumsal site, randevu sistemi, temel CRM entegrasyonları gibi yapılar barındırıyorsanız, iş kesintisi doğrudan müşteri kaybına dönüşebilir. Bu seviyede genellikle %99.9 uptime makul bir alt sınırdır. Ancak:

• Kritik formlar veya ödeme geçidi kullanıyorsanız, kesintilerin mesai saatlerine denk gelmemesi önem kazanır.
• DNS, SSL, yedekleme gibi bileşenlerin de düzgün yönetildiğinden emin olmanız gerekir.

E‑ticaret, SaaS ve yüksek trafik projeler

Burada konu sadece uptime yüzdesi değil, genel yüksek kullanılabilirlik (HA) mimarisidir. Tek bir sunucuya veya tek bir veri merkezine bağımlı kalmak yerine, çoklu node, yük dengeleme, yedekli veritabanı gibi yaklaşımlar devreye girer. Bu çerçeveyi daha geniş görmek için yüksek kullanılabilirlik (HA) mimarilerini ayrıntılı anlattığımız yazımıza göz atabilirsiniz.

Bu tip projelerde genellikle hedef:

• En az %99.9 (“üç dokuz”) ya da mümkünse %99.95 ve üzeri
• Yedekli altyapı, otomatik failover, CDN ve Anycast DNS kullanımı

Anycast DNS ve otomatik failover gibi DNS tabanlı çözümlerle kesinti riskini daha da azaltmak istiyorsanız, Anycast DNS ve otomatik failover ile kesintisiz yayını anlattığımız rehbere mutlaka bakmanızı öneririz.

Finans, sağlık, kamu ve kritik altyapılar

Bu seviyede hedef genellikle “beş dokuz” (%99.999) gibi çok daha sıkı uptime süreleridir. Ancak bu, sadece bir hosting planı seçerek elde edileceğiniz bir şey değildir; komple mimari tasarım, veri merkezi seçimi, çok bölgeli replikasyon, offline iş sürekliliği planları ve düzenleyici kurallarla uyumlu operasyon süreçleri gerektirir.

Böyle kritik projelerde SLA sadece bir başlangıçtır; esas önemli olan, kağıt üzerindeki hedefleri destekleyen tasarım ve operasyon disiplinidir.

DCHost tarafında uptime ve SLA’ya nasıl yaklaşıyoruz?

DCHost olarak bizim bakış açımız, uptime’ı yalnızca bir pazarlama sloganı değil, uçtan uca bir mühendislik problemi olarak ele almak. Bunun için:

• Yedekli ağ ve güç altyapısı kuruyor, tek noktadan gelecek arızalara karşı katmanlı önlemler alıyoruz.
• VPS, dedicated ve colocation çözümlerinde, donanım seçiminden ağ topolojisine kadar her adımı uptime hedefleriyle uyumlu planlıyoruz.
• 7/24 izleme ve alarm sistemleriyle olası sorunları, çoğu zaman müşteriler hissetmeden önce tespit etmeye çalışıyoruz.
• Planlı bakımları şeffaf şekilde duyurup, mümkün olduğunca kesintisiz veya çok kısa etkili olacak şekilde tasarlıyoruz.

Uptime’ın bir diğer ayağı da yedekleme ve felaket kurtarma. Bunun için sadece tek bir otomatik yedek özelliğine güvenmek yerine, 3-2-1 yedekleme stratejisini anlattığımız rehberde detaylandırdığımız gibi, birden fazla kopyayı farklı ortamlarda tutmayı öneriyoruz.

Daha kapsamlı bir iş sürekliliği planı yazmak istiyorsanız, RTO/RPO kavramlarını ve felaket senaryosu tatbiklerini adım adım ele aldığımız felaket kurtarma planı rehberimize de göz atabilirsiniz.

Kendi SLA’nizi doğrulamak için pratik kontrol listesi

%99.9 veya farklı bir uptime seviyesi içeren herhangi bir SLA’yi değerlendirirken şu adımları uygulamanızı öneririz:

1. SLA metnini gerçekten okuyun: Özellikle “kapsam”, “istisnalar”, “ölçüm” ve “telafi” başlıklarına odaklanın.
2. İhtiyaçlarınızı yazılı hale getirin: Kabul edilebilir aylık/yıllık kesinti süresi, mesai saatlerinde toleransınız ve kampanya dönemleri gibi kritik zamanları netleştirin.
3. Harici izleme kurun: Hosting sağlayıcısından bağımsız monitörler ile uptime’ınızı siz de ölçün.
4. Bakım iletişimini test edin: Planlı bakım duyuruları zamanında ve şeffaf mı geliyor, kontrol edin.
5. Olay sonrası rapor isteyin: Ciddi bir kesinti yaşandığında, “root cause analysis” ve alınan önlemler hakkında bilgi talep edin.
6. Yedekleme ve geri dönüşü doğrulayın: Sadece yedek alındığına değil, gerektiğinde geri dönülebileceğine dair testler yapın.
7. DCHost ekibiyle mimarinizi gözden geçirin: Özellikle e‑ticaret ve SaaS projelerinde, SLA hedefinizi destekleyecek VPS, dedicated veya çok sunuculu çözümleri beraber tasarlayın.

Özet: %99.9 uptime’ı doğru okumak ve doğru karar vermek

%99.9 uptime kulağa çok yüksek geliyor, ama sayılara döktüğünüzde ay içinde yaklaşık 43 dakikalık, yıl içinde ise neredeyse 9 saatlik kesinti toleransı anlamına geliyor. Bazı projeler için bu tamamen kabul edilebilir; bazı projeler içinse tek bir kampanya döneminde bile bu kadar kesinti yaşamak, ciddi gelir ve itibar kaybı demek. Bu yüzden, hosting seçerken asıl bakmanız gerekenler:

• Uptime yüzdesinin aylık/yıllık karşılığı
• Hangi katman için (ağ, güç, sunucu, uygulama) bu garantinin verildiği
• İstisnalar, ölçüm yöntemi ve telafi modeli
• Yedeklilik ve felaket kurtarma mimarisinin bu hedefi destekleyip desteklemediği

DCHost olarak amacımız, sadece bir rakam söylemek değil, bu rakamı karşılayacak (ve mümkünse üzerinde yaşayacak) bir altyapıyı birlikte inşa etmek. İster paylaşımlı hosting, ister NVMe tabanlı VPS, ister dedicated sunucu veya colocation arıyor olun; proje gereksinimlerinizi bizimle paylaştığınızda, size hem SLA metni hem de teknik mimari tarafında şeffaf bir yol haritası sunabiliriz.

Mevcut veya planladığınız projeyi birlikte değerlendirmek, uptime hedefinizi gerçekçi ve sürdürülebilir şekilde belirlemek isterseniz, DCHost ekibiyle iletişime geçmeniz yeterli. SLA’yı sadece imzalanan bir PDF olmaktan çıkarıp, gerçekten çalışan bir iş sürekliliği anlaşmasına dönüştürelim.