İş kritik web projelerinde “%99.9 uptime” yalnızca pazarlama ifadesi değil; ölçülebilir, denetlenebilir ve finansal sonuçları olan bir hizmet sözüdür. Bu rehber, kurumsal ekiplerin uptime oranlarını doğru yorumlaması, SLA maddelerini risk yönetimi perspektifiyle okuması ve gerçek dünyada yüksek erişilebilirliği sağlayan teknik/pratik koşulları kurumsal bir dille ele alır. Amaç, sadece “daha fazla 9” peşinde koşmak değil; iş hedefleriniz, bütçe ve teknik kapasitenizle uyumlu, sürdürülebilir bir erişilebilirlik standardı kurmaktır.
%99.9 Uptime Nedir? Matematiksel Karşılığı, Yanıltıcı Yanlar ve Beklenti Yönetimi
%99.9 uptime, bir hizmetin belirli bir ölçüm döneminde (çoğunlukla aylık) toplam sürenin en az %99.9’unda kullanılabilir olduğu taahhüdüdür. Bu oran, 30 günlük bir ay için yaklaşık 43.2 dakika (0.1% × 43,200 dk) planlanmamış kesintiye izin verir. Yıllık bazda (525,600 dk) yaklaşık 8 saat 45 dakika tolerans anlamına gelir. Karşılaştırma yapmak için: %99.99 aylık ~4.32 dk, yıllık ~52.6 dk; %99.95 aylık ~21.6 dk kesinti toleransı sağlar. Bu basit matematik bile, “bir 9 daha”nın ne kadar büyük bir operasyonel sıçrama anlamına geldiğini gösterir. Çünkü kalan kesinti penceresi logaritmik olarak küçülürken altyapı karmaşıklığı ve maliyet hızla artar.
Buradaki kritik nokta, “kullanılabilirlik” tanımının ne olduğudur. Tam kesinti (hard down) kadar kısmi kesinti (ör. checkout servisi çalışmıyor, CDN POP’larından biri hatalı cevaplıyor) veya performans bozulması (95. persentil yanıt süresi kabul edilemez seviyede) da kullanıcı gözünde kesintidir; ancak SLA metninde kapsama alınıp alınmadığı değişebilir. Birçoğu yalnızca “temel HTTP kullanılabilirliği”ni ölçer ve “yüksek hata oranı, yavaşlık, kısıtlı fonksiyonellik” gibi senaryoları kapsam dışı bırakır. Yine benzer şekilde, planlı bakım pencereleri, force majeure, müşteri kaynaklı hatalar, üçüncü taraf bağımlılıkları gibi kalemler, matematiksel uptime hesabının dışına itilebilir.
Bu nedenle, %99.9 gibi görünen çekici bir oran, sözleşmedeki tanıma göre çok daha dar bir güvence sağlayabilir. Kurumsal alımda doğru yaklaşım, SLA’nın neyi saydığına odaklanmak ve iş açısından “gerçek kesintiyi” temsil eden ölçütleri sözleşmeye açıkça yazdırmaktır: tam/kısmi kesinti tanımları, bölgeler arası (region/POP) farklılık, performans eşiği (ör. 95p < 400 ms) ve gerçek kullanıcıyı etkileyen kriterler. Aksi halde, tabloda %99.9 görünürken ekipleriniz gün boyu “kullanılamaz ama sayılmıyor” durumlarla mücadele edebilir.
SLA’da Hangi Metrikler Olmalı? Ölçüm Dönemi, Kapsam, Hariçler ve Delil Standartları
Sağlam bir SLA, sadece “uptime yüzdesi” içermez; ölçüm metodolojisi ve kanıtlama biçimini tarif eder. Öncelikle zaman penceresi (aylık/çeyreklik) ve ölçüm sıklığı (1 dakikalık/5 dakikalık proplar) belirlenmelidir. Ping veya port kontrolü tek başına yeterli değildir; HTTP/HTTPS uç noktalarında gerçek işlem (ör. 200 OK + belirli yanıt gövdesi) doğrulaması istenmelidir. Çok bölgeli mimarilerde, çoklu lokasyondan ölçüm zorunludur; tek bir lokasyondaki ağ sorunu, küresel hizmeti yanlış “down” gösterebilir veya tersi.
Kapsam başlığında; tam/kısmi kesinti, yüksek hata oranı (ör. 5xx > %2), kabul edilemez yanıt süreleri (ör. 95p > 800 ms), DNS çözümlenememe, TLS sertifika hataları ve kritik bağımlı servislerin (kimlik, ödeme, CDN origin, veritabanı) durumları nasıl değerlendirileceği açıkça yazılmalıdır. Hariç tutulanlar listesi mutlaka daraltılmalı: “planlı bakım” için önceden bildirim süresi (örn. 7 gün), yıllık toplam planlı bakım kotası (örn. ≤ 4 saat) ve yalnızca gece saatleri gibi kısıtlar eklenmelidir. “Üçüncü taraf” hariçleri (ör. global DNS sağlayıcısı, kamu bulutu) varsayılan biçimde tümden kapsam dışı kalmamalı; en azından müşterinin faydalanamadığı süre kısmi kredi doğurmalıdır.
Delil standardı, tartışmaları hızlı çözer: Sağlayıcı izleme kayıtları kadar, müşterinin bağımsız izleme verileri (synthetic + RUM), olay numarası, başlangıç–bitiş zamanları, kullanıcı etkisi ve kök neden analizi (RCA) raporları kredilendirme sürecinin parçası olmalıdır. “İtiraz süresi” ve “cevap/çözüm süresi SLA’ları” (SLO) ayrıca tanımlanmalı; yalnızca kullanılabilirlik değil, destek hizmet seviyesi de mutabakata bağlanmalıdır. Bu yapı, kesintinin varlığını ve kapsamını yoruma bırakmadan, sözleşmeye dayalı yönetişim sağlar.
Uptime ≠ Performans: Erişilebilirlik, Güvenilirlik ve Deneyim SLA’larını Ayırmak
Bir sistem ayakta olabilir, ancak kabul edilebilir hızda hizmet veremiyorsa kullanıcı gözünde “fiilen kapalıdır”. Bu nedenle kurumsal SLA tasarımında üç katmanı ayırmak verimli olur: (1) Erişilebilirlik SLA’sı (endpoint up/down), (2) Güvenilirlik/kalite SLA’sı (hata oranı, veri bütünlüğü), (3) Deneyim/performans SLO’ları (TTFB, 95./99. persentil yanıt süreleri, hata/saniye). Bu ayrım, tartışmaları “sunucu çalışıyordu ama checkout yapılamıyordu” gibi gri alanlardan çıkarır.
Kısmi kesinti örneklerini sözleşmeye yazdırın: Bölgesel POP arızası, tek bir mikroservisin down olması, ödeme sağlayıcısı entegrasyon hatası, kimlik sisteminin aksaması, veritabanında kilitlenme (lock) nedeniyle 95p yanıt sürelerinin hedefi aşması. Her biri için etki düzeyi (kritik/orta/düşük), algılama yöntemi (metrik/izleme kuralı) ve kredi tablosu (ör. kritik kesintide her 15 dakikada %2 kredi) tanımlanabilir.
Ayrıca, durumsal degradasyon (degrade mode) politikaları belirlemek, “tamamen kapanma” yerine “kısıtlı ama çalışır” senaryolarını mümkün kılar: Örneğin görsel sıkıştırmayı geçici kapatmak, bazı raporları asenkrona almak, yoğun saatlerde istek başına limit uygulamak. Bu tür esnek stratejiler, uptime yüzdesini korurken işlevsel deneyimi de makul seviyede tutar. Sonuçta, SEO ve gelir açısından önemli olan, salt “UP” olmak değil; öngörülebilir hız ve işlemlerin tamamlanabilirliğidir.
İzleme (Monitoring) ve Doğrulama: Synthetic, RUM, Çoklu Bölge ve Durum Sayfaları
SLA’yı güvenceye almak için bağımsız, çok katmanlı izleme kurgusu şarttır. Synthetic monitoring, dünyadaki farklı lokasyonlardan belirli aralıklarla tanımlı işlemleri çalıştırır: DNS çözümleme, TLS el sıkışması, HTTP yanıtı, uygulama akışı (login, sepet, ödeme) gibi. RUM (Real User Monitoring) ise gerçek kullanıcıların tarayıcılarından LCP/INP/CLS, TTFB ve hata oranlarını toplar; bu sayede yalnızca “teorik olarak erişilebilir” değil, gerçek deneyimin sürekliliği ölçülür.
Kurgu yapılırken, kontrol sıklığı (30–60 sn), eşik tanımları (3 lokasyondan ardışık 2 hata = incident), gürültü azaltma (flapping önleme), susturma pencereleri (bakım) ve otomatik olay açma (incident management) süreçleri netleştirilmelidir. İzleme ajanları yalnızca dış uçlara değil; iç servisler, veritabanı, mesaj kuyrukları, cache katmanı ve disk I/O metriklerine de erişmelidir. 95./99. persentil odaklı panolar, sıradan ortalamaların gizlediği kuyruk sorunlarını görünür kılar.
Durum sayfası (status page) ve olay iletişimi profesyonel bir SLA’nın parçasıdır. Etkilenme kapsamı (bölgeler/ürünler), geçici çözümler (workaround), ETA ve RCA yayın taahhüdü güven tesis eder. Müşterileriniz için webhook/e-posta bildirimleri, izleme entegrasyonları ve SLA raporları (aylık, denetime hazır) operasyon şeffaflığını artırır. Bu disiplin olmadan, %99.9 ifadesi kâğıt üzerinde kalır; izleme kültürü ise gerçek operasyonel güvenilirliğin omurgasıdır.
Yüksek Erişilebilirlik (HA) Nasıl Sağlanır? N+1 Tasarım, Ağ/Elektrik Yedekliliği ve Otomatik Failover
%99.9’un sürdürülebilir olması, tek noktadan arızaları ortadan kaldırmakla başlar. N+1 tasarım, her kritik bileşenin (güç, soğutma, ağ, firewall, load balancer, uygulama node’ları, veritabanı) en az bir yedeği olmasını şart koşar. Uygulama katmanında yük dengeleme (L4/L7) ve sağlık kontrolleri ile problemli node’ların trafikten çıkarılması otomatikleştirilmelidir. Blue/Green veya Canary dağıtımları, sürüm kaynaklı kesintileri minimize eder.
Veri katmanında, çoğaltma (replication) ve otomatik lider seçimi (failover) mekanizmaları kritiktir. Ancak “split-brain” gibi risklere karşı quorum ve fencing stratejileri uygulanmalıdır. Dosya/durum tutarlılığı gerektiren senaryolarda paylaşımsız (shared-nothing) mimariler, idempotent işlemler ve event sourcing yaklaşımı kurtarıcı olabilir. Cache ve queue gibi durumlu servisler için yüksek erişilebilir mimariler (sentinel, cluster) tercih edilmelidir.
Fiziksel katmanda, çift güç beslemesi, çift uplink, çoklu ISP/peering, DDoS temizleme ve BGP yönlendirme stratejileri olası ağ sorunlarını lokalize eder. CDN/edge ile statik içeriklerin kullanıcıya yakın sunumu, merkezi origin üzerindeki yükü ve tekil arıza etkisini azaltır. Son olarak, tüm bu mekanizmaların değeri yazılı olarak kanıtlanmış tatbikatlarla artar: düzenli chaos engineering egzersizleri ve failover tatbikatları gerçek hazırlığı ölçer. HA, satın alınan bir özellik değil; sürekli test edilen ve iyileştirilen bir mühendislik disiplinidir.
İş Sürekliliği (BCP) ve Felaket Kurtarma (DR): RTO/RPO, İmmutable Yedekler ve Tatbikat
Uptime, yalnızca anlık erişilebilirlik değil; felaket anında kabul edilebilir geri dönüş süresi ve veri kaybı sınırıyla da ölçülür. RTO (Recovery Time Objective), sistemlerin ne kadar sürede tekrar hizmete alınacağını; RPO (Recovery Point Objective) ise en fazla ne kadar veri kaybının tolere edileceğini tanımlar. %99.9 hedefleyen kurumlar için RTO/RPO değerleri iş etkisi analizine göre hizmet/sistem bazında değişken olmalıdır (örn. ödeme < 15 dk, içerik < 2 saat gibi).
Yedekler 3-2-1 kuralı ile yönetilmeli: 3 kopya, 2 farklı ortam, 1 kopya off-site/immutable. Fidye yazılımlarına karşı değiştirilemez (WORM/immutability) depolama ve air-gap stratejileri uygulanmalıdır. Yedeklerin geri yükleme tatbikatı yapılmadan güven olmaz: belirli aralıklarla sürpriz tatbikatlar, kurtarma talimatlarının güncelliğini ve ekip reflekslerini sınar. Veritabanlarında noktasal zaman geri yükleme (PITR), uygulamalar için altyapı-as-kod (IaC) ile yeniden kurulum otomasyonu ve gizli anahtar kasaları (secrets vault) DR başarısı için kritiktir.
BCP planı; iletişim matrisi, yetki devri, karar eşiği, statü sayfası güncellemeleri, hukuk/PR koordinasyonu ve müşteri bilgilendirme süreçlerini içerir. SLA’da, DR modunda “kısıtlı işlev” sağlayan geçici hizmet seviyeleri tanımlanabilir. Böylece tam kesinti yerine, öncelikli işlevlerin ayakta kalması (graceful degradation) güvence altına alınır. Bu bütüncül yaklaşım, uptime yüzdesini “gerçek iş sürekliliği” ile birleştirir.
%99.9 mu %99.99 mu? Maliyet, Karmaşıklık ve Getiri Eğrisi (TCO Perspektifi)
Bir “9” daha eklemek, yalnızca teknik iyileştirme değil; maliyet ve süreç karmaşıklığı artışı demektir. %99.9’dan %99.99’a çıkmak için genellikle çok bölgeli dağıtım, çift yönlendirme, otomatik veri çoğaltma, ileri seviye gözlemlenebilirlik, daha sık yedekleme ve fazla kapasite (headroom) gerekir. Bu yatırımın geri dönüşü, iş modeline göre değişir: Ödeme/finans, kritik B2C ve yüksek hacimli e-ticaret gibi alanlarda dakikalar önemli gelir kaybı yaratır; dolayısıyla “bir 9 daha” makuldür. Buna karşılık, içerik odaklı kurumsal siteler için %99.9 çoğu zaman optimum dengeyi sunar.
SLA kredilerinin çoğu fatura indirimi şeklindedir ve sıklıkla aylık ücretle sınırlı bir üst tavana sahiptir; iş kaybınızı karşılamaz. Bu yüzden “kredi”yi değil, önleyici mühendisliği satın aldığınızı varsayın. Karar verirken, geçmiş 12 ay hata dakikaları, kampanya günleri, coğrafi trafik dağılımı ve işlem başarısızlık oranları üzerinden bir iş etkisi modeli kurun. Sonra, %99.9 ve %99.99 senaryolarını TCO + beklenen gelir koruması açısından kıyaslayın. Çoğu kurum, çekirdek işlevler için %99.99; çevre sistemler için %99.9 hedefiyle katmanlı bir SLA stratejisi uygulayarak optimuma ulaşır.
Sözleşme İncelemesi ve Pazarlık: Krediler, Üst Limit, Hariçler ve Raporlama Yükümlülüğü
SLA pazarlığında üç alan kritik önemdedir: (1) Kredi tablosu ve üst limit, (2) Hariç tutulanlar listesi, (3) Raporlama ve şeffaflık yükümlülüğü. Krediler; etki düzeyine ve süresine göre kademeli olmalı, “tek olayda” ve “toplamda” üst limitler müşteriyi koruyacak düzeyde belirlenmelidir. Hariçler, “geniş ve muğlak” kalmamalı; planlı bakımın toplam süresi, bildirim süresi ve saat aralıkları sözleşmede netleşmelidir. Üçüncü taraf bağımlılıklar tam kapsam dışı bırakılmamalı; en azından müşterinin efektif kesinti yaşadığı durumlar için orantılı kredi tanımlanmalıdır.
Raporlama tarafında, aylık SLA raporu, olay listesi, kök neden analizleri, iyileştirme planı ve izleme verisinin paylaşımı şart koşulmalıdır. “SLA’yı sağlayıcı ölçer” yaklaşımı yerine, müşteri ölçümünün hak olarak tanınması ve uyuşmazlık çözüm prosedürü yazılmalıdır. Ayrıca, cevap verme süresi, geçici çözüm sunma, kalıcı düzeltme hedef süresi gibi destek SLA’ları ayrıca pazarlık edilmelidir. Bu maddeler, uptime hedefinin yaptırımı olan ve operasyonel gelişim doğuran bir çerçeveye dönüşmesini sağlar.
Sonuç
%99.9 uptime, tek başına bir güvence değil; doğru tanım, kapsam, ölçüm ve mühendislik disipliniyle anlam kazanan bir hedeftir. Kurumsal yaklaşım; metrikleri açık yazmak, çok katmanlı izleme ve HA/DR mimarisi kurmak, RTO/RPO hedeflerini iş etkisine göre belirlemek ve SLA pazarlığını veriye dayalı yapmak olmalıdır. Böylece uptime oranı, pazarlama cümlesinden çıkıp ölçülebilir iş sürekliliğine dönüşür.
Worldwide (English) 
