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. Bu rehber, hesaplama örnekleri ve sözleşmede kontrol edilecek maddelerle pratik bir okuma çerçevesi sunuyor.
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. Belirli bir ölçüm döneminde %100 uptime görülebilir; ancak bu, kesintisizliğin süresiz garanti edilebileceği anlamına gelmez. Planlı bakım, donanım arızası, ağ kesintisi veya yazılım hatası erişilebilirliği etkileyebilir.
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 hedeflerine karşılık gelen matematiksel kesinti eşiklerini hesaplayalım. Bunlar gerçek kesintinin aşamayacağı sınırlar değildir; SLA değerlendirmesinde ölçüm dönemi, kapsam ve istisnalar belirleyicidir:
| Uptime | Hedefe karşılık gelen aylık kesinti (30 gün) | Hedefe karşılık gelen yıllık kesinti (365 gün) |
|---|---|---|
| %99.0 | 432 dakika (7 saat 12 dakika) | 3 gün 15 saat 36 dakika |
| %99.5 | 216 dakika (3 saat 36 dakika) | 1 gün 19 saat 48 dakika |
| %99.9 | 43.2 dakika | 8 saat 45 dakika 36 saniye |
| %99.95 | 21.6 dakika | ~4 saat 23 dakika |
| %99.99 | 4.32 dakika | ~52.6 dakika |
| %99.999 | ~26 saniye | ~5 dakika 15 saniye |
Yani %99.9 hedefinin dönem bazındaki karşılığı şöyledir:
- 30 günlük bir dönemde, tüm süre ve kesintiler hesaba katıldığında eşik 43.2 dakikadır; bu süre aşılmadığında %99.9 uptime hedefi sağlanır.
- 365 günlük bir dönemde aynı hedefin karşılığı 8 saat 45 dakika 36 saniyedir. Ancak aylık SLA’de her ay ayrı değerlendirilir; yıllık toplamın bu eşiğin altında olması, herhangi bir aydaki ihlali ortadan kaldırmaz.
Ö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. Altyapı planlaması, ağ ve donanım yedekliliği ve operasyonel süreçler, taahhüt edilen SLA hedeflerini destekleyecek şekilde tasarlanmalıdır.
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. SLA hesabında toplam süre ve kesinti süresi, sözleşmenin kapsam ve istisna kurallarına göre belirlenmelidir:
Uptime (%) = (Toplam süre – Kesinti süresi) / Toplam süre × 100
Buradan kesinti süresini bulmak için uptime oranını ondalık biçimde (%99.9 için 0.999) kullanın:
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 “5 dakikadan uzun kesintiler sayılır” gibi bir alt eşik de bulunabilir; bu yüzden sadece toplam süre değil, “ne zaman kesinti sayılıyor” kısmı da önemlidir.
Örnek 2: Varsayımsal bir senaryo
Diyelim ki 30 günlük bir ay içinde, birbiriyle çakışmayan ve tamamı SLA hesabına dahil edilen ş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 varsayımlarla, aylık %99.9 uptime hedefi sağlanır: 42 dakika, 43.2 dakikalık kesinti eşiğinin altındadı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ı (SLA kapsamına dahil olup olmadığı ayrıca kontrol edilmelidir).
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. SLA değerlendirilirken müşterinin algıladığı toplam erişilebilirliğe etki eden katmanları birlikte düşünmek gerekir; hangi katmanın garanti edildiğinin sözleşmede net yazması kritiktir.
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. Sözleşmeye bağlı olarak şu durumlar SLA kapsamı dışında bırakılabilir:
- Planlı bakım çalışmaları: Önceden belirli bir süre önce duyurulan ve genellikle gece saatlerine konan bakım pencereleri.
- Force majeure (mücbir sebep): Deprem veya sel gibi olaylar; büyük çaplı bir altyapı arızasının mücbir sebep sayılıp sayılmadığı da sözleşme ve uygulanacak hukuk çerçevesinde değerlendirilmelidir.
- DDoS ve güvenlik saldırıları: Özellikle ağa yönelik büyük hacimli saldırılar için istisna bulunup bulunmadığını ve varsa sınırlarını kontrol edin.
- 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. Bakım pencerelerinin süresini, duyuru yöntemini ve müşteri trafiğine etkisini değerlendirin; kritik iş yüklerinde bakımın etkisini azaltmak için yedekli mimarileri de ele alın.
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.
Varsayımsal bir kredi tablosu şöyle olabilir; bunlar DCHost’un veya başka bir sağlayıcının doğrulanmış SLA koşulları değildir:
- Uptime %99.0 ve üzeri, %99.9’un altında: %10 hizmet kredisi
- Uptime %95.0 ve üzeri, %99.0’ın altında: %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.
- Kredi için üst limit de bulunabilir; limitin hangi hizmet bedeli ve hangi dönem üzerinden hesaplandığını kontrol edin.
5. Bildirim ve talep süreleri
Kesinti telafi kapsamına girse bile başvuru veya kayıt koşullarını kaçırmak kredi talebinin reddedilmesine yol açabilir. Örnek koşullar:
- “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. Sağlayıcıdan olay bildirimlerinin nasıl yapılacağını öğrenin; yazılı SLA metni her iki taraf için de referans noktası olmaya devam eder.
%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 hedefi, 30 günlük bir ayda toplam yaklaşık 7 saat 12 dakika ile 3 saat 36 dakika arasında kesintiye karşılık gelir; ancak bu tolerans projeniz için kabul edilebilirse yeterli sayılabilir. 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 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 kesinti riskini azaltmayı ele aldığımız rehbere mutlaka bakmanızı öneririz.
Finans, sağlık, kamu ve kritik altyapılar
Kritik iş yüklerinde “beş dokuz” (%99.999) gibi sıkı uptime hedefleri seçilebilir; gereken seviye işlevin kritikliğine ve geçerli yükümlülüklere bağlıdır. Ancak böyle bir hedef yalnızca hosting planı seçimiyle sağlanmaz. Mimari tasarım, veri merkezi seçimi, çok bölgeli replikasyon ihtiyacı, çevrimdışı iş sürekliliği planları ve düzenleyici kurallarla uyumlu operasyon süreçleri birlikte değerlendirilmelidir.
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 ile uptime ve SLA için neleri değerlendirmelisiniz?
Uptime’ı yalnızca bir pazarlama sloganı değil, uçtan uca bir mühendislik problemi olarak ele almak gerekir. DCHost ile hizmet seçeneklerini görüşürken şu başlıkları netleştirin:
- Yedekli ağ ve güç altyapısı kapsamında, tek noktadan gelecek arızalara karşı hangi katmanlı önlemlerin bulunduğu.
- VPS, dedicated ve colocation çözümlerinde, donanım seçimi ve ağ topolojisinin uptime hedefleriyle nasıl uyumlandırıldığı.
- 7/24 izleme ve alarm kapsamının ne olduğu ve alarmlara nasıl müdahale edildiği.
- Planlı bakımların nasıl duyurulduğu ve hizmete etkisinin nasıl sınırlandırıldığı.
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:
- SLA metnini gerçekten okuyun: Özellikle “kapsam”, “istisnalar”, “ölçüm” ve “telafi” başlıklarına odaklanın.
- İ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.
- Harici izleme kurun: Hosting sağlayıcısından bağımsız monitörler ile uptime’ınızı siz de ölçün.
- Bakım iletişimini test edin: Planlı bakım duyuruları zamanında ve şeffaf mı geliyor, kontrol edin.
- Olay sonrası rapor isteyin: Ciddi bir kesinti yaşandığında, “root cause analysis” ve alınan önlemler hakkında bilgi talep edin.
- 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.
- 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, takvim süresinin tamamı esas alındığında 30 günlük ayda yaklaşık 43 dakikalık, 365 günlük yılda ise yaklaşık 8 saat 46 dakikalık kesintiye karşılık gelir. Bunlar hedefin matematiksel karşılıklarıdır; gerçek kesintinin bu süreleri aşmayacağı garantisi değildir ve SLA istisnaları kullanıcıların yaşadığı toplam kesintiyi hesap dışında bırakabilir. 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
İ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.
Görüşme öncesinde mevcut mimarinizi, kabul edilebilir kesinti sürenizi ve kritik bağımlılıklarınızı hazırlayın; böylece SLA kapsamını ihtiyaçlarınızla somut olarak karşılaştırabilirsiniz.
