7/24 Uptime Takibi - Kesintiyi Müşteriden Önce Görmek

Kesintiyi çoğu site sahibi bir grafikten değil bir mesajdan öğrenir. Müşteri arar, bayi ekran görüntüsü gönderir, satış ekibinden "form çalışmıyor" haberi gelir. O mesaj elinize ulaştığında kesinti çoktan başlamıştır, bazen çoktan bitmiştir ve geriye ne kadar sürdüğünü, kaç kişiyi etkilediğini, arama motoru tarayıcısının o aralıkta uğrayıp uğramadığını gösteren hiçbir kayıt kalmamıştır.

İzleme aracının sattığı şey erişilebilirlik değil zamandır. Hiçbir izleme yazılımı sunucunuzu ayakta tutmaz; yalnızca kesinti ile sizin haberdar olmanız arasındaki boşluğu kısaltır. Kayıp ciro, kaybedilen form, bozulan güven ve arama tarafındaki etkinin büyük kısmı tam olarak o boşlukta oluşur.

Uptime, bir sunucunun gelen isteklere başarılı yanıt verdiği sürenin, ölçüm yapılan toplam süreye oranıdır ve yüzde olarak ifade edilir. Downtime ise aynı pencerede sitenin yanıt veremediği ya da hatalı yanıt verdiği süredir. Bu iki tanım basit görünür, fakat aşağıda göreceğiniz gibi hem yüzdelerin takvimdeki karşılığı hem de ölçümün kendisi çoğu kişinin beklediğinden farklı davranır.

Kesinti, trafik düşüşü teşhisinde en geç bakılan yerlerden biridir. Organik trafikte açıklanamayan bir kırılma ararken sıralama, içerik ve güncelleme ihtimalleri sırayla elenir; sunucunun o hafta kaç dakika 5xx döndüğü genelde hiç sorulmaz. Trafik düşüşünde izlenecek adımlar yazısındaki eleme sırasına erişilebilirlik kontrolünü eklemek, bazen haftalarca süren bir araştırmayı tek bakışta bitirir.

Uptime ve downtime tam olarak neyi ölçer?

Uptime bir sitenin değil, ölçtüğünüz adresin özelliğidir. Ana sayfa 200 dönerken sepet sayfası 500 dönebilir, ürün sayfaları açılırken arama işlevi zaman aşımına uğrayabilir. Tek bir URL izleyen bir kurulum bu durumda size %100 uptime raporlar ve rapor teknik olarak doğrudur, sadece yanlış soruyu cevaplamıştır.

İkinci belirleyici, ölçüm penceresidir. Aynı kesinti yıllık pencerede önemsiz bir sapma, aylık pencerede ciddi bir bütçe aşımı olarak görünür. Bir sağlayıcı %99,9 taahhüt ediyorsa bunun yıllık mı aylık mı hesaplandığı, taahhüdün gerçek anlamını değiştirir.

Üçüncüsü, taahhüt ile gerçeğin kapsam farkıdır. Barındırma sözleşmelerindeki erişilebilirlik taahhüdü genellikle sunucu ve ağ katmanını kapsar. Uygulamanızın kendi hatası, süresi dolmuş bir sertifika, yanlış yapılandırılmış bir yönlendirme veya alan adı tarafındaki bir sorun sizin için tam anlamıyla kesintidir, fakat sağlayıcının hesabında kesinti sayılmaz. Kullanıcının yaşadığı erişilebilirlik ile faturada yazan yüzde nadiren aynı sayıdır.

Yüzdeler takvimde kaç dakika kesinti demek?

Erişilebilirlik hedefleri "dokuzlar" diliyle konuşulur ve bu dil aradaki farkı gizler. %99 ile %99,9 arasındaki mesafe yazıldığında küçük, takvime çevrildiğinde on kattır.

Tablonun pratik sonucu şudur: %99,9 kulağa kusursuz gelir, fakat aylık bütçesi 43 dakikadır. Başarısız tek bir sürüm yayını, uzun süren tek bir veritabanı taşıması veya sertifika yenilemesinde yaşanan tek bir aksama bu bütçeyi tek seferde bitirir. %99,99 hedefi ise ayda 4 dakika 19 saniye demektir ve bu rakam artık insan müdahalesiyle korunamaz; yedekli altyapı ve otomatik devralma gerektirir.

Dağılım da en az toplam kadar önemlidir. Ayda 43 dakikanın tamamının tek bir olayda yaşanması ile 43 ayrı dakikaya yayılması aynı yüzdeyi üretir, ama farklı sonuçlar doğurur. Tek uzun kesinti müşteri iletişimi gerektirir ve tarayıcı tarafında ardışık hata dizisi oluşturur. Dağılmış kısa kesintiler ise genellikle fark edilmez, buna karşılık altyapıda kronikleşen bir sorunun daha güvenilir habercisidir.

Kesinti arama görünürlüğünü gerçekten nasıl etkiler?

Birkaç dakikalık bir kesinti dizin kaybı anlamına gelmez; dizin kaybını yaratan şey sürenin uzunluğu değil hatanın kalıcılığıdır. Bu ayrım, konu etrafındaki panik anlatısının büyük kısmını çözer.

Google'ın tarayıcı davranışını anlattığı belgelere göre 5xx sunucu hataları ve 429 yanıtları tarayıcıların taramayı geçici olarak yavaşlatmasına yol açar. Bu yavaşlama sitenin tamamına aynı şiddette uygulanmaz: tarama hızındaki düşüş, sunucu hatası dönen URL sayısıyla orantılıdır. Tek bir ürün sayfasının hata vermesi ile tüm sitenin hata vermesi aynı sonucu üretmez.

Dizin tarafında ise kademeli bir davranış vardır. Hâlihazırda dizindeki adresler bir süre korunur, fakat sunucu hatası kalıcı hale gelirse sonunda düşürülür. Google'ın dizine alma hattı, ısrarla sunucu hatası dönen adresleri dizinden çıkarır. Hata dönen bir adresten alınan içerik ise dikkate alınmaz; yani kesinti sırasında taranan bir sayfa "boş sayfa" olarak dizine işlenmez, o tarama denemesi sadece kayba yazılır.

Toparlanma da anlık değildir. Sunucu tekrar 2xx yanıtı vermeye başladığında Google tarama hızını kademeli olarak artırır. Bunun sahadaki karşılığı şudur: kesinti bittikten sonra bir süre daha yeni içerikleriniz geç fark edilir, güncellemeleriniz arama sonuçlarına geç yansır. Uzun bir kesintinin en görünür maliyeti genellikle sıralama düşüşü değil, bu tarama gecikmesidir.

İki nokta bu tabloyu ciddi biçimde ağırlaştırır. Birincisi, robots.txt dosyasının sunucu hatası dönmesidir; Google bu dosyanın 503 dönmesinin tüm taramayı engellediğini açıkça belirtir, dolayısıyla bakım modu kurarken bu dosyayı kapsam dışında bırakmak zorunludur. İkincisi, hız sınırlayıcı kurgulardır: güvenlik duvarınız tarayıcıya 429 döndürüyorsa sunucunuz sağlıklı olsa bile tarama yavaşlar, üstelik bu durum hiçbir erişilebilirlik raporunda kesinti olarak görünmez.

Kesintinin gerçekten etki edip etmediği tahminle değil veriyle anlaşılır. Olay sonrası bakılacak yer tarama istatistikleri ve gösterim eğrisidir; Search Console verisinin nasıl takip edildiği bu ölçümün nasıl kurulacağını anlatır. Kesinti tarihini işaretleyip sonraki iki haftanın tarama ve gösterim verisini karşılaştırmak, "acaba etkiledi mi" sorusunu bir cevaba dönüştürür.

Planlı bakımda doğru davranış nedir?

Bakım sırasında yapılan en yaygın hata, "şu anda bakımdayız" sayfasını 200 durum koduyla yayınlamaktır. Bu durumda tarayıcı gördüğü şeyi sayfanın gerçek içeriği sanar ve o içeriği işleyebilir. Doğru davranış, geçici durumu durum koduyla bildirmektir.

• 503 kullanın. Geçici olarak hizmet verilemediğini bildiren kod budur ve bakım için doğru sinyaldir.
• Retry-After başlığı ekleyin. Google bu başlığın makul bir tarih veya süre ile kullanılmasını önerir; tarayıcıya ne zaman geri dönmesi gerektiğini söyler.
• robots.txt dosyasını 503 kapsamına almayın. Bu dosya sunucu hatası döndüğünde taramanın tamamı bloke olur.
• Bakım sayfasını hafif tutun. Statik HTML, satır içi CSS ve gömülü kodlanmış görsel kullanmak hem sunucu hem istemci tarafındaki yükü azaltır. Kesinti anında bakım sayfasının kendisi sunucuyu meşgul etmemelidir.
• Kullanıcıya somut bilgi verin. Ne zaman dönüleceği, nereden bilgi alınabileceği ve iletişim yolu sayfada yazmalıdır.

Bir noktayı baştan bilmekte fayda var: bir sayfa 503 dönerken başlık, açıklama, meta bilgileri ve yapılandırılmış veri yenilenemez. Uzun süren bakımlarda arama sonuçlarında görünen bilgi eski halinde donar.

Daha büyük karar ise siteyi tamamen kapatıp kapatmamaktır. Google'ın açık tavsiyesi siteyi kapatmak değil işlevini sınırlamaktır: sipariş alınamıyorsa sepeti devre dışı bırakmak, tüm sayfalarda durumu anlatan bir bildirim göstermek, stok ve etkinlik durumunu yapılandırılmış veride güncellemek. Tam kapatma en fazla birkaç günlük bir önlem olarak tanımlanır ve siteyi arama sonuçlarından tamamen kaldırmaktan toparlanmanın sabit bir süresi olmadığı, bu süreci hızlandıracak bir mekanizma bulunmadığı belirtilir.

Bölge engelleme de aynı başlık altında değerlendirilmelidir. Google taramayı genel olarak ABD üzerinden yapar. Yoğunluk veya saldırı nedeniyle ABD trafiğini komple engellerseniz siteniz kullanıcılar için ayakta kalır fakat Google için tamamen erişilemez hale gelir. Bu, hiçbir uptime raporunda kesinti olarak görünmeyen bir görünürlük kaybıdır.

İzleme kurulumunun mantığı: sıklık, konum ve kontrol tipi

Kontrol aralığı iki şeyi aynı anda belirler ve ikincisi neredeyse hiç konuşulmaz. Birincisi tespit gecikmesidir: kontroller T aralığıyla yapılıyorsa, rastgele bir anda başlayan kesintinin ortalama tespit süresi yaklaşık T/2, en kötü durumda T kadardır. İkincisi ölçüm körlüğüdür: T'den kısa süren kesintileri sistematik olarak kaçırırsınız.

Bu ikinci etki, raporlanan uptime yüzdesinin neden fazla iyimser olduğunu açıklar. Beş dakikada bir kontrol yapan bir kurulum, bir dakika süren bir kesintiyi ancak kontrol anına denk gelirse görür; kesintinin başlangıcı kontrol takvimine göre rastgeleyse yakalama olasılığı yaklaşık beşte birdir. Yani aracınızın gösterdiği yüzde, gerçek erişilebilirliğinizin ölçümü değil üst sınırıdır. Kısa ve sık kesinti yaşayan sitelerde bu fark, kâğıt üzerinde mükemmel görünen bir raporla müşteri şikâyetlerinin neden aynı anda var olabildiğini açıklar.

Konum sayısı ise doğruluk meselesidir. Tek noktadan yapılan kontrol, ağ sorununu sunucu sorunundan ayıramaz. İzleme sunucusu ile siteniz arasındaki geçici bir yönlendirme problemi, siteniz sorunsuz çalışırken kesinti olarak raporlanır. Bir kesintinin gerçek sayılması için en az iki bağımsız konumdan doğrulanması, yanlış alarmların büyük kısmını eler.

Kontrol tipi ise neyi görüp neyi kaçıracağınızı belirler.

Pratikte en çok işe yarayan kombinasyon, HTTP durum kodu kontrolüne bir içerik kontrolü eklemektir. Bunun nedeni önbellek ve ara katmanların davranışıdır: bir dağıtım ağı veya vekil sunucu, kaynak sunucu çöktüğünde kendi hata sayfasını 200 koduyla dönebilir. Bu senaryoda durum kodunu izleyen araç hiçbir şey görmez. Sayfada olması gereken bir metni arayan kontrol ise anında alarm verir. Önbellek katmanının kesinti sırasında ne döndüreceği yapılandırmaya bağlıdır ve önbellek ile dağıtım ağı ayarlarında verilen kararlar doğrudan bu davranışı belirler.

Sertifika izleme ayrı tutulmalıdır çünkü farklı bir başarısızlık türüdür. Sertifikası dolan bir site teknik olarak ayaktadır, sunucu 200 döner, izleme aracı yeşil gösterir; buna karşılık tarayıcı kullanıcıyı güvenlik uyarısıyla karşılar ve trafik durur. Otomatik yenileme kurulu olsa bile izleme kapatılmamalıdır, çünkü otomatik yenileme de alan adı doğrulaması veya yapılandırma değişikliği yüzünden başarısız olabilir.

Alarm yorgunluğu neden gerçek bir risk?

Sahada en sık görülen başarısızlık, izleme aracının hiç kurulmamış olması değildir. Kurulmuş, çalışıyor, veri topluyor, fakat uyarıları kimse okumuyordur. Bildirimler sessize alınmış, kanal mute edilmiş, e-postalar bir klasöre yönlendirilmiştir.

Bunun mekanizması tahmin edilebilir. Kısa kontrol aralığı, tek konum ve doğrulama şartı olmayan bir kurulum haftada birkaç yanlış alarm üretir. İnsanlar üçüncü yanlış alarmdan sonra bildirimlere güvenmeyi bırakır. Dördüncüsünde susturur. Gerçek kesinti geldiğinde sistem çalışmaktadır, uyarı gönderilmiştir, kimse bakmamıştır.

Çözüm daha çok bildirim değil daha az ve daha güvenilir bildirimdir:

• Doğrulama eşiği koyun. Uyarı, en az iki ardışık başarısız kontrol ve en az iki farklı konumdan doğrulama sonrası çıksın.
• Kademe ayırın. Bilgilendirme niteliğindeki olay ile insanı uykudan kaldıracak olay aynı kanaldan gitmemelidir. Yavaşlama bilgilendirmedir, tam erişilemezlik uyandırma sebebidir.
• Tek sorumlu tanımlayın. Herkese giden uyarı kimseye gitmemiş sayılır.
• İzlenen adres sayısını dar tutun. Beş kritik yol çoğu site için yeterlidir: ana sayfa, temsili bir kategori, temsili bir ürün ya da içerik sayfası, dönüşümün gerçekleştiği sayfa ve robots.txt.

Buradaki takas açıkça söylenmelidir: doğrulama eşiği eklemek tespit süresini uzatır. İki ardışık başarısız kontrol şartı, bir dakikalık aralıkta ortalama haber alma süresini yaklaşık bir buçuk dakika daha geriye çeker. Bu bilinçli bir tercihtir. Güvenilmeyen hızlı uyarı, biraz gecikmeli güvenilir uyarıdan daha kötüdür.

Kesinti anında hangi sırayla hareket edilir?

1. Dışarıdan doğrulayın. Kendi ağınızdan yapılan test yanıltıcıdır. Farklı bir bağlantıdan veya bağımsız bir kontrol noktasından teyit alın.
2. Kapsamı belirleyin. Tek bir adres mi, tüm site mi, tek bir bölge mi etkileniyor? Tarama tarafındaki etkinin şiddeti doğrudan bu kapsama bağlıdır.
3. robots.txt durumunu kontrol edin. Bu dosya sağlıklı yanıt veriyor mu? Vermiyorsa öncelik sırası değişir.
4. Uzayacaksa kontrollü hataya geçin. Onarım dakikalar yerine saatler alacaksa 503 ve Retry-After ile açık bir bakım durumu yayınlayın. Belirsiz hata sayfası yerine tanımlı bir geçici durum bildirin.
5. Kullanıcıya durumu söyleyin. Sessizlik, kesintinin kendisinden daha fazla güven kaybettirir.
6. Onarın ve 2xx yanıtına dönün. Sağlıklı yanıt döndükçe tarama hızı kademeli olarak toparlanır.
7. Sonrasını ölçün. Olayın tarihini not edin ve izleyen iki haftanın tarama ile gösterim verisini kesinti öncesiyle karşılaştırın.

Bir uyarı: kesinti tespit edildiğinde servisi otomatik yeniden başlatan kurtarma betikleri cazip görünür ve kısa vadede işe yarar. Fakat bu betikler belirtiyi susturur, kök nedeni gizler. Haftada üç kez otomatik yeniden başlatılan bir sunucu, izleme panelinde neredeyse kusursuz bir uptime üretirken altında büyüyen bir bellek sızıntısını saklıyor olabilir. Otomatik müdahale kuruluyorsa her tetiklenmesi ayrıca kayıt altına alınmalı ve düzenli olarak gözden geçirilmelidir.

Hangi araç kategorisi yeterli, hangisi fazla?

Piyasadaki ürünleri tek tek karşılaştırmak yerine ne işe yaradıklarına göre ayırmak daha kalıcı bir karar verdirir. Kategoriler ihtiyaca göre birbirinin üstüne binen katmanlar oluşturur.

• Erişilebilirlik kontrolcüleri. Belirli aralıklarla HTTP, TCP veya ping kontrolü yapar, çok konumlu doğrulama ve sertifika takibi sunar. Çoğu kurumsal olmayan site için tek başına yeterlidir.
• Sentetik izleme. Gerçek bir kullanıcı akışını tarayıcıda taklit eder: giriş yapar, sepete ekler, form gönderir. Dönüşümün çok adımlı olduğu sitelerde anlamlıdır.
• Gerçek kullanıcı ölçümü. Ziyaretçilerin tarayıcısından veri toplar. Kesintiden çok bozulmayı ve yavaşlamayı gösterir, erişilebilirlik izlemenin yerine geçmez.
• Sunucu ve altyapı izleme. İşlemci, bellek, disk ve süreç durumunu takip eder. Kesintiyi haber vermek için değil nedenini bulmak için kullanılır.
• Hata ve günlük izleme. 5xx yanıtının hangi istekten ve hangi kod yolundan çıktığını gösterir. Onarım süresini asıl kısaltan katman budur.
• Durum sayfası. Kesinti anında müşteriye tek yerden bilgi verir ve destek yükünü düşürür.

Ücretsiz katmanların yeterliliği konusunda gereksiz bir çekingenlik var. Bu alandaki ücretsiz planlar tipik olarak sınırlı sayıda izleme noktası ve bir ila beş dakika arası kontrol aralığı sunar. Günlük birkaç yüz ile birkaç bin ziyaretçi arasındaki bir site için bu kombinasyon gerçekten yeterlidir, çünkü bu ölçekte belirleyici olan dakikalık hassasiyet değil kesintiden haberdar olmaktır.

Ücretli katmana geçmeyi gerektiren durumlar oldukça spesifiktir: bir dakikanın altında kontrol aralığı ihtiyacı, çok sayıda izlenecek adres, çok adımlı senaryo testi, telefon veya SMS ile uyarı, uzun süreli veri saklama ve sözleşmeye dayanak oluşturacak resmi erişilebilirlik raporu. Bu ihtiyaçların tek bir ortak paydası vardır: kesintinin dakikası ölçülebilir bir para karşılığına sahiptir.

Kategori seçiminden bağımsız tek bir kural vardır. İzleme sisteminizi izlediğiniz altyapının üzerinde barındırmayın. Aynı sunucuda, aynı veri merkezinde veya aynı sağlayıcının kesintisinden etkilenecek bir yerde duran izleme, kesinti anında sizinle birlikte susar.

Sık sorulan sorular

Yarım saatlik bir kesinti sıralamamı düşürür mü?

Bu ölçekte doğrudan bir sıralama kaybı beklenmez. Sunucu hatası dönen adresler bir süre dizinde korunur ve tarayıcı sağlıklı yanıt dönmeye başladığında tarama hızını kademeli olarak artırır. Gözlenebilir etki genellikle o dönemde yayınladığınız veya güncellediğiniz içeriğin geç fark edilmesidir.

Kaç saatlik kesintiden sonra dizin kaybı başlar?

Sabit bir saat eşiği açıklanmamıştır ve kriter de süre değildir. Belirleyici olan hatanın ısrarlı hale gelip gelmediğidir; sürekli sunucu hatası dönen adresler dizinden çıkarılır. Bu yüzden "kaç saat dayanırım" sorusu yerine "hata ne kadar sürede kalıcı olmaktan çıkar" sorusu doğru sorudur.

Bakım sayfasını 200 koduyla yayınlasam ne olur?

Tarayıcı o sayfayı sitenin gerçek içeriği olarak değerlendirebilir. Uzun bakımlarda bu, sayfanın asıl içeriğinin yerine bakım metninin işlenmesi riskini doğurur. 503 kullanmak bu riski ortadan kaldırır ve durumun geçici olduğunu doğru şekilde bildirir.

Ping kontrolü yeterli mi?

Değildir. Ping yalnızca makinenin ağda yanıt verdiğini gösterir. Web sunucusu yazılımı çökmüş, uygulama hata döndürüyor veya sertifika süresi dolmuş olabilir; bu senaryoların hiçbirinde ping başarısız olmaz. En az HTTP durum kodu kontrolü, tercihen sayfa içeriği kontrolü gerekir.

Aracım %100 uptime gösteriyor ama müşteriler şikâyet ediyor. Neden?

En olası üç neden şudur. Kontrol aralığınız kesintilerinizden uzundur ve kısa kesintiler ölçüm arasına düşmektedir. İzlediğiniz adres sorunlu adres değildir, örneğin ana sayfa çalışırken sepet hata vermektedir. Ya da ara katman hata sayfasını 200 koduyla döndürmekte, araç bunu sağlıklı yanıt saymaktadır.

Sunucum ayakta ama site açılmıyor. Bu kesinti sayılır mı?

Kullanıcı açısından evet. Alan adı çözümlemesindeki bir sorun, süresi dolmuş bir sertifika, yanlış yapılandırılmış bir dağıtım ağı veya bir yönlendirme döngüsü sunucu ayaktayken siteyi erişilemez yapar. Erişilebilirliği sunucunun durumundan değil kullanıcının gördüğü sonuçtan tanımlamak gerekir.

Kesinti izleme, altyapıyı daha sağlam yapan bir araç değildir; kesinti ile haber arasındaki süreyi ölçülebilir ve kısaltılabilir bir büyüklüğe çeviren bir disiplindir. Kurulumun kalitesini belirleyen soru "hangi aracı kullanıyorum" değil, "bu kurulum kesintiyi kaç dakikada ve kaç yanlış alarmla haber veriyor" sorusudur.