Kısa cevap: Bulut sunucu sağlayıcılarının SLA (Hizmet Seviyesi Anlaşması) taahhütleri ve sundukları destek seviyeleri, kesintisizlik ihtiyacınıza ve şirketinizin teknik öz-yeterliliğine göre seçilmelidir. KOBİ'ler için %99,9 ila %99,99 kesintisizlik oranları arasındaki fark, yılda yaklaşık 8,7 saatlik ekstra kesinti süresi ve ciddi bir maliyet katmanı demektir. Yalnızca donanım odaklı altyapı garantisine değil, işletim sistemi ve uygulama seviyesini kapsayan "yönetilen destek" hizmetlerine bakarak yapılan bir bulut sunucu sla karşılaştırma analizi, KOBİ'lerin bütçelerini verimli kullanmasını sağlar.
Bulut Sunucu SLA Karşılaştırma Rehberi: SLA Yüzdeleri Gerçekte Ne Anlama Geliyor?
Yazılım ve altyapı satın alımlarında teknik olmayan yöneticilerin en çok karşılaştığı ancak sıklıkla yanlış yorumladığı kavramların başında SLA (Service Level Agreement) gelir. Sağlayıcıların broşürlerinde yer alan "%99,9 Uptime" vaadi, kağıt üzerinde kusursuz görünse de yıllık bazda saatlerce süren sistem kesintilerine izin veren hukuki bir sınır ifade eder.
KOBİ ölçeğinde bir işletme için kesinti süresinin ne anlama geldiğini netleştirmek adına SLA yüzdelerini yıllık ve aylık bazda tolere edilebilir kesinti sürelerine dönüştürmek gerekir. Aşağıdaki tablo, sağlayıcıların sunduğu standart taahhütlerin somut karşılığını göstermektedir:
| SLA Yüzdesi | Aylık Maksimum Kesinti | Yıllık Maksimum Kesinti | KOBİ Operasyonuna Somut Etkisi |
|---|---|---|---|
| %99,0 | 7 saat 18 dakika | 3 gün 15 saat | Kabul edilemez. Yalnızca kritik olmayan iç test ortamları için uygundur. |
| %99,5 | 3 saat 39 dakika | 1 gün 19 saat | Mesai saatleri dışında tolere edilebilen dahili dosya sunucuları için sınır değer. |
| %99,9 ("Üç Dokuz") | 43 dakika 49 saniye | 8 saat 45 dakika | Standart B2B web siteleri ve dahili ERP/CRM sistemleri için en rasyonel F/P eşiği. |
| %99,99 ("Dört Dokuz") | 4 dakika 22 saniye | 52 dakika 35 saniye | E-ticaret platformları, ödeme sistemleri ve kesintisiz B2B SaaS hizmetleri için gerekli. |
| %99,999 ("Beş Dokuz") | 26 saniye | 5 dakika 15 saniye | Bankacılık, telekomünikasyon ve kritik sağlık altyapıları. KOBİ ölçeği için aşırı maliyetlidir. |
Teknik bir karar verici olarak göz önünde bulundurmanız gereken ilk kural şudur: Yüzde 99,9'dan %99,99 seviyesine geçiş yapmak, altyapı maliyetinizi basitçe %10 artırmaz; sistemin tamamen çift yedekli (redundant) ve yük dengeleyicili (load balancer) mimariye geçmesini zorunlu kıldığı için maliyetleri iki ila üç katına çıkarabilir.
Altyapı SLA'sı ile Uygulama Seviyesi SLA Arasındaki Hayati Fark
Global bulut devleri (AWS, Google Cloud, Microsoft Azure vb.) veya yerel veri merkezleri tarafından sunulan standart SLA sözleşmeleri, neredeyse istisnasız bir şekilde "Yalnızca Altyapı ve Veri Merkezi (Infrastructure) SLA'sı"dır. Yani sağlayıcı size şu taahhütte bulunur: "Sana tahsis ettiğim fiziksel sunucu, hipervizör ve ana ağ bağlantısı çalışır durumda olacak."
Ancak bir KOBİ'nin karşılaşacağı sorunların %90'ı altyapı kaynaklı değildir. Bir güvenlik açığı nedeniyle sunucunuzun kilitlenmesi, veritabanı indeksinin bozulması, disk doluluğu nedeniyle web servisinizin çökmesi veya bot saldırısı almanız durumunda global sağlayıcının altyapı SLA'sı sizi korumaz. Altyapı %100 ayakta olsa dahi, web siteniz veya uygulamanız erişilemez durumdadır ve global sağlayıcı bu durumda sorumluluk kabul etmez.
Sistemlerinizin sürekli erişilebilir kalması, sunucu üzerindeki trafik yükünün ve bot saldırılarının doğru yönetilmesine bağlıdır. Benzer bir sorun yaşıyorsanız, web sitesi çökme nedenleri ve sunucu yükü yönetim rehberimizi inceleyerek problemin teknik kökenini anlayabilirsiniz.
Bu noktada devreye "Yönetilen Hizmet SLA'sı" (Managed Service SLA) girer. Yönetilen hizmet sağlayıcıları veya uzman yazılım/sunucu danışmanlığı firmaları, işletim sistemi, veritabanı, güvenlik katmanı ve uygulama sunucusunun (Nginx, Apache vb.) çalışır durumda kalmasını taahhüt eder.
Destek Seviyeleri (Support Tiers) ve Mülkiyet Sorumlulukları
Bir bulut sunucu sağlayıcısı veya yönetilen hizmet partneri seçerken sözleşmede yazan destek detayları, kriz anındaki tek güvencenizdir. Destek seviyelerini değerlendirirken iki temel kavramı birbirinden ayırmalısınız:
- İlk Yanıt Süresi (Time to First Response - TTFR): Talebinizi ilettikten sonra teknik ekibin durumu incelemeye başladığını bildirdiği süre.
- Çözüm Süresi (Time to Resolution - TTR): Oluşan arızanın tespiti, giderilmesi ve sistemin tekrar çalışır hale getirilmesi süresi.
Pek çok sunucu sağlayıcısı "15 dakikada destek yanıtı" garantisi verir. Ancak bu yanıt genellikle otomatiğe bağlanmış bir "Talebiniz alındı, uzman ekibimiz inceliyor" mesajından ibarettir. KOBİ'ler için kritik olan, müdahale eden mühendisin yetkinlik seviyesi (Tier 1, Tier 2, Tier 3) ve sorunun ne kadar sürede çözüleceğidir.
Destek Kademeleri Neleri Kapsar?
Tier 1 Destek: Temel soruları yanıtlayan, şifre sıfırlama gibi basit işlemleri yapan, teknik derinliği olmayan çağrı merkezi kademesidir. Kritik bir çökme durumunda vakit kaybına neden olur.
Tier 2 Destek: İşletim sistemi yönetimi, veritabanı problemleri ve ağ konfigürasyonlarına müdahale edebilen kıdemli sistem yöneticileridir. KOBİ'lerin kriz anında doğrudan ulaşması gereken seviyedir.
Tier 3 Destek: Altyapı mimarları, kıdemli DevOps uzmanları ve yazılım geliştiricilerden oluşur. Veritabanı kilitlenmeleri, karmaşık mimari hatalar ve özel kod seviyesindeki tıkanıklıkları çözerler.
Kesintilerin önüne geçmenin en etkili yolu sorun oluştuktan sonra müdahale etmek değil, sistemdeki darboğazları önceden tespit etmektir. Şirketinizin altyapı performansını anlık olarak izlemek için sunucu otomatik performans izleme sistemleri ve verimlilik analizi içeriğimizden faydalanabilirsiniz.
KOBİ'ler İçin Bulut Sunucu SLA Karşılaştırma ve Karar Matrisi
İşletmenizin ölçeğine ve sunduğunuz hizmetin kritiklik derecesine göre doğru SLA ve destek paketini seçebilmeniz için hazırladığımız karar matrisi aşağıdadır:
| Şirket Profili & Hizmet Tipi | Önerilen SLA Oranı | Gerekli Destek Seviyesi | Kritik Durum (P1) Yanıt Süresi | Yönetilen Hizmet İhtiyacı |
|---|---|---|---|---|
| Kurumsal Tanıtım Sitesi / B2B Katalog (Anlık satış yapılmayan, prestij odaklı) |
%99,5 - %99,9 | Mesafe İçi (8x5) Tier 1 / Tier 2 Destek | 2 - 4 Saat | Düşük: Standart yedekleme ve temel güvenlik güncellemeleri yeterlidir. |
| Orta Ölçekli E-Ticaret / B2B Sipariş Portalı (Saatlik kesintinin doğrudan ciro kaybı yarattığı) |
%99,99 | 7/24 Tier 2 / Tier 3 Doğrudan Erişim | 15 - 30 Dakika | Yüksek: Otomatik ölçekleme, anlık veritabanı izleme ve bot koruması şarttır. |
| B2B SaaS / Kurumsal Yazılım Sağlayıcısı (Müşterilerine kendisi SLA taahhüt eden) |
%99,99 veya %99,999 | 7/24 Adanmış DevOps / Sistem Mimarı | 15 Dakika Altı | Kritik: Çoklu veri merkezi yedekliliği ve proaktif performans optimizasyonu gerekir. |
| Dahili Şirket Sistemleri (ERP/CRM/IK) (Mesai saatlerinde kullanılan dahili araçlar) |
%99,9 | Mesai Saatleri (5x12) Tier 2 Destek | 1 - 2 Saat | Orta: Mesai dışı bakımlara uygun, düzenli snapshot ve felaket kurtarma senaryoları. |
Sunucu SLA ve Destek İhtiyaçlarınızı Birlikte Belirleyelim
Kesinti sürelerinizi sıfıra yakın tutarken bütçenizi optimize etmek için sunucu altyapınızı ve mevcut sözleşmelerinizi uzman ekibimizle ücretsiz değerlendirin.
Ücretsiz Değerlendirme İsteyinBulut Sağlayıcı Sözleşmelerindeki Gizli SLA Tuzakları
KOBİ karar vericilerinin sözleşme imzalarken gözden kaçırdığı detaylar, ilk ciddi sistem kesintisinde finansal ve operasyonel kayıplara yol açar. Bir bulut sunucu sla karşılaştırma yaparken sözleşme metinlerinde şu 4 kritik maddeyi aramalısınız:
1. Tazminat ve İade Şartları (Service Credits vs. Cash Refunds)
Bir bulut sağlayıcısı SLA taahhüdünü ihlal ettiğinde (örneğin sisteminiz %99,9 yerine %98 oranında ayakta kaldığında) size doğrudan oluşan ticari kaybinizi ödemez. Kendi ihmallerinden kaynaklı kesintilerde dahi sorumlulukları, sözleşmede yer alan "Hizmet Kredisi" (Service Credit) ile sınırlıdır.
Sisteminiz 12 saat çöktüğünde ve 50.000 TL ciro kaybettiğinizde, sağlayıcı genellikle sadece çöken sunucunun o güne denk gelen kullanım bedelini (örneğin 100 TL) bir sonraki ayın faturasından indirim olarak düşer. Bu nedenle SLA'yı bir "sigorta poliçesi" olarak görmemeli, kesintiyi hiç yaşatmayacak yedekli mimarilere odaklanmalısınız.
2. Planlı Bakım İstisnaları (Scheduled Maintenance)
Pek çok sağlayıcı, önceden haber verilen bakım çalışmalarını SLA kesinti hesaplamasının dışında tutar. Cuma gecesi yapılan 4 saatlik bir veri merkezi bakımı, aylık kesinti sürenize yansımaz. E-ticaret yapan bir KOBİ için Cuma gecesi yaşanan kesinti ticari bir felaket olsa da, sağlayıcı hukuki olarak taahhüdünü bozmamış sayılır.
3. "Downtime" (Kesinti) Tanımı
Sağlayıcının kesinti tanımı ile sizin tanımınız uyuşmayabilir. Birçok hyper-scaler, sunucunuza paket ulaştığı sürece kesinti olmadığını savunur. Sunucunuza ulaşılıyor ancak veritabanı yanıt vermediği için sayfa 30 saniyede açılıyorsa veya %50 paket kaybı yaşanıyorsa, sağlayıcının gözünde sistem ayaktadır, sizin gözünüzde ise çalışmıyordur.
4. Sorumluluk Paylaşım Modeli (Shared Responsibility Model)
Tüm bulut sağlayıcıları bu modeli uygular. Sağlayıcı donanım, fiziksel güvenlik ve sanallaştırma katmanından sorumludur. İşletim sisteminin güncellenmesi, konfigürasyon hataları, SSL sertifikasının süresinin dolması, yazılımsal kilitlenmeler ve veri yedeklemesi tamamen müşterinin (yani sizin) sorumluluğunuzdadır.
Eğer kurum içinde özel bir sistem yöneticiniz (SysAdmin) veya DevOps uzmanınız yoksa, doğrudan altyapı kiralamak yerine yönetilen bulut hizmeti almanız şarttır. Maliyet optimizasyonu yaparken hibrit çözümleri de değerlendirebilirsiniz; detaylar için KOBİ’ler için hibrit bulut ve yerel sunucu karşılaştırma rehberimizi okuyabilirsiniz.
KOBİ'ler İçin SLA ve Destek Bütçesi Planlama Rehberi
Sunucu ve destek bütçesi oluşturulurken yapılan en büyük yanlış, yalnızca varsayılan sanal sunucu (vCPU/RAM) kiralama bedeline bakmaktır. Gerçekçi bir bütçe planı, üç temel bileşenden oluşur:
- Ham Altyapı Maliyeti: Sunucu, depolama (SSD/NVMe), bant genişliği ve IP bedelleri.
- Lisans ve Güvenlik Maliyetleri: İşletim sistemi lisansları, panel lisansları (cPanel, Plesk vb.), WAF ve firewall çözümleri.
- Yönetilen Destek ve SLA Paket Bedeli: Proaktif izleme, 7/24 acil müdahale, yedekleme yönetimi ve yazılım güncellemeleri.
Piyasadaki güncel koşullar ve hizmet standartları dikkate alındığında, KOBİ'ler için ortalama aylık bütçe bantları aşağıdaki gibi şekillenmektedir (Fiyatlar tahmini aralıklardır; sunucu sayısı, trafik hacmi ve döviz kuru dalgalanmalarına göre değişiklik gösterir):
Temel Düzey Altyapı + Standart Destek (Aylık Tahmini: 100 USD - 300 USD)
Dahili sistemler ve düşük trafikli kurumsal siteler için uygundur. Sağlayıcı yalnızca altyapının çalışmasını garanti eder (%99,9 SLA). Destek mesai saatleri içindedir, yazılımsal sorunlara müdahale edilmez. Sistem izleme ve yedekleme sorumluluğu KOBİ'dedir.
Yönetilen Bulut (Managed Cloud) ve Proaktif SLA (Aylık Tahmini: 300 USD - 1.000 USD)
E-ticaret siteleri, B2B sipariş platformları ve kritik kurumsal uygulamalar için ideal seviyedir. %99,99 altyapı SLA'sına ek olarak; 7/24 anlık izleme, 15-30 dakika içinde acil durum müdahalesi, günlük felaket yedeklemesi ve güvenlik yamalarının uygulanması dahildir.
Yüksek Erişilebilirlikli (HA) Mimariler ve Özel Destek (Aylık Tahmini: 1.000 USD - 3.500 USD+)
Yüksek anlık ziyaretçisi olan SaaS platformları ve büyük e-ticaret altyapıları. Yük dengeleyiciler, yedekli veritabanı kümelemeleri (clustering) ve özel atanmış kıdemli sistem mimarı desteğini kapsar. Kesinti toleransı sıfıra yakındır.
Adım Adım Sağlayıcı ve Destek Değerlendirme Çerçevesi
Bir bulut sunucu sağlayıcısı veya yönetilen hizmet partneri ile masaya oturduğunuzda, teknik ekibiniz olmasa dahi şu adımları izleyerek doğru seçimi yapabilirsiniz:
1. Adım: Kesinti Maliyetinizi Hesaplayın
Sistemlerinizin 1 saat kapalı kalmasının şirketinize maliyetini formüle edin: (Saatlik Ortalama Ciro Kaybı) + (Atıl Kalan Personelin Saatlik Maliyeti) + (Marka İtibarı Kaybı). Çıkan rakam, üst düzey bir SLA ve destek paketine vermeniz gereken aylık tavan bütçeyi belirler.
2. Adım: Destek Ekibiyle Sözleşme Öncesi Test Yapın
Satış temsilcisiyle değil, teknik destek ekibiyle iletişim kurmayı talep edin. Birkaç teknik senaryo vererek ("Veritabanı çökerse ne kadar sürede ve nasıl müdahale ediyorsunuz?") verdikleri yanıtların detayını ve samimiyetini ölçün.
3. Adım: İzleme ve Alarm Altyapısını Sorgulayın
Sa
