“%99,9 uptime garantisi” pazarlama broşürlerinin klasik başlığıdır. Pratikte ne anlama geliyor? Yıllık 8 saat 45 dakika izinli kesinti. 30 gün içinde 43 dakika. Bu süreyi aşan her saniye için cezai SLA kredisi devreye giriyor. Bu yazıda CloudSpark Cloud’un %99,9 SLA’sı arkasındaki mimari yapıyı ve müşterilerimizin iş sürekliliği projelerinde uyguladığımız desenleri saha tecrübemle anlatıyorum.

SLA Anatomisi: %99 vs %99,9 vs %99,99

SLA	Aylık izinli kesinti	Yıllık izinli kesinti	Tipik mimari
%99	~7 saat 18 dk	~3 gün 15 saat	Single instance, manuel restart
%99,5	~3 saat 39 dk	~1 gün 19 saat	Single instance + auto restart
%99,9	~43 dk 50 sn	~8 saat 45 dk	HA cluster, multi-instance
%99,95	~21 dk 56 sn	~4 saat 22 dk	HA + cross-AZ
%99,99	~4 dk 23 sn	~52 dk 36 sn	Cross-AZ + cross-region

%99,9 hedefe ulaşmak için single point of failure olmamalı. Compute, storage, network, power, cooling — hepsi en az ikili yedeklenmeli.

Compute Redundancy: VM Failover

CloudSpark Cloud’un compute katmanında her sanal makine bir host’ta çalışır. Host (fiziksel sunucu) düşerse VM’in yaşam döngüsü:

1. Host failure tespiti (heartbeat kaybı ~~30 saniye).
2. OpenStack Nova compute service’in failover triger’ı.
3. VM’in Ceph üzerindeki disk volume’u başka host’ta mount edilir.
4. VM yeni host’ta start edilir (~~60-90 saniye).

Toplam recovery time: ~~2-3 dakika. Critical workload için bu çok bile olabilir; uygulama seviyesinde HA (load balancer + multi-instance) gerekiyor.

Müşterilerimizde uyguladığımız desen: Stateless web/API servisleri için minimum 2 instance arkasında load balancer. Stateful database için master-slave replication (PostgreSQL streaming, MySQL semi-sync, MongoDB replica set) ile otomatik failover.

Storage Triple Replication: Veri Kaybı Önleme

Ceph storage cluster default 3-way replication ile çalışır. Bir disk yazma işleminde:

1. Client write request gönderir.
2. Primary OSD (Object Storage Daemon) yazmayı kabul eder.
3. Aynı anda 2 secondary OSD’ye replikasyon başlar (farklı host’lar, mümkünse farklı rack’ler).
4. 3 yazmanın ackı geldiğinde client’a “OK” döner (synchronous replication).

Bu yapı sayesinde 2 disk veya 2 host eşzamanlı düşse bile veri kaybı olmaz (sadece 3. replika kalmış olur). 3 disk eşzamanlı düşmesi pratikte çok düşük olasılık (failure domain ayrı host/rack’lere yayılmış).

Tradeoff: 1 TB usable storage için 3 TB raw capacity. Hyperscaler’ın object storage’ında bu maliyet kullanıcıya yansımıyor (arka planda yapılıyor, fiyatın içinde). CloudSpark fiyatlandırması da usable GB üzerinden, müşteri raw kapasiteyi düşünmüyor.

Network Failover: Bond + Spine-Leaf

Her hypervisor host’un en az 2 fiziksel NIC’i (genellikle 2x 25 Gbps), LACP bonding ile birleşik. Bir kablo veya switch port düşerse trafik otomatik diğer kablodan geçer.

Datacenter network mimarisi spine-leaf:

• Her host iki ayrı leaf switch’e bağlı.
• Her leaf birden fazla spine switch’e bağlı.
• Tek noktada failure tüm trafik’i etkilemez.

Public internet edge: BGP multihoming ile birden fazla ISP. Bir ISP düşerse trafik otomatik diğeri üzerinden akar (~~30-90 saniye BGP convergence).

Power ve Cooling: Tier III+ Datacenter

• 2N+1 UPS sistemi (kesinti sıfır).
• Yedek dizel jeneratörler (yakıt kapasitesi 72 saat).
• Cooling redundancy (N+1 chiller, hot/cold aisle containment).
• Fire suppression (FM-200 veya inert gas).
• Multi-feed power (iki ayrı şebeke kaynağından beslenmeyen tier III+ datacenter).

Bu fiziksel altyapı CloudSpark’ın doğrudan operasyonunda; tüm bu redundancy’ler %99,9 SLA’nın temelini oluşturuyor.

Backup Stratejisi: 3-2-1-1-0 Kuralı

HA tek başına yetmez. Veri silme, ransomware, mantıksal bozulma gibi senaryolar için backup şart. Müşterilerimizde uyguladığımız modern backup kuralı:

• 3 kopya veri (1 production + 2 backup)
• 2 farklı medya (disk + object storage)
• 1 kopya offsite (farklı bölge)
• 1 kopya immutable (silinemez, ransomware-proof)
• 0 hata (restore testi düzenli yapılmalı)

CloudSpark Backup (Acronis tabanlı) ile uygulanışı:

Production VM (Bursa DC)
├── Daily incremental backup → Bursa S3 (hot tier)
├── Weekly full backup → Ankara S3 (offsite, cold tier)
└── Monthly snapshot → Immutable S3 bucket (180 gün retention, lock policy)

Restore testi: Her 3 ayda bir, kritik 5 sistem için tam restore yapılıp veri bütünlüğü kontrol edilir.

DRaaS: Cross-Site Replikasyon

İş sürekliliği gereksinimi backup’tan ileri ise (örn: bankacılık, hastane sistemi), DRaaS devreye girer. CloudSpark DRaaS:

• RPO (Recovery Point Objective): ~~5 dakika (replikasyon sürekli, async).
• RTO (Recovery Time Objective): ~~15-30 dakika (test failover’a göre).
• Production Bursa, DR Ankara (veya farklı kombinasyon).
• DR site’da VM’ler “warm standby” – kapalı ama snapshot hazır.
• Failover komutuyla VM’ler DR site’da açılıyor, IP yeniden assign ediliyor, DNS güncelleniyor.

Bir E-Ticaret Müşterisi: Black Friday Senaryosu

İzmir’de bir e-ticaret platformumuz var. Yıllık ciro ~~180 milyon TL, Black Friday günü tek günlük cironun %12’si. 2025 Black Friday için yapılan planlama:

• Compute scaling: Web tier normal 6 VM, Black Friday öncesi 24 VM’e scale-out. Application tier 12 → 36 VM.
• Database: PostgreSQL master + 2 read replica. Read replica’lara read-heavy traffic dağıtıldı.
• Cache: Redis cluster 6 node’a çıkarıldı.
• Static assets: CDN (CloudSpark partner CDN üzerinden) full preheating.
• Monitoring: Real-time dashboard, otomatik alert thresholds.
• DR drill: 1 hafta önce tam test failover (sürekli yedek site soğuk durumda).

Black Friday günü: Saat 00:01’de trafik 8x normal. Kısa süreli iki incident:

1. 00:14 – Application VM’lerden birinde memory leak, HA otomatik restart, kullanıcı etkisi 0.
2. 02:47 – Bir Redis node’una network ısıkı, sentinel failover, ~~12 saniye gecikme yaşandı.

Toplam etkili kesinti: ~~12 saniye. SLA hedef %99,9 günlük 86 saniyenin altında. ROI: tek günde alınan ciro normal aylığın 1.4 katı, tüm yıl boyunca uptime maliyetinin karşılığı.

Sahada Düşülen Üç Tuzak

1. SLA’yı tek katmanda görmek: %99,9 IaaS SLA’sı her şeyi kapsamıyor. Application seviyesinde HA kurulmadıysa, infra düşmüş olmasa da uygulama down olabilir. Stateless mimari + load balancer + auto-scaling şart.
2. Backup test edilmiyor: Yedek var sanıyorsun, restore zamanı geliyor, dosya bozuk veya eksik. Düzenli (en az çeyreğe bir) restore drill yap.
3. DR planını dökümante etmemek: Failover 7/24 SOC tarafından yapılır ama runbook yoksa ilk DR olayında panik. Adım adım runbook + role assignment + iletişim listesi.

Sonuç: Uptime Bir Sonuç, Mimari Bir Yatırım

%99,9 uptime tek başına bir ürün değil, doğru mimari + doğru operasyon + doğru yatırım sonucu ortaya çıkan bir metric. CloudSpark Cloud altyapısı bu hedefi destekliyor; gerisi müşterinin uygulama mimarisini de HA-aware tasarlamasına bağlı.

CloudSpark olarak iş sürekliliği değerlendirmesi, BIA (Business Impact Analysis), HA + DR mimari tasarımı ve drill yönetimi konularında end-to-end danışmanlık veriyoruz. Mevcut sistemlerin SLA durumunu değerlendirmek için ücretsiz analiz workshop’u sunuyoruz.