Uptime Nedir, Nasıl Hesaplanır? %99,9 ile %99,99 Farkı
Uptime, bir sistemin çalışır kaldığı sürenin toplam süreye oranıdır. Hesaplamasını, izin verilen kesinti sürelerini ve SLA'da nelere bakılacağını anlattık.

Kısa cevap: Uptime, bir sistemin ya da hizmetin belirli bir dönemde çalışır durumda kaldığı sürenin toplam süreye oranıdır: çalışılan süre / toplam süre × 100. %99,9 uptime yılda yaklaşık 8 saat 46 dakika, %99,99 ise yaklaşık 52,6 dakika kesintiye izin verir. Sözleşmede bu yüzde tek başına bir şey anlatmaz; neyin kesinti sayıldığı, ölçümün hangi dönemde ve nereden yapıldığı, planlı bakımın hesaba katılıp katılmadığı da yazılı olmalı.
Uptime nedir?
Uptime, bir sistemin ya da hizmetin çalışır durumda geçirdiği sürenin ölçüsü. AWS erişilebilirliği aynı mantıkla tanımlıyor: bir iş yükünün kullanılabilir olduğu sürenin, ölçülen toplam süreye oranı.
Uptime ile erişilebilirlik (availability) her zaman aynı şeyi söylemez. NIST sözlüğündeki tanımlardan biri erişilebilirliği, yetkili bir tarafça talep edildiğinde erişilebilir ve kullanılabilir olma özelliği olarak tarif ediyor. Sunucusu ayakta ama veritabanına bağlanamayan bir uygulama, makine tarafında çalışıyor görünür; kullanıcı içinse erişilemez durumdadır.
Sözcüğün sunucu tarafında bir anlamı daha var: Linux'taki uptime komutu, sistemin ne kadar süredir çalıştığını, yani son açılıştan bu yana geçen süreyi gösterir. Bu bilgi makinenin kendisiyle ilgili; hizmetin erişilebilirliği hakkında tek başına bir şey söylemez.
Uptime nasıl hesaplanır?
Temel formül AWS'nin anlatımında şöyle: erişilebilirlik = çalışılan süre / (çalışılan süre + kesinti süresi). Sonucu 100'le çarpınca yüzde elde edilir.
Örnek: 30 günlük bir ayda 43.200 dakika var. O ay iki kesinti toplam 30 dakika sürdüyse uptime (43.200 − 30) / 43.200 = %99,93 olur. Bu sonuç %99,9 hedefini tutturur, %99,95 hedefinin ise altında kalır.
Google'ın SRE kitabı ikinci bir yöntemi de anlatıyor: istek tabanlı erişilebilirlik, yani başarılı isteklerin toplam isteğe oranı. Kitaptaki örnekte günde 2,5 milyon istek karşılayan ve günlük %99,99 hedefi olan bir sistem en fazla 250 hatalı cevap verebiliyor. Kitaba göre bu yöntem, yükü gün ya da hafta içinde değişen hizmetlerde kesinti süresine bakmaktan daha kullanışlı.
%99, %99,9, %99,95 ve %99,99: izin verilen kesinti
Hesap basit: izin verilen kesinti = (1 − hedef) × dönemin süresi. Aşağıdaki değerler 365 günlük yıl (525.600 dakika) ve 30 günlük ay (43.200 dakika) ile hesaplandı:
- %99: yılda 3,65 gün (87,6 saat), ayda 7,2 saat
- %99,9: yılda 8,76 saat (8 saat 45 dakika 36 saniye), ayda 43,2 dakika
- %99,95: yılda 4,38 saat (4 saat 22 dakika 48 saniye), ayda 21,6 dakika
- %99,99: yılda 52,56 dakika, ayda 4,32 dakika
Google'ın SRE kitabındaki erişilebilirlik tablosu aynı sonuçları veriyor. Kitap yıl uzunluğunu belirtmiyor, ama değerler 365 günlük yıl ve 30 günlük ay hesabıyla birebir örtüşüyor. Artık yılda %99,99'un payı 52,7 dakikaya çıkar.
Her ek "dokuz", izin verilen kesintiyi onda birine indirir: %99,9'dan %99,99'a geçmek, yıllık payı 8,76 saatten 52,6 dakikaya düşürür. Hangi ayın ölçüldüğü de sonucu değiştirir; aynı %99,9 hedefi 31 günlük bir ayda 44,6, 28 günlük şubatta 40,3 dakikaya izin verir.
SLA, SLO ve SLI farkı
Google'ın SRE kitabı üç terimi şöyle ayırıyor:
- SLI (service level indicator): Hizmet seviyesinin bir yönünü ölçen, dikkatle tanımlanmış nicel ölçü. Örneğin başarılı isteklerin oranı.
- SLO (service level objective): Bir SLI için konan hedef değer ya da aralık. Örneğin "isteklerin %99,9'u başarılı olacak".
- SLA (service level agreement): SLO'ları içeren ve tutturulup tutturulamamasının sonuçlarını tanımlayan sözleşme.
Kitabın önerdiği ayırt etme yolu basit: SLO tutmadığında ne olacağını sorun. Açık bir sonucu yoksa baktığınız şey neredeyse kesin olarak bir SLO'dur. Hedef de %100 olmamalı; kitap %100'ün büyük ihtimalle hiçbir zaman doğru güvenilirlik hedefi olmadığını söylüyor. SRE çalışma kitabına göre hata bütçesi (error budget) %100 eksi SLO. %99,9'luk bir SLO'da bütçe %0,1 olur; kitabın önerdiği dört haftalık pencerede bu, süreye dayalı hesapla yaklaşık 40 dakikaya karşılık gelir.
SLA'da uptime maddesini okurken nelere bakılmalı?
Sözlüğümüzdeki uptime ve SLA maddelerinin uyarısı aynı: tek başına bir yüzde yetmez. Bulut sağlayıcılarının SLA'ları, nelere bakılacağını iyi gösteriyor:
- Neyin kesinti sayıldığı: AWS'nin EC2 SLA'sında tek bir sunucu için kesinti, dış bağlantının olmaması demek. Sunucuya ulaşılabildiği sürece üzerindeki uygulamanın hata vermesi bu tanıma girmez.
- Kapsam: Aynı SLA, en az iki availability zone'a yayılmış kurulum için %99,99, tek sunucu için %99,5 taahhüt ediyor.
- Kısa kesintiler: Google Compute Engine SLA'sında bir dakikadan kısa kesintiler kesinti süresine sayılmıyor.
- Planlı bakım: Oracle'ın bulut hizmetleri politikasında planlı bakım süreleri plansız kesinti hesabına girmiyor.
- Ölçüm penceresi: Bu sözleşmelerde uptime aylık hesaplanıyor; kötü geçen bir hafta, ayın geri kalanıyla dengelenebiliyor.
- Telafi: AWS ve Google'da ihlalin karşılığı, aylık faturanın yüzdesi olarak verilen hizmet kredisi. Google, kredi talebinin 60 gün içinde ve kesintiyi gösteren loglarla yapılmasını şart koşuyor; kendi ölçümünüz yoksa ihlali kanıtlamanız zorlaşır.
Sağlayıcıya sorulacak diğer soruları MSP seçerken sorulacak 10 soru yazımızda topladık.
Uptime nasıl ölçülür?
Kullanıcının gördüğü uptime'ı ölçmenin yolu, hizmeti dışarıdan bir kullanıcı gibi denemek. SRE kitabı buna kara kutu izleme diyor: dışarıdan görünen davranışı kullanıcının göreceği gibi test etmek. Pratikteki karşılığı sentetik kontroller:
- AWS'nin CloudWatch Synthetics canary'leri bir müşterinin izlediği yolu tekrarlıyor ve dakikada bir çalışabiliyor; böylece trafik yokken bile hizmet doğrulanıyor.
- Google Cloud'un uptime kontrolleri dünyanın farklı noktalarından istek gönderiyor ve kontrol ancak birden fazla noktadan cevap alınamadığında başarısız sayılıyor. Tek bir noktanın ağ sorunu böylece yanlış alarma dönüşmüyor.
Ölçüm aralığı da sonucu etkiler: dakikada bir yapılan bir kontrol, iki kontrol arasında başlayıp biten bir kesintiyi göremez. Sentetik kontrollerin uygulamanın kendi hata ve istek metrikleriyle birlikte okunması bu yüzden önemli. Kurgunun ayrıntısını 7/24 izleme sayfamızda anlattık.
MTTR ve MTBF: uptime'ı ne belirler?
AWS aynı formülü iki ortalamayla da yazıyor: erişilebilirlik = MTBF / (MTBF + MTTR). MTBF (mean time between failures), iş yükünün normal çalışmaya başlamasıyla bir sonraki arıza arasındaki ortalama süre; MTTR (mean time to repair) ise arızalı parça onarılıp hizmete dönene kadar geçen süre.
Hesap iki yolun eşdeğer olduğunu gösteriyor. MTBF 1.000 saat, MTTR 1 saatse erişilebilirlik %99,90. MTTR'yi yarım saate indirmek de MTBF'yi 2.000 saate çıkarmak da sonucu %99,95'e taşır. AWS'nin ifadesiyle arıza sıklığını azaltmak da kurtarma süresini kısaltmak da erişilebilirliği artırır.
Mimari de bu denklemin parçası. Bir load balancer arkasındaki sunuculardan biri sağlık kontrollerini geçemezse trafikten çıkarılır ve istekler sağlıklı sunuculara gider. Bağımlılıklar ise hesabı aşağı çeker. AWS'ye göre teorik üst sınır, çalışması gereken bütün bileşenlerin erişilebilirliklerinin çarpımı; %99,9'luk iki bileşene birlikte bağımlı bir hizmette bu sınır %99,8. AWS hesabın kaba bir tahmin olduğunu, ama bağımlılık azaldıkça arıza ihtimalinin de azaldığını vurguluyor. Önleyici bakım tarafını sistem güvenilirliği hizmetimizde ele alıyoruz.
Uptime ile Tier seviyeleri aynı şey değil
Veri merkezlerinin Tier sınıflandırmasını yapan kuruluşun adı Uptime Institute; ama Tier seviyeleri bir uptime yüzdesi değil. Tier sınıflandırması veri merkezi altyapısına odaklanıyor ve kurumun kendi açıklamasına göre güncel standart, seviyelere erişilebilirlik tahmini atamıyor; yıllık beklenen kesinti süresine yapılan atıflar 2009'da kaldırıldı. Tier III bir tesiste çalışmak, uygulamanızın belli bir uptime yüzdesini tutturacağı anlamına gelmez. Tier seviyelerini veri merkezi yazımızda anlattık.
Sık sorulan sorular
Uptime ne demek? Bir sistemin ya da hizmetin çalışır durumda geçirdiği süre demek. Çoğunlukla belirli bir dönemdeki toplam sürenin yüzdesi olarak verilir.
%99,9 uptime ne kadar kesinti demek? 365 günlük bir yılda yaklaşık 8 saat 46 dakika, 30 günlük bir ayda 43,2 dakika.
%99,9 ile %99,99 arasındaki fark nedir? %99,99 hedefi, %99,9'un izin verdiği kesintinin onda birine izin verir: yılda 8,76 saat yerine 52,6 dakika.
Uptime ile erişilebilirlik aynı şey mi? Yakın ama aynı değil. Uptime sistemin çalıştığını, erişilebilirlik ise kullanıcının hizmeti gerçekten kullanabildiğini anlatır.
%100 uptime mümkün mü? Pratikte hayır. Google'ın SRE kitabı, %100'ün büyük ihtimalle hiçbir zaman doğru güvenilirlik hedefi olmadığını söylüyor.
Kaynaklar
- Google, SRE Book: Availability Table: izin verilen kesinti süreleri
- Google, SRE Book: Embracing Risk: süreye ve isteğe dayalı erişilebilirlik, %100 hedefi
- Google, SRE Book: Service Level Objectives: SLI, SLO ve SLA tanımları
- Google, SRE Workbook: Implementing SLOs: hata bütçesi ve dört haftalık pencere
- Google, SRE Book: Monitoring Distributed Systems: kara kutu izleme
- AWS, Availability and Beyond: erişilebilirlik, MTBF ve MTTR formülleri (dağıtık sistemler ve bağımlılıklar bölümleriyle)
- NIST, CSRC Glossary: availability: erişilebilirlik tanımları
- man7.org, uptime(1): Linux uptime komutu
- AWS, Amazon EC2 SLA: kesinti tanımı ve taahhütler (Mayıs 2022)
- Google Cloud, Compute Engine SLA: kısa kesintiler ve kredi talebi
- Oracle, Cloud Hosting and Delivery Policies: planlı bakımın kesinti hesabı dışında tutulması (Eylül 2026)
- AWS, CloudWatch Synthetics canaries: sentetik kontroller
- Google Cloud, Uptime checks: çok noktadan kontrol
- AWS, Application Load Balancer health checks: sağlık kontrolleri
- Uptime Institute, Tier Classification System ve Explaining the Tier Classification System: Tier seviyelerine erişilebilirlik tahmini atanmaması
- Bu katmanı nasıl işlettiğimiz: 7/24 izleme