Uptime Nedir? Sunucu Erişilebilirliği ve SLA Rehberi 2026

Uptime Nedir? Sunucu Erişilebilirliği ve SLA Rehberi 2026

Sunucunuz günde kaç dakika erişilemez? "Hiç" diyorsanız yanılıyor olabilirsiniz. %99 ile %99.99 arasındaki fark kulağa küçük gelir; ama yılda 87 saat ile 52 dakika arasındaki fark, canlı bir e-ticaret sitesi için çok büyük bir farktır. Bu rehber uptime'ın ne anlama geldiğini, SLA'nın nasıl okunacağını, downtime nedenlerini ve yüksek erişilebilirlik mimarisini pratik örneklerle açıklamaktadır.

Buyukweb hizmetlerini arıyorsanız: Web Hosting, VDS Sunucu, E5-V4 VDS, Sanal Sunucu, cPanel Web Hosting — Bursa Pendc Tier 3 veri merkezinde %99.8 uptime SLA ile hizmet veriyoruz.

---

Uptime Nedir?

Uptime, bir sunucunun veya web sitesinin belirli bir zaman dilimi içinde kesintisiz ve erişilebilir biçimde çalıştığı süredir. Yüzde (%) cinsinden ifade edilir ve genellikle aylık ya da yıllık bazda hesaplanır.

Temel formül:

Uptime (%) = (Toplam Süre - Downtime Süresi) / Toplam Süre × 100

Örnek: 30 günlük bir ayda toplam süre 43.200 dakikadır. Sunucu 43 dakika erişilemez olduysa uptime = (43.200 - 43) / 43.200 × 100 = %99.9'dur.

Downtime ise sunucunun herhangi bir nedenle erişilemez olduğu süredir. Downtime planlı (bakım penceresi) veya plansız (arıza) olabilir; SLA hesaplamalarında her ikisi de farklı değerlendirilir.

---

"Dokuzlar" Tablosu: %99'dan %99.999'a Kadar

Uptime yüzdeleri arasındaki küçük farklar, gerçekte büyük zaman dilimlerine karşılık gelir. Aşağıdaki tablo her seviyenin yıllık ve aylık izin verilen maksimum downtime süresini göstermektedir:

Uptime	Yıllık Downtime	Aylık Downtime	Haftalık Downtime	Yaygın Kullanım
%99 (2 dokuz)	87 saat 36 dk	7 saat 18 dk	1 saat 41 dk	Geliştirme/test ortamları
%99.5	43 saat 48 dk	3 saat 39 dk	50 dk 24 sn	Düşük bütçeli projeler
%99.9 (3 dokuz)	8 saat 46 dk	43 dk 50 sn	10 dk 5 sn	Standart hosting SLA
%99.95	4 saat 23 dk	21 dk 55 sn	5 dk 2 sn	Premium hosting
%99.99 (4 dokuz)	52 dk 36 sn	4 dk 23 sn	1 dk 5 sn	Kritik kurumsal altyapı
%99.999 (5 dokuz)	5 dk 16 sn	26 sn	6 sn	Finansal/telekom sistemler

Pratik yorum: %99 ile %99.9 arasındaki tek bir "9" farkı, yılda 79 saat ekstra downtime anlamına gelir. Bir e-ticaret sitesi için bu, onlarca siparişin kaybolması demektir.

Buyukweb %99.8 uptime SLA garantisi vermektedir — bu aylık yaklaşık 86 dakika izin verilen pencereye karşılık gelir; ancak uygulamada hedeflenen gerçek uptime çok daha yüksektir.

---

Availability, Reliability ve Durability: Kavram Farkları

Uptime ile ilgili tartışmalarda bu üç kavram sıkça karıştırılır:

Kavram	Tanım	Ölçüm	Örnek
Availability (Erişilebilirlik)	Sistemin istek anında yanıt verebilir olması	Uptime %	%99.9 SLA
Reliability (Güvenilirlik)	Sistemin belirli koşullarda beklenen şekilde çalışması; MTTF (Mean Time To Failure) ile ölçülür	MTTF, MTBF	Disk MTBF 200.000 saat
Durability (Dayanıklılık)	Verinin kaybolmadan saklanması; depolama kalıcılığı	Veri kaybı ihtimali (9'lar)	%99.999999 veri dayanıklılığı

Özet: Sunucunuz erişilebilir ama tutarsız sonuç veriyorsa reliability sorunu vardır. Sunucunuz çalışıyor ama disk verileri yok oluyorsa durability sorunu vardır. SLA'larda en çok bahsedilen availability'dir.

---

Downtime Nedenleri

Planlanmamış downtime'ın başlıca kaynakları şunlardır:

1. Donanım Arızası

Disk, RAM, güç kaynağı veya ağ kartı gibi fiziksel bileşenlerin bozulması. Yedekli (redundant) donanım mimarisinde tek nokta arızaları (SPOF) sistemi çökertmez.

2. Ağ Kesintisi

ISP tarafındaki tıkanma, BGP yönlendirme sorunları veya DDoS saldırısı nedeniyle bant genişliği tükenmesi. Tier 3 veri merkezleri çoklu hat (multi-homed) yapısıyla bu riski azaltır.

3. DDoS Saldırısı

Hedefli trafik bombardımanı sunucunun meşru isteklere yanıt verme kapasitesini aşar. L4 (UDP flood) ve L7 (HTTP flood) olmak üzere iki ana katmanda gerçekleşir.

4. Bakım Penceresi (Scheduled Maintenance)

Güncelleme, kernel yama veya donanım değişimi gibi planlı işlemler. İyi planlanmış bakım, rolling update veya blue-green deployment ile downtime'a yol açmaz.

5. Yazılım Hatası / Bug

Uygulama çökmesi, bellek sızıntısı (memory leak), yanlış konfigürasyon veya başarısız yazılım güncellemesi. Bu kategori tüm downtime'ların önemli bir bölümünü oluşturur.

6. Güç Kesintisi

Elektrik altyapısı veya UPS arızası. Tier 3+ veri merkezleri N+1 UPS ve jeneratör redundancy'si ile bu riski minimize eder.

7. İnsan Hatası

Yanlış komut, konfigürasyon değişikliği veya yanlışlıkla silinen dosya. Incident response sürecinin önemi tam da bu senaryolarda ortaya çıkar.

---

SLA (Service Level Agreement) Nasıl Okunur?

SLA, hosting firmasının size garanti ettiği uptime ve bunun ihlal edilmesi durumunda uygulanan telafi mekanizmasını tanımlayan sözleşmedir.

Temel SLA Bileşenleri

1. Uptime Garantisi
Örnek: "%99.8 aylık uptime" — aylık toplam sürenin en fazla ~86 dakikası downtime olabilir.

2. Ölçüm Yöntemi
SLA'nın nasıl ölçüldüğü kritiktir. "Sunucu tarafı ölçüm" ile "dış kaynaklı monitoring" sonuçları farklılaşabilir. Güvenilir bir SLA, bağımsız ölçüm metodolojisini açıklar.

3. Penalty Clause (Ceza Maddesi) / Kredi Mekanizması
SLA ihlali durumunda müşteriye geri ödeme yapılır. Tipik kredi yapısı:

Aylık Uptime	Kredi
%99.0 - %99.8	1x (1 günlük hizmet bedeli)
%95.0 - %99.0	3x
%90.0 - %95.0	7x
%90.0 altı	15x veya sözleşme feshi hakkı

Önemli: SLA kredisi genellikle otomatik değildir. Destek talebi açarak ihlali belgeleyen bir ticket oluşturmanız gerekebilir.

4. Muafiyet Maddeleri (Exclusions)

SLA garantisi dışında kalan durumlar:

• Planlı bakım (Scheduled Maintenance): Önceden duyurulan bakım pencereleri genellikle downtime hesabına dahil edilmez.
• Force Majeure: Deprem, sel gibi doğal afetler.
• Müşteri kaynaklı sorunlar: Kendi yüklediğiniz yazılımın çökmesi, yanlış konfigürasyon.
• Üçüncü taraf servisler: DNS sağlayıcısı, CDN veya ödeme altyapısı kaynaklı kesintiler.

---

Uptime Ölçüm Araçları

Hosting firmasının söylediği uptime ile gerçek uptime her zaman örtüşmeyebilir. Bağımsız monitoring araçlarıyla kendi ölçümünüzü yapın:

Uptime Robot

• Ücretsiz katman: 50 monitor, 5 dakikalık polling aralığı
• HTTP, HTTPS, ping, port ve keyword monitoring desteği
• E-posta ve SMS bildirim
• Uptime raporları ve durum sayfası (status page) oluşturma
• Adres: uptimerobot.com

Freshping

• Ücretsiz katmanda 50 URL, 1 dakika polling
• Global lokasyonlardan paralel kontrol
• Webhook entegrasyonu (Slack, Discord, PagerDuty)

Better Uptime

• Ücretli; ekip bildirim yönetimi ve on-call rotasyonu güçlü
• Incident timeline ve post-mortem raporlama

Pingdom

• Ücretli; kurumsal kullanım için detaylı RUM (Real User Monitoring) ve sentetik test

Kendi Cron Ping Scripti

Basit bir bash script ile kendi monitoring altyapınızı kurabilirsiniz (aşağıdaki "Bash Monitor" bölümüne bakın).

---

Monitoring Metrikleri: Sadece "Uptime" Yetmez

Sunucunuzun "ayakta" olması her şeyin yolunda gittiği anlamına gelmez. İzlemeniz gereken temel metrikler:

TTFB (Time to First Byte)

Tarayıcının istek gönderdiği andan ilk baytı aldığı ana kadar geçen süre. 200 ms altı iyi; 500 ms üzeri kullanıcı deneyimini olumsuz etkiler. Sunucu yanıt süresi, ağ gecikmesi ve backend işlem süresinin toplamıdır.

Response Time (Yanıt Süresi)

Tüm sayfanın yüklenmesi için geçen süre. TTFB'den farklıdır; büyük kaynakların (CSS, JS, görsel) transferini de içerir.

Error Rate (Hata Oranı)

Belirli bir zaman diliminde HTTP 5xx dönen istek yüzdesi. %0.1 üzeri dikkat; %1 üzeri kritik alarm eşiği kabul edilebilir.

Availability %

HTTP 200 dönen başarılı istek oranı. External monitoring aracının ölçtüğü budur.

---

Yüksek Erişilebilirlik (HA) Mimarisi

Tek sunucu mimarisi her zaman SPOF (Single Point of Failure) içerir. Yüksek erişilebilirlik (High Availability — HA), bu tek nokta arızalarını ortadan kaldıran mimaridir.

Load Balancer (Yük Dengeleyici)

Gelen trafiği birden fazla sunucuya dağıtır. Bir sunucu düşerse trafik otomatik olarak sağlıklı sunuculara yönlendirilir.

İstemci → Load Balancer → [Web Sunucu 1]
                        → [Web Sunucu 2]
                        → [Web Sunucu 3]

Aktif-Pasif Failover

İki sunucu vardır: biri aktif çalışır, diğeri bekler. Aktif sunucu düşünce pasif devreye girer. Heartbeat sinyali ile sağlık kontrolü yapılır.

• Araçlar: Keepalived, Pacemaker + Corosync, DRBD (disk senkronizasyonu için)
• RTO (Recovery Time Objective): Genellikle 30 saniye - 2 dakika
• Dezavantaj: Pasif sunucu kaynak harcar ama iş yapmaz

Aktif-Aktif Cluster

Her iki sunucu da aynı anda trafik alır. Herhangi biri düşerse kalan sunucu tüm yükü devralır.

• Araçlar: HAProxy, Nginx upstream, Kubernetes
• RTO: Milisaniyeler
• Avantaj: Kapasiteyi de kullanır, failover'dan bağımsız ölçeklendirme mümkün

Veritabanı HA

Web sunucu HA'nın yanı sıra veritabanı katmanı da çoğaltılmalıdır:

• MySQL/MariaDB: Master-slave replikasyon veya Galera Cluster (aktif-aktif)
• PostgreSQL: Streaming replikasyon + Patroni
• Redis: Redis Sentinel veya Redis Cluster

---

Datacenter Tier Standartları (Uptime Institute)

Uptime Institute'un Tier standardı, veri merkezinin fiziksel altyapı güvenilirliğini tanımlar:

Tier	Uptime	Yıllık Downtime	Redundancy	Concurrent Maintainability
Tier 1	%99.671	28.8 saat	Yok	Hayır
Tier 2	%99.741	22 saat	Kısmi (N+1 güç)	Hayır
Tier 3	%99.982	1.6 saat	Tam (N+1 veya 2N güç, soğutma)	Evet — bakımda downtime yok
Tier 4	%99.995	26.3 dakika	2N+1 tam yedekli	Evet — arıza toleransı

Tier 3 ne anlama gelir?

• Birden fazla güç ve soğutma yolu (aktif + pasif)
• Herhangi bir bileşen bakıma alınırken sistem çalışmaya devam eder
• Yıllık maksimum 1.6 saat planlanmamış downtime
• Türkiye'deki kurumsal hosting altyapısı için tercih edilen standart

Tier 4: Tam arıza toleransı — bir yol veya bileşen tamamen devre dışı kalsa bile sistem çalışır. Finans, telekomünikasyon ve kritik kamu altyapılarında kullanılır.

Buyukweb altyapısı: Bursa Pendc Tier 3 veri merkezinde barındırılmaktadır. Bu seviye, bakım sırasında dahi kesintisiz erişim ve yıllık 1.6 saat altı planlanmamış downtime hedefini sağlar.

---

Türkiye'de Hosting Seçerken Uptime: Neden Tier 3 Önemli?

Türkiye'deki hosting altyapısı son yıllarda hızla olgunlaşmıştır. Ancak tüm firmalar aynı veri merkezi kalitesini sunmamaktadır. Hosting seçerken şu soruları sormanız önerilir:

1. Veri merkezi Tier belgesi var mı? Uptime Institute sertifikası, bağımsız denetimle doğrulanmış bir güvencedir.
2. Ağ altyapısı nasıl? Yerel backbone bağlantısı, Türkiye'den erişim hızını doğrudan etkiler. Birden fazla ISP'ye bağlantı (multi-homed) SPOF'u önler.
3. DDoS koruması hangi katmanda? L4 koruması UDP flood'u engeller; L7 koruma ise uygulama katmanı saldırılarını filtreler.
4. SLA belgesi talep edin: Uptime garantisi, ölçüm yöntemi ve kredi prosedürü yazılı olmalıdır.

Buyukweb, Bursa Pendc Tier 3 veri merkezinde Türkiye yerel backbone bağlantısıyla hizmet sunmaktadır. Web hosting paketleri ve VDS sunucu seçenekleri için sayfalarımızı inceleyebilirsiniz.

---

Incident Response Süreci

Downtime kaçınılmaz olduğunda doğru adımları izlemek iyileşme süresini (MTTR — Mean Time To Repair) minimize eder:

1. Tespit (Detection)

Monitoring aracı (Uptime Robot, Freshping, kendi scriptiniz) anormal durumu algılar ve bildirim gönderir. Alarm eşiği: İlk başarısız kontrol hemen alarm göndermemelidir (false positive önleme); genellikle 2-3 ardışık başarısız kontrol sonrası alarm tetiklenir.

2. Bildirim (Notification)

Teknik ekibe, müşterilere ve iç paydaşlara bilgilendirme yapılır. Durum sayfası (status page) güncellenir. "Sorunun farkındayız, araştırıyoruz" mesajı bile müşteri güvenini önemli ölçüde korur.

3. Teşhis (Diagnosis)

Log analizi, monitoring grafiklerine bakış, en son değişiklik incelemesi (change log) ile kök neden araştırılır. Araçlar: journalctl -xe, dmesg, Nginx/Apache error log, uygulama APM.

4. Düzeltme (Fix)

Kök nedene göre aksiyon: servis yeniden başlatma, hatalı konfigürasyonun geri alınması (rollback), kaynak artırımı, trafik yönlendirme.

5. Post-Mortem

Olay sonrasında; ne oldu, neden oldu, ne kadar sürdü, nasıl çözüldü ve tekrarını önlemek için ne yapılacak sorularını yanıtlayan yazılı rapor. Ekip içi öğrenme ve süreç iyileştirme için kritiktir.

---

Maintenance Window Best Practice

Planlı bakımı downtime'sız geçirmek için iki ana yöntem:

Rolling Update (Kademeli Güncelleme)

Cluster'daki sunucular tek tek güncellenir. Birini bakıma alırken diğerleri trafik almaya devam eder. Yük dengeleyici, bakımdaki sunucuyu otomatik devre dışı bırakır (drain).

Adım 1: web-01'i load balancer'dan çıkar → güncelle → geri ekle
Adım 2: web-02'yi load balancer'dan çıkar → güncelle → geri ekle
Adım 3: web-03 ... (tüm cluster güncellenene kadar devam)

Blue-Green Deployment

İki özdeş ortam (blue = canlı, green = yeni versiyon) paralel çalışır. Yeni versiyon green'e deploy edilir; testler geçince trafik tek seferde green'e taşınır. Sorun çıkarsa blue'ya geri dönmek saniyeler içinde gerçekleşir.

Mevcut durum:  Load Balancer → BLUE (v1.0) aktif
Deploy süreci: Green (v1.1) kur, test et
Geçiş:         Load Balancer → GREEN (v1.1) aktif
Rollback:      Load Balancer → BLUE (v1.0) aktif (anlık)

---

Bash ile Basit Uptime Monitor Scripti

Harici araçlara ek olarak kendi sunucunuzdan basit bir cron + curl ping monitoru kurabilirsiniz. Bu script, hedef URL'yi her 5 dakikada kontrol eder; erişilemezse e-posta gönderir.

#!/bin/bash
# /usr/local/bin/uptime-check.sh
# Kullanim: Her 5 dakikada cron ile calistirin

TARGET_URL="https://www.siteniz.com"
ALERT_EMAIL="[email protected]"
LOG_FILE="/var/log/uptime-check.log"
TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S")

# HTTP durum kodunu al (maksimum 10 saniye bekle)
HTTP_CODE=$(curl -o /dev/null -s -w "%{http_code}"   --max-time 10   --connect-timeout 5   "$TARGET_URL")

if [ "$HTTP_CODE" != "200" ]; then
  echo "[$TIMESTAMP] HATA: $TARGET_URL -> HTTP $HTTP_CODE" >> "$LOG_FILE"
  echo "UYARI: $TARGET_URL erisilemez! HTTP: $HTTP_CODE | Zaman: $TIMESTAMP"     | mail -s "Uptime Alarmı: Siteniz erisilemez!" "$ALERT_EMAIL"
else
  echo "[$TIMESTAMP] OK: $TARGET_URL -> HTTP $HTTP_CODE" >> "$LOG_FILE"
fi

Scripti kaydedip çalıştırılabilir yapın:

sudo chmod +x /usr/local/bin/uptime-check.sh

Cron ile 5 dakikada bir çalıştırın:

# crontab -e ile ekle:
*/5 * * * * /usr/local/bin/uptime-check.sh

Systemd timer ile daha sağlam bir alternatif:

# /etc/systemd/system/uptime-check.service
[Unit]
Description=Uptime Check Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/uptime-check.sh

# /etc/systemd/system/uptime-check.timer
[Unit]
Description=Uptime Check Timer

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

sudo systemctl enable --now uptime-check.timer
sudo systemctl list-timers uptime-check.timer

Uptime Robot ile fark: Uptime Robot dışarıdan kontrol eder (müşteri perspektifi); bu script sunucu içinden kontrol eder. İkisi birbirini tamamlar. Sunucunun kendi ağından erişebildiği bir URL'nin dışarıdan erişilemez olması ağ katmanı sorununa işaret edebilir.

---

Sık Sorulan Sorular

%99.9 uptime yılda kaç saat downtime demektir?

%99.9 uptime, yılda 8 saat 46 dakika downtime anlamına gelir. Bu süre aylık 43 dakika 50 saniyeye karşılık gelir. Aktif bir e-ticaret sitesi için bu değer kritiktir; %99.95 veya üzeri hedeflenmelidir.

SLA kredisi nasıl alınır?

SLA ihlali durumunda genellikle şu adımlar gerekir: (1) Kesinti süresini belgeleyin — monitoring aracı raporları veya sunucu logları kullanın. (2) Hosting firmasına destek talebi (ticket) açın, kesinti başlangıç/bitiş saatini ve kanıtını ekleyin. (3) Firmanın SLA sözleşmesinde belirtilen kredi hesaplama formülüne göre hesaplanan tutar bir sonraki faturadan düşülür. Otomatik kredi uygulaması nadirdir; aktif başvuru gerekebilir.

Monitoring ne sıklıkta ping atmalı?

1-5 dakika en yaygın aralıktır. Ücretsiz Uptime Robot hesabı 5 dakika polling sunar; bu çoğu site için yeterlidir. Kritik e-ticaret veya finansal uygulama için 1 dakika önerilir. 30 saniyeden kısa aralıklar, düşük trafikli bir sunucuda access log'u gereksiz şişirir.

Uptime Robot ücretsiz mi?

Evet, Uptime Robot'un ücretsiz katmanı 50 monitor, 5 dakika polling aralığı, e-posta bildirimi ve durum sayfası içermektedir. Küçük ve orta ölçekli siteler için bu kota çoğunlukla yeterlidir. Daha sık kontrol (1 dk), SMS bildirimi ve çoklu lokasyon desteği için ücretli planlar mevcuttur.

Datacenter Tier 3 ile Tier 4 arasındaki fark nedir?

Tier 3 veri merkezleri N+1 redundancy ile herhangi bir bileşeni devredışı bırakmadan bakım yapılabilmesini sağlar. Tier 4 ise tam arıza toleransı (fault tolerance) sunar; bir bileşen veya yol tamamen arızalansa bile sistem çalışmayı sürdürür. Tier 4, Tier 3'e göre çok daha yüksek yatırım gerektirir; genellikle finans ve telekomünikasyon sektörlerinde tercih edilir. Kurumsal hosting için Tier 3 büyük çoğunlukla yeterli ve maliyet-etkin çözümdür.

Tek sunucu ile %99.99 uptime elde edilebilir mi?

Pratikte son derece güçtür. Donanım arızası, kernel güncellemesi veya yazılım hatası durumunda tek sunucu çökebilir ve recovery süresi SLA'yı ihlal eder. %99.99 hedefi için yük dengeleyici + en az 2 web sunucu + replikasyonlu veritabanı mimarisi neredeyse zorunludur.

Planlı bakım downtime SLA'yı etkiler mi?

SLA sözleşmesindeki muafiyet maddelerine göre değişir. Önceden bildirimli (genellikle 24-48 saat öncesinden duyurulmuş) bakım pencereleri çoğu SLA hesaplamasından muaf tutulur. Bildirimsiz veya uzun süre aşan planlı bakımlar kredi kapsamına girebilir. Sözleşmenin "Exclusions" veya "Muafiyetler" bölümünü okuyun.

---

İlgili Büyükweb Hizmetleri

• Web Hosting — %99.8 SLA garantili, Tier 3 veri merkezinde cPanel hosting
• VDS Sunucu — Türkiye lokasyonlu, yüksek erişilebilirlik odaklı sanal sunucular
• E5-V4 VDS — Intel Xeon E5-V4, NVMe SSD, 7/24 teknik destek
• Sanal Sunucu — Paket karşılaştırması ve özellik detayları
• cPanel Web Hosting — Yönetim kolaylığı, otomatik günlük yedekleme

Uptime garantisi, SLA detayları veya altyapı soruları için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.