- Katılım
- 21 May 2023
- Mesajlar
- 528
- Tepki
- 17
- Puan
- 18
Yeni bir e-ticaret platformuna geçmeden önce üç adayın status sayfasını yan yana açtığınızda hepsi de neredeyse tamamen yeşil görünür; son on beş günde "operational" dışında bir şey yok gibidir. Oysa kendi mağazanızda ya da bir tanıdığınızın mağazasında ödeme adımının çöktüğü bir gün hâlâ hafızanızdadır ve o gün status sayfasında hiç görünmüyordur.
Bu çelişkinin nedeni gizli bir veri saklama değil, status sayfasının ne ölçtüğünü bilmemek. Bu yazı, birçok platformun status sayfasını çalıştıran Atlassian Statuspage'in kendi belgelerine dayanarak uptime yüzdesinin neyi saydığını, neyi saymadığını ve bir kesintinin sayfaya nasıl (ve ne zaman) düştüğünü gösteriyor.
Örneğin Shopify'ın resmî durum sayfası altbilgisinde "Powered by Atlassian Statuspage" ibaresini taşıyor ve Admin, Checkout, Storefront, API & Mobile gibi dokuz ayrı bileşeni Operational, Degraded Performance, Partial Outage, Major Outage kategorileriyle listeliyor. Bu kategori adları platforma özgü değil; Statuspage'in kendi ürün mantığından geliyor, dolayısıyla farklı e-ticaret platformlarının status sayfalarında da benzer bir yapıyla karşılaşmanız olası.
Statuspage'in kendi belgesine göre bir "component", hizmetin ayrı bir altyapı ya da işlevsel parçasını temsil ediyor ve belge şirketlere "hizmetinizin her büyük işlevsel/mimari bölümü için bir bileşen ekleyin" öneriyor (Statuspage'in "component nedir" belgesine göre). Bu, hangi servisin ayrı bir satır olarak izleneceğine platformun kendisinin karar verdiği anlamına geliyor: ödeme entegrasyonu, üçüncü taraf bir API ya da belirli bir bölgesel altyapı ayrı bir bileşen olarak listede yer almıyorsa, orada yaşanan bir aksaklık sayfaya hiç düşmeyebilir.
Statuspage'in uptime hesaplama belgesine göre yüzde şu formülle çıkarılıyor: major outage dakikaları artı partial outage dakikalarının %30'u, toplam dakikaya bölünüyor. Aynı belge iki istisnayı açıkça belirtiyor: planlı bakımın genelde bu hesaba girmemesi gerektiğini ve "degraded performance" (yani işlerin yalnızca yavaş çalıştığı durumların) bu özelliği hiç etkilemediğini yazıyor.
Belgedeki en dikkat çekici cümle şu: bir olay (incident) kaydedilse bile bileşenler bu kesinti durumlarından birine elle işaretlenmezse, grafikte hiçbir şey görünmüyor. Yani uptime yüzdesi otomatik bir ölçüm değil, operatörün bileşen durumunu doğru işaretlemesine bağlı bir kayıt.
Statuspage'in genel durum ve olay etkisi hesaplama belgesine göre sayfanın en üstündeki genel durum, her bileşen değişikliğinden sonra otomatik olarak yeniden hesaplanıyor; olayın etki seviyesi de aynı şekilde bileşen durumlarından otomatik türetiliyor. Ama belge bir istisna daha tanımlıyor: ekip, olay sekmesinden etki seviyesini elle değiştirip geçersiz kılabiliyor. Yani gördüğünüz "Major Outage" ya da "Partial Outage" etiketi, sistemin kendiliğinden ürettiği bir sayı değil, ekibin onayladığı bir sınıflandırma.
Statuspage'in "backfill" özelliği bu tabloyu tamamlıyor: bir olayı geriye dönük eklemeyi anlatan belgeye göre geçmişte yaşanmış ama zamanında sayfaya işlenmemiş bir kesinti, sonradan da eklenebiliyor; belge bunun amacını "sayfanızın boş görünmemesine yardımcı olur" diye açıklıyor. Geriye dönük eklenen olaylar abonelere bildirim göndermiyor. Yani gördüğünüz geçmiş kayıt, olayın yaşandığı anda mı yoksa haftalar sonra mı sayfaya girildiğini görünürde ayırt ettirmiyor; kayıt tamlığı da operatörün tercihine bağlı.
Bu yalnız küçük platformlara özgü bir tercih değil; eşiği açıkça yazan sağlayıcılar da var. Google Cloud'un kendi belgesine göre genel durum sayfası "broad, severe" olayları iletiyor ve bir olay ancak "küresel etkisi varsa ya da birden çok bölgede müşteri projelerinin kayda değer bir yüzdesini etkiliyorsa" bu sınıfa giriyor.
Yani tanım gereği, yalnız sizi ya da dar bir müşteri grubunu etkileyen bir aksaklık genel sayfada hiç görünmeyebilir. Sayfanın yeşil olması "kimsede sorun yok" demek değil, "eşiği aşan bir sorun yok" demek.
Bu, "Ücretsiz SSL Dahil" gibi bir pazarlama sözünün ne anlama geldiğini tarayıcıdan doğrulamayı anlattığımız yazımızdaki mantıkla aynı yerde duruyor: platformun kendi sayfası bir iddia sunuyor, bağımsız doğrulaması size düşüyor. Genel platform karşılaştırması yaparken güvenilirlik yalnızca bir kriter; diğerlerini e-ticaret platformları karşılaştırması yazımızda ele almıştık.
Deneme sürenizi de bu amaçla kullanabilirsiniz: tıpkı deneme bitmeden dışa aktarmayı sınamanızı önerdiğimiz yazıdaki mantık gibi, platformun status sayfasını da karar vermeden önce birkaç hafta izleyip kendi deneyiminizle karşılaştırabilirsiniz.
Bir e-ticaret platformunun status sayfası bağımsız bir ölçüm aracı değil; hangi servisin bileşen olarak izleneceğini, hangi kesintinin "major" ya da "partial" sayılacağını ve hangi geçmiş olayın sayfaya işleneceğini büyük ölçüde platformun kendisi belirliyor. Uptime yüzdesi de yalnızca major ve partial outage dakikalarını sayıyor, yavaşlama gibi "degraded" durumlar bu hesaba hiç girmiyor. Sayfayı okurken önce hangi bileşenlerin listelendiğine, sonra da kendi yaşadığınız aksaklığın orada karşılığı olup olmadığına bakmak daha güvenilir bir tablo veriyor.
Bir platformun status sayfasını gerçek deneyiminizle karşılaştırdınız mı?
Güncelleme: 24 Ağustos 2026.
Bu çelişkinin nedeni gizli bir veri saklama değil, status sayfasının ne ölçtüğünü bilmemek. Bu yazı, birçok platformun status sayfasını çalıştıran Atlassian Statuspage'in kendi belgelerine dayanarak uptime yüzdesinin neyi saydığını, neyi saymadığını ve bir kesintinin sayfaya nasıl (ve ne zaman) düştüğünü gösteriyor.
Status sayfalarının çoğu aynı altyapıyı paylaşıyor
Örneğin Shopify'ın resmî durum sayfası altbilgisinde "Powered by Atlassian Statuspage" ibaresini taşıyor ve Admin, Checkout, Storefront, API & Mobile gibi dokuz ayrı bileşeni Operational, Degraded Performance, Partial Outage, Major Outage kategorileriyle listeliyor. Bu kategori adları platforma özgü değil; Statuspage'in kendi ürün mantığından geliyor, dolayısıyla farklı e-ticaret platformlarının status sayfalarında da benzer bir yapıyla karşılaşmanız olası.
Bileşen listesini kim belirliyor?
Statuspage'in kendi belgesine göre bir "component", hizmetin ayrı bir altyapı ya da işlevsel parçasını temsil ediyor ve belge şirketlere "hizmetinizin her büyük işlevsel/mimari bölümü için bir bileşen ekleyin" öneriyor (Statuspage'in "component nedir" belgesine göre). Bu, hangi servisin ayrı bir satır olarak izleneceğine platformun kendisinin karar verdiği anlamına geliyor: ödeme entegrasyonu, üçüncü taraf bir API ya da belirli bir bölgesel altyapı ayrı bir bileşen olarak listede yer almıyorsa, orada yaşanan bir aksaklık sayfaya hiç düşmeyebilir.
Uptime yüzdesi tam olarak neyi sayıyor?
Statuspage'in uptime hesaplama belgesine göre yüzde şu formülle çıkarılıyor: major outage dakikaları artı partial outage dakikalarının %30'u, toplam dakikaya bölünüyor. Aynı belge iki istisnayı açıkça belirtiyor: planlı bakımın genelde bu hesaba girmemesi gerektiğini ve "degraded performance" (yani işlerin yalnızca yavaş çalıştığı durumların) bu özelliği hiç etkilemediğini yazıyor.
Belgedeki en dikkat çekici cümle şu: bir olay (incident) kaydedilse bile bileşenler bu kesinti durumlarından birine elle işaretlenmezse, grafikte hiçbir şey görünmüyor. Yani uptime yüzdesi otomatik bir ölçüm değil, operatörün bileşen durumunu doğru işaretlemesine bağlı bir kayıt.
Sayfanın üstündeki genel durum kim tarafından belirleniyor?
Statuspage'in genel durum ve olay etkisi hesaplama belgesine göre sayfanın en üstündeki genel durum, her bileşen değişikliğinden sonra otomatik olarak yeniden hesaplanıyor; olayın etki seviyesi de aynı şekilde bileşen durumlarından otomatik türetiliyor. Ama belge bir istisna daha tanımlıyor: ekip, olay sekmesinden etki seviyesini elle değiştirip geçersiz kılabiliyor. Yani gördüğünüz "Major Outage" ya da "Partial Outage" etiketi, sistemin kendiliğinden ürettiği bir sayı değil, ekibin onayladığı bir sınıflandırma.
Statuspage belgesi' Alıntı:
Geçmiş kayıt neden sonradan eklenmiş olabilir?
Statuspage'in "backfill" özelliği bu tabloyu tamamlıyor: bir olayı geriye dönük eklemeyi anlatan belgeye göre geçmişte yaşanmış ama zamanında sayfaya işlenmemiş bir kesinti, sonradan da eklenebiliyor; belge bunun amacını "sayfanızın boş görünmemesine yardımcı olur" diye açıklıyor. Geriye dönük eklenen olaylar abonelere bildirim göndermiyor. Yani gördüğünüz geçmiş kayıt, olayın yaşandığı anda mı yoksa haftalar sonra mı sayfaya girildiğini görünürde ayırt ettirmiyor; kayıt tamlığı da operatörün tercihine bağlı.
Büyük sağlayıcılar bile her olayı genel sayfaya koymuyor
Bu yalnız küçük platformlara özgü bir tercih değil; eşiği açıkça yazan sağlayıcılar da var. Google Cloud'un kendi belgesine göre genel durum sayfası "broad, severe" olayları iletiyor ve bir olay ancak "küresel etkisi varsa ya da birden çok bölgede müşteri projelerinin kayda değer bir yüzdesini etkiliyorsa" bu sınıfa giriyor.
Yani tanım gereği, yalnız sizi ya da dar bir müşteri grubunu etkileyen bir aksaklık genel sayfada hiç görünmeyebilir. Sayfanın yeşil olması "kimsede sorun yok" demek değil, "eşiği aşan bir sorun yok" demek.
Karşılaştırma yaparken kontrol listesi
- Bileşen listesi: Ödeme, checkout, API gibi kritik servisler ayrı bileşen olarak mı listeleniyor, yoksa tek bir genel satırda mı eritiliyor?
- Uptime formülü: Sayfa yalnızca major/partial outage mu gösteriyor; "degraded performance" etiketi çok görünüyorsa bu hiçbir uptime hesabına girmiyor.
- Görüntülenen pencere: Sayfa son kaç günü gösteriyor, daha eski bir kesintiye erişim var mı?
- Olay sıklığı: Belirli aylarda kayıt yoğunluğu aniden artıyorsa bu geriye dönük toplu ekleme izine işaret edebilir.
Platform kararını status sayfasına bırakmayın
Bu, "Ücretsiz SSL Dahil" gibi bir pazarlama sözünün ne anlama geldiğini tarayıcıdan doğrulamayı anlattığımız yazımızdaki mantıkla aynı yerde duruyor: platformun kendi sayfası bir iddia sunuyor, bağımsız doğrulaması size düşüyor. Genel platform karşılaştırması yaparken güvenilirlik yalnızca bir kriter; diğerlerini e-ticaret platformları karşılaştırması yazımızda ele almıştık.
Deneme sürenizi de bu amaçla kullanabilirsiniz: tıpkı deneme bitmeden dışa aktarmayı sınamanızı önerdiğimiz yazıdaki mantık gibi, platformun status sayfasını da karar vermeden önce birkaç hafta izleyip kendi deneyiminizle karşılaştırabilirsiniz.
Özetle
Bir e-ticaret platformunun status sayfası bağımsız bir ölçüm aracı değil; hangi servisin bileşen olarak izleneceğini, hangi kesintinin "major" ya da "partial" sayılacağını ve hangi geçmiş olayın sayfaya işleneceğini büyük ölçüde platformun kendisi belirliyor. Uptime yüzdesi de yalnızca major ve partial outage dakikalarını sayıyor, yavaşlama gibi "degraded" durumlar bu hesaba hiç girmiyor. Sayfayı okurken önce hangi bileşenlerin listelendiğine, sonra da kendi yaşadığınız aksaklığın orada karşılığı olup olmadığına bakmak daha güvenilir bir tablo veriyor.
Bir platformun status sayfasını gerçek deneyiminizle karşılaştırdınız mı?
Güncelleme: 24 Ağustos 2026.
Dijital Dünyanıza Yön Veren Pusula
Ekli dosyalar
Son düzenleme:
